These are just made up numbers. In our team, PR review is always 1 minute -- we never review, just approve, and let production reviews. /s
Every layer of review makes you 10x slower
231–240 of 339 posts
Re: Every layer of review makes you 10x slower
#232Earlier quoted context omitted.
Isn’t “bad output” already worst case? Pre-LLMs correct output was table stakes. You expect your calculator to always give correct answers, your bank to always transfer your money correctly, and so on.
> Isn’t “bad output” already worst case? Worst case in a modern agentic scenario is more like "drained your bank account to buy bitcoin and then deleted your harddrive along with the private key" > Pre-LLMs correct output was table stakes We're only just getting to the point where we have languages and tooling that can reliably prevent segfaults. Correctness isn't even on the table, outside of a few (mostly academic)…
> drained your bank account to buy bitcoin and then deleted your harddrive
These are what I meant by correct output. The software does what you expect it to.
> We're only just getting to the point where we have languages and tooling that can reliably prevent segfaults
This is not really an output issue IMO. This is a failing edge case.
LLMs are moving the industry away from trying to write software that handles all possible edge cases gracefully and towards software developed very quickly that behaves correctly on the happy paths more often than not.
Re: Every layer of review makes you 10x slower
#233Earlier quoted context omitted.
> You also need to build a team that you can trust to write the code you agreed you'd write I tell every hire new and old “Hey do your thing, we trust you. Btw we have your phone number. Thanks” Works like a charm. People even go out of their way to write tests for things that are hard to verify manually. And they verify manually what’s hard to write tests for. The other side of this is building safety nets. Takes ~1…
> I tell every hire new and old “Hey do your thing, we trust you. Btw we have your phone number. Thanks” That's cool. Expect to pay me for the availability outside work hours. And extra when I'm actually called
> Expect to pay me for the availability outside work hours.
We pay people enough to care about the software they ship.
Don’t want to be called outside of work hours? Make sure your code works. Simple.
Re: Every layer of review makes you 10x slower
#234Earlier quoted context omitted.
> The other side of this is building safety nets. Takes ~10min to revert a bad deploy. Does it? Reverting a bad deploy is not only about running the previous version. Did you mess up data? Did you take actions on third party services that that need to be reverted? Did it have legal reprecursions?
Having data model changes be a part of regular deployments would give me persistent heartburn.
It's why you always have a rollback plan. Every `up` needs to a `down`.
Re: Every layer of review makes you 10x slower
#235Code reviews are a volunteer’s dilemma. Nobody is showered with accolades by putting “reviewed a bunch of PRs” on their performance review by comparison with “shipped a bunch of features.” The two go hand-in-hand, but rewards follow marks of authorship despite how much reviewers influence what actually landed in production. Consequently, people tend to become invested in reviewing work only once it’s blocking their w…
Or the reviewer feels responsible for the output of the code from the person they are reviewing or the code they are modifying. For instance a lead on the team gets credit for the output of the team
Also, wanting to catch bugs on review before they make your on call painful can be a large motivation.
Re: Every layer of review makes you 10x slower
#236Earlier quoted context omitted.
> You also need to build a team that you can trust to write the code you agreed you'd write I tell every hire new and old “Hey do your thing, we trust you. Btw we have your phone number. Thanks” Works like a charm. People even go out of their way to write tests for things that are hard to verify manually. And they verify manually what’s hard to write tests for. The other side of this is building safety nets. Takes ~1…
> The other side of this is building safety nets. Takes ~10min to revert a bad deploy. Does it? Reverting a bad deploy is not only about running the previous version. Did you mess up data? Did you take actions on third party services that that need to be reverted? Did it have legal reprecursions?
> Does it? Reverting a bad deploy is not only about running the previous version.
It does. We’ve tried. No it’s not as easy as running the previous version.
I have written about this: https://swizec.com/blog/why-software-only-moves-forward/
Re: Every layer of review makes you 10x slower
#237Earlier quoted context omitted.
I'm very surprised by these comments... I regularly review code that is way more complicated that it should. The last few days I was going back and forth on reviews on a function that had originally cyclomatic complexity of 23. Eventually I got it down to 8, but I had to call him into a pair programming session and show him how the complexity could be reduced.
I know the aggravation of getting a hairball of code to review, but I often hold my nose. At least find a better reason to send it back, like a specific bug. If you're sure cyclomatic complexity should be minimized, I think you should put such rules in a pre-commit hook or something that runs before a reviewer ever sees the code. You should only have to help with that if someone can't figure out how to make it pass.…
I always approve a change with comments for nits that are optional to address. I only hold back approval if there is a legitimate flaw of some sort. Generally this leads to small changes almost always getting approved on the first shot, but larger changes needing at least one back and forth. AI code review tools make it much easier to spot legitimate problems these days.
Re: Every layer of review makes you 10x slower
#238Earlier quoted context omitted.
Anyone who talks about pair programming has either never done them or just started doing them last week.
My sense is that there is a narrow slice of software developers who genuinely do flourish in a pair programming environment. These are people who actually work through their thoughts better with another person in the loop. They get super excited about it and make the common mistake of "if it works for me, it will work for everybody" and shout it from the hilltops. Then there are the people who program best in a fugue…
I hope you mean "flow state" and not actually "fugue state".
Re: Every layer of review makes you 10x slower
#239Earlier quoted context omitted.
> 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 sou…
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 de…
> 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.
Re: Every layer of review makes you 10x slower
#240[dead]