King of All Excuses: Part 3

I’ve written blogs about an employee which I referred to as Beavis, due to his grunt laugh. He is a complete liability and I don’t know why we didn’t sack him ages ago. His constant excuses why he cannot work are obvious lies. He came up with loads when we worked in the office but then when we started worked from home during lockdown, he had a whole new set to go through.

I understand some people can have some bad luck or them or their family members can have health issues, but is it possible for him to be hit with such frequent illnesses and issues?

Check out Part 1 and Part 2.

Here’s around 3 months of excuses.

Mobile phone has problems so can’t use authenticator to connect to VPN
Broadband is too slow
Needs to take his wife’s car for an MOT
Laptop broke
Antibiotics for his dog
Drove down to the village to see the extent of the floods
Optician appointment
Broadband not working
Cracked Laptop Screen
Oven repair
Daughter’s sports day
BT Broadband outage
BT Broadband outage again, and phone tethering won’t work either.
Builder is looking at some “snagging issues”
Throat glands have all swollen up and I’ve lost my voice
Emergency dentist work
Check up following dentist work. Will take an hour total travel, waiting, then dentist time. So at least 2 hours.

A colleague was saying that his line manager isn’t very active so therefore he can send him a message saying that he isn’t coming in, then Nigel won’t have replied to accept his request.

“he uses Nigel’s inability to reply to his advantage”

Isobel: "I have been in contact with Beavis who did the work but he has had to take the day off unexpectedly"
Andy: "is it actually unexpected at this point?"

Other People’s Excuses:

“randomly I’ve just got to move some bales of straw. back soon”

Zoe

(one of the top manager’s wife, so gets a bit of leeway to do what she wants):

cleaning dining table
having a shower
in garden having beers

Derek

(also notorious for slacking. I suspected the occasional lie from him too):

I’ll be working from home today, a leaky shower box is causing an unintended indoor water feature, so I’m hanging around for a plumber. Don’t forget to skype me for the stand-up 😉

I’m working from home today. Sorry I haven’t emailed sooner, I had some problems initially remoting in as my computer at work had a dicky fit.

4 Year Special: Derek

It’s been 4 years since I started writing this blog! how time flies.

The original inspiration for the blog was to tell stories about my incompetent colleague Derek. However, he left shortly after I started writing – so I didn’t end up writing many blogs about him.

After going through some old chat logs I found, I have dug up some extra stories, code snippets, and quotes.

“There’s a lot of duplication here, surprisingly. Functionally it is probably quite a big bag of spanners”
Derek

Hypocrite

When I first started working with Derek, I was telling my manager about the things he was doing and saying. My manager asked me how he is getting on to see if I had more stories to tell.

Matt:
How is Derek getting on?

Me 10:36:
on holiday, but he has spent a week or so sorting out some buttons. He has assigned two items to himself. 

So he complained that the User Stories were too big, so we have split them up a bit more. Yet he then assigns 2.

He hasn't sorted out all my comments I made on his last fix.

After Derek was making excuses that he wasn’t productive due to the size of our planned work, we split it into smaller chunks for his benefit. He then picks up multiple chunks in addition to also needing to rework his previous work. It seems we didn’t need to split the work up at all.

Redefining a boolean

bool hasSelectedReports = SelectedReports.Count != 1; 
bool noReportSelected = SelectedReports.Count == 0;

A boolean or “bool” for short represents true or false. Since there are two states, if you created a variable called “hasSelectedReports” you can invert it using the ! (not) operator, so saying !hasSelectedReports reads as “has no selected reports”. Derek decided to create a variable for the inverse, but then he got the logic wrong: If Count is 0, both hasSelectedReports and noReportSelected are true!

“I’m working from home today. Sorry I haven’t emailed sooner, I had some problems initially remoting in as my computer at work had a dicky fit.”
Derek

Pointless Conversion and check

return !String.IsNullOrEmpty(ConceptId.ToString()) ? ConceptId.ToString() : null;

ConceptId is defined as a long ,which is a number. It can represent any whole number between -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807. It cannot be null/empty. By default it will be 0. Here, Derek converts the number to text (string) so he can take advantage of the IsNullOrEmpty method. If it is somehow null, we will return null… apart from if ConceptId was somehow null, calling ToString on it would crash.

If he really did want the text presentation of the number, this code should simply be

return ConceptId.ToString();

Pointless Conversion and check: part 2

if (!String.IsNullOrEmpty(conceptId.ToString()))
{
   	_conceptIdInt64 = Convert.ToInt64(conceptId);
}

Again, Derek decides to convert the number to a string so he can check it isn’t null. It is always true, so then goes into the code block. He then converts the long to an Int64. A long IS an Int64. It’s just an alias for it. So the code is completely pointless, other than assigning a simple variable.

“I may have taken too much artistic licence”
Derek

