Christiaan Lam – over de dagelijkse avonturen van een mobiele manager
Random header image... Refresh for more!

Staying sane

Developing software is a very challenging business: it’s hard to do right, and you’re usually on a (tight) budget. Then there’s politics. There are always a whole bunch of forces at work influencing the project. The larger the organisation, the more of these forces you’ll encounter.

Of course, in practice it isn’t all that bad. You’ll only really need to watch out for a small portion of these and with some good working agreements there shouldn’t be too much trouble. However, the first time you get into a situation like this it can be overwhelming.

So, how does the lead developer stay sane?

[text by Serge Beaumont]
Developing software is a very challenging business: it’s hard to do right, and you’re usually on a (tight) budget. Then there’s politics. There are always a whole bunch of forces at work influencing the project. The larger the organisation, the more of these forces you’ll encounter. Once, while working for a large organisation I tried to make a list of influencing parties. I stopped counting when I reached fifty… Of course, in practice it isn’t all that bad. You’ll only really need to watch out for a small portion of these and with some good working agreements there shouldn’t be too much trouble. However, the first time you get into a situation like this it can be overwhelming.

So, how does the lead developer stay sane?

1 – Detachment
Detachment is the first and most important way of staying sane. People who are stressed out are generally those who care too much. They put heart and soul into the project, worry about it and work really hard to get things done. The irony is that good qualities like these can turn against you with a vengeance. So you need to force yourself to just let go. If the task is impossible, do the best you can. If you don’t succeed, you gave it your best shot. And the sun will still shine tomorrow.

Rule One of Staying Sane: Don’t worry about the things you can not influence.

Stress is always due to problems with things you can not influence. When you’re programming, do you get stressed because you are looking for a solution? Of course not!. Finding a good solution is the creative and fun part of programming. More important, you’re supposed to influence the software, so that’s not the issue. It’s the time pressure that starts acting up when you take too long. And deadlines are one of those imposed factors you can almost never influence.

2 – Agree upon your responsibilities and communicate them
Talk to your manager. Make a list of what you are responsible for, what is not your responsibility, what sort of problems to redirect to him and what the (verdeling) is of your tasks. If you can agree upon such a list it will help you focus on your tasks and in my experience it also serves as protection. New tasks tend to creep up on you as you go and you’ll need to communicate this if the workload gets too much. The argument to use here is not “it’s too much for me” or “I’m too busy”: it’s always a case of “but you’re the only one who can do it” or “everybody’s too busy”. The argument to use is always quality. “If you want me to do this as well, I won’t have time to spend time on…”. Make sure that you know the relative priority of your tasks. If the new one is on the bottom of the list it might not get done: so be it.

What if my manager can not or does not want to agree upon a responsiblities list? What if I am worried that my PHB will misuse it in all kinds of ways?

Just make a list for yourself. Communicate it with your own team members if necessary. At the very least the process of thinking about it will focus your daily activities.

3 – Make sure your rights and responsibilities are in line.
If you get responsibility for something that you can not influence, you can get in real trouble. A discrepancy between your rights and your responsibilities is normally not a problem. But like a contract, rights are there for when things go wrong. “You’re responsible for the architecture of the application, but you have to listen to our Mr. Application Architect and do everything according to his specs.”. “You’re repsonsible for a faultless installation on the production environment. No, you can’t tell the sysadmins what to do. No, you can’t talk to them and no, you’re not allowed to know what the production environment looks like”.

When you get a responsibility, make sure you have the rights to go along with it. If you are responsible for application architecture, you should have the last word. If Mr. Architect has the last word, make sure he’s responsible as well. If you believe that he is screwing up, either do your best and detach, or get ready to fight for your right for influence.

4 – Talk
I am constantly amazed how many problems are solved by simply talking things over. When you use the basic rules of feedback this actually works very well.
1.Observe, don’t judge.
2.Give your observations from your perspective and your perspective only.
In short: say what happens and how you feel about it. For instance: “When you keep saying ‘It’s not going to happen’, I feel you are not taking me seriously”.
Talking is the only way to handle e-mails that offend you (see: E-mail is dangerous). Most of the time it wasn’t intended that way.

