Programming advice

1 January, 2012

Show comments

When I was a younger chap - I remember hearing the song Wear Sunscreen and being struck by the profound and meaningful lyrics. Of course at the time I was entirely ignorant to the fact that the lyrics came from somewhere else. Over the past year I've contemplated writing a post on advice for the next generation of tech geeks a number of times. Since I'd like to get a head start on my new year's resolution to do/write more - here is that advice.

Learn to solve problems§

This is my "one tip for the future".

First let me clarify what I mean by this - I do not mean "learn to be a better more efficient programmer" or any other such useless advice. I mean things like learn how to look at broken code and at least determine where it is broken. Learn (or study) how to look at a coding problem and understand how to solve it without necessarily writing a line of code.

If you can deterministically find where code is broken and, starting from a blank piece of paper, outline how to implement/solve some requirement - all the rest (language, platform, framework) are just details that change as time goes by.

Google first, ask second§

Google knows more than you - use it.

When you have a question - type it in google first. If you ask a question on a help channel or, worse, via some mailing list and simply typing the question in google gives an answer - feel embarrassed. And don't do it again.

Learn to test your code§

If you don't test your code - you have no confidence it actually works.

So often when I hear "testing" used the term does not apply to some kind of repeatable process - It means "pressing F5". This is a waste of time - pressing F5 is not testing. If you fix/solve a problem in such a way that you cannot automate verifying that the problem is fixed - all that means is if the problem resurfaces you have no idea it's back. Until someone tells you. Put yourself in a position to proactively know about problems - use unit tests.

Turn this:

Bert: Earnie, can you fix/implement x please?
Earnie: Sure ... done.
.... time passes ....
Bert: Earnie. z is broken again! Why does this keep breaking!?!


Bert: Earnie, can you fix/implement x please?
Earnie: Sure ...
Earnie: Oh, doing that breaks z
.... some minutes pass ....
Earnie: ... fixed, done.
.... time passes ....

Have a side project§

Use your imagination, test your limits.

I write a lot of code - and most of it now is thankfully obsolete1. However, along the way various ideas were tried out, tossed out, massaged, refined etc. Having a side project - especially if it's in a language that you do not work with for your day job will allow you the freedom to find your boundaries and continue to grow professionally.

Stay Hungry, Stay Foolish§

Don't be afraid to make mistakes.

If you have a full time programming job, getting stuck in a comfort zone is quite easy, don't let yourself professionally stagnate - don't allow yourself to live a 9-5 existence with the risk of, at some point in the future, looking back and realizing you learned nothing in the recent past. If this describes 2011 for you - do something about it - get hungry, get foolish. That doesn't mean quit and live like a hippie - simply ensure that something in your regular programming week involves something you are not familiar with.

If you do not have a full time programming job (but want one) - start a project that you're interested in, something you'll enjoy working on. If you can't think of such a project (where is your imagination!) look for a project and contribute.

But don't get taken for a ride. Especially if you're a productive kind of guy - at some point in your professional career someone is going to ask you to help them out for free/cheap and do something that turns out to be massively more work than initially described. When this happens - google "sunk costs" and get yourself out of that situation as professionally as you can.

Be opinionated§

Whatever your opinion - don't be afraid to share it.

Don't be like me from time to time - don't be too loud about it - but state your opinion. Be open to the opinions of other's. Listen, you don't have to agree, but listen. Be humble when you're proven wrong - in keeping with the previous point, don't be afraid to make mistakes.

On the other hand, don't be an empty fanboy opinion. Have an informed and balanced opinion. Love cakephp? Why? What do you dislike about it? I like it because of the sheer simplicity. What do I dislike? Quite a lot really, there are still bits that could be done better - starting with the bit I'm most known for writing.


If you have any additional advice you'd like to give the next generation - feel free to leave a comment.


  1. Most of the code I've written solved problems for cakephp <=1.3. These problems are solved by the framework or otherwise don't exist any more with the release of cakephp 2.0