Processes are a prerequisite for high-performance in software engineering teams due to their ability to amplify the skill of the team. I believe there exists no team, given that there is little to no process to begin with, whose performance could not be improved by adding appropriate process.
Engineering Managers (EMs) are sometimes said to be “shit umbrellas”. They are supposed to keep all the distractions away from the team: the short-lived whims and fancies of various stakeholders, vague plans that are going to change several times before being solidified — all that stuff. Distractions are poisonous to good software, so hiding them should help the team deliver more and better software. A large part of this is true.
However, I would like to argue here that behaving like an umbrella is probably not a good thing. Umbrellas are shields that block rain. And what are these EMs blocking? Hopefully distractions, but also information and reality.
In this article I’m going to take a look at software quality as a way to differentiate between junior, mid-level, and senior software engineers, through the lens of failure demand, purely so that I can introduce a new concept that I thought up on a walk today, which I’m calling negative failure demand.
In part two of this series, we’re going to look at how the must-have priority bucket leads engineering to make bad decisions.
Categorising requirements into buckets like “must-haves” and “nice-to-haves” is a common approach to prioritisation in software projects. In my opinion, this is a bad way to priortise work, for reasons which become clear when you look at the incentives it produces.
A recent shower thought of mine is that agile software development might be similar to the strategic concept of a glass cannon in gaming — specifically, that it’s a high-risk high-reward strategy where the risk can be mitigated by skill/experience.
If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.
— Sun Tzu, The Art of War
Applying for a junior engineering position, or any job, is an exercise in marketing and sales. You are the product, and the employer is a potential customer. To market and sell anything effectively, you need to understand how the customer thinks.
In this article, I want to explore a bit of employer psychology when it comes to hiring juniors, and give some suggestions that I believe increase your chance of success.
When is “measure twice, cut once” bad advice?
One of my hobbies is complaining about the tendency of software developers to view choices as binary, moralistic decisions. Measuring twice is obviously correct, and anyone who doesn’t do it is an unprofessional, evil wood waster. Either that or double measurers are a bunch of know-nothing shysters selling snake oil for exorbitant consulting fees. This black-and-white thinking is a mental shortcut that many animals take, but sometimes it’s nice to apply a little more intellectual rigour than a Pomeranian.
I’d like us to think less in terms of right and wrong when it comes to technical decisions, and think more in terms of context, costs and benefits.
It’s that time of year again. It seems like about once a year I get interested designing a schema library. This post is a collection of my latest ideas and design goals, mostly based on what I’ve learnt from the previous three or four implementations.
This topic is probably interesting to a tiny subset of developers, and super boring to everyone else. I’ve tried to write this post in a way that is accessible to a wider developer audience, but you have been warned!
This is a quick look at the recent CI/release automation I wrote for the byebug-skipper gem.
Config for standard-version, which is what bumps the version and updates the changelog using the commit history.
CI step that ensures commit messages have the correct format