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:

  1. he is passing in a parameter “isScotland” then not using it
  2. 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”
  3. 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?

Testing Fail: The Config File

A Tester asked me to send them a Test Harness tool which I had been using the previous day. I thought I can either send them it, or remind them how to download it from Source Control and build it themselves. As it goes, I already had the Test Harness in my shared folder, which I’m pretty certain it was from last time when they asked me for it.

I also remembered that was also the time when they had checked out a folder which had several branches in it, and was building the code from one branch, and looking for the output in another.

Anyway, I send them the link to it, then thought it would be best if I actually give them the config file to point to the test system they are using. So put the file into the Instant Messaging app along with the text “this is the config file I used for the test system”. They accept it and thank me for my help.

Ten minutes later, they tell me the Test Harness crashes and asked if I knew why. I tell them that the Test Harness is a bit crap and doesn’t appear to have any error handling whatsoever. However, when it crashed for me, it was because it didn’t have the correct connection details to the server. So I ask them:

TimeInInts: “did you use the config file I sent?”

Tester: “No”.

TimeInInts: “Why not?”

Tester: “I wanted to use the config file you used, because that one works”

TimeInInts: “but the config file I sent you was the one that works”

Tester: “Oooooooooh right, I thought you were just saying that’s what the config file looks like”

HOW CAN YOU BE SO DUMB? If I was telling them where the config file was, why wouldn’t I simply send them a direct link to the file within the appropriate subfolder? Why would I make them download a file which is a copy of what they have already copied to their machine?

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.

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. Here is a bonus quote:


“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.

Mini Musing #3: The Unconfident Merge

I was doing a bit of Spring cleaning on my work PC, and I came across a folder for an old Instant Messaging client we used to use a few years ago. I found this conversation with an experienced developer.

(7:24:06 PM) ExperiencedDeveloper: hello

(7:24:13 PM) TimeInInts: hi

(7:24:16 PM) ExperiencedDeveloper: you still at office?

(7:24:19 PM) TimeInInts: no

(7:24:51 PM) ExperiencedDeveloper: I need someone to remove Main access

(7:25:24 PM) TimeInInts: surely removing isn’t an urgent thing

(7:25:32 PM) ExperiencedDeveloper: nope..

(7:25:51 PM) ExperiencedDeveloper: all good.. I am doing a merge and don’t want to check into Main by mistake

(7:26:11 PM) ExperiencedDeveloper: all good cheers..


He was so unconfident of his merging skills, he thought he may accidentally check his project branch into Main – instead of updating his branch with Main. To mitigate that, he wanted his permissions to the Main branch revoked.