Lightnews — Scholar-powered news

Allen Holub

@allenholub.bsky.social

3.6K followers 130 following 1.2K posts

Author, international speaker, consultant, software architect, kitchen-sink wrangler.

Posts Media Videos Starter Packs

Allen Holub @allenholub.bsky.social · 11h

Thanks!

Allen Holub @allenholub.bsky.social · 20h

just visiting. was in copenhagen last week & decided to get out of the airport on the way home

Allen Holub @allenholub.bsky.social · 21h

Amsterdam!

Allen Holub @allenholub.bsky.social · 2d

IME, it's best to do that by working collaboratively when you write the code—ensemble (or in a pinch, pair) programming solves the problem nicely. If remote is an issue for you, both ways of programming work fine in a remote environment.

Allen Holub @allenholub.bsky.social · 5d

Consequently, they usually focus on trivia like formatting. That benefits nobody.
11/11

Allen Holub @allenholub.bsky.social · 5d

I *really* don't buy that. An isolated reviewer doesn't understand the context. They don't know why design decisions were made. They have to waste a vast amount of time coming up to speed. They are also often not in a position to know whether the code will actually work.
10/11

Allen Holub @allenholub.bsky.social · 5d

If you're working in a regulatory environment, the Driver signs the code, and then any other member of the mob/ensemble can sign off on the review, all as part of the commit/push process, so that's a non-issue. There's also a myth that it's best if the reviewer is not familiar with the code.
9/11

Allen Holub @allenholub.bsky.social · 5d

they don't bother to track them. When a bug comes up, they fix it. Right then and there.
8/11

Allen Holub @allenholub.bsky.social · 5d

One of the teams at Hunter Industries, which mob/ensemble programs 100% of the time on 100% of the code, went a year and a half with no bugs reported against their code, with zero productivity hit. (Quite the contrary—they work very fast.) Bugs are so rare across all the teams, in fact, that
7/11

Allen Holub @allenholub.bsky.social · 5d

I will grant that two or more sets of eyes on the code leads to better code, but in my experience, the best time to do that is when the code is being written, not after the fact. Work in a pair, or better yet, a mob/ensemble.
6/11

Allen Holub @allenholub.bsky.social · 5d

They DO create bottlenecks, dependencies, and context-swap overhead, however, and all that pushes out delivery time and increases the cost of development with no balancing benefit.
5/11

Allen Holub @allenholub.bsky.social · 5d

You review everything you look at, and when you find issues, you fix them.

My experience is that PR-driven reviews rarely find real bugs. They don't improve quality in ways that matter.
4/11

Allen Holub @allenholub.bsky.social · 5d

Furthermore, you are reviewing the code in a real-world context, not in isolation, so you are better able to see if the code is suitable for its intended purpose. Continuous review, of course, also leads to a culture of continuous refactoring.
3/11

Allen Holub @allenholub.bsky.social · 5d

That is, continuous review is better than what amounts to a waterfall review phase. For one thing, the reviewer has a vested interest in assuring that the code they're about to use is high quality.
2/11

Allen Holub @allenholub.bsky.social · 5d

Last night, I was chatting in the hotel bar with a bunch of conference speakers at Goto-CPH about how evil PR-driven code reviews are (we were all in agreement), and Martin Fowler brought up an interesting point. The best time to review your code is when you use it.
1/11

Allen Holub @allenholub.bsky.social · 14d

The concept comes from Holacracy [https://www.holacracy.org/blog/why-consent-is-better-than-consensus/]. 2/2

Allen Holub @allenholub.bsky.social · 14d

With consensus, everybody has to agree. With consent, you don't have to agree that a particular solution is better, but you can still give your consent to try it as an experiment. If that solution doesn't work out, the assumption is that you'll back it out and try the other one. 1/2

Allen Holub @allenholub.bsky.social · 14d

Finally, it's never a good idea for a manager to decide—that's just seen as taking sides. It's the manager's job to help the team make decisions, not to make the decision.
11/11

Allen Holub @allenholub.bsky.social · 14d

That tends not to happen with a collaborative team. The team will collectively correct the problem. If everybody's in the habit of making collaborative decisions (with consent, not consensus), then the unhelpful sorts of arguments (e.g., personal) tend not to happen.
10/11

Allen Holub @allenholub.bsky.social · 14d

It's also important to realize that argument, in and of itself, is a good thing. A psychologically safe environment is one in which it's not only okay to disagree without repercussions, but it's encouraged. The problem is the argument devolving into the personal.
9/11

Allen Holub @allenholub.bsky.social · 14d

Also, it requires the team to be in a position to make the decision, so it encourages a culture of learning. Siloed skills are never a good idea, in my experience. They do nothing but create dependencies, bottlenecks, delays…, and ineffective arguments.
8/11

Allen Holub @allenholub.bsky.social · 14d

Not only does it remove ego from the equation, but it also requires the people with the ideas to clarify those ideas to the point where they can be effectively presented. The team uncovers any fuzziness.
7/11

Allen Holub @allenholub.bsky.social · 14d

(3) I find that it's best if the final decision not be made by either of the people who are arguing. You get better results if both people present their case to the team as a whole, and the team makes a collaborative decision.
6/11

Allen Holub @allenholub.bsky.social · 14d

When I explained the same technique they were using now, his response was: "Damn, I had hoped that they'd figured out a better way to do that by now!" He would have been overjoyed if I knew something he didn't, "junior" or not.
5/11

Allen Holub @allenholub.bsky.social · 14d

In my very first interview out of school, the team lead (he was not a boss—a sure sign of a good leader) asked me if I knew how to do something.
4/11