My Top 4 (Work-Related) Mistakes

When I wrote about my motivation to write this blog a few months ago, among the reasons I described there was the possibility to reflect upon my mistakes later and learn from them.

A crucial part of learning from mistakes is acknowledging them. While this is rather inappropriate for some mistakes (say, having cheated on your wife, especially when she doesn't yet know about it), others qualify for being announced publicly.
I think there are two main functions of such a public confession:

1. You show that you are past the point where you feel ashamed, and are ready to move on.
2. You allow others to learn from your mistakes, which not only helps them, but also establishes a certain level of trust among you

In the light of the above, I will today share my biggest work-related mistakes so far. Maybe I'll share some non-work-related ones in the future as well.

Please note that due to my IT-background, some of these might sound a little bit nerdy. I'll try my best to cover the IT-stuff as much as possible.

My biggest mistakes:

No. 4, Shopping carts

When I was in high school, I was short of money all the time. So, imagine a big shopping mall. On the entrance, dozens and hundreds of shopping carts are available for customers. However, once the customers return with carts full of stuff they don't need anyways, and loaded more of these items into the trunk of their car than fit into it, they obviously don't feel like walking those fifty meters back to the entrance of the mall. No, instead they prefer to leave the shopping carts directly where they parked their car.

So, the shopping carts have to get back to the entrance, in order to be filled with new customer's wishes. The carts being unable to move themselves, somebody is required to push them. And that somebody was me, every Saturday afternoon.

Naturally, you don't only push one cart at a time, because the continuous stream of customers would simply overwhelm you. Instead, you are required to take multiple carts at once, say, 20 to 25.
Strangely, the 25th shopping cart in the front of the queue develops something like its own will, which might be contrary to the young lad pushing it.

Thus, I once lost control over it, and the carts crashed into a brand new, golden BMW, which was parked innocently over there, and leaving a nice scratch along the driver's side.
Now, that would still be understandable; that's not the mistake I want to talk about. Yet, to make it even worse, I thought that nobody had seen me, and simply moved on without informing anybody.

However, when I was called to the information desk five minutes later, facing a rightfully upset customer kind of falsified my former assumption.
Taught me an interesting lesson about honesty, tough!

No. 3, Broke the Build

During my time as an intern in the first software development company I worked for, the senior developer was preparing a presentation of our software to some key-clients the other day. Therefore, he told us to hold back with our most recent changes, in order not to introduce new bugs that close to the presentation.
However, me still being simply inexperienced with version control systems, I could not see the potential harm of a small check-in.

Useless to say, that "small check-in" was not quite compatible with the rest of the repository, and obviously broke the build.

Cost the senior developer half a day, and me a beer :-)

No. 2, Test it faster!

Later on in my development career, I noticed that one of the systems we were developing became increasingly slow the more data we added. Initially, it was fast enough (remember, everything is fast for small n), but the more data we added, the slower it became; to the point, where it was not test- and usable at all any more.

Now, instead of searching for the root-cause of the performance issues, I simply introduced a debug-switch which would prevent loading more than 25 entries from the database at once. Bang, problem solved!

I think you can imagine what happened once we turned that switch off again to test in a real-world environment ....

No. 1, Ignore the need for feedback

Being entrusted with managing my first IT-project on my own, we had to re-develop a legacy system, plus adding certain features. It was agreed that in a first phase, the features of the existing system should be copied, the data migrated into the new system, and the users start working on it in order to give feedback about usability issues. In a second phase, the new features should be added.

However, once we were close to releasing the first version, the client changed his mind and did not want to go to production without the new features.
In strict violation of a very important principle, "version 1 sucks but ship it anyway" (see also here), I was too weak to resist him back then.

Of course, once we finally introduced the full new version including new features, there were still several glitches, because it was the first time users started really working with it. The resulting changes caused a big delay in the project schedule and consequently, it was not quite "on budget" anymore either.


Dear former colleagues and current co-workers, bosses and clients, please excuse both my mistakes mentioned, as well as all the big and small ones I forgot to mention. If you think there is a nice complementary to this list, feel free to leave a comment below ;-)

So, these are my biggest work-related mistakes (so far) ... and what are yours?