Math Formula

Wednesday, June 27, 2012

When Your Boss Calls You, It's Never A Good Sign

My high school teacher in bookkeeping was a nice person, with our well-being in mind all the time. Even though she was a little bit inconvenient occasionally, I'm inclined to think that she did also that with best intentions.
And similar to many of my teachers (I attended a high school for IT and business administration), she had worked in the private sector several years before becoming a teacher.

Thus, she would tell us innocent students a story from the "real business world" every now and then.

"When I still worked in that company, we were afraid whenever the telephone rang and the display showed the extension from our boss.", she began one day.
The story-telling attitude she showed now awoke some of us, as it was known already that at times the bottom line of the story could be interesting. Yes indeed, sometimes even more interesting than continue playing Counter-Strike.

So, one of the motivated dudes in the first row devotedly asked: "But how's that, why were you afraid? Maybe he just wanted to inform you about something?"
"Wrong", she replied, holding her breath for a second. "For it was known, when the boss calls you, it's for one of two reasons: Either he has some nasty task for you ... or he rants at you. When your boss calls you, it's never a good sign."

I'm still surprised about the purity of Management 1.0Theory X attitude shown in that one sentence.

Do you remember #4 of the 13 top habits of how not to manage?
"4. Only contact them when something is wrong, but never praise them" (me)
I think common sense tells you how wrong that behaviour is, so let me propose something else instead:

Respect and credit what somebody is proud of! Do it frequently, at least by showing genuine interest. (me)

It doesn't matter whether it's a co-worker, a child or your parents - all of them will appreciate your interest. Even if it's something small which might seem insignificant to you, for them it's maybe not, so it least praise their effort. Maybe it was done better than the time before?

Whatever it is, let them know ... and mean it!

Wednesday, June 6, 2012

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?

Search This Blog