This article was originally published by Tomasz Łakomy on .cult by Honeypot, a Berlin-based community platform for developers. For the latest updates, follow .cult by Honeypot on Twitter, Facebook, Instagram, Linkedin and YouTube.
Building software is what we — developers — are paid for.
Unfortunately, more often than not we’re also paid to break stuff. Then, we get an “amazing” opportunity to fix what we’ve broken.
I don’t think we talk enough about those stories.
Do you know how your Instagram feed is full of absolute highlights? Well, it’s the same when it comes to developer horror stories. I’ve heard some which would make your skin crawl. It’s funny though, we don’t often share these stories.
I strongly believe there’s a lesson to be learned from every ‘fuckup.’ And there’s probably a funny story behind every odd rule your company has. “Why do we have a code freeze before major holidays?” — because Mike and Jenny had to spend their entire Christmas Eve migrating the database after a yolo-merge.
“Why can’t I push directly to master? I know what I’m doing!” — sure, but one time Andrew wrote-off two weeks of work off the repo when he accidentally force pushed to master (I am not making this up, this actually happened in my career).
“Why is there a warning on my shirt telling me not to iron it when I’m wearing it? Who does this?” — you know the deal, it happened once, and now it’s a continual warning.
Now, I want to tell you the story of my biggest fuckup from when I was still a junior engineer.
[Read: How do you build a pet-friendly gadget? We asked experts and animal owners]
Did someone order fried motherboards?!
A bit of background before we continue. At the beginning of my career in tech, I worked as a Junior Software Engineer at a Samsung R&D Center in Poland. I was being paid to build some pretty unique apps — my team was creating JavaScript applications for… SmartTVs.
Side note: building apps for TVs is wonderful because there’s only one resolution you need to care about, so we could style entire apps with position: absolute; because why not! SmartTVs have an entire motherboard in them (with surprisingly good hardware — we’re talking about multiple core processors and gigabytes of RAM! In a freaking TV!). At this point (back in 2013/2014) hardware was cheaper than software [citation needed].
In 2013, while at Samsung I was moved to a brand new exciting project: Tizen. I was moved since I had ‘vast’ experience with C++, apparently, two semesters at university was enough to qualify.
To quote Wikipedia: Tizen is a Linux-based mobile operating system backed by the Linux Foundation but developed and used primarily by Samsung Electronics.
At the time Tizen was really cutting edge (operating systems under heavy development tend to break all the time) but one day we got a present from HQ.
Three brand new shiny motherboards with the newest Tizen firmware.
In under an hour, two of them were fried to the point of no return.
Yes, I literally fried the 💩 out of them.
Why?
Well, I was told to perform a system update on those motherboards and to follow the instructions I was given.
Unfortunately, the instructions did not take into account a quirk in the newest system version, and performing those steps turned the rather expensive SmartTV motherboard into a useless piece of plastic.
After doing the system update on the first board I knew something funky happened. Did I make a mistake? I must have, crap, what do I do now?
Since I didn’t have a lot of experience I decided to simply repeat the steps one more time, this time making sure that I followed the instructions 100%. Turns out that I did follow them correctly both times.
I could have pretended I didn’t touch those boards, maybe they had arrived broken — honestly, everyone would have believed me.
After all, this was cutting-edge stuff, things were supposed to break.
But in the end, I decided to tell my team lead:
- We have a problem…
- I followed the instructions correctly
- but… 2/3 of our shiny new boards are absolutely bricked
- the manual needs to be updated as soon as possible because it may affect our other departments
Luckily he just chuckled and asked me why I’d gone and fried the second motherboard immediately after I broke the first one.
Lessons learned:
- Take ownership — admit when you’ve made a mistake, don’t try to blame it on others. Acknowledge the failure and try to become a better person/engineer having learned a valuable lesson.
- Raise issues early and clearly — it’s even better to raise an early alarm (even if it’s false) than to be silent when something is clearly broken.
- Follow instructions and documentation, but within reason — documentation can get outdated and a software engineer needs to be able to deal with that. And it’s probably worthwhile to make sure the docs are up to date.
- Don’t try to hide things that are broken (or suboptimal). Being open with others can bring you a long way and, at the very least, it’ll position you as a trustworthy member of your team.
