Connect with us


What my largest fuck-up as a developer taught me about taking possession

This text was initially revealed by Tomasz Łakomy on .cult by Honeypot, a Berlin-based group platform for builders. For the most recent updates, observe .cult by Honeypot on Twitter, Fb, Instagram, Linkedin and YouTube.

Constructing software program is what we — builders — are paid for.

Sadly, as a rule we’re additionally paid to interrupt stuff. Then, we get an “superb” alternative to repair what we’ve damaged.

I don’t suppose we discuss sufficient about these tales.

Are you aware how your Instagram feed is stuffed with absolute highlights? Nicely, it’s the identical on the subject of developer horror tales. I’ve heard some which might make your pores and skin crawl. It’s humorous although, we don’t usually share these tales.

I strongly consider there’s a lesson to be discovered from each ‘fuckup.’ And there’s in all probability a comic story behind each odd rule your organization has.  “Why do we’ve got a code freeze earlier than main holidays?” — as a result of Mike and Jenny needed to spend their total Christmas Eve migrating the database after a yolo-merge.

Why can’t I push on to grasp? I do know what I’m doing!” — positive, however one time Andrew wrote-off two weeks of labor off the repo when he by accident power pushed to grasp (I’m not making this up, this really occurred in my profession).

Why is there a warning on my shirt telling me to not iron it once I’m sporting it? Who does this?” — you understand the deal, it occurred as soon as, and now it’s a continuing warning.

Now, I need to inform you the story of my largest fuckup from once I was nonetheless a junior engineer.

[Read: How do you build a pet-friendly gadget? We asked experts and animal owners]

Did somebody order fried motherboards?!

A little bit of background earlier than we proceed. In the beginning of my profession in tech, I labored as a Junior Software program Engineer at a Samsung R&D Middle in Poland. I used to be being paid to construct some fairly distinctive apps — my crew was creating JavaScript functions for… SmartTVs.

Facet be aware: constructing apps for TVs is fantastic as a result of there’s just one decision that you must care about, so we might model total apps with place: absolute; as a result of why not! SmartTVs have a whole motherboard in them (with surprisingly good {hardware} — we’re speaking about a number of core processors and gigabytes of RAM! In a freaking TV!). At this level (again in 2013/2014) {hardware} was cheaper than software program [citation needed].

In 2013, whereas at Samsung I used to be moved to a model new thrilling challenge: Tizen. I used to be moved since I had ‘huge’ expertise with C++, apparently, two semesters at college was sufficient to qualify.

To cite Wikipedia: Tizen is a Linux-based cell working system backed by the Linux Basis however developed and used primarily by Samsung Electronics.

On the time Tizen was actually innovative (working techniques below heavy growth have a tendency to interrupt on a regular basis) however at some point we acquired a gift from HQ.

Three model new shiny motherboards with the latest Tizen firmware.

In below an hour, two of them have been fried to the purpose of no return.

Sure, I actually fried the 💩 out of them.


Nicely, I used to be informed to carry out a system replace on these motherboards and to observe the directions I used to be given.

Sadly, the directions didn’t consider a quirk within the latest system model, and performing these steps turned the moderately costly SmartTV motherboard right into a ineffective piece of plastic.

After doing the system replace on the primary board I knew one thing funky occurred. Did I make a mistake? I will need to have, crap, what do I do now?

Since I didn’t have a whole lot of expertise I made a decision to easily repeat the steps another time, this time ensuring that I adopted the directions 100%. Seems that I did observe them accurately each instances.

I might have pretended I didn’t contact these boards, possibly that they had arrived damaged — actually, everybody would have believed me.

In spite of everything, this was cutting-edge stuff, issues have been supposed to interrupt.

However in the long run, I made a decision to inform my crew lead:

  • Now we have an issue…
  • I adopted the directions accurately
  • however… 2/3 of our shiny new boards are completely bricked
  • the guide must be up to date as quickly as attainable as a result of it could have an effect on our different departments

Fortunately he simply chuckled and requested me why I’d gone and fried the second motherboard instantly after I broke the primary one.

Classes discovered:

  • Take possession — admit once you’ve made a mistake, don’t attempt to blame it on others. Acknowledge the failure and attempt to turn out to be a greater particular person/engineer having discovered a beneficial lesson.
  • Elevate points early and clearly — it’s even higher to lift an early alarm (even when it’s false) than to be silent when one thing is clearly damaged.
  • Observe directions and documentation, however inside purpose — documentation can get outdated and a software program engineer wants to have the ability to take care of that. And it’s in all probability worthwhile to verify the docs are updated.
  • Don’t attempt to conceal issues which can be damaged (or suboptimal). Being open with others can deliver you a great distance and, on the very least, it’ll place you as a reliable member of your crew.

Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *