The path from being able to program, to learning how to program

9/12/2009

Is the most obscure path you’ve ever taken. It goes from knowing something, to realising you don’t, to learning about the something you knew.

This little tale is inspired from my first two years as a programmer and it briefly explains some of the hops and bumps I hit while learning I don’t actually know what I thought I knew.

In programming, your knowledge goes from knowing a lot, to knowing almost nothing as you keep learning new things. This is usually a pronounced effect to those learning programming from “teach yourself in 30 days” types of books, as they only teach you the basics, but going from knowing nothing about programming to actually being able to write something that half works, is a great achievement which automatically changes the way you look at yourself.

You know programming.

Now that you know the basics, you think of yourself like some sort of master of programming, able to tackle any given problem without much hassle and in a very short time.

You give yourself tasks, like “I wonder how fast I could build a forum”, and you successfully build one in several days. You practice some more for a few weeks but finally get bored of it, as you can’t find anything challenging enough. So you start looking for a project.

It’s only downhill from there on.

The first project you will find will be so exciting. The first piece of work, you are finally able to show the world what you’re made of. You finish the project in 3 days, working 18 hours a day (that’s around 6 normal working days) and you feel great, the client really appreciates you and overlooks the few slight issues, because you delivered so fast.

Your ego is fed.

That first project is the one that will probably doom your next year of career, as it will be the one thing that every other project you do gets compared to, and that first project will always be the one that was the best one, as you will slowly lose interest and get tired and not be able to deliver as fast.

6 months after your first project, you will probably get a part / full time job doing programming, within those six months you would’ve learned some new tricks, like abstract classes and magic methods and you probably already have your own small environment. Now that you know all these tricks, you will automatically start complicating your own work as they seem to do magical things for others, and you want to apply those too … because you are great. You’re not.

You’re unnecessarily complicating your own work.

Not only will you complicate your own work, but you will end up not being able to fully understand how your own code works, because you’ve added so much magic to it that it became unorganised and even the simplest of tasks requires drilling down into several classes.

Six to eight months into your first job and you are already experiencing fatigue, as you didn’t have time to learn how to pace yourself and you’re not even close to being able to organise your own work, let alone plan your work. If you were lucky enough, you had a great project manager, that didn’t let you overwork yourself by not organising your work.

You don’t know how to pace yourself, or organise yourself.

Within your last 3 months in your job, you’re starting to wear out the “Remember that first project I did? That was fast as hell and very accurate, I just don’t know what changed and why I don’t perform as well now.” and you start getting subtle complaints from your boss.

You will probably end up quitting your job before your employer gets the chance to end it for you, and you will feel like you need a short break. After all, you’ve had a very very busy year, and the reason you stopped performing is because you got so tired.

During this first break, you’re not actually taking a break from coding, you’re just taking a break from doing it full time for someone else, instead you do it full time for yourself. You start polishing that little environment of yours, which turned into a big hog that you don’t really understand.

You don’t know how to organise your applications.

That’s how the first rewrite crawls it’s way into your life. You start rewriting small bits of your environment, but you soon realise that these new fresh and polished parts have nothing to do with what you were actually rewriting, and they don’t really fit into your old environment, so instead of rewriting 2 small parts, you end up rewriting 2 small parts and then rewriting the whole environment, based and wrapped around those 2 small parts. Chances are those 2 small parts aren’t key parts and you’ve just rewritten a whole environment around the wrong idea and solving the wrong problem.

You can’t identify the real problem.

Now that you’ve rewritten your environment, you brushed up your skills on abstract classes and magic methods. You are very impressed with your recent work and feel like you’ve achieved a new level and that you’re definitely back on track and ready to start a new job.

First weeks into your new job and you’re already sloppy, missing even the simplest of deadlines and not really performing as you did while working for yourself. You start questioning if you are really a full time person, or maybe you’re more suited for a freelancer’s job. Then you start thinking about the problem and the more you think about it, the more you realise that everything went wrong since you rewrote your environment. After much consideration and thought, you go back to your old environment, but not before you archive and store your new, polished environment, for later use. After all, you’re just trying to prove yourself it’s not actually the environment that’s the problem.

You don’t adapt to new environments easily, no matter how good they are.

Three months into your new job and you’re still using your old environment, you’re so much more productive and everything just seems to work.

You can’t tell a solved problem, from a shifted problem.

You eventually leave this job as well as you feel you’re not really learning anything new and go to a more challenging, more mature company.

That’s when you realise you don’t know anything about programming or the web, you start learning new concepts and polishing the ones you already thought you knew, but didn’t really.

You’re now ready to start learning programming.

You can learn a programming language in 30 days, and if you keep at it 14 hours a day, for the full 30 days, you will probably be great at hacking things into place and delivering things that sort of work.

It takes at least 4 years to figure out the basic problems you might stumble upon on a day to day basis while programming and to learn how to deal with them. It’s not skill that’s valuable, it’s knowing how you can go wrong and being able to anticipate it, or at least realise when and where you were wrong.

How much of your path to a programmer is reflected in this little story?

There is 1 comment in this article:

  1. 18/02/2010Valentin say:

    I should warn you that this path is mostly tied to web programming. Only here can you see the fastest results, without learning all the details beneath.
    Also, this is interesting: http://norvig.com/21-days.html

Write a comment: