The Philosopher Developer

half-sound logic, half-decent code

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.

Logically...

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

The business goal
November 12, 2018

The team met up on Monday morning, as they always did to discuss the items in their backlog.

“Let’s talk about Alice’s ticket,” said Bob, the product owner. “Alice, the summary here says Configure auto-scaling. That sounds like a technical solution. Remind me, what’s the actual business goal there?”

Alice fidgeted in her seat, as all engineers do under the light of a business person’s attention. “Well, I guess it’s to make sure the system stays healthy under production load,” she managed to say. “If we don’t have enough workers to keep up with the queues, message processing could be delayed and eventually our servers might run out of memory and crash.”

Bob thought for a moment. “All right, so it sounds like if we don’t set up auto-scaling, we might not be able to handle peak traffic; is that right?” Alice nodded. “Then let’s update the summary on this ticket to Prepare the servers for peak traffic. I think that better captures the outcome we actually care about without being too prescriptive...

Read more

Information intoxication
October 18, 2018

I still remember the last time I got hopelessly inebriated. It wasn’t as long ago as I’d like to admit. But it was a turning point for me, a wake-up call to a grown man who shouldn’t be letting that happen. The details of the story aren’t really important, except for one: it started with the all-too-familiar mistake of drinking without having eaten dinner.

Anyone who’s made this mistake understands the ramifications. When your stomach is empty, a little bit of alcohol has much more of an impact than after you’ve had a full meal1. As a result it’s very easy to get drunk without meaning to when you haven’t eaten recently.

The relationship between food and alcohol in the context I’m describing is one of proportionality. Ideally a small amount of alcohol is preceded by a much larger amount of food. The alcohol provides a pleasant buzz, while the food acts as a buffer, protecting against some of the negative effects of the alcohol.

I have noticed that a similar relationship exists between...

Read more

The house with many rooms
August 26, 2018

Note: this post was published in 60 minutes.

There’s an analogy I’ve used many times to describe Bitbucket, both to my team as well as to outsiders. It works for Bitbucket but I think it works for plenty of other software projects I’ve worked on, and even for everyday life. Anyway, the analogy is this: Bitbucket is like a house with many rooms and only a small staff to maintain it. Some of the rooms are neat and tidy; but given the limited size of the staff, many of the rooms are a total mess.

When you first join the staff that maintains this house, you don’t have much context. You may have seen the house before. Maybe you’ve even been inside it for a social event, in which case you’ve probably seen the dining room, the living room, perhaps a bar area or a study. But you haven’t seen the attic, the cellar, many of the storage closets, etc.

So in your first few weeks, you find yourself discovering some of these rooms you’ve never seen before, and they’re messy and in poor condition...

Read more

Published in 60 minutes
August 08, 2018

I realized something recently: I share my ideas with people every day in 1-1 conversations; but the rate at which I share my thoughts in written form is much slower. Probably 100x slower. That’s not an exaggeration: in the past few years my rate of publishing posts on this blog is less than 2 per year. Meanwhile I have multiple conversations, both at work and outside of work, every day.

You’ve probably heard the expression “The perfect is the enemy of the good.” A big part of the reason for the discrepancy between the value I provide in 1-1 interactions1 vs. written communication is the amount of scrutiny I apply to the things I write versus the things I say. Meanwhile, the value of the information I share in written form is nowhere near 100x as valuable.

I suspect the phenomenon of diminishing returns kicks in very quickly for me with written communication. Most of the value is captured in the first 50% of time invested; the remaining 50% of time invested only improves the final result...

Read more

Next