This article was originally published by Tomasz Łakomy on cult of honeypot, a Berlin community platform for developers. For the latest updates, follow .cult by Honeypot on Twitter, Facebook, Instagram, Linkedin and Youtube.
We – developers – are paid to create software.
Unfortunately, most of the time we get paid to break things too. Then we get an “amazing” opportunity to fix what we broke.
I think we don’t talk enough about these 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 that would make your skin creep. It’s funny, we don’t share these stories very often.
I firmly believe that there is a lesson to be learned from any “crap”. And behind every strange rule your company has is likely to have a funny story. “Why did we freeze a code 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 go straight to Master? I know what I’m doing! “- sure, but once Andrew wrote off two weeks of work from the repo when he was accidentally forcibly pushed to become a master (I don’t make it up, it actually happened in my career).
“Why is there a warning on my shirt that I shouldn’t iron it when I’m wearing it? Who does that? “- You know the deal, it happened once and now it’s a constant warning.
Now I want to tell you the story of my biggest crap when I was a junior engineer.
[Read: How do you build a pet-friendly gadget? We asked experts and animal owners]
Has anyone ordered fried motherboards ?!
Side note: making apps for televisions is wonderful as all you have to worry about is one resolution so we can design whole apps with the position: absolute; because why not! SmartTVs have an entire motherboard (with surprisingly good hardware – we’re talking about multiple core processors and gigabytes of RAM! In a goddamn TV!). At that point in time (2013/2014), hardware was cheaper than software .
When I was at Samsung in 2013, I was transferred to a brand new exciting project: Tizen. I was moved because I had “great” experience with C ++. Apparently two semesters at university were enough to qualify me.
To quote Wikipedia: Tizen is a Linux-based mobile operating system supported by the Linux Foundation, but primarily developed and used by Samsung Electronics.
At the time, Tizen was really up to date (operating systems that are in strong development keep breaking down), but one day we got a gift from headquarters.
Three brand new shiny motherboards with the latest Tizen firmware.
In less than an hour, two of them were fried until they couldn’t return.
Yeah, I literally fried them.
Well, I was told to perform a system update on these motherboards and follow the instructions I was given.
Unfortunately, the instructions in the latest version of the system didn’t take into account quirks, and following these steps made the rather expensive SmartTV motherboard a useless piece of plastic.
After doing the system update on the first board, I knew something funky had happened. Did I do something wrong? I have to, crap, what do I do now?
Not having much experience I decided to repeat the steps all over again, this time to make sure I followed the directions 100%. It turns out I followed them correctly both times.
I could have pretended I hadn’t touched these boards, maybe they arrived broken – honestly, everyone would have believed me.
After all, this was cutting edge stuff, things should break.
But in the end I decided to tell my team leader:
- 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 as this may affect our other departments
Fortunately, he just giggled and asked me why I fried the second motherboard immediately after breaking the first one.
- Take responsibility – admit when you’ve made a mistake and don’t try to blame others for it. Acknowledge the mistake and try to become a better person / engineer after learning a valuable lesson.
- Raise problems early and clearly – it is even better to set off an early alarm (even if it’s false) than to be silent when something is clearly broken.
- Follow the instructions and documentation, but within reasonable limits – the documentation may be out of date and a software developer must be able to handle it. And it’s probably worth making sure your documents are up to date.
- Don’t try to hide broken (or suboptimal) things. Being open to others can go a long way in positioning you, at the very least, as a trustworthy member of your team.