This may seem cynical, but never do more than you are told to do.
There are two reasons to color inside the lines. First, you expose yourself to risk. When management asks for a feature, you estimate conservatively, keep a log, and blame them when anything goes wrong. When you build in unrequested functionality it’s your neck when something breaks. Or when someone else’s code breaks and they blame it on your maverick code to save face. Unrequested code is presumed guilty even after proven innocent because blame cannot flow anywhere but the author. It’s a safe play for anyone above you in the management chain.
Second, you create more work for others. You may volunteer your time and effort to write unrequested code but other people will have to integrate and maintain it. This is a quick way to make enemies of your coworkers. Your problems become their problems which then makes you a problem for them.
A friend of mine was a developer for a small financial services company. He worked on the back end database for processing all incoming web requests. He inherited a rather naive schema, tortured and twisted with every new feature. The smart thing to do was leave it be and keep shoehorning in functionality. The foolish thing he did was champion a complete rebuild. Being the only half-way competent developer, all the work fell on him. He also had to keep up with his normal workload. He didn’t make a single dime extra since he was paid on salary. Eventually the rebuilt database shipped. He was immediately blamed for three critical production outages over the next few months, only one of them being his fault. He burned valuable social credit with the front end developer who had to integrate changes with an already full schedule. Executives and customers will never even know the difference.
There are exceptions to this rule. Automating existing tasks can pay off big time. Start with a small shell script. Stop when it outgrows the capabilities of bash. A few minutes per day over the course of two weeks resulted in a script that saved my employer two hours of labor per day and eliminated manual errors. If it doesn’t make your job easier leave well enough alone.
An obvious exception is if you’re the guy in charge. Then your job is to implement things as you see fit. Blame for problems falls squarely on your shoulders anyway, as it should. Keep in mind the limits of your authority and discretion.
Another exception is “20% time”. Always work on work projects during this time. Never give them the rights to your personal clever idea or project in exchange for salary you would have gotten anyway. Writing a cool new feature won’t earn you a raise. Refactoring library code won’t get you in too much trouble, if you’re lucky. Career advancement comes through social bullshit and demonstrated skills. Save that inspiration for your Github account where people can do more than just take your word for it. Build your bullshitting skills by selling the normal work you’ve been doing as a new and creative idea when the time comes to show off your 20% efforts.
Taking initiative worked out a few times for me. I got burned more often. Even when it worked out blame flew my way easily. None of the projects benefited my career or earned me any interview points. Nobody cared. They can’t even be maintenanced by remaining staff after I have left. Save your energy, save your ass, save your ideas; don’t do more than requested.
Leave a Reply
You must be logged in to post a comment.