Saturday, August 29, 2015

The 4 rules of coding - or, of coding-applied strategic thinking.

Coding is not an easy job. From the perspective of the programmer, Coding is a war. I'll tell you why.
You need to do it right; which means; you need to do it clean; you need to do it FAST; and you - potentially, well, pretty much all the time - absolutely NEED to get it right the first time. There is no second chance. You have time to think on how to do it, sure, perhaps weeks, months, YEARS; but you will get that time only ONCE.

One shot. Perfection.

It's not an easy life being a coder. If you like to write; if you like to think; if you like to plan; you are not good enough. You need to like to write AND to think AND to plan. You need a STRATEGY.

Remember, practice makes the master. FOUR simple "riddles" govern the practice of coding, each of them require solving for the specific problem they are being applied on. The four riddles of coding, for properly solving a given problem, are for you find out:
  1. WHAT needs to be done
  2. HOW to achieve that (functionality-wise)
  3. WHY it needs to be done like this (in a structural context)
  4. HOW IT CAN BE USED
Point 1. Is pretty straightforward, and stems off from the requirements.
Point 2. is purely logic; and means collecting the idea of how to do things (i.e. opening files, writing to them vs opening pipes and/or writing to a REST Api etcetcetc). This is the threshold of AVERAGE programmers. They will write average code. This is just a fact. It is not BAD code per se; as it will do what it is meant to do. Only; people working with that code will make the coder's ear ring with F*U's for the rest of his life.
Point 3. Adds perspective in the mix. You might say, "of course I know WHY it needs to be done like this; to fulfill the requirements". That's only half the coin, man! This WHY is waay more subtle and entwingled into the deeper meaning / structure and is meant to get you to think of the solution you are applying (to the problem given by the requirements) in a broader spectrum; or, how more "advanced" programmers like to put it, in terms of "architecture", and in a wholistic view. In short, this point opens up for future usability of your code (funcionality-wise). Things like code structure, Functionality-grouping, application of patterns fall into this area. You can discern Good coders from the rest by the fact that they make use of these tools or not.
Point 4. is the hardest one, and usually only Great coders make it all the way up to this point. This is strategy to it's finest. Point 3 at the n'th potential. Code that is written needs to be USED. Needs to be relied on. If code cannot be used, it is useless, rusty, unreliable. If your code is not "level 4" code, it won't survive a new generation of programmers in your team. "The old code is shit, let's rewrite it", they will say. NIH sindrome.

No comments: