Every layer of review makes you 10x slower
apenwarr.ca473 points by greyface- 17 hours ago
473 points by greyface- 17 hours ago
But you can’t just not review things!
Actually you can. If you shift the reviews far to the left, and call them code design sessions instead, and you raise problems on dailys, and you pair programme through the gnarly bits, then 90% of what people think a review should find goes away. The expectation that you'll discover bugs and architecture and design problems doesn't exist if you've already agreed with the team what you're going to build. The remain 10% of things like var naming, whitespace, and patterns can be checked with a linter instead of a person. If you can get the team to that level you can stop doing code reviews.
You also need to build a team that you can trust to write the code you agreed you'd write, but if your reviews are there to check someone has done their job well enough then you have bigger problems.
This falls for the famous "hours of planning can save minutes of coding". Architecture can't (all) be planned out on a whiteboard, it's the response to the difficulty you only realize as you try to implement.
If you can agree what to build and how to build it and then it turns out that actually is a working plan - then you are better than me. That hasn't happened in 20 years of software development. Most of what's planned falls down within the first few hours of implementation.
Iterative architecture meetings will be necessary. But that falls into the pit of weekly meeting.
That's actually one thing that always prevented me from following the standard pathway of "write a design document first, get it approved, then execute" during my years in Google.
I cannot write a realistic non-hand-wavy design document without having a proof of concept working, because even if I try, I will need to convince myself that this part and this part and that part will work, and the only way to do it is to write an actual code, and then you pretty much have code ready, so why bother writing a design doc.
Some of my best (in terms of perf consequences) design documents were either completely trivial from the code complexity point of view, so that I did not actually need to write the code to see the system working, or were written after I already had a quick and dirty implementation working.
That’s why I either started with the ports and adapters pattern or quickly refactored into it on spikes.
You don’t have to choose what flavor of DDD/Clean/… you want to drink, just use some method that keeps domains and use cases separate from implementation.
Just with shapes and domain level tests, the first pass on a spec is easier (at least for me) and I also found feedback was better.
I am sure there are other patterns that do the same, but the trick is to let the problem domain drive, not to choose any particular set of rules.
Keeping the core domain as a fixed point does that for me.
It’s a muscle you can exercise, and doing so helps you learn what to focus on so it’ll be successful. IME a very successful approach is to focus on interfaces, especially at critical boundaries (critical for your use case first, then critical for your existing design/architecture).
Doing this often settles the design direction in a stable way early on. More than that, it often reveals a lot of the harder questions you’ll need to answer: domain constraints and usage expectations.
Putting this kind of work upfront can save an enormous amount of time and energy by precluding implementation work on the wrong things, and ruling out problematic approaches for both the problem at hand as well as a project’s longer term goals.
> Most of what's planned falls down within the first few hours of implementation.
Pair programming 100% of also works. It's unfortunately widely unpopular, but it works.
The problem is that you can only meaningfully pair program with programmers. The people involved in architexture/design meetings might not be programmers. The questions that arise when 2 programmers work might not be resolvable without involving the others.
Nonsense. I pair all the time with stakeholders. If you strip out all of the cucumber nonsense this is essentially what BDD is - fleshing out and refining specs by guiding people through concrete, written example scenarios.
I also often pair with infrastructure people on solving a problem - e.g. "im trying to do x as per the docs, but if you look at my screen i get an 1003 error code any idea what went wrong?".
Or, people on a different team whose microservice talks to mine when debugging an issue or fleshing out an API spec.
It's true that this isnt possible in plenty of organizations due to the culture, but lots of organizations are broken in all sorts of ways that set piles of cash on fire. This one isnt unique.
I also think we're going to see a resurgence of either pair programming, or the buddy system where both engineers take responsibility for the prompting and review and each commit has 2 authors. I actually wrote a post on this subject on my blog yesterday, so I'm happy to see other people saying it too. I've worked on 2-engineer projects recently and it's been way smoother than larger projects. It's just so obvious that asynchronous review cycles are way too slow nowadays, and we're DDoSing our project leaders who have to take responsibility for engineering outcomes.
For anything complicated or wide in scope, we've found it much more productive to just hop on a call and pair.
I’ve started pair programming with Claude and it’s been pretty fun. We make a plan together, I type the code and Claude reviews it. Then we switch.
You’ve made the analogy but I don’t think you’re actually doing an analogous thing. I think you’re just talking about code review.
Maybe it's time to do pair agentic engineering? Have two engineers at the screen, writing the prompts together, and deciding how to verify the results.
You are exactly correct. As to why it’s unpopular, I believe it’s just that no one has given it a fair try. Once you have done it for at least 20 hours a week for a few weeks you will understand that typing is not and has never been the bottleneck in programming. If you have not tried it then you cannot have an opinion.
> You are exactly correct. As to why it’s unpopular, I believe it’s just that no one has given it a fair try. Once you have done it for at least 20 hours a week for a few weeks you will understand that typing is not and has never been the bottleneck in programming. If you have not tried it then you cannot have an opinion.
I haven't tried pair programming except in very ad-hoc situations, but doing it all the time sounds utterly exhausting. You're taking programming, then layering on top of it a level of constant social interaction over it, and removing the autonomy to just zone out a bit when you need to (to manage stress).
Basically, it sounds like turning programming into an all-day meeting.
So I think it's probably unpopular because most software engineers don't have the personalty to enjoy or even tolerate that environment.
Yeah, I’d have a mental breakdown within weeks if I had to pair more than an hour a day, max (even that much, consistently, would probably harm my quality of life quite a bit—a little every now and then is no big deal, though). No exaggeration, it’d break me in ways that’d take a while to fix.
[edit] I’m not even anti-social, but the feeling of being watched while working is extremely draining. An hour of that is like four hours without it.
Well as the person you are replying to said, it's hard to have an opinion when you haven't actually tried it. I don't find it like that at all. Also, it doesn't mean you get NO solo time. Pairs can decide to break up for a bit and of course sometimes people aren't in leaving your team with an odd number of people, so some _has_ to solo (though sometimes we'd triple!)
But it's something you have to work at which is definitely part of the barrier. Otherwise, saying it sucks without giving it a real try is akin to saying, "I went for a run and didn't lose any weight so I feel that running is exhausting with no benefit."
> Well as the person you are replying to said, it's hard to have an opinion when you haven't actually tried it. I don't find it like that at all.
I don't need to try pair programming because I know how that level of constant social interaction makes me feel.
> Otherwise, saying it sucks without giving it a real try is akin to saying, "I went for a run and didn't lose any weight so I feel that running is exhausting with no benefit."
No, what you're doing is sort of like if you're raving about the beach, and I say I don't like bright sun, and you insist I need to try the beach to have an opinion on if I like it or not.
I wouldn't call "work" social interaction but I get ya. It's my biggest pet peeve of this industry: it has a whole lot of people who just don't want to talk to anyone. It is what it is, though.
> I wouldn't call "work" social interaction but I get ya.
IMHO, social interaction is anything where you interact with other people.
> It's my biggest pet peeve of this industry: it has a whole lot of people who just don't want to talk to anyone.
That's very black and white thinking. I like talking to other people, but too much of it is draining. Every day spending all-day or even a half-day working directly with someone else? No thanks.