About a year ago, a colleague reached out to me for some advice. He was a peer of mine and was receiving feedback from his manager that he wasn't meeting expectations. He suspected that I was faring a bit better within the organization and wanted my opinion on how he could improve.
Have you read The Zax, by Dr. Seuss? It's a powerful story. Ultimately it's about the dangers of stubbornness and pride. In the story, the north-going Zax and the south-going Zax both refuse to budge to the left or the right, neither wanting to concede anything to the other side. Each Zax wants the other Zax to be the one to step aside.
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.
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.
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.
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.
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.
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.
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).
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.