Let me start by saying that if you are not prepared to work your ass off then you cannot be good developer. If you are not in 0.1% of geniuses for which all this comes quite naturally, be prepared for hard work.

If you are bad developer, forgetaboutit. You will never become competent let alone good. I’d suggest you find something else to do where your talent deposits are richer and fun factor higher.

By the same token, you can only move from being competent to being good, but never genius. Geniuses are freaks of nature that are born that way. Either you have it, and know it, or you don’t. You cannot become one.

So what we, average ones, are left with is moving from competent to good. Let me define competent. Being competent developer is really as simple as not doing harm on project and being able to get something done. Nothing spectacular. Not super fast, not super slow, just average. Competent devs punch their 8 hours in, do what they are told, get their pay check and that is it. For them it is just a job like any other.

Good developers are the ones that are passionate about what they do and you can always depend on them to get things done. They have deep understanding of what is going on under the hood and they do quality work. They do what they love to do, and not working is real work for them.

In every competent developer, there is a good developer. Problem is, mofo is deep underground. And you have to dig that sucker out with little foldable trench shovel. And then you have to build him a house to live in. And only then you get to reap full benefits.

So how do you start digging out that guy? You start with basics, by understanding the technology you are using every day. Understanding how it works underneath the public interface you are using.
I remember when I started learning programming and itched to learn assembler after learning BASIC on my Spectrum ZX. I asked friend of mine (probably single genius programmer I know) to teach me assembler.

“Well, you print out 16K of ZX Spectrum ROM and start reading from address 0”, he said.

“By the time you come to video memory, and understand what’s going on, you should have pretty good grasp of it.”

“That’s how I learned it too”, he said, and pulled ROM print-out to show me.

Once you know what is going on underneath the framework/platform you are using, your daily work will become much easier. You will know how to do things so they “fit” into the framework. You will be able to find those hard to fix bugs much, much easier, because you have advantage of knowing what is going on inside.

Lot of people advocate reading as much code as possible. I don’t agree with that. “You just said to read platform code, this is contradicting”, you might say. Not, really. You read platform code to understand platform not to learn programming. Software development is a lot like riding the bicycle. You can read all you want about mechanics of bicycle riding, but you will never learn unless you actually start riding it yourself. More you do it, better you get.

Stop asking for help too. Being self reliant and solving problems on your own is one of the key characteristics of good developer. Asking for help is the last resort if you want to become really good. The more problems you solve alone, easier it gets. When you see hard problem, get excited. It is opportunity to improve your skills.

And at the end, you need to commit to writing quality code. Usually that requires to stop lying to yourself. Deep down we know when we do quality work. Always. Start listening to this quality voice in your head and don’t settle for less. Result is that you will be disgusted with your code most of the time 🙂

What about TDD, extreme programming, patterns, etc. you might ask? These are secondary. They will come to you naturally when/if needed as you improve your craft and polish your skills.

How long will this take? I read about magical figure of 10,000 hours that is needed to hone any skill to impressive level. I think that is about right. It also means that if you write code 4 hours a day it will take you almost 7 years. So, be prepared to commit to 5-7 years.

I think these are basics that are valid for almost anything you want to really master, not only programming. Now, go, work your ass off!