The Philosopher Developer

half-sound logic, half-decent code

Focus time is not petty cash
June 27, 2020

Budgets are useful when you have a limited amount of something and discipline is required to use it appropriately given your needs and priorities.

For example, if you have a limited amount of monthly income (i.e. you are a normal person), a typical monthly budget would allocate a certain amount to your housing expenses, another amount to food, perhaps some more necessities (e.g. medicine, commuting to work), and then the remainder would be divided according to your preferences. One person might have a budget for dining out, another for travel, another for classes, etc.

A typical monthly budget might look something like this
A typical monthly budget might look something like this

Enforcing a budget requires categorizing every expense, which represents some administrative overhead. For sufficiently small expenses, the cost of this overhead could actually exceed the expense itself. As an optimization to reduce this overhead, a common practice among businesses is to budget some small amount of petty cash that can be used at individuals' discretion...

Read more

What can I do to help?
June 13, 2020

These past couple of weeks have been surreal. On the Bitbucket team, I have sensed ambient levels of sadness, frustration, and numbness as everyone makes an effort to be productive and contribute to their teams' projects, even while I’m sure many of us have had a voice in our heads asking how any of the work we’re doing matters in the shadow of the terrible systemic problems facing our society: police brutality, systemic racism, and a pandemic that is disproportionately killing the poor and underprivileged, just to name a few.

If you’re like me, something you may occasionally be experiencing is the sensation of being utterly useless. It is a strange feeling, recognizing that I am the beneficiary of an unjust system, wanting to contribute to a solution, while at the same time understanding that I have much to learn. As a software engineer, I am acutely aware that in a complex system, work that is well-intentioned but ill-informed is a deadly combination that often does more harm than...

Read more

What is a spike?
January 23, 2020

Many software teams use the term “spike” or “research spike” to refer to a particular type of task where the primary work involved is some sort of research or investigation.

You can find plenty of articles out there defining what a spike is and suggesting when it’s useful. This post comes from my own experience and proposes a pretty simple definition that, at least for me, makes the value of a spike perfectly clear. It also helps to avoid a common pitfall I’ve seen some teams fall into (including some of my own!), saving time and improving outcomes.

Two axes of measurement

A task that might be assigned to a software developer (or practically any worker) involves two characteristics: the scope of its requirements, and an estimate of the work required.

The requirements for a task, also sometimes known as acceptance criteria, tell the developer what the desired outcome of the task is. Sometimes requirements can be fairly broad. This is why it helps to talk about scope, which clarifies...

Read more

Software that explains itself
October 14, 2019

My first job as a developer was at a company called MP Capital, an algorithmic trading firm in Philadelphia. Our boss, an experienced trader, would present models to us and we would do our best to code them. Sometimes he would question why our models resulted in certain particularly risky trades. To help him understand cases like these, he asked us to build a feature that would provide a breakdown of every trade: essentially a record of the algorithm that triggered it, every step of the way. At the time I didn’t appreciate just how unique this was.

At Google, I remember the search team had something similar: a tool that could provide a rule-based explanation for why a given page was listed for a given profile at a given position in the search results.

More recently I’ve been working on a side project with a friend that involves scanning documents. The code is fairly complex in some areas; at times it’s unclear why it produces certain results. Again, I’ve found myself wanting the same...

Read more

The case for promoting over hiring
July 18, 2019

Here’s a little tip I received fairly early in my career. I’ve heard this in various forms from various people, but the following is a quote from a boss I had not too many years ago:

Operate as if you already have the job that you want and then you’ll be promoted and everyone will be surprised, thinking you had been in that role all along.

Good advice, bad guideline

For anyone who wants to be promoted, this is great advice. Getting a promotion is ultimately a matter of convincing someone—sometimes it’s your manager, sometimes it’s a committee—that you’ll be effective in a new role. And the easiest way to convince someone of something is always to do all of the work for them. Put another way, the advice says: Make the decision easy for your manager by making it for them. Go ahead and do the job you want, and then they won’t feel they’re taking a risk on you.

I recently wrote about advice vs. guidelines because I wanted to write about this topic. While the above tip is great advice

Read more

Advice vs. guidelines
June 21, 2019

It’s been a while! This is another 60-minute post.

