July 13, 2023 • Josip Ledić • 0 min

Opinions are Overrated. Just Get the Job Done.

Let's talk about something that's been bugging me for a while - the kind of software engineer who puts their personal preferences, coding style, and, yes, opinions, above practicality. You know who you are.

You're the one who takes it upon themselves to reformat every autogenerated piece of code to match your preferred casing style, even though it's going to be overwritten the next time the generator runs. You're the one who writes a Python script to convert camelCase variable names into snake_case in the C# codebase, just because it's more "Pythonic".

I mean, come on! If we were supposed to write the code manually, the generator wouldn't exist in the first place. It's a tool for efficiency, not a canvas for your artistic expression.

Example 1: The Alias Fanatic

Let's take a look at our first exhibit - the Alias Fanatic. This person finds it offensive when the autogenerated code doesn't match their preferred casing style. They go as far as to create aliases for every single generated piece of code, just so it matches the rest of the codebase.

Imagine having the patience to write something like this:

let getCustomer = GetCustomer; 
let getInvoice = GetInvoice; 

... for every single autogenerated function in your codebase. That's not being meticulous; that's being a busy idiot. I have one thing to say to you - drop the aliases, and use the time saved to solve real problems.

Example 2: The Comment Crusader

Next up, we have the Comment Crusader. This person believes that every line of code, no matter how simple or self-explanatory, must be accompanied by a comment.

Here's a classic example:

# incrementing the counter by 1 
counter += 1 

Really? I'm pretty sure anyone who can read Python knows what counter += 1 means. These comments don't help anyone; they just clutter the codebase.

Instead of spending hours writing comments that state the obvious, why not put that effort into writing clean, readable code that doesn't need comments in the first place?

Example 3: The Code Artiste

Finally, we have the Code Artiste. This person sees every line of code as a piece of art. They will spend hours debating the use of a single keyword or the placement of a curly brace.

Here's a fun anecdote. A Code Artiste on one of my teams spent a whole day arguing that we should use a for loop instead of a while loop in a particular piece of code. After hours of debate, we implemented the for loop... and guess what? The code execution time didn't improve at all.

To all the Code Artistes out there - save your energy for something that actually makes a difference. Like optimizing a slow database query, or fixing that bug that's been lingering in the backlog for months.

Example 4: The Architecture Astronaut

Another breed of engineers is the Architecture Astronauts. They are the ones who would want to rewrite the entire codebase in a new, shiny technology just because it's the "future". Even when the current stack is working perfectly fine and meets all requirements.

They'd argue, "But Go is faster than Python!" or "Rust has zero-cost abstractions." Yes, and a Ferrari is faster than my old Toyota, but it doesn't mean I need one to go grocery shopping.

Example 5: The Pattern Purist

The Pattern Purist is another character you might have come across. They have an unhealthy obsession with design patterns. Observer pattern, Singleton, Factory - you name it, they have it. In fact, they have it even when they don't need it.

I remember a piece of code where the Pattern Purist created a Factory for a class that had only one subclass. The justification? "We might add more subclasses in the future." It's been two years, and we are yet to see a second subclass.

Conclusion

At the end of the day, software engineering is about solving problems, not about indulging our personal preferences. So the next time you're about to reformat an autogenerated piece of code, write a useless comment, or introduce an unnecessary design pattern, ask yourself this - are you solving a problem, or are you just being a busy idiot?

Remember, opinions are overrated. Just get the job done.