Engineering principles, pair programming, smart generalists 💡
Discover more from Refactoring
Engineering principles, pair programming, smart generalists 💡
Monday 3-2-1 — Edition #36
Hey, Luca here! Welcome to the Monday 3-2-1 ✨
Every Monday I will send you an email like this with 3 short ideas about engineering management, technical strategy, and good hiring.
You will also receive the regular long-form one on Thursday, like the last one:
To receive all the full articles and support Refactoring, consider subscribing if you haven’t already!
p.s. you can learn more about the benefits of the paid plan here.
1) 🌟 Principles are about making good decisions
Many companies do not invest in creating a set of engineering principles, because they are confused as to why they should be useful.
My simple answer for that is that principles describe how decisions should be made.
Why does that matter?
Without principles, you might meet goals in a way that doesn't reflect your culture.
Engineers might deliver features... without peer review.
Managers might meet deadlines... by making people overwork.
Teams might go fast... by cutting corners on security and accessibility.
Principles are a set of shared beliefs that create alignment over how you do things in your company.
They are, simultaneously:
👌 A definition of what good looks like.
🗣️ A shared language to be used in daily work.
By creating alignment, they enable productive autonomy.
You can find more ideas about how to create good principles in this previous article 👇
2) 👯 Pair programming is productive
There is convincing research that pair programming is just as productive as regular programming — that is, two developers working on separate tasks — if not more.
For three reasons:
Less distractions — two people are less likely to get distracted and lose focus than one. That short trip to Instagram doesn't look all that appealing when there is someone else looking at your screen.
More awareness — when working for several hours on some problem, you might dig yourself into a rabbit hole and lose the correct perspective of the main task. This is also called yak shaving. Remember that time you spent all the afternoon on a bug and then fixed it in 10 minutes the morning after? This wouldn't probably happen in a team of two.
No code reviews — this is one of the factors I like the most: all the code is automatically reviewed. No further PRs to interrupt your productivity. Also, chances are this kind of review is way better than your usual PR.
These factors were also demonstrated in the paper "The Costs and Benefits of Pair Programming". Cockburn and Williams showed that the immediate, raw output of a programming pair is only 15% smaller than that of two independent developers.
This 15% is easily repaid down the line by the improved code quality, automatic knowledge sharing, less turnover, and team growth.
More ideas on why pair programming is useful and how to implement it in your team 👇
3) 🤹♂️ In small teams, just hire generalists
When you are starting a company and your team is <10 people, you should probably hire just smart generalists.
At this stage you are figuring out what to build and how to build it. You can't really anticipate what you will do, both in terms of tasks, and tech.
For this reason, surround yourself of generalists who are happy to build pretty much anything.
Generalists are open, they don't bother switching tech, throwing in some no-code tools, and doing whatever it takes to deliver the product.
On the other side of the spectrum, you probably don't want someone who is heavily invested in some specific technology, as they will try to use it no matter what, because they feel their career depends on that.
As your team grows, you get to a point where this generalist stage breaks, usually for two reasons:
📣 Communication — in a larger group of people, “everyone does everything” makes it hard to organize work properly.
📚 Skills — tech becomes more complex and it requires specific skills to move forward.
One year ago I wrote an article about the three stages of engineering orgs, where I cover how your team structure will likely change with scale 👇
And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:
1) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. You can learn more about the benefits of the paid plan here.
2) ❤️ Share it — Refactoring lives thanks to word of mouth. Share the article with your team or with someone to whom it might be useful!
I wish you a great week! ☀️
Luca