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.
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.
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.
- 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.