If at first you don’t succeed, try again

public Entity GetEntityFromConceptId(long conceptId)
{
  	return 
  	  	(EntityFinder.TryGetEntityFromId(conceptId)) != null 
  	  	? 
  	  	EntityFinder.TryGetEntityFromId(conceptId) 
  	  	: 
  	  	null;
}

When methods are named “Try”, it means that it might not be successful and can return “null”. In this case, TryGetEntityFromId returns null if you pass in a conceptId that doesn’t exist. So you should check for null, and do something different, maybe display an error message to the user. Although Derek decides to simply try again. Why would it work the second time?

(frustrated tone) I’ve spent 5 days on the same work item
Derek after 13 days trying to implement a simple feature. For the previous 3 days, during the daily stand-up meetings, he was saying he is “nearly finished and it’s pretty much ready to check in”

Conclusion

As you can tell from these stories, Derek made some bizarre choices and generally seemed deluded. There were times where I thought he had to be trolling, because there is no way you would write so much redundant code. I understand you can have bad days and have the occasional moments of madness, but it was a daily occurrence with Derek. For more stories about Derek, click the Derek tag.

Derek: 0 Points

I made this blog primarily to talk about Derek and I seem to have convinced myself I had already written this story, but it seems I haven’t.

I have often thought about how to measure a developer’s performance and it seems an impossible task. The best idea I had was to somehow assign the same work to 2 different developers and see who writes it faster, who writes the cleanest solution, and if there are any bugs in the produced code.

There was some work where Derek had to add a new user control in a certain condition. He had spent over a week on it, then kept on ranting about it in the stand-up meetings. He kept on saying how it was too big for one piece of work and we should have refined it more. I told him he could have split up the work into small Tasks and completed them separately. There was nothing stopping him doing so, but he kept on using it as an excuse. “It’s too big, my focus keeps jumping between many files as I add code here and there”.

It got to the 11^th work day, and he said he was on annual leave in the afternoon, and he was trying to solve an error but he didn’t expect to get to the bottom of it. I told him to write down his findings, and shelve his code. I would take a look at it in the afternoon when I was free.

He doesn’t bother sending me any explanation of the problem, but it’s not a big deal; I’ll grab his code and test it out.

I take his code and look through his changes. He has changed way more files that I anticipated. He has put the main part of the code in a file I didn’t expect. The code that looked reasonable still needed to be tidied up.

I reverted his changes from several files, moved his main code to a different location, refactored the code so it was clearer, added the rest of the features that were mentioned in the user story. The next morning, I did a bit more refactoring, added a few unit tests. Job done. 1.5 days compared to Derek’s 10.5.

You may tell me that he gave me a head-start. I would argue that I wasted time trying to understand his code and I ended up deleting the majority of it, and the bits that I kept – I could have written within minutes anyway. It would have probably been quicker if I had started from scratch.

When we actually planned that piece of work, I expected it to take 5 days. In hindsight I was wrong; it was only 1.5, but Derek took 10.5 and moaned it was too big. 10 working days is a full 2 week “sprint”, and he failed to deliver any work during that time.

If you wonder how much better I am than Derek and wanted some kind of measurement, I reckon I am 9 days better. My solution met the requirements and there were 0 bugs.

Bye Derek?

Recently, Derek has been “Working” From Home due to not being able to drive to work. After we finished the development of our project, the developers needed to chip in with Regression testing. We had a chart to track our progress, and I thought that would motivate Derek to work; but that wasn’t the case.

After 3 days, I looked at the chart. I had ran 35 tests, and Derek had run 3. What has he being doing? Obviously not working. Anyway, days later, he announces he is leaving the company. OK, that makes sense, he was out doing job interviews in company time.

Our company has many employees that have left and then come back at some point. So even though it is sad that Derek is leaving, I believe he will be back. I’ll give him 3 months. I assume he will be on a probation period, and I’m sure if a company thinks they are getting a Senior and then Derek turns up, they will be backing out of that deal. Then Derek will come crawling back.

The two main inspirations for the Colin character have moved teams, so in that regard; the blog has taken a massive hit this month.

On the positive side, I’ll be starting a new project soon and will most likely be working with new people with new technologies.

It’s quite possible the blog will be a bit quiet for the time being. But hopefully it’s not the end.

Small Project: Complete

So after we finish our long-lasting project, myself, Derek and the Junior Developer were assigned to a small project. This involved adding a few fairly simple extra features. Derek was assigned to lead this small team.

I thought it would be interesting how Derek takes on the challenge, since in a smaller team, his incompetence would be more obvious. Sadly for the blog, he did pretty well. As a side note, since I wasn’t working with the main inspiration for Colin, and he is moving teams; there’s a lack of Colin ideas for the blog too. For whatever reason, external teams stopped sending me code to review too; so I have been a lot focused on my own work.

