Warning: the following article will strike fear into the hearts of programmers everywhere. It may be Halloween, but it’s terrifying to realize these issues can crop up at any time of year. Turn back before it’s too late …
1. Estimation Aversion
Time estimation is hard. Even if you adequately divide a project into tiny constituent parts, it’s difficult to accurately predict how long a task will take if you’ve never done it before. Even if you’re confident, you’ll probably forget the impact of non-programming issues such as progress meetings, vacations, sick leave, documentation, etc.
Estimation is made worse by naive project managers who tie you down to those figures. Remind them that estimates are called “estimates” for a reason.
2. Suspicious Schedules
Projects must have clearly defined goals and time-lines or they can drift forever. Nothing can be ever considered “complete” but goals should be achievable and dates should be realistic. Even then, be prepared for slippage because things go wrong and it’s impossible to foresee all problems.
Programmers are often blamed for release delays. It’s not necessarily your fault: bad management and a failure to plan is the cause.
3. Scope Creeps
Those who overcome estimation and scheduling woes can be faced with the scope creep; a dastardly character who insists on new features or total overhauls every few days. Nothing is ever good enough and the project veers uncontrollably from one rewrite to another. Good project management will help. Or simply ask the creep for a fully-documented specification — they’ll go mysteriously quiet.
4. Tool Tremors
There’s one thing worse than not having the right tools for the job: being forced to use tool you hate. Perhaps you’re a PHP developer being moved into Java. Or a Gulp expert compelled to use Grunt. Or an Atom user obliged to use Eclipse.
Be pragmatic and adopt the procedures and processes used by others in your team (unless you can convince them that migrating elsewhere is cost-effective). But having to use random tool or editor because “that’s what we use here” is soul-destroying. The solution? Don’t whine and use whatever you need. It’s easier to beg forgiveness than ask permission — and few will complain if you get the job done.
5. Non-Technical Colleague Concerns
Do you dread certain people coming to the office? They may be perfectly pleasant individuals but it becomes tiring having to explain the same technical issues every time they visit. They’ll want to know why IE8 isn’t showing rounded corners, why the application looks different on their ancient Blackberry, why their laptop is running slowly, why email wasn’t working at 10:52pm, why their browsing history is visible and how someone accessed their Facebook account.
They won’t investigate themselves. They won’t Google. They’ll use you: their unofficial IT support lifeline. There are a number of options to consider. You could invoice them for your time? Or hide.
6. Frustrated Designer Fright
Perhaps worse than non-technical colleagues are those “with an eye for UX”. The ones making this claim invariably never have those skills but it won’t stop them suggesting frivolous interface changes. Let’s move that button two pixels to the right? Let’s switch to purple — it’s an on-trend color. Let’s make it pop.
Fortunately, the frustrated designer quickly forgets their recommendations because they’re never documented and they change their mind frequently. Tell them their ideas will be implemented within a vague period and forget about it.
7. “Just” Jitters
Fear the word “just”. It’s used to make sentences sound simple while introducing mind-numbingly complex functionality requiring a decade of intensive research, e.g.
- “Just make the free-text search better.”
- “Just introduce some artificial intelligence.”
- “Just allow users to talk to the application.”
Education is your best option. Or perhaps nod thoughtfully and suggest an astronomical budget.
8. “It Won’t Take Long” Worries
“Just” sentences are followed by this quote. It’s always made by someone with zero development experience and no knowledge of the project or its aims. Inevitably, the time taken to complete a feature is inversely proportional to their “estimate”.
Ignore imprecise statements. Time is relative; they may be thinking about one day’s implementation but you can presume whatever period you like.
9. Support Struggles
Fixing bugs is easy. What’s difficult is working out what the problem is when faced with typical complaints such as “it doesn’t work”. Users will presume you’re a mystical entity who knows what OS they’re running, what software they’ve installed, what features they were using and what their screen looked like when they had a problem three weeks ago.
In their efforts to be helpful, the user won’t reveal what they were doing or the errors they encountered. It’s fun playing twenty questions only to discover they formatted their hard disk.
10. Screw-up Scares
No one wants to screw up and some companies evolve an unhealthy blame culture. We’ve all done something stupid. We’ve all lost essential files or data. We’ve all regretted writing code in a particular way. It’s how we learn. Accept and admit to your mistakes — it’ll make you a better developer.
11. Boredom Burdens
We all want to work on cool stuff. We all want to remain interested. We all want to make a difference. But it doesn’t matter what you’re doing; boredom affects everyone regardless of their role. That said, if you’ve spent the past 25 years working on a COBOL-based tax assessment project, perhaps it’s time for a change of direction. You know what’s holding you back …
12. The Uneasiness of the Unknown
The previous sections can be summarized in a single statement: fear of the unknown. As a programmer, you’ll be placed in situations you’ve not experienced before. The work will be unfamiliar; you’ll never have used that technology or developed in that way.
You have nothing to fear except fear itself. Embrace it: experience is good you may enjoy the change. You won’t know until you try …
Have I missed your most troublesome terrors? What nightmares have you endured?
Craig is a freelance UK web consultant who built his first page for IE2.0 in 1995. Since that time he's been advocating standards, accessibility, and best-practice HTML5 techniques. He's created enterprise specifications, websites and online applications for companies and organisations including the UK Parliament, the European Parliament, the Department of Energy & Climate Change, Microsoft, and more. He's written more than 1,000 articles for SitePoint and you can find him @craigbuckler.
Visual Studio Code: End-to-End Editing and Debugging Tools for Web Developers
Your First Year in Code
HTML5 Games: Novice to Ninja