Thursday, 4 April 2013

Why coding is important when you learn coding


I know, it's very close to yet another commonsense topic - but - I think it worth to emphasize and say aloud. In order to code well you have to write a lot of code.


Probably there is no need to explain why practicing is an important part of learning. Generally you may think of memorizing facts, data or building up a nice routine - eliminate forced thinking to shift it to an unconscious activity. That's all right, makes sense. However I think in development you have some extra benefits as well.

Sometimes coding is the only way to discover problems. That's one of my biggest problem I'm facing whenever I learn something new. I need genuine real world problems. I don't want to write a HelloWorld app, or a loop, or a module. That's gonna be simple, unusable and most probably I'll cut all the corners I can in order to make it quick. There are quite some websites targeted to newcomers - how to learn a language by going through some real issues.

Also, when you don't have problems, you don't have the anxiety or stress. And without it I've found hard to assimilate the facts. Exactly like learning real languages. It's either the level of anxiety or the fact that in stress your senses are accepting more input - in order to deal with the situation - and eventually that leads to more memories. And it's well known that a key to memorize things is biding them.

What I also realized is coding is not a one-time activity. Your work evolves through time. You build it up piece by piece and literally can apply improvements anytime later. Also others can interact with the same code. That we call the evolution of code. During that progress you can follow the states of that piece of work. It's quite interesting if you think about extensibility. I've seen a lot of coder making codes for themselves. Which worked perfectly, it just wasn't made for others to extend easily. A typical pattern I've seen many times:

function foo($var) {
  if (!$var->type == 'a') {
    // Not my type.
    return;
  }

  // Actions working on 'a' type $vars.
  // ...
}


(These are only examples, dead simple ones. It doesn't mean that this format is essentially wrong. It's just easy to use as a representation.)

So here you see a function, accepting an argument and the very first part is a decision about the type of the argument. If it's not an expected type then we return, otherwise do whatever we want. And it's still better than having the condition-exit in the middle of the function. Why? When somebody else it extending this code - and not caring about the type of the argument - then s/he has to refactor it so it's not returning. Simply using the opposite would make it more obvious:

function foo($var) {
  if ($var->type == 'a') {
    // Actions working on 'a' type $vars.
    // ...
  }

  // Fellow coders do whatever you want.
}


Well, to be honest I think the code part in the middle is begging for a small function to be extracted into - so it doesn't become a mutant function at the end.

And there is a last - very important thing around coding a lot. When you practice more - and apply more matured patterns your invested energy and risk is decreasing. We all have deadlines, and we try not to be cursed by the project managers, so we go on the safe road usually. But the more advanced problems you solved the more likely you solve new problems with similar techniques. In my experience almost 90% of the sloppy code I've seen was produced because there was no time or the developer felt unconfident about it.

So my suggestion for today is to code a lot and look for problems, as many as you can.

---

Peter

No comments:

Post a Comment