BASIC SURVIVAL
You might get into a situation where functioning normally is not possible due to bad management, bad company culture, death march conditions… Then it’s time to pull out the basic survival kit. The advice presented here is:

Remember all agreements
There are times when you need to remember what it was that you agreed upon with somebody else. Most of the time this is simply because after a while people (including you!) can forget what the exact agreement was or may not remember the very last agreement made. Once I finished a project in about 2000 hours. The manager at that time wasn’t very happy with me because it had been offered to our customer for 1200 hours. Then I found that I still had a printed copy of an e-mail with my initial estimate: 2000 hours. He then focused his attention on the people who had offered a 2000-hour project for 1200. Note that I had forgotten the initial estimate myself as well…
Confirm any agreement by e-mail or on paper.

E-mail is dangerous
Never forget, in a work situation e-mail is a very dangerous medium. A lot of arguments start because an e-mail is interpreted differently from what was intended. “Hey sleepyhead!” in an e-mail will be interpreted very differently when you say it directly with a nudge, a wink and a smile. The absence of body language means that a lot of information we unconciously rely upon is missing. This leads to many misunderstandings.
The reason that this happens is that we tend to write e-mails the way we talk. When we write a larger document (like I’m doing now, for instance) we take much more time and care with what we write, and the language we use is much more carefully thought out. I think this has to do with the fact that a document is seen as something “official”.
Re-read any e-mail you write. If it is an important e-mail, have someone else read it and tell you how they interpret it.

Any e-mail you write will come back to haunt you.
And remember, when you are in doubt of the intent of an e-mail you receive, ask. Don’t assume that an insult or negative comment was intended. It usually isn’t. Especially watch out when the writer is from another country. The most problems arise from the cultural differences you did not expect. The best thing to do is to drop by personally (assuming you’re not on the other side of the world, of course).

Get out of there
If all else fails, don’t torture yourself. It’s not a case of “my fault, his fault or their fault”, it happens that there simply is not the right chemistry to do good work. I’ve seen it happen a lot. The magic words are usually “good for the project/company”. Any manager is susceptible to this argument. If at the cost of some reshuffling he can improve the situation, he will do so. The decision to leave can even work in your favor: people respect that you made a hard choice.

Do fun stuff
Make sure that there is something you like to do. For instance, if you’ve had a week full of meetings, I like to do a small, fun, programming task. Scripting languages like Perl or Python are ideal for this. Try to make a script that makes something in your day-to-day work easier. Write a CGI script that exports an excel sheet to HTML, make an automated build script, a code generator, as long as you have fun doing it. Or install a Quake server and blast your teammates to bits. Or play darts.

Management management
My manager/customer keeps switching priorities: today he wants this, tomorrow that…
This is a problem if you have to switch direction so often that you don’t get anything done. It’s a classical case of management management. Just nod wisely and when he’s gone, go your own way. When he asks you what you’re doing, go into geek mode. Don’t tell him about the overall issues, but focus on the technical problem at hand: there is almost always one.

“Well, we’re busy finding out what the problem is with the message queue connection. We’ve looked in the logs and it doesn’t seem to be a problem in the QueueReader class. This class uses the MQBus interface that we got from department X. It connects to the bus, reads a message and writes it to a temporary file. The MessageLoader class then picks it up, using a polling mechanism by the way… etc. etc. etc.”

Notice how the description went from the work at hand to a technical description of the system? Keep at it with geeky enthousiasm until his eyes glaze over. If he’s smart enough to ask the question in another way, just so the same thing all over again. Hey, what else can you expect from a geek?

Protecting your manager/customer from himself is a good thing as long as you are really sure you are doing the right thing in the meantime! Always keep in mind that your ultimate goal is to help the customer get quality sofware on time.

I really need to refactor the system, it’s a mess. But my manager won’t let me.
Another classic case. You know deep in your bones that if you don’t do this now, you’ll be in deep trouble later. But your manager only sees progress as the number of new screens you churn out. Again, the solution is simple: don’t tell him what you’re doing. Not yet. You don’t need his permission when you write a loop or a new method, do you? Making sure the software is maintainable is simply part of your job. The same goes for writing automated tests. Just write them. They’re just one of those boring technical details that you don’t need to bother your manager with.

0 comments

There are no comments yet...

Kick things off by filling out the form below.

Leave a Comment