Hypocrisy by Chris

 I got to do one of my favorite things at work yesterday. The first thing you have to understand is that I'm a gigantic hypocrite. I absolutely hate having my code reviewed. Conversely, I really love looking at someone else's code and offering some ideas or suggestions that they might not have considered before. Yes, I know, I'm a monster who thinks they are smarter than everyone else. I'm working on that. I don't actually think I'm smarter than the people I'm reviewing. (I always think I'm smarter than the people reviewing me. I know that I'm not. Stupid self always gets defensive. I'm working on it!)

Anyways I did two big reviews and came up with some simple and straightforward ideas to make the code more maintainable and clear. That's kinda my jam. I assume that one of the reviews was written in a roughshod manner in order to "get it out quickly" and "iterate" and "learn". I'm not sure about that approach. I mean, love the idea of getting things out and learning. But I don't really love the idea of not refactoring while you go. You can't go fast, and you can't learn, if your code is in a garbage state. Just fix it! It's fun to do! 

The trick to the second review was that "This is how we've always done this" is usually the correct answer, unless you can find a safe and clear way to maintain the current pattern and improve clarity. Specifically, "these public methods must live in this particular 3000 line file" was true, but "therefore all the behavior behind those public methods must also live in that file" was false. Add another class! Call that class from the 3000 line monster. Fewer conceptual collisions! 

I think I did a good job. There's a nagging (like a 2/10 nag here. Nothing serious) concern that all my suggestions are ultimately founded on "vibes" and don't actually contribute to the success of the project. Maybe what I believe to be "good practice" is really just some other human-dude's opinion that I internalized. Was I indoctrinated? What evidence do I have that my ideas actually contribute to project success? Like it feels good when the code is more clear. It makes sense that code that doesn't suck is easier to maintain and build on top of. But really, how much greater is our chance of project success with great code vs poor code? Like 10%? I don't know. The success of the project feels like such a nebulous thing. What are all the factors that influence it? We can't even quantify all of them. We feel like good code matters so we do our best. 

The underlying uncertainty here feels a little deeper. What leads to a happy life? What actions should I take as a parent to help my kids' future? What are the things that matter? 

Well that's enough for today. Might be back later. 

My previous post has five views as of right now. That's about 36 hours. I expect that represents zero humans. This is okay. I will continue to write. For me.