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
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.
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...
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...
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.
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.
Rolling deployments tend to be good for reliability. They require no downtime,
since some of the environment is...
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.
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...
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...
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...
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...
