Random Thoughts On Builders At Work - Part 11.

Young Kick-Ass Fire-Fighter.

As a young and budding developer at Multiplitaxion Inc; I took great pride in my fire-fighting skills.

Something does not work?

You need a quick and dirty macro to do payroll processing for the month?

The sky is falling?

I was your man.

Even if the so-called-senior programmers refused, cringed and pull back at the very thought of working under panic or doing something quick-and-dirty; I; dear reader was around to get-stuff-done; especially when the sky was falling.

Remember those visual-basic applications with a lot of hidden text boxes and a lot of public modules?

Heck; I built a lot of them.

But; at the end of the day; I got stuff done --- at the eleventh hour; when people were getting all worked up and wanted the work done.

Crisis As A Way Of Life.

While as developers; we all do crisis-based-reactive-programming or what I have called demo-driven-development; the problem with crisis is that if you allow it to happen; it will. 

All the time.

Humor me; dear reader. Analyze your organization; take a sample size of a few managers in your organization. Chances are that you will at-least find a couple of them whose projects have a track record of people staying late; people working holidays; people making random mistake; people panicking --- people firefighting.

Now; go look at teams within your organization and I'm sure you will find teams that have a track record working in projects which require a lot of firefighting.

No dear reader; I'm not talking about the isolated example of one project where the client was desperate to get things done really quickly or your CTO was desperate to have the next version rolled out before the demo.

I; dear reader; am talking about a life-style; where the team spends every single day working on 'changes' suggested that day and fumbles to get them done by the end of the next day; and they do this; day after day; project after project.

Managers; who know how to create crisis out of every situation.

Teams; which will be the most reactive and productive when asked to firefight; everyday.

Programmers; who crave crisis; because it lets them flex their engineering mussels and flaunt their heroism.

People who get into crisis all the time; and once they are there; they refuse to even think of giving up.

Believe it or not; dear reader; crisis; is a way of life.

Soak Time And The Problem With Crisis.

As I write this I can visualize multiple young and budding managers knitting their brows.

'So Pops; what is wrong with a little bit of crisis everyday; specially if it keeps your team reactive and helps you get stuff done?' --- you ask.

The answer dear reader; is simple:

'No Soak Time'.

Ever passed by a passage of cubicles and observed a few veteran programmers staring intently at their code?

No; they are not working.

They are indulging in the act of; what I call; letting-the-problem-soak-into-their-heads.

Soak time; is usually the time when your brain is making decisions; that will eventually dictate the life-span of your project. It's the time when your brain thinks of taking the bold decision of throwing away code or routing through the shortest and smartest ways of finding the right way when you are lost.

Soak time; is the time when you brain is chirping away at more problems connected to the primary problem are trying to solve. Problems that are not documented as 'exception flows' in your use-case-document. Problems that are only found and fixed during the soak time.

Soak time; dear reader; is the time when your brain decides to take the reporting module of your application out of the core-application-code and package it as a separate component.

It is the time when you take the most critical decisions associated with your codebase; the problem that you are trying to solve or the overall product.

It is the time that ultimately results in the neatest of features which ultimately make your applications tick. The time when you think about dropping features and question if you really need them. The time that decides your burn-down and how long your code-base will survive the test of time.

Observe any genuine builder out there; and you will learn that a decent part of the day for any builder; is his soak-time.

The biggest problem with crisis; dear reader; is that you have --- no soak time.

When you are in crisis mode you are doing only one of the three things:

1. 'Monkey Attacked, Monkey Fights Back'.
2. 'Monkey Attacked, Monkey Runs'.
3. 'Monkey Attacked, Monkey Gives up. Monkey Gets Hurt'.

Ever seen developers in meetings trying to convince their managers why a particular feature cannot be done and then scrambling to do it when their manager refuses to listen or accept the fact that it cannot be done?

If you have, you probably know what I mean by the three monkey-statements I make above.

Irrespective how how amazing a manager you are; crisis situations happen once in a while.

Handle them with Empathy and your team will take you out of them.

Create crisis situation; project after project; and all you are doing is turning your team of genuine builders into monkeys without any soak-time.

Advice For Managers: Think.

The next time; you press the panic button as a manager; think.

Can you prevent it?

Can you focus on the core and have your team build more by building less? 

Are you giving them room to maneuver and giving them the 'soak time' they need to take the right decisions for the project or are you just turning them into monkeys that 'react' to situations and your panic-buttons all the time.

Advice For Developers: Think.

The next time; you decide to indulge in the firefighting exercise as a developer; think.

Is it really as critical as your manager is making it sound?

Is there stuff in there that you can turn around and say 'no' to building?

Are you being asked to solve a problem and add meaning through your work or are you just being made to react to situations and write some random code?

Isolated incidents of firefighting are fine; but if you find yourself firefighting all the time; you might be getting your promotions; hikes and pats on your back; but chances are you are not developing any real roots or doing anything genuinely innovative.

I was a firefighter. I still am; but I don't really go around looking around for crisis situations so that I can flex my mussels and show my heroism or get a few pats on my back.

In fact; as a developer; I try my best to avoid the crisis situations all together if I can. As a manager; creating panic and crisis situations definitely shows up as one of the top items of my not-to-do-list.

Remember those visual basic applications with a lot of hidden text-boxes and lots of public modules?

I try my best not to make them now.

Maybe I have grown older; or maybe that is just a part of growing up; as a developer and as a manager.

The next time you find yourself firefighting take a pause; and reflect. Are you doing it all the time or is this just an isolated incident? If you find yourself firefighting all the time; dear reader; it is time to keep some soak-time aside; figure out what you are going to do about it and then go out and do it.

I wish you good luck.

@BuildersAtWorkBookNotice