Monthly Archives: January 2018

Should you Fire a Coworker for Making an Honest Mistake?

A while back my hairdresser accidentally cut my ear. It was just a small cut and I hardly felt it but since cuts in ears have a tendency to bleed a lot my hairdresser felt really bad and almost starting crying.

After having driven home with one hand on the steering wheel and the other hand holding a towel to my ear (it’s hard to drive a stick that way), why wife went into conniptions and while she tried stopping the bleeding she demanded that I find a new hairdresser.

“Why would I do that?”, I asked.

“Well, obviously this one is highly incompetent. And she even made you pay 100 DKK for this mess”.

I said: “I am not going to find a new hairdresser. I just invested 100 DKK to be absolutely sure that this hairdresser will never cut my ear again.”

So far I have been right. The nice little scar on my ear reminds my hairdresser to be extra careful and thorough :-).

Once in a while you read about developers being fired for making honest although massive bugs. The question is: Is it the right thing to fire people?

Personally, I think it is the wrong thing to do. Making an honest mistake is not enough to get you fired.

But it all depends on how you handle that mistake. If the person who made the mistake steps up to the plate, takes responsibility and does everything he or she can to fix it and learn from it, then you as a company will not get a better co-worker by firing and hiring somebody else. The new guy might even make the same mistake. It’s also very likely that the mistake happened because the processes in your company are not good enough.

What do you think is the right thing to do?

Some Advice for Beginners

If you are new at programming, here is some sane advice for you.

The list is built from my own experience since we are all newbies at something, right?

The list could be a lot longer but I have picked 7 important pieces of advice that recently have had some relevance for me while mentoring.

1. Have Fun!

Yes, that’s right. This is the first and most important piece of advice. Coding is supposed to be fun. If you are not having fun, maybe coding is not for you 🙂

2. Use Existing Guide Lines

You may be a beginner and you may be in over your head but the sooner you start using existing guide lines such as naming standards and best practices, the sooner your coding skills will take off. Your company may have existing coding standards (they should) and they are there for a reason. Following guide lines and standards will help you and your mentor better understand the code.

Also, your code will probably not pass code review without following existing standards and it is a real pain to fix it all later.

3. Your Code is not a Special Case

I am sorry I have to break this to you but your code is in no way ground breaking or requires special treatment. That means you do not get to use gotos liberally, use inheritance like the world has never seen before, or put all 3,000 lines of your program in the same file.

Everybody else can do without strange constructs and so can you.

4. Read the Error Messages

If the compiler refuses to compile your code, then by all means read the errors messages. They may be cryptic but you might as well get used to them because it won’t be the first time you see them.

Runtime errors can be hard to figure out but the next item on this list may help you with that.

5. Debug Everything

Debugging is really, really, really important. Someone once gave me the advice to always debug through your code. So this piece of advice applies to everybody, not just beginners.

Debugging will help your understand how your code is working. Whenever I write a piece of code I step through it with the debugger, even though it appears to be working. A good way of doing this is to debug through your unit tests.

So, learn how to debug in the programming environment that you are starting to learn. Did I mention that it is important?

6. The Error is Most Likely in Your Code

If your code fails (and it will) it is like 99.99 percent certain that you are the one who introduced a bug. The bug is not in the programming language or in the platform. It is in your code!

So it you think that .NET cannot save files larger that 50 lines or that C# is slow at simple math operations, then you are wrong.

The bug is in your code!

7. Stop Excusing

Everybody seems to make excuses for their code. There is no reason to. Your code has bugs and it could be designed better but I am yet to meet a programmer who writes perfect code. If your mentor ridicules your code, you need to find a better mentor (yes, we are all guilty of laughing at some poor guy’s code).

That’s it. I hope it will make your journey into coding a tad easier.