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.