I love what I do, and I work with a great team. While it’s still far from perfect; I can say that I do love my job. For the last couple weeks though, I’ve had to remind myself of this several times. I’m sure we’ve all done it, in this industry it’s hard to avoid. You read an email or receive a phone call and repeat the mantra “I love my job, I love my job, I love my job.”
Unreasonable clients, managers that just don’t understand; there are so many reasons, so many triggers. While reciting this mantra often invokes laughter from those nearby, some thought should be given anytime it’s used. More often than not, used as a joke, but a joke masking true problems.
Some issues are unavoidable, some no amount a planning or preparation will help with; for those I can offer no advice. For those, even a perfect environment won’t help. It’s the others I care about, those issues that shouldn’t be, the deadlines that should never have been set, and those whose sole cause is lack of planning or forethought. Those are the ones that tire me; those are the ones I hate.
When I run into one of these situations, it makes me wish this was closer to reality than a dream of how we want things to be. However, why shouldn’t it be reality? Why do we allow this to happen time and time again?
Wait, read that last sentence again. Why do we allow, why do we allow? Yes, as developers we allow this to happen, and often encourage it. Late nights, working weekends, 90-hour weeks. Those could all be prevented, and could be reduced significantly should we stand up. If we do not take a stand, we encourage those that push us too far by doing just what they ask. Why should they stop if they can get a single developer to do the work of two?
A Solution?
So, what are we to do? Taking a page from Rob, here is my modest proposal. A few simple rules for both developers and managers to keep in mind. While rules such as these can never be enforced, keeping these things in mind could make life more pleasant for everybody.
Managers…
- shall keep requests for after hours work to a minimum. While there are “crunch times” on occasion, these should be minimal.
- shall seek input from at least one developer before estimating a project. An estimate should not be created without consulting those that will be working on it, as they should have the most realistic idea of how long it will take to implement.
- shall not ask developers to implement a hack or kludgey solution to meet an unreasonable deadline or request; especially if it will compromise stability or maintainability.
- shall understand that developers are often passionate about their work, and the quality of the software they produce. Asking a professional to implement a solution based on a bad design, or inferior technologies will often be viewed as an insult, especially when this is done to meet an unreasonable goal.
- shall shield developers from unnecessary distractions and meetings. Distractions can destroy productivity.
- shall not ask developers to do the job of a Support technician. Tasks such as installing or configuring third-party software should not be given to a developer.
- shall filter all requests and put policies in place to ensure that requests do not go directly to a developer.
- shall give developers the freedom and opportunity to test different development methodologies when the schedule allows.
Developers…
- shall make every reasonable effort to complete a task, including working long hours (so long as the hours and frequency are reasonable).
- shall not complain about boring or undesirable tasks.
- shall alert management when an issue arises that may impact a deadline, as soon as possible.
- shall build the best software they are able to.
- shall provide accurate estimates when asked.
- shall be available as much as possible should an emergency arise.
- shall not over-build, or over architect just for the sake of doing so.
- shall try to understand the pressures and forces at play when communicating with management.
- shall make an effort to improve development methods and processes.
If you agree with this last, take it to your manager and talk about it; if not, build your own and talk about it. Either way, the idea is to talk about the issues and try to find ways to get everybody on the same page. If we make no effort to improve things, then we are just as much a part of the problem as anyone else.
If you don’t like things, complain; but complaining to a friend or co-worker won’t help, you need to let management know that there are problems and that you have some ideas to fix them.