Here’s a concept I often find myself mentally coming back to. I frequently want to use these terms in conversation, but I refrain because I am aware whoever I’m talking to doesn’t have a shared understanding of what I mean by these terms. So this is me writing it down so that I can link to it in the future.

Advice is a suggestion you give someone to be helpful to them as an individual.

Guidelines are instructions you give to everyone in a group, to be helpful to the group as a whole.

The key difference is in what you’re treating as constant. When you give advice, you aren’t trying to change the system; you’re just trying to help one person within the system. You take the system itself for granted. Advice is unopinionated about whether the system is good or bad.

Guidelines define how a system should be. When you define guidelines, you are trying to change the system. You’re writing down how you think things should work.


Read more

The Pit of Success
June 19, 2019

If you search for “pit of success” (a well-known concept in the software field, and perhaps in other fields) in Google, the first result is a blog post on Coding Horror by Jeff Atwood. In the post, he links to an MSDN article by Brad Abrams, which as far as I can tell is considered the seminal piece of writing on the topic (though the term itself was apparently coined by a CLR architect named Rico Mariani).

Unfortunately, if you visit the above MSDN blog today, you will see that it’s nearly unreadable due to a plethora of rendering artifacts. (My educated guess is that the MSDN blog network must have migrated from one blogging platform to another at some point, and the way the content is escaped clearly changed.) Perhaps this is infuriating to no one but myself; but I view it as a minor tragedy that such an important piece of writing is, in its current form1, so badly misfigured.

Therefore I’ve taken it upon myself to lovingly restore the original content to a more readable presentation...

Read more

Putting more thought into dependencies
February 06, 2019

In my time as an engineer I’ve had lots of conversations about software dependencies. I’ve been meaning to put my thoughts in writing for a while now—specifically about how I feel most teams, and in fact the industry at large, don’t put enough thought into how they manage dependencies—but it’s such a big topic that I’ve never found the energy to sit down and capture all of my opinions in writing, as doing so would likely take up an entire book.

With that in mind, I gave myself 60 minutes to just write down everything I could, and I used that as a first draft1. I’ve since made some revisions, but what follows is still a bit rough. It’s best to think of it as more a stream of consciousness than a buttoned-up treatise.

The biggest problem

Probably the biggest oversight that I see being made time and time again is that developers don’t appreciate the huge role that trust plays in their dependency strategy. We assume that the ecosystems we depend on are full of good, competent actors who...

Read more

The rolling cultural deployment
December 12, 2018

When we use the word “software” we’re really talking about two things. First there’s the code, which is essentially a set of instructions, or routines. But just as an instruction manual doesn’t magically accomplish a task, code by itself doesn’t do anything. It needs to run in an environment: all of the requisite pieces, both hardware (e.g. a PC or server) and software (e.g. an operating system), that the code needs to work.

A deployment is when you take software that’s running in a particular environment and you update its code.

Red is the old code. Blue is the new code.
Red is the old code. Blue is the new code.

One type of deployment is called a rolling deployment, where you update slices of the environment (for example, groups of servers) in sequence, so that until the deployment is over you have both old and new code running at the same time.

A rolling deployment. For a time, both old and new code are running.
A rolling deployment. For a time, both old and new code are running.

Rolling deployments tend to be good for reliability. They require no downtime, since some of the environment is...

Read more

Don't make me think
November 30, 2018

Note: This is another of those 60-minute posts.

Suppose I said to you, “Go read War and Peace and write me a 10-page book report on it.” What would you say? Probably something like Why? or Who do you think you are? or maybe just No. That’s a homework assignment, and there’s no reason I should be entitled to just give you a homework assignment.

Why isn’t it reasonable for me to give you a homework assignment? Because I’m not your boss1. And in civilized society, we don’t abide individuals just assigning arbitrarily large tasks to one another. It isn’t proper.

Notice I said “arbitrarily large tasks”; we actually are okay with assigning small tasks to each other. For example, almost no one thinks it would be audacious of me to say, “Hey, could you hand me that stapler?” Even if I were to blurt, “Give me that stapler!”—a significantly ruder way to say it—my suspicion is that most people would still give me the stapler, albeit with a bit of annoyance.

There is some sort of unspoken dividing...

Read more