Anyway, as we neared completion for the final development work, we were relying on a third party to provide us with an API call. It was a simple true/false value we needed, and if it was true, we would display an icon next to the data items. As a temporary solution until we got the new API call, we chose a property which would roughly give us a 50/50 split of true/false values. That way we could check in our changes and see the icons next to a decent amount of data; a representation of the final product.

Anyway, by the time we got the new API call, Derek had booked a week off. That wasn’t a problem since all I needed to do was switch out everywhere we used the temporary property and use the correct one. Easy task. However, I changed all the places and one feature wasn’t working. Just so happens to be the only place where Derek didn’t use the agreed temporary solution, and chose a property that was always true, so always showed the icon.

In all the other places where we use it, once the data is there, it is never changed. However, this particular control, you can select a data item, then change it for a new one. Therefore the image should show/not show depending on your new selection. Of course, we couldn’t see that this feature didn’t work because all the items were always showing the icon.

Did he use the wrong property to intentionally cover the fact it didn’t work? Of course he did. I thought it would be easy to change, but the control had all kinds of dependencies and it wasn’t designed to refresh the image on a new selection. Took me the whole day to sort out. Massive twat.

Understanding Key Points of a Project

(I had this blog drafted up last month, but didn’t finish it. Anyway, here it is.)

In this blog post, let’s say one of the main features of our Project (that has lasted over 1 Year) was Identification Numbers. These Identification Numbers have a certain format so some are easy to identify as invalid.

Derek posted on our team forum if anyone knows if some Identification Numbers were invalid or not. Our Lead Developer saw me looking at the post and he goes “It’s not like he has been on the project a year or so, is it?” and he shakes his head in disgust. I joked “shall we tell him to ask a developer?”, and he said “he should ask a Senior”. Banter.

Recently, I was looking at some Test Cases that Derek had run. Derek is the kind of person to be oblivious to a lot of things, and I’m the opposite. So I know that he has no idea that the testing software has a keylogger. If you run the Test Case in a certain way, the software will create a text file and attaches it to the test results. That way, if you come across a bug whilst running the Test Case, you have some reproduction steps of what you clicked and typed. Anyway, in I go, snooping for lols.

“I know this sounds dumb since I have been on this project a year or so, but I don’t know a lot about Identification Numbers”
Derek in an Instant Messaging conversation to a Tester.

Classic Derek. He is incompetent and he definitely knows it.

Care

After I write some code, I always test and inspect it thoroughly. I’ll write Unit Tests, running manual tests, constantly reading and re-reading the code. Any slight change I make, I then end up repeating the process. Even when I’m about to send it to review, I get paranoid that I’ve missed something, so end up looking at the files again to make sure.

It’s often rare that I get any (serious) feedback to change my code, and it’s rare that Testers will find anything wrong with it. But then sometimes I wonder if I’ve spent a little too long in the development stage.

However, Colin and Derek seem to take the opposite approach and end up coming out with something more quick and dirty.

Derek always seems to come up with a solution close to a hack which I’ll tear apart in the Code Review. After, it will end up being rejected by Testing and he will put in another bodge.

Colin spends time writing Unit Tests but often misses some scenarios. His methods often need refactoring down more, and methods/variables/classes may not have the best names. His solutions still come across as rushed, and he seems to cut more corners when the deadline approaches. When I point out his mistakes, he often says “the deadline is tomorrow night, so I just have to get it checked in”.

But surely it’s useless if it doesn’t work? In a similar fashion to “it’s better late than never”, you could say “it’s better that it is late and works, rather than getting it early and broken”.

He got some comments last week to refactor some of his methods. He quickly changes them and submits his new method for review. It was a one-line method, and somehow there were 3 mistakes in it. The thing is, he had Unit Tests covering every possible scenario of that method; he just didn’t run them. Unit Tests take a several seconds for a large batch of them to run; why would you cut corners so much that you don’t even run the unit tests? If you had full coverage, it will allow you to cut manual testing, but to cut testing completely? Madness.

Anyway, his code was something like this:

public string DisplayInfo(bool isScotland)
{
 return DisplayInfo(Configuration.Scotland==Configuration.Scotland); 
}

The 3 things that are wrong:

he is passing in a parameter “isScotland” then not using it
where he should be using “isScotland”, he is calculating it…but wrongly. He is comparing a value to itself; so it always evaluates to “True”
The method just calls itself, which calls itself, which calls itself…until it crashes with a StackOverflowException because it’s an infinite loop.

Absolute Junior-level coding.

Reading code

“When I get a Code Review request, I always open it. If it is a one line change, I click ‘Looks Good’, otherwise I’ll close it and let someone else deal with it”
Derek

Derek said this in jest, but the thing is, it is actually true. Derek avoids doing Code Reviews because he just wants to write code, or simply chill out. Or that was my interpretation anyway.

