Conceptual compression means beginners don’t need to know SQL — hallelujah!


It used to be a fundamental requirement that you learned an extensive amount of SQL before you were able to start working on database-backed applications. It was taken as self-evident that you needed to speak the native language of the database before you were qualified to use it. And better yet, you really ought to understand and care about your particular brand of database engine.

This is no longer so. That fact has snuck up upon us, but it’s none the less true — and that’s amazing.

Through advances in leaky abstractions, we’ve managed to compress the conceptual overhead of the database so much that it needn’t feature in the introduction material for making database-backed applications. In Rails, we call that abstraction Active Record, and it falls into the category of object-relational mappers (ORM).

The ORM was long derided by programmers as an unreliable, even harmful, aid of the lazy or the weak. Something Real Programmers shouldn’t expect to lean on, as it was likely to break down if not immediately, then certainly soon thereafter. And then you’d better know all your relational theory!

That’s the past.

Basecamp 3 has about 42,000 lines of code, and not a single fully formed SQL statement as part of application logic! It serves millions of people. It not only leans on the ORM abstraction, it hardly even thinks about it the vast majority of the time.

Do you know what else application programmers rarely need to think about any more either? Memory management and garbage collection. It used to be just as foundational to know your pointers, your destructors, your mallocs, and all the other conceptual overhead needed to deal with manually managing memory. Now it isn’t.

Our abstraction of SQL isn’t quite yet to the point of our abstraction of memory management, and certain frameworks and environments are further ahead than others, but it’s getting closer. The first version of Basecamp had a bunch of #find_by_sql calls, the latest have none. That’s progress.

It’s not that knowledge of SQL isn’t nice to have. It’s good to know a lot of things. Just like it’s helpful to have a strong conceptual model of how computers deal with memory management. It’s just that you no longer need to know these things to start making applications, and that’s a wonderful thing.

SQL, like memory management, is a concept you can unpack when you need to. Further down the line of your career. Then after you learn it, you can compress it back down again and spend more of your mental capacity on other things most of the time. I used to write SQL statements every day. Now maybe I do so once a month? Less? And that’s against a major application that’s reached a scale that most beginner apps never will.

Some programmers will scoff at this notion instinctively. That it’s simply irresponsible for programmers to start writing code until they know these historical fundamentals. I suppose it’s natural to think that all the hard work you spent learning the basic concepts — that indeed were required when you got started — should still be taught to all on day one. This is one of the key pitfalls of experience. Falling in love with the trials and tribulations you had to suffer, rather than rejoicing in the fact that the next generation doesn’t have to endure them.

The relational database is a glorious invention, but for most programmers it doesn’t need to be more than an appliance. Sure, take the time to learn how the drying tumbler machine works, it may well save you a service call to a specialized technician one day. But it’s hardly a requirement for living with such a device and getting your clothes dry.

The relegation to “appliance status” isn’t a dig, but an honor. It means we’ve finally made the technology and the abstraction so good that many, if not most, programmers don’t even have to think about it on a daily basis.

It also means it’s become a commodity. At Basecamp we happen to use MySQL, but to be honest, it’s basically only for historical and operational reasons. We could switch to PostgreSQL tomorrow, and I wouldn’t really give a damn. We have nothing in the application that relies on a particular brand of the database appliance.

Building stuff with computers means building on top of abstractions. CPUs, 1s and 0s, assembler, C compilers, database drivers, memory management, and a million other concepts are required to make our applications work. But as we progress as an industry, fewer people need to know all of them, and thank heavens for that.

It takes hard work to improve the conceptual compression algorithms that alleviate application programmers from having to worry about the underpinnings most of the time, but it’s incredibly rewarding work. The more effectively we compress the concepts of yesterday, the lower the barriers to entry become. And we need low barriers if we are to get more people started making applications.

SQL is perhaps the brightest example of conceptual compression over the past decade or so, but application work is full of other examples. And we need such conceptual compression more than ever to starve off specialization, and to preserve the power of individual generalists to make complete applications.

We’re currently living through an explosion of conceptual expansion and experimentation on the client-side in the web application world. That’s really exciting! Lots of new ideas and approaches churning rapidly. But it’s also needlessly intimidating in many ways. We don’t all need to spend hours or days learning how to configure build pipelines. Some day our leaky abstractions will be good enough that the conceptual compression will relegate such tooling to appliance status as well. That will be a good day.

You can’t learn everything. You can’t hold every concept fully expanded in your head. And moreover, you shouldn’t. As we compress formerly fundamental concepts, we make room for new, grander abstractions. These are the leaps of progress it’ll take to continue to make us more efficient and ultimately more effective.

But I get that it’s hard to break habits. Like the stereotype of an old person complaining about the price of gas or a gallon of milk because their frame of reference is anchored in a time past. Broad-based progress sometimes need that generational churn to really happen (and that’s not about your physical age, rather the years of experience).

Don’t be a fogey. Don’t fight the conceptual compression. Help make it happen.

Ignorance got a bad rap

One of the best skills to develop as an entrepreneur? Ignorance.

I think a lot of folks are spending way too much energy trying to know it all. They’re trying to be over-informed. Soaking up every piece of advice. Following every story, watching every video. Trying to understand too many things about how things currently work. Who’s doing what, what the latest techniques are, which list of steps to follow, etc.

They’re collecting mentors, stories, anecdotes. They’re asking for 15 minutes to pick people’s brains. They’re queuing up dozens of podcasts, looking for that one quote, that one piece of sage wisdom that’ll make everything make sense.

Stop it.

