Adam Caudill

Security Leader, Researcher, Developer, Writer, & Photographer

I Love My Job

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.

Adam Caudill

Related Posts

  • You can’t fix stupid…

    For those outside of the IT field, developers are looked at as miracle workers – through us, business leaders think anything is possible (and they often see no reason why we can’t work our latest miracle by the next morning). In reality though, we do work miracles; we save companies vast amounts of money every year through increased worker efficiency and automation, we enable new lines of business that wouldn’t be possible otherwise, and reduce energy costs because we keep the office lights turned off.

  • What It Takes To Be A Great Developer

    Recently a programmer I know decided that it was time for a career change, leaving the IT field entirely. This gave me cause to think; what does it take to be a great developer. Many people go through school believing they have what it takes, only to receive a rude awaking once they enter the real world. Before I go on, I think it’s important to define what I mean by developer, and the differences between a developer and a programmer.

  • The Pressure to Be Great

    I’m a developer, and I love what I do, it’s a great industry, and a very exciting field to be in. If you read my blog often, you’ll see I take every opportunity to mention how great this line of work can be, today I offer a somewhat different, less sugar-coated view. The Pressure There is a constant pressure on developers to be better, to do more, to produce more, sometimes more than is possible.

  • Trojan Source and Why It Matters

    Yesterday the news hit of a new vulnerability that threatens the security of all code; dubbed Trojan Source by the researchers from the University of Cambridge. From an initial analysis, it does seem to impact just about everything, and the status of fixes is very hit or miss at this point. But the real question is, does this even matter? Is this issue worth spending your time on? Let’s look closer.

  • Best Practices vs Inane Practices

    A Full Vindication of the Measures of Security Practitioners, from the Calumnies of their Enemies; In Answer to A Letter, Under the Signature of A. Gwinn. Whereby His Sophistry is exposed, his Cavils confuted, his Artifices detected, and his Wit ridiculed; in a General Address To the public, And A Particular Address To the dedicated members of the security community. Veritas magna est & prœvalebit. Friends and Colleagues, It was hardly to be expected that any man could be so presumptuous as to openly controvert the equity, wisdom, and authority of the measures, adopted by the practitioners of information security: a group truly dedicated to the protection of business and individuals around the world!