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
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...
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...
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...
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...
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.
