3 ms·

Huge disagree on this. Old code tend to be much more terrible because the tools were terrible. They gave little incentive and absolutely no help to write even p

Huge disagree on this. Old code tend to be much more terrible because the tools were terrible. They gave little incentive and absolutely no help to write even passable code. We end up with a mess of poorly documented, sparingly commented spaghetti code that sometimes work, often by accident. Nowadays, we have linters to point out common classes of mistakes, programming languages with actual type systems to enforce invariants, integrated testing tools, etc... Note that, yes, we do still have new, terrible codebases. But at least the tooling nowadays raised the bar to have a minimum floor of quality that, while very low, is still oh so much higher than it used to be.

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 ago
    Reading every commit seems like the best short term way to maintain code quality and keep the whole project in your head?
  - com2kid 4y ago
    It 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.
TedDoesntTalk 4y ago
This is nonsense. The code quality is determined by the author, just like today. > Nowadays, we have linter I was using a C linter in 1986. The tooling is better now but it still comes down to the author.
- maestroia 4y ago
  I agree with the first sentence, and re: the second, also was using a C linter in 1986.
- Clubber 4y ago
  We had "coding standards," and if you didn't code it to the right format, you'd get fussed at. I didn't start professionally until the mid 90s, so I'm a little younger than the OP. I've been coding since the mid 80s though as a youngster. Putting BEGIN..END around a one line block was always a contention since it wasn't required. Less code vs arguably more readable code (Pascal) If BLA Then Begin DO STUFF End vs If BLA Then DO STUFF
- lmm 4y ago
  > The code quality is determined by the author, just like today. This is nonsense. The worst authors can still produce bad code with the best tools and the best authors can still produce good code with the worst tools, but most authors are somewhere in the middle, and tooling makes a huge difference to the average.

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 ago
  Reading every commit seems like the best short term way to maintain code quality and keep the whole project in your head?
- com2kid 4y ago
  It 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.

TedDoesntTalk 4y ago

This is nonsense. The code quality is determined by the author, just like today. > Nowadays, we have linter I was using a C linter in 1986. The tooling is better now but it still comes down to the author.

maestroia 4y ago
I agree with the first sentence, and re: the second, also was using a C linter in 1986.
Clubber 4y ago
We had "coding standards," and if you didn't code it to the right format, you'd get fussed at. I didn't start professionally until the mid 90s, so I'm a little younger than the OP. I've been coding since the mid 80s though as a youngster. Putting BEGIN..END around a one line block was always a contention since it wasn't required. Less code vs arguably more readable code (Pascal) If BLA Then Begin DO STUFF End vs If BLA Then DO STUFF
lmm 4y ago
> The code quality is determined by the author, just like today. This is nonsense. The worst authors can still produce bad code with the best tools and the best authors can still produce good code with the worst tools, but most authors are somewhere in the middle, and tooling makes a huge difference to the average.