4 ms·

That thing about 'you had to do more thinking up front, so you wrote better code' is total nonsense. Maybe the guy he interviewed; there rest of us were struggl

That thing about 'you had to do more thinking up front, so you wrote better code' is total nonsense. Maybe the guy he interviewed; there rest of us were struggling with wasted runs because of syntax errors, cards out of order, worn cards that didn't read right...a total waste of human life. Terminals meant you could iterate 10X to 100X faster. Which was the whole ball game right there. Because iterating wasn't (mostly) about thinking; it was about bookkeeping, typing. Expecially on a keyboard that operated a cardboard-punch-device that rattled and shook and jammed.

JohnMakin 3y ago
This article didn't say it produced better code. It said it forced him to think carefully about what he was doing before he input the code to the system, which made him a better programmer. This is very plausible. Lots of people, especially beginners, love to just spaghetti their way to a solution rather than taking 30 seconds to think about what they're trying to do and if this is the best way of doing it.
- drpixie 3y ago
  And make people better programmer it did :) It's very usual now (and for the last 20-30 years) to see programmers live a loop of more-or-less randomly change code and see if it runs, repeat... Their code will eventually run, and pass the tests, but will be terrible - not understandable, inefficient, and break when confronted with reality or better tests. When it was quicker and easier to think about the code, than play with it, people generally produced higher quality code.
- bregma 3y ago
  I think the word you're looking for is 'agile'.
eloisant 3y ago
I have the feeling that we've had a constant increase in productivity, but the expectations keep being adjusted to take that into account. We have more powerful tools now, but instead of having it easy we are constantly asked to do more in a shorter time.
- ghaff 3y ago
  I've often thought how frustrating it would be to go back to my first job as a product manager for large computer systems. I would find the inability to get anything approaching current information really annoying. Of course, everyone else would be in the same boat. I'm sure some coursework and jobs would look a lot more similar than others. But we also take a lot for granted.
stcredzero 3y ago
That thing about 'you had to do more thinking up front, so you wrote better code' is total nonsense. It's not total nonsense. However, people take it too far. The point is, does the candidate use their brain when using the tool, to use it to its full advantage? There's a big difference between programmers who: - Just mindlessly step through the debugger - Do some groundwork so they know where to step - Has devious tricks, like writing a "tripwire" to activate a special debugging version, and has the program find the bug. So I find people who have this bias against debuggers just silly. It's not the tool that's the deciding factor. It's the programmer! The same goes for writing new code and refactoring existing code. Does the programmer exercise their brain to utilize the tool to its fullest extent? The same even goes for prompt engineering and otherwise leveraging AI. One shouldn't just stop at the surface level of analysis. Look for underlying principles. Try to get to first principles!
mwbajor 3y ago
I didn't read the whole article but it is similar to what my mom told me. My mom worked for AT&T in the late 60's early 70s as one of the girls that would take your program and make the punch cards or take your punch cards and run them. She also said that you just checked it over as much as possible and got good at not making many mistakes because of how tedious it was. From what I recall, she said her dept. was basically a 24hour operation. She also said that she hated it and didnt stay in that dept for long.

JohnMakin 3y ago

This article didn't say it produced better code. It said it forced him to think carefully about what he was doing before he input the code to the system, which made him a better programmer. This is very plausible. Lots of people, especially beginners, love to just spaghetti their way to a solution rather than taking 30 seconds to think about what they're trying to do and if this is the best way of doing it.

drpixie 3y ago
And make people better programmer it did :) It's very usual now (and for the last 20-30 years) to see programmers live a loop of more-or-less randomly change code and see if it runs, repeat... Their code will eventually run, and pass the tests, but will be terrible - not understandable, inefficient, and break when confronted with reality or better tests. When it was quicker and easier to think about the code, than play with it, people generally produced higher quality code.
bregma 3y ago
I think the word you're looking for is 'agile'.

eloisant 3y ago

I have the feeling that we've had a constant increase in productivity, but the expectations keep being adjusted to take that into account. We have more powerful tools now, but instead of having it easy we are constantly asked to do more in a shorter time.

ghaff 3y ago
I've often thought how frustrating it would be to go back to my first job as a product manager for large computer systems. I would find the inability to get anything approaching current information really annoying. Of course, everyone else would be in the same boat. I'm sure some coursework and jobs would look a lot more similar than others. But we also take a lot for granted.

stcredzero 3y ago

That thing about 'you had to do more thinking up front, so you wrote better code' is total nonsense. It's not total nonsense. However, people take it too far. The point is, does the candidate use their brain when using the tool, to use it to its full advantage? There's a big difference between programmers who: - Just mindlessly step through the debugger - Do some groundwork so they know where to step - Has devious tricks, like writing a "tripwire" to activate a special debugging version, and has the program find the bug. So I find people who have this bias against debuggers just silly. It's not the tool that's the deciding factor. It's the programmer! The same goes for writing new code and refactoring existing code. Does the programmer exercise their brain to utilize the tool to its fullest extent? The same even goes for prompt engineering and otherwise leveraging AI. One shouldn't just stop at the surface level of analysis. Look for underlying principles. Try to get to first principles!

mwbajor 3y ago

I didn't read the whole article but it is similar to what my mom told me. My mom worked for AT&T in the late 60's early 70s as one of the girls that would take your program and make the punch cards or take your punch cards and run them. She also said that you just checked it over as much as possible and got good at not making many mistakes because of how tedious it was. From what I recall, she said her dept. was basically a 24hour operation. She also said that she hated it and didnt stay in that dept for long.