Saturday, September 28, 2019

How to succeed as a poor programmer

In a previous post I outlined why programmers should strive to be good at one thing rather than everything.

In this post I discuss how to be an asset to an organization when you are not a good programmer.  First, for the record:

I am a poor programmer.   Ask anyone who has worked on group projects with me.

But the key compensation is I am aware I am a poor programmer.   I do not try to do anything fancy.   I follow some heuristics that keep me productive IMO.   I think these heuristics are in fact good for all programmers, but are essential for those of us in the bottom quartile.

  1. KISS.   Always ask first something the extreme programming movement advocates:  what is the simplest thing that could possibly work?  Try that and if it doesn't work, try the second simplest thing.
  2. YAGNI.   When it comes to features and generality, "You Aint Gonna Need It".
  3. ALAN. Avoid Learning Anything New.   Various languages and environments and tools come and go, and each of them requires learning a new set of facts, practices, and a mentality.   And they will probably go away.   Only learn something new when forced.   In 1990 I learned C++.   In 2015 I learned Python.  Good enough.
  4. Make arrays your goto data structure.   Always ask "how would a FORTRAN programmer do this?".   During the course of your lifetime, you should occasionally use trees, but view them like binge drinking... regular use will damage your liver.
  5. Never pretend you understand something when you don't, and never bluff.  Google first, then ask people for what to read, and finally ask for a tutorial from a colleague.   We are all ignorant about almost all things. 
  6. Be aware that most coding advice is bad.   Think about whether there is empirical evidence that a given piece of advice is true.
  7. Avoid linking to other software unless forced.  It empirically rarely goes well.
  8. Try to develop a comfort zone in some area.   Mine is geometric C++ code that calls random numbers.   Don't try to be an expert in everything or even most things.
Finally, let the computer do the work; Dave Kirk talks about the elegance of brute force (I don't know if it original with him).  This is a cousin of KISS.   Hardware is fast.  Software is hard.   Bask in the miracle of creation in software; you make something with behavior out of bits.   If you are bad at programming, you are still programming, something that very few people can do.

9 comments:

Unknown said...
This comment has been removed by the author.
Unknown said...

Do you have a link to Dave Kirks talk/paper?

teki said...

https://www.nvidia.fr/docs/IO/8343/Elegance-of-Brute-Force.pdf

ReJ said...

Great write, can relate greatly to this!
I would just add one thing - "find team that compensate your weaknesses and allow your contributions to amplify that team".

Unknown said...

If you follow those (bad) advice you too can be a Munchkin at the bottom of the ladder.

Unknown said...

Their is a lot of wisdom in this post.

Markus said...

I read from somewhere that Carmack said they pretty much rely on the array when making Doom. But I guess at least he used some tree for BSP?

Unknown said...

I love this article !

squeen said...

Brilliant! This typifies the difference between wisdom and intelligence. Intelligence might (for example) think #3 is wrong---wisdom over the decades proves it to be the correct choice.