Pair-Programming

The first time I watched a senior engineer tear apart a junior’s pull request, I didn’t say anything. The feedback was technically correct. Every comment pointed to a real issue, a naming convention, an edge case, a slightly inefficient pattern. Nothing was wrong with the review itself.

Everything was wrong with how it landed.

The junior didn’t submit another PR for three days. When they did, it was half the size it should have been, over-engineered in the places where the senior had left comments and under-thought everywhere else. They’d learned a lesson, but not the one we wanted them to learn. They’d learned that code review was a test you could fail.

Last Tuesday I mass-deleted a hundred lines of Python that I’d spent two days writing. Not because the code was bad. It was actually pretty elegant, if I say so myself. I deleted it because I realised I’d spent two days solving a puzzle that I should have handed to my team on Monday morning.

I love solving puzzles. That’s the problem.

The early days are different

When you’re a co-founder getting an idea off a whiteboard and into a working demo, you should be writing code. You should be writing CI pipelines. You should be debugging at 11pm with a cold coffee next to your keyboard. You should be doing devops, handling support tickets, and deploying on Fridays because there’s nobody else to do it.