Maintaining Your Programming Focus, Or, How To Make Your Own Grass The Greenest

daisy2_

Let’s be honest with each other. Are you really, truly focused on what you do?

Or do you find your attention wanders to new and shiny things more often than you’d like to admit?

Do you order programming books from Amazon on a variety of different subjects and then find that they end up gathering dust on your bookshelf?

Do you play around and write ‘hello world’ programs in other languages, or create basic scripts, but then never really spend any more time on them?

If you see yourself doing this, you might well be suffering from a lack of programming focus.

Is that so bad?

Now don’t get me wrong. I’m all for broadening your skill base and I do believe that a programmer with more than one tool at his disposal is a more well-rounded programmer (and probably learns faster – see below), but there is a big difference between being proficient in one or two subjects and being a jack-of-all-trades by dabbling in lots of them.

So why does the grass always seem greener and the technology more exciting on the other side of the fence?

Psychologists have puzzled over this attitude for decades, and I’m not about to solve it here, but what I can tell you is that by not focusing on your potential area of expertise, you’re sabotaging your own skill set.

Eh? That sounds a bit harsh!

Yes, it does, doesn’t it. Shall I put it a nicer way?

By not focusing on your potential area of expertise, you’re passing up the chance to be the hottest network/RTOS/Ruby programmer this side of the Atlantic.

Ooo, that sounds much better.

Good.

Did you know that you actually learn better and retain more knowledge when you’re reading and learning about a subject you ALREADY KNOW? (Now, this is a bold claim that I can’t currently back up because I can’t for the life of me remember where I read it (oh, the irony) and I’ve had a glass of wine so my Googling skills are somewhat suspect, but trust me, it’s true).

This is because the brain has the structure in place already and can file new information in context. So deepening your knowledge and becoming and expert is actually less of a challenge for the brain than learning lots of new things from scratch.

And even better, when you learn a subject in depth, it often pays off in terms of mirroring the structure/pattern of other subjects, so you win on both counts.

I’m convinced. Where do I sign up?

Well, just as with all things in life that are worth doing, it does take a little bit of effort.

So, here are my top 5 tips for maintaining your focus  – and becoming a C/Arduino/Javascript programming hotshot.

(Hells bells, that sounds good!)

1) Do more of what you already do.

Stuck writing Java for a boring application?

Write more Java at home and create something you enjoy using the same skill set.

If you’re already employed working in a particular area, you are essentially being given the opportunity for free training every. single. day. Take it and run – you never know, you might even start enjoying your job more.

2) Dust off (and read!) the books that deepen your knowledge, rather than broaden it.

You know the ones. Go and get one off the shelf right now, and read chapter 1.

Even if you think you know it all, you often discover new things when reading a good programming text. Not only that, but you could even write a review about it once you’ve finished (see point 4).

3) Vow to learn something in-depth in a language you already know.

Spend half an hour a day for a week reading and writing code in a niche that you have knowledge of. Get to grips with threads, finally work out what O notation is all about, or understand the ins and outs of lighting in OpenGL. Think how great it will feel to finally know exactly what you’re doing ;-).

4) Write an article for a magazine or online programming resource.

Take something you know, and really get to know it.

Then share it with the world!

5) Regularly read blogs and news about what you do.

Try reading more about what you’re already doing – what you do is exciting to other programmers, remember? They are looking at your grass thinking how nice it is, so don’t neglect it.

So there you have it.

It turns out the grass isn’t actually greener with Ruby, Java, OpenGL, Networking, MATLAB or C.

Nope.

The grass is always the greenest where it is tended.

So look after your lawns, people.

Online!

Did ya miss me??

A year has passed and it’s about time I started bothering you all with some little snippets of code again.

So what exactly have I been up to for the last 12 months?

Well, I’ve been mainly looking after my two boys (now 3 and 1.5 years old), but for the last 6 months I have also been actively employed working with my good old friend the marine navigation unit. Lots of C and C++, lots of GDB and a few bits of new technology just to keep things interesting. The combination of these two things has left me no time at all to do much of anything else.

BUT.

Latest news in the Williams household is that I am leaving my secure, happy, multi-threaded post and going on to do… well, at the moment, nothing!

The boys need Mummy around a lot more than I anticipated, and unsurprisingly they are not overly keen on me spending all my time away from home solving complex problems and refactoring code.

So officially, for now, I’ll be a Stay At Home Mum.

But unofficially that means I’ll be spending a bit more time around here and getting to know you all a bit better.

So put the kettle on chuck, and tell me all about yourself…

The Biggest Programming Mistake I Ever Made

Well folks, as mentioned in How To Learn From Your Programming Mistakes, here it is.

The story that still makes me shudder when I think about it.

When it comes to all time, super-duper cock-ups, this is one I will never forget.

Strictly speaking I wasn’t actually trying to program anything when it happened. I was trying to…

Oh let’s just start from the beginning shall we?

The danger of embedded systems

Not long out of university, I was working on an embedded linux platform. The embedded OS, or target, was accessed via telnet from Linux desktop machines. At any one time your terminal window could be logged into your desktop, or into the embedded Linux platform (can you see where this is going?).

I was asked to help out a colleague who was having trouble getting his target up and running.

He pointed me to his machine in the lab, and then disappeared, leaving me to it.

Straight away I could see that the embedded board he was using was in a mess. Files were missing, some were corrupt, and it was basically unrecoverable.

I had several terminal windows open at the same time, and I was switching rapidly between them to check build version, firmware version, and to access my own machine remotely. I downloaded the latest build from my machine and logged into the target to reinstall it.

At least, I thought I did.

I typed:

rm -rf /

to delete everything, so I could start the install from scratch[1].

