Monday, 11 January 2010

Working in locked-down IT work environments can be frustrating, especially as a developer. We usually find a way around or are able to provide valid productivity or basic functionality reasons to have the rules relaxed for us. As long as I can write and run code, administer most tools required for development and google when I'm stuck then I'm a happy coder.

It is the latter that is most likely to be restricted to the point of insanity. This is the case in my current workplace and in pretty much every bank, insurance company and Government department that I have ever frequented for remuneration.

Why can't I use the Internet at work?

Let me talk to you here about how I work and how I like to work. These are two different things but certainly impact the other. How I work is what makes a Damana tick. How I like to work is what makes a Damana productive in the workplace.

As software engineers, ours is a thinking game. The actual doing does not take much time. If you see your job involving a lot of typing then you are most probably doing it wrong. The majority of my time is taken up with deciding what to do and then implementing it follows as a distant second.

When I say thinking, that doesn't mean reclining with feet on the desk and smoking a cigar, while wearing a dressing gown. No, it simply means that my progress can be broken down as follows...

How I like to Work

Decide which task to work on next [thinking] - Where does the task fit in to the work I'm currently doing or just finished? What is the highest priority at the moment and which task satisfies that? What task will score me the most points with the business? What are the business benefits of this? So on and so on;

Pick up the task [doing] - claim the task in whatever tracking system is used. Read any specs, details or notes associated with the task. Talk to the analyst or business to gain a common understanding of what needs to be achieved;

Look at the code and running application so far to find out where this task fits in to the scheme of things or work out where it will if nothing yet exists. [thinking] - Understanding the context and the requirements is a thinking processing. Scrolling through the code or clicking a few buttons in the front-end doesn't constitute "doing" to me;

Come up with a solution and an approach [thinking] - most problems are solved or have patterns that are used to best solve them. Experience will let you identify them quickly and googling can help you otherwise. This is the point where you can jump to the quickest solution or procrastinate and find the perfect one. My way is to think of a few ways and implement the one that seems the nicest technically and is within the timeframe. Of course, this is all decided knowing that refactoring is available to me in the future;

Deciding how to test what I'm about to build [thinking] - working out how to test something lets you explore your understanding of the problem domain and create an interface to what you are about to build. It helps inner design and in determining how to build only what is needed;

Write tests and code [doing] - this is the typing part;

Show the user/business representative/analyst what you are building as you build it [thinking] - this is thinking as a group (not to be confused with group think);

Merge and deploy [doing] - this can be automated. With a lot of developers on the same project, this can be a problem solving exercise and also involve thinking if bugs or clashes emerge during integration.

This is of course a skeleton view of the process and does change depending on what the task is. The thing is that what I refer to as "thinking" takes up the majority of time. If I was to add percentages to the different steps, I'd allocate 15-20% of that time to "doing" parts.

Why does this have anything to do with my me accessing the Internet?

How I Work

To be clear, I am not a Buddhist monk and really don't understand how I work in all aspects of my life. I'm nowhere near Nirvana but I do have a bloody good idea about what makes me productive at work.

Thinking is a mentally intensive process. It's not even correct to call it a process as that seems to imply some kind of contiguous set of steps. That's not what it is to me. Solving problems and implementing solutions needs to happen in small bursts. Of course, these bursts can follow each other closely or be broken up over different periods of minutes, hours or days. Days are less likely since I work in smaller tasks than would require days. Either way, I have to break that process up so that I don't become mentally exhausted. Breaks are important.

Call it slack. Call it a brain-break. Call it what you will.

Nothing is going to let me work 10 hours in a row doing nothing but thinking. Instead, I need to work in the bursts I talk about. Think-Do-Stop; rinse and repeat. What this means in a work day is that if you _made_me_ put all the thinking and doing together then you'd see me working a 6 hour day and then collapse in a heap. Instead, if I take micro-breaks between the bursts, I can easily produce valuable output in a combined 8-9 hour day, all the time working at a sustainable pace.

Does that mean spending time sitting at my desk with my brain turned off? Not really. Usually my brain-breaks still involve thinking but in a different way to the way I think at work. For me, reading my RSS feeds; sharing knowledge, events and fluff in real-time with friends online ; and turning around and talking about the front of the newspaper with my office mate let's me recharge. How much of the time I spend doing this depends on the how challenged I feel that day due to difficulty of and interest in the task and how tired/alert I'm feeling.

The format of working I have developed over the years has resulted in my being able to easily punch out 9 hour solid productive days, without burning out. In the process of learning this, I have burnt out. Damn, I'm the Phoenix of software development.

That's why I need access to the Internet at work. I want to read what I want. I want to talk to whoever I want. I want to be slack whenever and however I want. At least assume I mean well and want to do the best work I can. Not all of us want to abuse resources or our employers. In fact, most people are good people. Why treat us as if we are like the few who rort the system? It's the same as blaming all religious people for the acts of extremists. That's not representative.

It doesn't matter how much you lock-down your environment, I'll have my slack time. Thanks to smart phones, you have no way to bore me to death or burn me out anymore. So, what's the point of doing it now?

Search This Blog

Follow by Email

About Me

I am a nomad. I travel a lot for work and for fun. For the last 20 years, I have been building big web applications that business wants and users like to use. I've worked for federal gov, large media organisations, banks and a couple of startups in the areas of mobile technology and vision tracking. I was at ThoughtWorks for a while being agile and having fun as a polyglot programmer. Then I was a Developer Premier Field Engineer at Microsoft where I was the Asia Pacific ASP.NET MVC Lead, an agile software development coach and a languages and integration specialist.
For a while, I was playing in .gov.au as an Architect building Voice Authentication for Aussie citizens. My further adventures see me delivering more large systems for gov.au. Now I'm living in Seattle and working for a large book store. I love cats, cocktails and cooking. People are more important than things. Ideas drive the world.
I do not speak for my employer. All opinions are my own.