Often I refer to the Pidgin code base as scary. This is because it is very old, has implementations for things that there are libraries for now, is full of tech debt. Most of it was originally written by teenagers and people in their early 20's. In other words, not "professional" developers.
But that's okay. As you all know I was one of those people in their early 20's writing some of that scary code. And now I'm pushing to make that code more friendly. It's way more approachable from all points of view today, but of course there's still work to do.
However, that's not what I want to talk about today. Today we're going to talk about my philosophy when it comes to the attitude or approach I like to take with that code and how it can affect both our peers and ourselves.
I've explained this quite a few times on stream but found myself explaining it again in person and decided that I should really just write this down so that others can see it and hopefully add to it. So without further ado..
We've all been there before, getting frustrated trouble shooting some code and finally go "Who the hell wrote this!?" and immediately reach for our blame tool. We're frustrated and annoyed and we want to be angry at someone for it dammit!
We all know the meme about this, that 9 times out of 10 it ends up being yourself, or something to that nature. But the real question here is, "Why are we so angry about some code?" Sure this code is weird, hard to read/follow, and probably buggy, but why are we so mad at it?
Do we feel like that person that wrote that code was really trying to make things inconvenient for us? Do they have it out for us? Are they lazy? The answer to all of these questions is "who cares?"
In my experience, most developers are trying to do the best they can every day every line of code. Maybe they didn't know of a technique that you're aware of and would be excited for you to teach it to them, maybe they were or are going through some personal things and aren't able to do their best, maybe they're just having an off day and don't want to put up with your shit, or maybe they don't even work or contribute to that project anymore.
Getting angry about this is just nonsensical. It doesn't fix the problem and in most cases it's going to slow you down as you have to calm down. Sure it sucks, but programming is hard and no one writes bug free code that's completely optimal. If someone makes that claim, they're full of shit.
And sure, watching an experienced programmer work can look like magic as they dance their way around writing bugs and memory leaks, all while avoiding the documentation as they have most of it memorized, but this all comes down to practice, so much practice.
So what do I suggest instead? It's easy, just fix the code. Most of the time it doesn't matter who wrote the code, the real issue is the bug and the effects it's having on the people that use your software. They don't care who broke it, they care that it is broken.
But in the case that it does matter, it's more important when they wrote that code. If someone has been working on this code for long time and they're making mistakes, you should be helping them to do better, constructively by mentoring them not humiliating them.
Don't approach them like "Hey this code is shit..." that's going to immediately put them on the defensive and make the situation worse because now they're rightfully going to think you're an asshole.
Instead try something like, "Hey I was reviewing some code in this section and noticed there's better/simpler/easier way to do this. If you're interested just let me know and I can walk you through it when you have some time."
I know a lot of you are probably cringing at this, but even if someone is 100% completely objectively doing something wrong, they're way more open to discussion about it if you're courteous of their effort and their time. Also if you can't be polite to each other, you're probably not going to be working together much longer as well.
This all applies to code review too of course. Many people get anxiety about code review because they identify with their code. This gets reinforced by the blame wars and messes with the motivators to write good code.
Instead of writing good code to write good code which is rewarding, they start writing good code to avoid getting blamed/flamed/put on blast/whatever which is negative reinforcement and just creates contention between peers.
What I'm really trying to say here is, be nice to each other, including your past self. We're all constantly getting better and we are not our old, new, or future code.
And in the very rare case you need to find out who wrote some code and when, use annotate. In most version control systems blame is an alias of annotate and it has none of the negative connotations with it which helps check those micro biases.
I hope you're enjoying these posts! Remember they go live for patrons at 9AM CST on Mondays and go public at 12AM CST on Thursdays! If there's something specific you'd like to see me cover here, please comment below!
Top comments (12)
I guess the thing for me is that it's wasting time that could be better spent on learning or working on something new. One thing that frustrates us the most is "carelessness", the idea that we think people simply don't care, they throw anything together to make it work at 5pm on a Friday afternoon, rather than doing the job properly all day Monday.
I'm one of those people who would rather spend a week doing a job properly than throw some garbage together in an hour and walk away. I guess people like me see others who rush things as "bodgers" who can't be bothered to "measure twice and cut once".
Maybe it's disingenuous to consider people are careless but I think that's the root of the frustration. Which then leads back to your piece, "Does it really matter? Just fix it and move on with your life.".
I understand where you're coming from as I'm the same way, but even when I do the current "gold standard" in a year that could completely change. I even had an example of that this week. reviews.imfreedom.org/r/2738/#comm...
The code base is so old, in fact, that those teenagers are in their 40s now! I think about that from time to time. It's pretty wild. :)
To be fair, I'm in my 40's now too :P
I take issue with this prejudicial remark, and a lot of the really judgmental sentiments contained within this article. Iβve been a professional software engineer for 25 years, starting when I was 16.
You make several good points in here regarding code review and refactoring, but the judgmental remarks really take away from what otherwise could have been a very constructive article about the challenges old code presents.
The code that was written by inexperienced developers speaks for itself, it is not prejudice...
Iβm not talking about the code, Iβm talking about your words.
Okay, what specifically is wrong with the words?
I did highlight that in my initial comment. Your initial paragraph carries with it an awful lot of problematic implications, and then you went on to say that you didnβt want to talk about it.
I donβt think that those remarks are fair or inclusive of younger developers, less experienced developers, or people who do open source work but have a non-programming day job.
No implication, clearly stated, not professional developers. And then it's immediately followed with
I go on later to expand on this topic...
And I added more later with:
I'm sorry I couldn't answer address everything in the opening paragraphs, I disagree with your opinion that it had problematic implications as I didn't imply anything and was very inclusive in the rest of the post.
What's more interesting to me is that the underlying meaning I was trying to get across is that every developer, from the imaginary "10x" to the "non professional ones" are doing their best and people shouldn't be cutting them down regardless.
I totally agree with you here Gary. Mike is basically just looking for things to get offended by.
This is an example of that you can always find something that offends you if you really take your time to look for it.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.