The Brogrammer

This week, we have a group of Junior developers starting out their careers. Despite our casual dress code, I find that people usually turn up smartly dressed for the first week. I think only two of these new starters turned up in what could be described as smart-casual, and the others were very casual.

One guy has caught my attention. He turns up late for his first day dressed in a very urban style and wearing a baseball cap indoors. He then joins his team in a meeting, slouched as low as he can. He even brought his Vape to the meeting to charge. I’m gonna deem him The Brogrammer.

For his second day, he opts for a similar dress code, but this time casually rests his stereo headphones on top of his cap, whilst drinking his oversized bottle of Lucozade.

I love how he has made no effort to make a positive impression with his appearance or demeanour. My approach would be to try to be professional until I fully gauge the culture then begin to blend in.

Hopefully, he can be the source of some good stories.

Colin doing a Derek

It was a nice surprise when former team member Colin sent me a review. There was some existing code that basically used an ID to look up some data from a local cache. It was written in a way that implied that one result should always be returned. The ID number does not come from the user, it will (originally) come from the database if you trace the code back far enough.

Anyway, Colin had changed the code to allow for 0 results. Just like the story I told about Derek in https://strangercodingtings.home.blog/2019/02/07/derek-origins/, Colin is basically hiding an error from the user. So began an argument in the review:

timeinints:“if we have an ID, how is it possible that this doesn’t find a result”

Colin: “I don’t know, this is a question for Paul” <link to Paul’s original change>

timeinints:“this is clearly a data issue. Paul’s code works as intended.”

Colin: “My change prevents the crash. I don’t care about it finding a result, the information it retrieves from there isn’t applicable in my case.”

timeinints: “A crash signifies to the user that there is a problem. Preventing the crash hides the problem, and the user will miss potentially key information. Just because your scenario doesn’t use the extra data doesn’t mean you can change it; all the other scenarios require it.

Colin: “Just to explain this problem: The user has a task which they can Accept or Reject. This problem happens if the user Rejects it.”

timeinints: “If they Reject it, should it clear out the ID because it no longer exists then?

Colin: “On further investigation, there are other scenarios where this can occurs. It’s a bigger problem than I anticipated”.

<facepalm> I think it’s quite disheartening that I can spend less than a minute looking at an issue and can categorise a problem better than Senior Colin. Not much thought had gone into finding out the root cause of the issue. He has gone straight to the “paper over the cracks” approach. That mentality is deserving of a demotion to Junior Developer.

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:

  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.