Developers should always partake in Code Reviews. It helps enforce Coding Standards, and helps your team learn from each other. It’s also mandatory for our code to be approved before we can commit it, so it’s good if is done promptly.

It winds me up that Derek never does them (well, it’s a rare event). It was part of his job as a Developer, but he is a Senior; so it is definitely part of his job.

Anyway, shortly after moving over to Git source control, Derek calls me over and asks me how he can grab the code from the Pull Request (Git’s nomenclature for Code Review) so he can test it out himself. I was quite shocked he actually was looking at one. Anyway, he comes out with this quote for the reason he wanted to test the code out:

“Some people are better at reading code and understanding it than others”
Derek

He was stating a reason he doesn’t do Code Reviews is that he finds it difficult to read code, and can only really understand it if he can step through it using the debugger.

The thing is, reading code is a major part of what a developer does. I think it’s a huge struggle if you can’t work things out and picture how it pieces together simply by reading. Sure, debugging does help, and is required with more complex and abstract areas… but; a Code Review is usually a small change. The changes are clearly highlighted with the editor with a Before and After view, with the colour Green showing additions and Red showing deletions. It will be linked to a Bug report so you know the Developer’s intention. They will (or should) have written a good Commit Message which will show in the History when they check it in. What extra help does he really want/need?

Delegating/Shirking Responsibility

As a developer, we are paid to fix bugs or introduce new features. So as long as you are asked to write in the language you know, it seems silly to turn work down. The exception to this is if part of the code-base requires a high amount of domain-specific knowledge.

We do have a few areas that are like that, and we end up keeping that knowledge with a small group of developers, and in some extreme cases; just a single developer. If that developer leaves the company, then there’s trouble.

I think there has only been one situation where I’ve been asked to fix something, and I have declared it to be a bad idea. It was in an area of code that basically works in 99% of the situations, and if you change it; you are almost guaranteed to introduce a new bug (or many). It’s a really important area of the system, a manager was stating it had to be fixed within a few days; piling on the pressure. I put up a good argument to wait a day for the Lead Developer to return from holiday. A gamble; but I could take the pressure off myself, reduce risk of mistakes, and I could pass on the responsibility.

It was a brilliant idea in hindsight. He came in, I explained the problem and he managed to come up with a really understandable solution within an hour. Worked perfectly; crisis averted.

There’s been plenty of times where there’s been really standard, low risk bugs and Derek has been asked to fix them and he has said “I don’t know much about that area, so I’m not best placed to do it”. But it’s a bit of a paradox, because if you don’t look at the code, and don’t learn about functionality, then you will never know it, and will always come up with that excuse.

“that’s the limit of my knowledge, so I draw a line under it and move on.”
Derek

A few days ago, in the stand-up meeting, our Team Lead asked Colin if he could help pick up one of the bugs. Again, it was a standard bug and he said “I don’t think I should pick it up, I think Sam should do it.” The thing is, Colin is a Senior and Sam is a Junior; a couple of ranks below him. When you think of it in those terms; it is just absurd. Sure, I understand Colin’s point that Sam may know which files the problem may reside in; maybe Sam has even introduced it! But, is there really a situation where a Junior is in a better position to fix something than a Senior?

In my opinion, delegating down makes you appear silly. Delegating up alerts people to the severity of the problem. You’ll just look silly if it is actually a simple problem.

Commit Messages

Now that we have moved to Git, our Lead Developer seems to be making more of an effort to promote good “commit” messages. Over the last few months, we have joked about the quality of some of the commit messages in TFS, and how useless and frustrating they are.

“Fix bug 1756”
“Address code review comments” 
“correct previous check-in” 
“fix crash”

All of these don’t describe what has happened, or why the code has changed. With any code change, you always know it has happened to fix a problem, be it: a crash, performance issue, or refactoring to make the code easier to read.

There’s plenty of times when I’ve been investigating a bug, and you track it down to a particular file. Then you view the history of the changes to try and understand at what point the bug was introduced. When you are greeted with any of the examples stated above, then you have to look at each change and look at the linked Work Item (Bug Report). It’s great when you can just glance at the commit messages and can jump straight to the most likely culprit.

Say you are investigating a issue with Threading and you see:

“Minor refactoring of the DisplayInfo method”
“Change threading to use a threadpool” 
“Add null check to prevent crash after clearing data”

You can then just jump straight to the change that clearly states there’s a change regarding threading.

I overheard the Lead Developer tell Derek to write a detailed commit method for his latest change and he says “seriously? I never write a detailed commit message; linking a Work Item is enough”.

I was face-palming. Surely, with a few months development experience, you will learn that good commit messages are very helpful. You could argue it only saves a few clicks and a few minutes here and there; but why make your job, or other people’s jobs harder?