In the early days, I wrote many blogs about Colin, a Senior Developer who was constantly writing bad code, cutting corners, and saying dumb stuff. After going through some old chat logs, I found a few stories that I don’t think I covered in the blog before:
Two Days For Nothing
Me 13:06:
Colin asked me for help. He says he has spent 2 days on his Work Item
No changes were needed; next!
Dean 13:06:
haha what's the Work Item about?
Me 13:07:
he was baffled by everything. He was creating a template with “Last Entry” field and he was like "why isn't it showing anything"
I said "your selected record is empty"
Misleading Braces
Usually you use braces to group together blocks of code like for an If Statement, or Methods. Colin put his logic on the same line as the “if”, but then used a brace under it. So it looked like the brace belonged to the “If Statement” but it actually did not. We weren’t even aware you could just randomly put braces around code like that.
if ((!criterianValueSets.Any() || hasConcepts)) return hasConcepts;
{
//other code here
Me 10:12:
what a sneaky return. I'm surprised you can have a { after a return like that
Dean 10:12:
so what does the { even mean here?
like why is that code block in braces if it's not related to the if statement?
Me 10:12:
just groups together a random bit of code
I guess technically it is the else
Dean 10:12:
so can you do that wherever you want?
Me 10:12:
I was wondering that
you would have thought code analysis would moan even if it is valid
Dean 10:14:
you can, weird, and it affects the scope too...
is that legacy code where you found it?
Me 10:15:
nope. Colin. always Colin
Node Resolvers
Colin didn’t know about the Accept and Cancel properties on a windows form. His mind was blown
Colin said there were multiple Node Resolvers and he was stripping out Nodes from one of them…then a minute later he says there are only 1 Node resolver and he wasn’t stripping out Nodes. Now Steve is confused because he was calling Colin’s code and was expecting it to strip them out
Open closed principle
Me 15:12:
Colin is making a bit of a fool out of himself, showing a lack of knowledge of programming concepts
I said to him
“do we really need 3 separate methods for this? what about 1 method with a switch?”
So he simply replied “Open closed principle”
So I explained he was actually violating that principle by writing it the way he did.
“If there was a new Node system, you would have to change this dialog. It doesn't matter if you do my suggestion or leave it as it is. To conform to the open closed principle, surely you would need to pass in an object which can return the string. That way if a new Node system is added, you would add a new Node system object, and this class wouldn't need to be touched.
Anyway, merging the 3 methods would be neater”
Dean 15:13:
Urrrgh
Me 15:13:
I also slagged off that class he wrote before
“I reckon that the guy who came up with Polymorphism would be in tears if he saw this class.”
Colin had replied “Is that a complement ? I do not see any problem with it .”
I then emailed him with how to write it, and he now realises I am right
Dean 15:14:
That's good
Bugged Mindset
Colin always gets annoyed when I find a bug in his code.
But when testing miss something he loves it, even though it’s out in live and therefore it looks bad for all of us.
He’s not happy I have logged two bugs for his provenance story
NodeSystemCompatibility
Colin wrote a few similarly named methods but they did slightly different things but it wasn’t clear when to call them, and some returned a different value than what you would expect.
Me 12:45:
CheckNodeSystemCompatibility , IsNodeSystemCompatible
what is the difference?
Dean 12:45:
Lol
Me 12:45:
but don't call IsNodeSystemCompatible for documents, you need CheckDocumentForCompatibility
and CheckNodeSystemCompatibility has a switch that calls different methods and then negates them
case FolderItemTypes.DocumentTemplate:
return
!IsNodeSystemCompatibileForDocumentTemplate(selectedItem);
so if it is compatible, CheckNodeSystemCompatibility returns false
I think we should just delete the branch and pretend it didn't happen
Dean 12:50:
Hahahahaha
Why are they overcomplicating things??
Me 12:53:
they want bugs. it's not even unit tested
Dean 12:57:
What?!
Health and Safety
Me 14:08:
Colin has a wrist rest on the windowledge and it has melted
Dean 14:08:
ha
Me 14:08:
the gooey stuff has dripped down towards the plug sockets
bit of a health and safety hazard
meanwhile, he also had a hot chocolate hidden behind his monitors that stunk of sick
Dean 14:10:
nice
Me 14:13:
Colin claims he got that drink this morning
a bit worrying if the machine is dishing out sick
Me 15:22:
Mel reported Colin's wrist rest incident
the handyman dude is here to save the day
Dean 15:23:
thank god
Multiple Attempts
Me
is this correct? ...we can copy folders if there is one item we can copy, regardless if there are loads which it can't copy?
Colin
my mistake. should be the otherway round. Will change this to "!documentItems.Any(di => di.CanCopy)"
Colin
correction. documentItems.Any(di => di.CanCopy.Equals(false)); lol
Colin
documentItems.All(di => di.CanCopy). sorry my brain isn't working.
Call It Twice
Me 16:15:
bool canCopy = NodeSystemHelper.GetActionsWithProvenance(selectedItem: SelectedItem) != null && NodeSystemHelper.GetActionsWithProvenance(selectedItem: SelectedItem).CanCopy;
if the returned object isn't null, create it again and check a property
classic Colin
Dean 16:18:
Wtf; that's melting my head
i don't see how you can take any enjoyment out of development writing code like that
Christmas has come early
Me 16:18:
seems Colin has left us with 36 failing unit tests
Christmas has come early
Manager 16:19:
want me to get him to sort them out?....
Me 16:19:
are you going down there and punch him in the stomach
Manager 16:20:
gonna stove his head in!!....
No Unit Tests
Me 13:22:
Colin fixed a bug
“Fix bug where protocols created pre-version 1.5 shows N/A rather than the correct value”
On the code review:
“Me
unit tests?
Colin
Not failing”
oh that's ok then. Just fix a bug and don't cover the missing scenario
WHY DO I WORK HERE?
Dean 13:22:
Why would you not write one??
Me 13:22:
it may fail if you write one 😀
No Root Cause
In one part of our application, we always have problems where you select some data in a grid, then the menu bar refreshes multiple times.
This time, there was a bug involving a menu option not becoming enabled until you hover the mouse over it – which was very strange.
Colin then decides to fix this new issue by adding another call to refresh the menu. Brilliant. It already flickered many times – let’s add another flicker!
The lead developer questions this change, and asks him what the root cause was. “This code is complicated, so I didn’t investigate”. Brilliant, totally lazy.
Luckily another developer stepped in and provided the proper fix.
If you don’t understand how the problem came about, then you could end up adding “hacky” code to make it work. But this just pollutes the codebase with more bad code and can cause more confusion and make the codebase harder to diagnose future issues. Good developers don’t cut corners like that.