The Context and the Logic

March 9, 2021

Soroush Khanlou:

As a professional programmer, there are two main types of tasks you work on. I’ve started thinking about them as the context and the logic. […]

This framing, context vs logic, illustrates two things for me:

First, that we all tell ourselves a lie: this job is primarily about the logic, interview candidates should mainly be tested on their ability to think about the logic, a “good” programmer is someone who can write the logic really well. In fact, an overwhelming amount of the job is making the context work. […]

I’m primarily a context programmer. I wish I weren’t — I enjoy writing the logic a lot more — but it is the reality. I should embrace that and treat the context as my job, rather than as an impediment to “my real job”.

Second, if you can make your context simpler and smaller, you can spend less time on it.

(Via Michael Tsai.)

Software Inventory

March 2, 2021

Joel Spolsky:

The “cost” of code inventory is huge. It might add up to six or twelve months of work that is stuck in the assembly line and not yet in customers’ hands. This could be the difference between having a cutting-edge product (iPhone) or constantly playing catchup (Windows Phone).

A great line when it was written in 2012, now aged to perfection.

The reason I’m linking to this article though, is the timeless wisdom about bug tracking that has stuck with me since the first time I read it:

At some point you realize that you’ve put too much work into the bug database and not quite enough work into the product.

  • Suggestion: use a triage system to decide if a bug is even worth recording.
  • Do not allow more than two weeks (in fix time) of bugs to get into the bug database.
  • If you have more than that, stop and fix bugs until you feel like you’re fixing stupid bugs. Then close as “won’t fix” everything left in the bug database. Don’t worry, the severe bugs will come back.

You’re Not Alone

March 1, 2021

Brent Simmons:

I don’t know about other senior developers, but I can tell you about me. I have decades of experience and an amount of wisdom. I’ve written some bad, some good, and a couple great apps over the years.

But I’m no Jedi.

Chris Liscio:

Despite my long history of writing (and debugging) pretty “hardcore” software for Mac and iOS, I still managed to miss a (now-)obvious red flag in my configuration.

We’re all just a bunch of dummies flailing about wildly out here!

Years ago a similarly “hardcore” developer told me that if he gets to lunchtime without realizing he made a colossally simple mistake, the day is a win. Count me in with him, Brent, and Chris: nobody knows it all, and sometimes we even miss things that we do know.

There’s a lot of peace to be found accepting that this happens to everybody.

Designing Languages and Libraries

November 14, 2020

I haven’t written much code in Swift. But as a C++ developer, I found John Sundell’s interview with Dave Abrahams (recommended by Michael Tsai) on the Swift by Sundell podcast fascinating.

Abrahams, on first encountering the C++ STL:

But there were no libraries. And when the STL came along, it really changed my life, because not only did it give me some tools that I could just use, but these tools were composable in a way that I had never seen before.


They were documented in a way that you could really use these components without looking inside them at their implementations. And they provided kind of a framework for thinking about a whole range of problems.

I never programmed in C++ without the STL being available. It’s so fundamental to my personal notion of ideal C++ code, I cannot imagine writing C++ without it.

On value semantics:

The other aspect of protocol-oriented programming that I left out was how it enables polymorphism with value semantics. And when I say value semantics I mean something very specific. There are functional programming languages where everything is immutable. And those are all values. But that’s not what I think of as interesting value semantics. Interesting value semantics is mutable value semantics.


One of the fundamental sources of bugs that we have in software today is shared mutable state. It’s terrible for threading, and it’s sort of an invitation to race conditions if you’re doing multi-threading. But it’s also just a source of bugs in regular code. I mentioned functional programming languages deal with this by making things immutable. Which is a really interesting approach, but it’s really costly. Because, the basic model of your machine is one with mutation. You’ve got a memory and you can write to it, right? So what happens when your language takes you a good distance away from the machine model? That means that the compiler has to do a huge amount of work to recover the efficiency of using the features of the machine.

If you are interested in language or library design, give this episode a listen.