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!