I did a technical interview recently — the kind that you can’t really prepare for, but where you (unfortunately) need to rely on your wits and experience.
The interviewer asked “what are some challenges that developers face?” and, despite having been a developer for many years, I’d never really thought about it. So I made up an answer on the spot, which clearly wasn’t great as I didn’t get the role.
So here, for the record, are some of the things I wish I’d said…
In many organisations you work with people from different backgrounds and with vastly different levels of technical expertise. The challenge is in knowing how to interact with them at a meaningful level.
As a developer, you understand how all aspects of your application work — but to a non-technical outsider, your app is basically black magic. A common scenario is trying to explain why a seemingly-simple problem will require hours of work to fix.
XKCD sums it up perfectly in this comic:
Try helping an elderly relative when their phone asks for their iCloud password. “Even though your iCloud username is your email address, your iCloud password isn’t the same as your email password (although it might be).” This makes complete sense to me…
I recently built an application using the new ArcGIS Web AppBuilder, where the goal was not to produce a particular map, but to create a reusable framework which could be deployed to create any map. I spent my time ensuring that the messaging between all the components was working, rather than worrying about the actual map content.
When I triumphantly showed my work to a manager, he was fixated on the fact that the colours on the map were wrong, even though I’d repeatedly explained that the map itself was a placeholder, and I was working on everything else except the content.
Any developer who’s ever answered the question “but why is it all in Latin?” will appreciate that non-technical users often can’t tell which bits you’ve built, and which bits they need to contribute.
When you’re technically-minded, it’s tempting to dive right in and start writing code. It’s what you’re good at, and you probably enjoy it. So when the boss asks you to solve a problem to a tight timeframe, the temptation is to write a quick+dirty program which gets the job done.
But inevitably the requirements will change, and (if you haven’t written your code flexibly) you’ll need to refactor your application. Depending on the complexity of the change, this may require an entire rewrite.
I was recently asked to scrape some website data and convert into another format, then feed that into a series of other complicated scripts which finally arrived at a solution. And the answer was needed ASAP (as always).
But I wasn’t told that the input data would change periodically, and that the entire process would need to be re-run at intervals. I should have clarified this at the start, then taken a step back and analysed the entire chain of events, before writing a modular set of programs to handle each component.
It’s easy for a non-technical manager to change the requirements at any point; it’s a lot harder for a programmer to adapt to changed requirements once they’ve started writing code.
When you’re not closely involved in the initial stages of a project, or if you’re replying to a Request for Tender, you may receive documentation which has been written by a business analyst or (worse) a committee at the client site.
Often the requirements can go into excruciating detail over obvious issues (the map must have controls to zoom in, zoom out, pan north/south/east/west) while glossing over the real purpose of the application (the site is designed to help citizens find X).
Sometimes there is a Mandatory requirement which you could solve in a more elegant way. But when replying to a Request for Tender, you need to ensure that your response satisfies every requirement, even when you fundamentally disagree with the approach which has been proposed by the client.
When you’re working on your MacBook in a cafe, everything is easy. You have full control over your development environment, you can install anything you need, and you can make changes (and see the results) instantaneously.
When you’re working in a corporate environment, all of these things become frustratingly hard. You won’t have admin access to your PC (it’s always a PC) so you won’t be able to install plugins or applications, and you’ll need to factor in a firewall and/or proxy. You’ll probably have to debug a product or technology you’ve never used before.
Any changes will need approval by multiple managers — I once worked at a government department which required us to print, sign and fax a work order for every change to the system, whether it was a whole new release or just to fix a typo. Changes are slooooow.
You’ve built a beautiful application which showcases the best of your skills. You find out the client’s entire workforce uses IE7.