You’ll make something new when you’re new. You’ll make something also when your mind is filled with other people’s ideas.

Certainly other people’s experiences and ideas can help you avoid missteps. There’s some value in avoiding a mistake, but it’s more costly to close your mind to a possibility because someone else tried it and it didn’t work.

And further, the more you know, the more likely you’ll be to talk yourself out of it. The deeper you get, the more things you begin considering. As the knowledge piles up, it becomes a heavier burden to take the first step.

So go on, be ignorant and just make something. Ignorance is bliss, but sometimes it’s even better business.

How I became (and stayed) a successful programmer

3 strategies that have been crucial to the longevity of my programming career

For a while now, interest in programming has been skyrocketing. So there are a lot of beginners out there starting their careers — and that’s a wonderful thing!

If you’re one of those beginners, eventually you may start thinking about the long-term prospects of your new skills: How do I take a new skill like programming, grow it, shape it, and tune it over time so I can achieve longevity in the industry?

I asked myself that same question early on in my career. Now, a mere 15 years into it, I’m hoping I can give you some answers.

Below are a few general strategies that have helped me become (and stay) a successful programmer over the long haul.


1. I surround myself with programmers who are way better than me

Over the course of my career, I’ve always tried to pick work where the people I’d be working with are exceptionally talented. To put it more bluntly, I put myself in the company of programmers who were way better than me.

This is crucial, because the best way to improve (at anything) is to learn from people better than you. It might be a nice ego boost if you know more than everyone around you, but you’re otherwise just flat lining your actual progress.

When I’m around these talented programmers, I constantly keep my eyes and ears open for nuggets of wisdom. I watch how my fellow programmers carry themselves, how they breakdown a problem, how they talk to each other. I look at their code for patterns and style choices that I can mimic. I remind myself to talk less and to listen more.

Unless you’re the Michael Jordan (or dare I say the LeBron) of your respective field, there should always be someone better than you — this is a good thing!

You have nothing to lose and everything to gain in such a situation. Take advantage of it. 🚀


2. I occasionally leave my comfort zone

I’ve found it beneficial to leave my programming comfort zone once in a while. It helps me think differently by challenging a bunch of established ideas I already have.

For sure, you don’t want to do this constantly because it can be hard to get into a rhythm with your normal area of work. But in moderation it can really open your mind to new ways of thinking.

For example, my comfort zone is Java and Android. But over the last year, I’ve taken on stuff well outside that zone:

  • I helped build an open-source framework. Turbolinks Android was the first time I’d ever worked seriously with Turbolinks (new tech to me), it was my first open-source project ever (new process for me), and it was a cornerstone for Basecamp 3 for Android (a new product for the company). It was one of the hardest projects of my career!
  • I started writing Kotlin instead of Java. I’d been writing Java for over a decade, so picking up a new langauge was no trivial task. Not to mention I’d never written a single line of Kotlin previously! But before I knew it I jumped in head first and am now writing Kotlin most of the time. (Incidentally, I’m completely in love with the language!)
  • I’m learning the underpinnings of our open source rich text editor. By learning the ins and outs of Trix, our Android team will be able to better utilize its capabilities now and in the future. But as someone who isn’t totally up to speed on advanced Coffeescript and DOM manipulation, this has more or less melted my brain. But I shall prevail!

Here’s what’s important to remember — none of this stuff was particularly easy or comfortable for me. In fact much of it was downright uncomfortable, nerve-wracking, and filled with doubt. At times I literally felt like I had no idea what I was doing.

But as challenging as they were, I did them anyway because I knew how valuable those experiences would be . They gave me the opportunity to work with a variety of the programmers, let me reacquaint myself with technologies I’d fallen behind with, and let me learn brand new stuff that few others in the company got to. All of that made me a better programmer.

So find a programming task that takes you out of your comfort zone and make it your next project. Then watch it pay off in spades. 💰


3. I value being independent

When you’re just starting out, you’re going to have a lot of questions. That’s OK!

What’s most important is how you choose to find the answers to your questions.

One philosophy that’s always served me well is to be independent. Usually this means that I’ll try to do most things myself first, and only when I really get stuck, I’ll ask for help.

Being independent has tons of benefits, but to name just a few…

  • You learn how to be resourceful. Finding answers may just be one Google result away, or it might take a dozen different queries. You might have to patch together 5 different solutions that you’ve found to work together. Who knows. Finding the answers you need on your own is a skill that’ll serve you well for years.
  • You earn respect by being courteous of other people’s time and work. When you prioritize your independence, working with other programmers is easier. They’ll appreciate that you’ve done a lot on your own and have taken it as far as you can before asking for help. By respecting other people’s time and work, you’ll earn respect back. And mutual respect is the cornerstone for trust and solid teamwork.
  • You start developing your creativity. When you need to come up with answers, you’ll find yourself coming up with creative solutions you hadn’t considered. You’ll try things that seem crazy and out of the realm of possibility. Some will work and some won’t, but you’ll begin to develop a palette of creative solutions that you can draw from many times down the road.

The next time you have a burning question, see if you can answer it yourself, even if it takes a little longer than asking someone. It’ll be worth it.🔥❓✔️


Becoming a successful programmer is, like anything worthwhile, hard work. But these strategies have always served me well in the long run — after all, I ended up getting my dream job working at Basecamp. I hope they can help you get to where you want to be, too. 😀

I hope this article was helpful to you! If so, please do hit the heart button below and let me know on Twitter.

We’ve been working really hard to make the all-new Basecamp 3 and its Android app as great as they can be. Check ’em out, we hope you love them.