[SoftTalker]

Yes, this is common ground for "old" programmers.

Quite simply, when you had to walk across campus or at least to a different room to submit your card deck, wait (perhaps hours) for the results (printed on fan-fold paper, that again you had to go to a different building or room to pick up) only to find your program didn't compile due to a syntax error or didn't run due to a careless bug, you learned to "desk check" your code, run the program in your head, and be as sure as you could be that there were no errors.

Even when we got connected terminals, it could still take hours for your compile job to work its way through the queue of pending jobs, because it was in a development region that only got resources when the production queue was clear. You didn't use the compiler as a syntax checker in those days.

That all started to change when we got PCs or workstations, or at least good interactive multiuser development environents, and a "code-compile" loop or repl became part of the standard toolkit.

[michaelrpeskin]

I have a old guy that I work with - PhD in Math (because CS didn't exist then) - who does lots of algorithm development with me. I often get Word docs of pseudo code from him. I'll do a search-and-replace on things like "LET" and "ELSE IF" and a very high percentage of the time if I run it in Python it works on the first try. Kind of amazing to me.

The hard part for me is then translating his ideas into vectorized numpy for speed, but at least I get the right answer to check against.

[markus_zhang]

I sometimes wonder whether following some of these practices may promote more mediocre programmers, if they so wish, to become better ones.

- Think through and write on paper in pseudo code first;

- Run written code in head, or on paper if they don't have the capacity, a couple of times before pressing that BUILD menu item;

- Restrain from using libraries if a custom, better solution is possible;

But then I think, it probably doesn't make a lot of sense if you work as a frontend pushing out JS, or as a data eng writing Python code which calls some Scala code which runs in JVM which is highly complicated, because the whole industry is "AGILE" and the chain is way too long. You need to get into the right job, to nurture such a mindset. The old timers got lucky. They started with 6502 bare metal.

That's why I'm pushing myself to get out of Data Engineering, to do something lower level, until I get deep into the basement. I probably won't succeed here but it's fun to try.

[SoftTalker]

Not sure if actually writing it out on paper is necessary. But along these lines I will often start my code by just writing comments explaining what the code in this file does. Then as I get into writing code, I break up the comments and insert the functions/classes below the comments that describe what they do. So sort of literate programming, but I don't usually go to the lengths that would really qualify that description..

I disagree about not using libraries. Libraries are almost always going to be better tested, better reviewed, and handle more edge cases than anything you come up with in-house. Of course if no suitable library exists you have no choice.

[markus_zhang]

I agree with the library being better tested part, so that's why I think it's better to find a job that actually doesn't allow the use of libraries (or too many of them), than to try to go to the bottom in a job that has 5 layers of abstraction.

It's good to hear the literate programming thing. I sometimes do that on paper when I need to clear my mind. Basically code in English but with C type {} as scope.

[hackingonempty]

I recently switched build tools because I couldn't get rid of a ten second delay in recompiling/rerunning my back end app when I saved a file.