Monthly Archives: May 2012

Are you bored at work?

On my way to work today, I almost got a hard lesson in the evils of multitasking. I was doing maybe 70km/h on the highway during rush hour, and for some reason I looked out the side window for a few seconds. When I looked back on the road, the cars in front of me was standing still. And I was still doing 70.

Being a certified ninja driver, I instantly hit the brakes and ended up partially sideways about an arms length away from the nearest car. I also had time to peek in the rear view mirror, where I was able to share a look of panic with the guy in the car behind me. Luckily for me, his braking skills was as amazing as my own.

I guess that should have made me want to write something profound about life. About not wasting your life in the office, perhaps. And it kind of did.

When driving a car, you should really pay attention to what you’re doing. But it’s easy to get distracted when you’re sleepy, as I was. It’s also easy to get distracted when you’re bored.

People who really love what they do are often portrayed as being really focused. They may appear single minded, driven towards a goal. You’d probably not hear anyone describe them as distracted.

At the moment I drive a “family car”. It’s so boring to drive that I’m both distracted and sleepy before I even get out of my driveway. A few years back I had a purpose built sports car. Something about it seemed to demand my full attention at all times.

Sure, I drove more aggressively when I had it, but I was also a lot more focused behind the wheel. Driving to work was no longer a task, it was fun. I was focused on driving the car, and never got distracted by random objects along the road. Driving a sports car actually made me a better driver. I was doing something fun. And part of what made it fun, was that I was a part of a well functioning system. So if you are easily and often distracted at work, why is that?

How does it feel when you sit behind your desk at the office, does it feel like you’re driving a Porsche? Or are you actually bored and frustrated? Are your boss, your co-workers or the processes and policies of your company preventing you from doing a good job?

If that is the case, please let me remind you that you are spending nearly half of your waking hours at that desk. That’s a lot of time spent not having fun.

Just saying.



The art of cutting corners

I’m pretty sure that if a developer built a house, it wouldn’t have any corners. Their first instinct at the sight of an obstacle would be to get rid of them. Corners you say? Who needs them! And then they’ll all start chanting: Cut a corner, cut a corner! 

At Revio, we challenge the developers to deliver estimates that they believe in. We tell them not to consider the expectations of management or customers. Consider the task at hand, and attempt to figure out how long it will take to get it done, and done right.

As discussed in an earlier post, accurate estimates are hard. That means even though we estimate with the best intentions, we might still end up hard pressed for time. And even in the flowery, sunny world of our little company, we occasionally misunderstand the customer. So there we are, with maybe 3 developers in the team, ten days until deadline, and 500 hours of work yet to be done.

Cut corners:

Fig. to take shortcuts; to save money or effort by finding cheaper or easier ways to do something.

To do something in the easiest, quickest, or cheapest way, often harming the quality of your work.

In a situation like this, the vision of an unexperienced developer often narrows down to the very next line of code as he mentally calculates how to shortcut his way out of his misery. Must. Code. Faster.

Let me share with you what I as a manager would want the developers to do in this situation:

  • Give me a calculator, help me type in 3 developers times 8 hours times 10 days equals 240 hours. Explain that we have 500 hours yet to be done. Then ask me patiently what I would like to do with the 260 hours worth of work that we do not have the capacity to complete.
  • Tell me to read “The mythical man month” if I suggest to add another 3 developers to solve the crisis.
  • Ask me wether moving the deadline is a viable option (More often than not, it actually is).
  • Work together with me in order to figure what features can be moved to a later phase, while still delivering as much value as possible in the current phase.
  • NEVER EVER cut on code quality (architecture, coding practices, coding conventions).
  • NEVER EVER cut on quality assurance and testing.

If you discover mid-project that you have more work than you have hours available, you will not get everything done in time. Period. Going into a team-wide panic and start building up technical debt like crazy won’t really help. In the long run, it’ll just make things worse.

Often, quick and dirty actually takes even longer. This is especially true if you have poor specifications and need to do a lot of re-work. When you tell me “yes we can” when actually we don’t, that’s bad for both of us.

So in conclusion: The next time you’re stuck in a doomed project, make sure you stay realistic and maintain your own integrity. Your manager may ask you to get 20 days worth of development done in 10 days, but it’s up to you to accept it.


Stiff Upper management (The process)

It’s strange how when a company grows, it suddenly fills up with people not really doing anything. So called management. I mean sure, they’re doing SOMETHING. But they’re not creating. They’re not producing.

No wait, that’s not right either. They’re producing stuff like policies. Processes. Rules. Sometimes they’re even yelling and pointing fingers. I’m one of them management types. That is, I try not to point fingers too much, but I’m quite keen on the rest of it. Well, I’m actually mostly a process guy. I happen to think they are quite useful. Rules on the other hand, that sounds a bit harsh, doesn’t it? And what does a policy really tell you, when you get down to it?

Our policy is to have policies

A policy is some kind of general principle that the employees and / or company commits to.  “Never say no to a customer.” “You must change your password twice a month”. “In order to protect the environment, you are not allowed to print emails.” Stuff like that. If you are really lucky, you’re in a company where policies are defined as the stuff your boss rants about before they give you access to the alcohol at the Christmas party. He’ll say something like “From now on, everyone must work smarter!” and you will go “What does that even mean?”

To be fair, having sound policies like “Don’t share company secrets on Facebook” and “Don’t say bad things about our customers, at least not in public” is probably a good thing. But they seldom tell you exactly what to do in any given situation.

The beauty of the Process

A process is a documentation of the best known way to solve a given problem or situation. “Best known way” is the key part. That means every time the road changes, the old process no longer applies. The process must be changed with it. It also means that every time someone figures out a better way to do something, the process must reflect it. Implementing a process for the first time doesn’t necessarily mean you have to change much, or even anything at all. The process is there to document how something is done. And how it’s done right. How to update a server. How to service a car.

What’s the point of that, if you’re already doing it? Well, if you got more than one person performing any given action, it’s very likely that there are as many variations on execution as there are persons. A documented process improves the chance that more than one person is performing the action in an optimal fashion (according to the process).

Simply writing down the process the first time, will probably trigger someone going “Hey, that’s not how I’m doing it!” – and you’ll discover that four out of five guys where doing it wrong. If it’s a complicated task, the process will also help people so they don’t forget any vital part of it.

Last but not least, documenting a process is the first step towards improving it. Which is another subject, for another post (or series of posts). So I guess that’s a cue for me to stop writing, for now.

Happy processing!