Monday 3 February 2014

Programming with the Man Flu (Comfort Zone Programming)


To cut the explanation short, Last week I was taken out of action for four or five days with Man Flu. And like all sofa-bound individuals reached for the trusty laptop and immediately opened my IDE to get some uninterrupted* programming time in with the determination that this wasn't going to be a total waste of time.

* = Programming time was frequently interrupted by naptime.

Attempts at developing software under these conditions were met with varying degrees of success - some tasks were quite possible while others not so much.Your brain uses some 20% of your energy, and in my energy-restricted flu-coma my immune system had clearly decided to shut down those pesky thought processes that were hogging system resources.

The end result was a pared-back subset of programming and refactoring skills and I was focused on just doing the things I knew how to do - the core actions that I could perform on autopilot. Coding in my Comfort Zone.

Comfort Zone programming is a reflection on your skillset, and in your confidence in those skills. I naturally tended toward the things I found easiest and away from 'difficult' tasks - when you have no brainwidth, go with what you know.

Over this time I performed several pre-emptive refactors of non-critical systems. Clearly I could spot problems, demeter violations, better injection patterns - but lacked the judgement to ignore problems off the critical path.  I was also quite happy spending a few hours writing some packet processors for data bytestreams, which I attribute to a lot of the image processing and network code I've written in the past rising to the surface.

While dying from Man Flu isn't a great way to identify your comfort zone - and not an experience I'd recommend for anybody - The process of identifying what you are good at provides value not only because you can Keep Doing It, but also because you can stretch further, learn something and better yourself.

Comfort Zone programming has helped me learn which skills I default to when times are hard - what my reflex actions are - who my autopilot is.

Learning what to learn is one of the hardest skills to develop, and in this instance I've got a list of the "difficult" tasks my fever brain avoided, and my programming autopilot wasn't able to handle.  Over the coming weeks I'll be able to reflect upon that list and get practice at my weaker refactoring and programming skills, to drill them into my brain until even my autopilot can manage them.

The take home lesson here - and your challenge, should you decide to accept it, is to get out of your comfort zone. And a great way to do that might just be to get in to your comfort zone and see what it looks like. Identify the skills that you don't use enough, follow the advice you frequently ignore.

No comments:

Post a Comment