“Can you just add this little thing in before the launch tomorrow?”
There is no “just”, and there is no “little”!
Sometimes, the people on-high just really don’t get what you do. How difficult is it to simply add an extra bit of code into the website? After all, they only want a mini game with 100 levels to open when a user logs in. Easy, right?
No, it isn’t, and never mind the hours of testing and debugging you did for the rest of the website or app launch. The thought of sending out code without any sort of stress testing wakes programmers up in a cold sweat at night because, when it all goes wrong, they’re going to be the ones who gets the blame!
“I have this idea that’s very similar to [insert famous programme/app here]. It’ll probably only take you a few days.”
This is very similar to the first one, with the added horror of it being a friend or family member asking you. They have no clue what coding is, they’re just the ideas-person. They’ve seen a bit on YouTube and it seems straightforward. You do it for a living, though, so it’ll be quicker if you do it.
Never mind that the idea is terrible, like a dating app for dogs, but when are you meant to find the time? And will you be paid for it? No, didn’t think so.
Telling your partner or best friend this is hard, and the social awkwardness of it is enough to send any programmer fleeing to the hills.
“The data is accurate across all sources”
Excellent. Now, what sources are they, and how accurate is “accurate”?
Working in Data is a detail-oriented and precise job, with stakeholders using your analysis to determine the direction of the business. Yet here someone is telling you to blindly trust that what you’ve been given isn’t going to send the company into free fall.
You’ve built up a reputation for being thorough and trustworthy, not testing the data yourself just raises the hairs on your arms.
“We’re not sure why it failed, but it seems to be working now!”
Everything was working fine! The programme was running, people were using it. Then, out of nowhere, a system error pops up and everything stops working. You get called to fix it, but by the time you get there, it’s all up and running again.
You want to look at it, to find the problem and fix it, except the manager is convinced that miracles happen. Of course, the code fixed itself, that’s how good you are at your job. You only need to be in the vicinity.
Except, it isn’t, and when it crashes again (which it will!), you’re going to be the one who gets a stern talking to.
“The client doesn’t like it, but they don’t know why. Can you give it another go?”
Now, here’s not to berate the client. They are, after all, paying you for a service. A little more information wouldn’t go amiss, though, would it?
Did they not like the layout? Or was it the branding? Should you change the website hierarchy?
There are any number of things you can amend, but it might not make any difference. It could be worse! That trepidation as you try to guess what the client might want next is enough turn anyone crazy.
“Did anyone else click the link on that weird email sent to everyone in the company?”
You.
Did.
What?
Despite numerous emails and training sessions discussing just this moment, there’s always an intern or manager who ignores them. They click the link or download the file titled “Win a free pint” from an email address ending @lolmail.ru and suddenly your entire team is on damage limitation.
Now, you’ve worked 3 days straight to clear the system of the hack, your boss is berating you for not making the system more foolproof, and you’ve got to visit HR for calling the manager an idiot for even opening the email in the first place.
Nightmares. Literal nightmares.