But as I pressed the return key, I realised I was using the terminal window for his desktop machine.

And I was logged in as root.

If I had to describe that moment using a movie scene, it would look like this[2]:

 

 

I cancelled the process immediately, but it was too late. I had totally destroyed his filesystem. Now he had no target and no desktop computer either.

What did I do?

After I’d finished reeling from the massive mistake I’d just made, I gathered myself together, went to find my poor victim and confessed.

And apologized.

A lot.

He very graciously took it in his stride (since there was bugger all he could do about it, I guess), and seemed happy enough once I promised I would immediately reinstall his operating system AND fix the target, as I had originally intended.

Now, to save face (and enhance my career prospects), I suppose I could have done the reinstall in secret, and feigned ignorance if he had asked where his local files had gone.

But I owned up, and it wasn’t as bad as I thought it would be.

And now I can laugh about it (just).

And of course, I have NEVER made the same mistake again.

 

[1] The command I used, for those of you that aren’t familiar with Linux, is the equivalent of selecting your hard drive and pressing the delete key.

[2] Jaws contains a classic example of the Dolly Zoom: that wonderfully abused effect where the background moves away while the actor appears to loom larger, usually accompanied by some tense string music.

 

How to Learn From Your Programming Mistakes (in 5 Easy Steps)

Once upon a time, I made a very big mistake on a project at work. It was astonishingly stupid of me.

I’ll share that wonderful event with you tomorrow (see how I’m craftily tempting you to come back and visit me again?). In the meantime, here’s my take on how you can learn from those moments you’d rather forget…

1. Acknowledge what you did wrong

Even in this day and age of tools that record everything, automated comments, log files and digital history, there are still programmers out there who won’t admit when they have made a mistake. This varies from the vague ‘I don’t know how that happened,’ to the more outrageous ‘It wasn’t me!’.

Programmers, more than any other professionals I know, are very protective of their work and hate to look like they don’t know what they are doing. Compounding this is the culture of schadenfreude in finding fault with peers, and the retelling of major errors over and over again, especially on team events and nights out: “hey dude, at least I’ve never checked in code with half an email to my wife pasted in the comment at the top, ha ha ha!”

These stories, that provide so much amusement to everyone listening (except the protagonist), are popular because they make us all feel that we aren’t the only ones that make mistakes. And you know what? That’s actually a good thing.

No one gets it right all the time, so why try and hide your errors? As embarrassing as they are, covering them up and trying to forget about them is counter-productive. Not only are you trying to fool others that you never get it wrong, you are also fooling yourself that you don’t need to improve, or take more care, or understand a tool better, or learn something new.

So next time you check in a source file and find you’ve accidentally left memory leaking all over the show, stand up and be proud to admit it. In fact, get in first and tell people what you’ve done. Throw your hands in the air and shout about it. Apologise to your manager for causing 15 crashes in the overnight test suite.

Be human and accept that the only errors computers make are the ones we tell them to make.

2. Understand why it was wrong

In some cases this is easy, but in others you need to really look at why you made the mistake in the first place. If you don’t really, truly understand exactly what the error is that you made, and why you made it, you can’t be sure that you won’t ever do it again.

Was it a lack of understanding in a particular area? Maybe you don’t fully appreciate the workings of the library you are using, or your knowledge of pointers is less than perfect, or you’ve never really worked with this particular language/algorithm/operating system.

Whatever it is, understand why. It could be as simple as the fact that you were rushing and trying to do too many things at once (focus, people – attention to detail is one of your biggest assets). Or it could be that you were making modifications to code using intuition rather than knowledge. (Oops. Guilty.)

Once you know exactly why you made a mistake, you are a very, very long way ahead of the person next to you that just sweeps it under the carpet and tries to forget about it.

3. Commit to improving

Here’s the hard bit. This is the step that won’t happen instantly and that won’t happen by itself either. You HAVE to make the effort to improve in the area in which you made the mistake.

Created a mind-boggling memory leak? Read up on malloc and free (or new and delete; pick your weapon and don’t get them mixed up). Got your iterators all over the place? Go back to basics with STL and learn what you were trying to do. Deleted an afternoon’s worth of code by accident? Get the manual out, google a tutorial, or read the help files and understand the tool you are working with.

Make the commitment to NEVER make that mistake again. But if you do, go back to step 1 😉

4. Look back and laugh (eventually)

It is very important to maintain a sense of humour about your mistakes. Going over things you have done wrong can destroy your confidence and leave you sitting in a corner, unwilling to contribute, failing to suggest ideas, refusing to raise your hand, and staying out of the debate.

Never let a big programming mistake, especially a publicly humiliating one (my story tomorrow!), take away your confidence or your desire for learning. Don’t give up.

If you admit your mistake, understand it, and improve your knowledge, then you will be able to forgive yourself.

And you might even end up as the one saying, “Hey dude, do you remember that time I checked in code with half an email to my wife pasted in the comment at the top, ha ha ha!”.

5. Be gracious when someone else makes a mistake (very important)

I’m not saying you can’t laugh at someone else’s coding misfortunes, or that you have to cuddle your colleagues and tell them it’s OK to mess up the overnight test suite.

What I am saying is don’t go overboard on the humiliation. We left a voodoo doll on the desk of a colleague that messed up a release build one evening (OK, that’s actually quite horrible). BUT we were nice about it. We rallied around and talked about the disasters we had caused, we supported his mistake by talking about our own.

Remember that you’re all in it together. Your team, however diverse and intelligent/incompetent they are, will ALL benefit if everyone approaches mistakes with the right mindset.

Admit.

Understand.

Learn.

Laugh.

Join in.

Easy, eh?