Human Interest

This article was originally published on .cult by Tomasz Łakomy. .cult is a Berlin-based community platform for developers! We write about all things career-related, make original documentaries and share heaps of other untold developer stories from around the…

This article was originally published on .cult by Tomasz akomy. .cult is a Berlin-based community platform for developers! We write about all things career-related, make original documentaries and share heaps of other untold developer stories from around the world!
Building software is what we developers are paid for.
Unfortunately, more often than not were also paid to break stuff, then we get an amazing opportunity to fix what weve broken.
I dont think we talk enough about those stories.
You know how your Instagram feed is full of absolute highlights? Well, its the same when it comes to developer horror stories. Ive heard some which would make your skin crawl. Its funny though, we dont often share these stories.
I strongly believe theres a lesson to be learned from every fuckup. And theres 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 cant I push directly to master? I know what Im doing! sure, but one time Andrew wrote-off two weeks of work off the repo when he accidentally force pushed to master (btw, 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 Im wearing it? Who does this? you know the deal, it happened once now its a continual warning.
Now I want to tell you a story of my biggest fuckup from when I was still a junior engineer.
[Read: Stop counting on tools to fix your work problems]
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 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 theres 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 were 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 the 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 of, crap, what do I do now?
Since I didnt 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 didnt 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
  • but2/3 of our shiny new boards are absolutely bricked
  • the manual needs to be updated as soon as f-ing possible because it may affect our other departments

Luckily he just chuckled and asked me why Id gone and fried the second motherboard immediately after I broke the first one
Lessons learned:

  • Take ownership admit when youve made a mistake, dont 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. its even better to raise an early alarm (even if its false) than to be silent when something is clearly broken.
  • Follow instructions and documentation, but within reason documentation ~can~ will get outdated and a software engineer needs to be able to deal with that. And its probably worthwhile to make sure the docs are up to date.
  • Dont try to hide things that are broken (or suboptimal). Being open with others can bring you a long way, at the very least, itll position you as a trustworthy member of your team.

Published August 3, 2020 — 09:46 UTC