3 ms·
> Huge disagree on this. Old code tend to be much more terrible because the tools were terrible. I've looked at 1990s code in the Windows NT kernel. It was won
by com2kid 4y ago
> Huge disagree on this. Old code tend to be much more terrible because the tools were terrible.
I've looked at 1990s code in the Windows NT kernel. It was wonderful.
Oldest source file I went through was from 1993. Perfectly readable and understandable.
One of the best modern code bases I ever worked in didn't even have a linter setup. The principle dev reviewed every single commit and enforced a consistency across the code base that was better than what any tools ever could have done.
- twright0 4y ago> The principle dev reviewed every single commit and enforced a consistency across the code base that was better than what any tools ever could have done. How was it so much better that it justified that level of busywork on the part of the senior member of the team (and busywork for everyone else, to fix the style nits they enforced in review)? I would have guessed that taking a few hours to install and configure a formatting linter to free up the principal dev's time to focus on other things would have been hugely high leverage.
- beckingz 4y agoReading every commit seems like the best short term way to maintain code quality and keep the whole project in your head?
- com2kid 4y agoIt ensured not only consistency of style, but also consistency of ideas. Every file was structured similarly, impedance mismatches were minimized, work across the entire code base was organized and unified. Junior engineers got a chance to talk to the principle developer about every commit they made, and accordingly their abilities as software engineers skyrocketed. Developers quickly set their IDEs to follow the team's coding guidelines, style wasn't really a problem.