Refactoring

Share this post

Engineering principles, pair programming, smart generalists 💡

refactoring.fm

Engineering principles, pair programming, smart generalists 💡

Monday 3-2-1 — Edition #36

Luca Rossi
Feb 6
26
Share this post

Engineering principles, pair programming, smart generalists 💡

refactoring.fm
Article voiceover
1×
0:00
-5:22
Audio playback is not supported on your browser. Please upgrade.

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:

  • What is a Technical Program Manager 🗺️

To receive all the full articles and support Refactoring, consider subscribing if you haven’t already!

Become a better tech leader today ✨

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:

  1. 👌 A definition of what good looks like.

  2. 🗣️ 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 👇

Refactoring
Engineering Principles ⭐
Hey 👋 this is Luca! Welcome to a 🔒 weekly edition 🔒 of Refactoring. Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies. You can learn more about Refactoring here. To receive all the full articles and support Refactoring, consider subscribing 👇…
Read more
a year ago · 27 likes · 10 comments · Luca Rossi

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 👇

Refactoring
Pair Programming 👯‍♀️
There are well-known engineering practices everyone respects, and then there are secrets. Things that radically change the way you work, provide strong benefits to your team, yet few companies adopt. Secrets are often hidden in plain sight. They just look unappealing and…
Read more
a year ago · 12 likes · 2 comments · Luca Rossi

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.

Twitter avatar for @lucaronin
Luca Rossi ꩜ @lucaronin
@shl Well, this is true as long as you need to scale ~2x. To scale 10x you need specialists and processes. Can't escape that. The other problem with "generalism" is you always need incredible people. My take is: first 10 hires = incredible generalists, then scale vertically.
10:23 AM ∙ Jan 15, 2021
27Likes2Retweets

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 👇

Refactoring
The Three Stages of Engineering Teams 📊
Hey 👋 this is Luca! Welcome to a 🔒 weekly edition 🔒 of Refactoring. Every week I write advice on how to become a better engineering leader, backed by my own experience, research and case studies. You can learn more about Refactoring here. To receive all the full articles and support Refactoring, consider subscribing 👇…
Read more
2 years ago · 17 likes · Luca Rossi

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.

Get full access to Refactoring today ✨

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!

Share

I wish you a great week! ☀️

Luca

Share this post

Engineering principles, pair programming, smart generalists 💡

refactoring.fm
Comments
TopNewCommunity

No posts

Ready for more?

© 2023 Luca Rossi
Privacy ∙ Terms ∙ Collection notice
Start WritingGet the app
Substack is the home for great writing