Worst crimes a Software Developer can commit
After my last article about the Real Art of Commenting Code I received a lot of stories on the matter. I’m grateful for the feedback and everything, but I wish all those people would not forget to like (or clap, whatever Medium calls it) and share, hint hint.
But enough of this passive-aggressive way of promoting my Medium blog. Join me in my (almost) weekly journey, and today we’ll discover the vilest, the most terrible atrocities a software developer can commit. Each of these crimes would be scored from 1 (an officer giving a warning) to 10 (getting electrocuted).
Again, this is no fluffy “do-not-overlook-tests” or “always-be-a-part-of-the-team” list. We’re talking about stuff that can make you lose your client or even go out of business.
Watch your language! (3–5)
In my last article we discussed the proper and the improper comments, but I did not explicitly point out that, well, comments aren’t license agreements: someone may actually read them. And, unlike the Wingdings of ancient Egyptians, the guy who reads your code may not be the archeologist of the future but rather your coworker or a client.
So, it’s always a bad idea to use a word to describe your CTO that you wouldn’t use when talking to him face to face.
“We had a developer who added insults to the code, like, “fu*cking cto”. The Customer saw it but didn’t tell a thing. He started to watch that guy closely and gave him hell for every task that he coded. Finally, we had to replace him”
“My friend got a job at [certain IT company from last article’s Afterword] and he says devs there call each other homosexuals in comments”
This applies not only to comments in the code, but to git commit messages too. What is a simplest and the most effortless way to show off your incompetence and rebel against the oppressing industry standards that limit your creativity? Just make a commit with “1111” message! Or, perhaps, “fixed”?
Fixed what? The lack of vocabulary?
Or how about some transliterated Russian words words that every CS:GO player knows?
Basically, a friend of my friend hired a developer who not only published the entire project on GitHub for the entire world to witness their disgrace (more on publishing projects — later), but also did not hesitate to use some strong language. I checked out that project. To this day I do not know what traumatic childhood experience someone must endure to use snake_case in Javascript in 2019.
Did you notice a trend? First comments, them commit messages. The further we go, the less effort it takes for a customer to know what the developer thinks of them. Finally, there’s good old “go-f-yourself” to the face.
Score: 4–7 for comments, depending on if your client saw it, 6–8 for telling explicitly.
What you should do: if you feel like talking about that would help, go for it. If the guy doesn’t feel sorry for his wrongdoings or gives you “I’ll-never-do-it-again” 3rd time in a row... Are they someone your company needs?
Sabotage
There was a developer who had about 4 years of experience. He would do what he was told (sort of), but if you’d skip some obvious requirement, rest assured that sweet upload form would be designed, as in Figma, but not connected, i.e. no frontend-side file upload code just would not be there.
His motivation was: “I was not told to do it, therefore, I should not do it. I said everything is complete because I did what I was told”.
Taking into account some other clues, I called it sabotage. I got that guy fired within the first two weeks.
One more example was from way back when classes in js were the new hot thing. About a month before quitting, one guy sold the management the idea of rewriting the frontend of the existing MEAN-stack app with this new shiny goodness everyone was so hyped about.
I left that company about 2 months after him, and, although I primarily did the backend, I thoroughly enjoyed working with the abomination he had created.
Long story short, there’s nothing better than sticking classes just for the sake of it while using scope instead of controllerAs to pass data to the template. I remember we were left with Object.assign($scope, this); in every single controller and that made some things unusable. And almost gave me PTSD.
Score: 8–10. They will screw with your projects and screw with your employees.
What you should do: Fire. Fire. Fire.
How to keep my project safe from people trying to sabotage it, one may ask. In an upcoming article about migration I’ll talk about that in more details, but the main answer is: “CTO is your best friend”. Trust them with all important technical decisions, or, even better, wait a week till my article on Migration.
Considering my publish schedule, that would be one week in dog years.
Oopsie!
This may or may not be true because the source is unreliable, so I’ll change the names of the companies involved. I was told by one guy who worked at one big outsourcing company here… let’s call it Eapm, that they had a big project for… let’s call it Thmoson Retuers, and on that project a new QA Automation Engineer was onboarded. He was granted access to a bunch of servers and a script to dump the database and populate it with test data. And by reading this you understand that something went terribly wrong there because this story made it to this list. And you’re right. Allegedly, that guy ran the script against a server he was not supposed to be able to run it against, i.e. the production server, thus removing prod data. This may or may not be true.
If you were Google, you’d probably wish this story wasn’t true either: an intern accidentally running a yellow rectangle ad that cost 10'000'000$ (unless this entire story was one big marketing campaign).
What certainly was not a scam and made much more people wish it never happened was the “I accidentally killed it”. The guy who played around with Parity and made more than 280'000'000$ worth of Ether disappear without any malicious intent.
If that wasn’t an oopsie, I don’t know what is.
Oopsies happen to all of us, famous youtubers and software engineers.
When an oopsie happens on your project, please understand: there are two people involved: the guy who pulled the trigger and the one who loaded the gun.
For example, in the parity story, the infamous devops199 pulled the trigger, but the loaded gun was given to him by the Parity developers. The QA at Eapm pulled the trigger, but devlops’ loaded the gun.
Sometimes, one who loads the gun is the same person who pulls the trigger. Somewhere in 2014 I accidentally ran sudo chown -R `whoami` /. instead of sudo chown -R `whoami` ./ on my laptop, screwing up my Ubuntu installation.
I am sure there are known incidents of the similar fashion in production on large-scale projects, share them in the comments.
Score: 2–6+. I hope you have regular backups, don’t you?
What you should do: This may sound counterintuitive, but you should not fire people over oopsies, unless there’s some 3rd-party that wants blood really really bad. Or it’s you who wants blood — but in this case, none of my advice would make any difference. What’s important is preventing further oopsies.
Make sure people are sorry for what they did. This may sound like a total jerk move, but don’t let your people forget it. Of course, this applies only to big, grandiose oopsies: you don’t want to be that manager that everybody hates. Keep it light-hearted, mention it in a playful manner. Create a board with the biggest fails at your company, but turn it into a meme. Why? To crush them emotionally? Of course not. If the guy takes it seriously, don’t push them too hard. The purpose is for everybody to remember that shit happens.
Sorry for such a comparison, but think of it as an unprotected sex act. She may be on the pill and you may feel it’s ok, but only until you know your friend knocked up his Tinder date.
To this day, whenever I’m running something like sudo chown -R `whoami` ./ I check twice.
Ask what was done to prevent the oopsie from happening again in a few weeks/months. If the answer is “uhm… nothing”, take some measures. What measures? Dunno, don’t pat your devs on the head anymore?
Never within the Deadline / A lot of bugs, always! / very bad code
It’s important to understand, what is the reason of those issues. If it’s not caused by super-tight schedules, vague requirements and you playing with Parkinson’s law to see if that new big feature can be completed within 1 week, then it’s probably the developer.
If procrastination can and should be fixed by stricter management (and even micromanagement in some cases, which I’m totally not a fan of), the incompetence is a different story. I don’t agree with all this “feels-good” BS about firing Competent Assholes because they are assholes and nurturing and teaching Incompetent Nice Guys.
If nice guys finish last, then incompetent ones never finish at all.
I would choose Competent Assholes over Incompetent Nice Guys all day long. Fire the incompetent.
Of course, everything is a spectrum (except one 6-letter word which I’m totally not mentioning on such an overall liberal platform as Medium). There are software developers all across the Competent-Incompetent spectrum. Remember that a software developer should bring your company money. Outsourcing/Startup/Enterprise, hell, even Non-Profits hire developers not for the sake of reducing the number of unemployed. And if the guy keeps bringing you new bugs instead of money, let him bring some new bugs to a new employer for a change.
This somewhat applies to Junior Developers too (I’m making a post about them soon, btw). The difference is the threshold after which you say “Enough is enough”. For Junior Developer this threshold is way higher then for some bloke with 5+ years of experience who calls themself a Senior Developer, or, God forbid, a Team Leader and lacks basic knowledge of the language he codes in (I wish I was making this up). Junior Developers are an investment because you hope they’ll learn from their mistakes and stop making them. Those “Team Leaders”, on the other hand, are to be fired.
Score (assuming it’s not bad management):
- 0–2 for Junior developers
- 5–9 for Middle+ developers
What you should do:
- Manage the procrastinator
- Teach the Junior
- Fire the “Team Lead”
This reminds me of some other similar-sounding instruction:
Not doing their job / Doing their side job
At Xfuturum, I’ve always always focused on delivery rather than micromanagement and the time people clock in. Maybe it’s because I once worked at a company that never enforced the proper working culture: people were working on their side hustles and the UX guy was just watching DotA streams (I think it was DotA). Of course, they did some work, but… let’s call that working style “tranquilo”.
More and more people were hired in hopes to increase productivity, but guess what, increasing your staff count by 25% will not bring your company’s productivity up by 25%. People who previously worked at companies where the culture was enforced, like Wargaming, would come and start working actively. But the more they visited office and saw people coming at 1pm just to go to lunch right away, they would become “tranquilo” themselves.
Score: 8
What you should do: Fix your management. Introduce KPIs. Talk to people. If it’s too late, fire some of them to instill the feeling of “If I don’t get my shit together and start working, I’ll get fired” in the hearts of others.
The guy starts working with your customers directly
So, imagine this: your client tells you they would like to stop working with you. “It’s not you, it’s me” kind of thing. OK, you say. Some time later a lead developer who worked on that project also leaves. OK, you say.
The kicker is, in 3 months you find out by pure accident that the guy founded his own company and now has your client as his client.
“But… muh customer…”
A lot of smaller outsourcing companies here in Belarus & Ukraine (and the rest of the world too, I guess) were founded through this. I was asked to sign the non-competition agreement only at one out of three of my “normal office jobs”. But even with that, with the legal system here it may be complicated or near impossible to take agreement violator to justice.
But guess what, if your outsourcing company is just a middle man who introduces the developer to the client and then steps back to count the cash they mace on that introduction, then you probably deserve it.
Your managers, BAs and your CTO should be such an important part of the deal that it would make no sense for the client to start working with your developer directly.
Score: 6–9.
What you should: Legal action, I guess? Reconsider the way you treat your clients.
Making your precious source code publicly available
That happens more often that you think.
To prevent that from happening, make sure your vendor has strict NDAs with their employees, and/or, as an additional measure, you may sign NDAs with all developers on the project on top of that, just in case.
At Xfuturum we do have good NDAs.
Score: 10
What you should do: If it’s not too late and it’s not your client who found that repo, first contact the violator and ask him to remove it. If they do, and you don’t feel like only their blood would wash away the shame (figuratively, I hope: it’s not 90s anymore and you’re no kingpin… I hope), then you can call it a day. If not, contact lawyers. The source code falls under NDA. Unlike the non-competition thing, there were precedents here that got a few “You-ain’t-gonna-do-shit-to-me” guys down for large compensation for reputational damage or other losses.
If you never signed the NDA, then congratulations, you did it to yourself.
If you have a cool story about crimes of software developers (and I mean real crimes, not like that Java dev who got arrested for growing weed at his apartment), share it with me.
If you’d like me to work with you, hit me up on Linkedin or drop me a line at alex@xfuturum.com.
Cheers!
