The world needs bad developers, we keep other bad developers from the door

Recently, I watched the show True Detective. In the movie, the main character has a famous quote “The world needs bad men. We keep other bad men from the door”

Have you ever wondered if you are a bad developer?

At some stage in our careers, we all make mistakes. Looking back at the code I wrote when I was a junior developer, I can’t definitively say whether I was a good developer. At that time, my primary goal was to make things function, and I wrote code that achieved that. I felt genuinely satisfied with my work. However, as a senior developer, I can’t help but feel some regret about the technical debt and code issues I created. Over time, as you advance in your career and gain a deeper understanding of the system and tools, the code you once wrote may start to appear less than ideal.

What’s different? It’s you. You continually strive to learn new things every day and understand that in this industry, knowledge is never static. Frameworks receive updates every few months, and new ones emerge regularly. Everything is constantly evolving, and you must keep up with the pace. I’m not suggesting that you need to master every new technology or framework, but you should aim to become a better programmer.

Getting better

I keep reminding myself “You can’t keep doing this! You can’t keep writing sh*tty code and then feel bad about yourself like that makes it okay! You need to be better! Just stop! You are all the things that are wrong with you. It’s not the Agile, or the Code reviewer, or any of the sh*tty things that happened to you in your career, or when you were a kid. It’s you. Okay? It’s you”. Once I embraced this mindset, I ceased to dwell on the code I wrote as a junior developer. I understood that it was the best code I could produce at that stage of my career. In fact, I’m grateful for those experiences because the idea of still writing the same code today terrifies me. It’s evident that I’ve come a long way since then, and I can see the significant progress I’ve made.

“It gets easier. Every day it gets a little easier. But you gotta do it every day — that’s the hard part. But it does get easier”. Understanding that you’ll continually improve, which implies you were less skilled in the past, isn’t a negative realization. The key is that you’re making progress. It might be challenging to discern significant improvement in a single day, but gradual progress leads to becoming the individual responsible for establishing a large, well-structured codebase for a project.

Keeping other bad developer from the door

How does this work? How can a subpar developer prevent other subpar developers from entering? It’s because they’ve been there themselves. Have you heard about understanding the criminal mindset? To truly grasp how a criminal thinks, you need to delve into their world. The same principle applies to coding. To comprehend what it means to be a subpar developer, you must have experienced it. By consistently writing code, you gain the expertise to spot suboptimal code or performance issues at a glance. (for example: the n+1 query problem in Enttiy Framework core), you will understand all the dark side of the industry and help others not getting into it. Just like the dark knight.

The finest developer was once the weakest link on the team. They made mistakes and felt frustrated with the team leader for not approving their code. Now, they’re the ones reviewing code and establishing coding standards for the entire team. Think about Jon Skeet when he first joined Stack Overflow; he had no reputation on the platform, and look at him now, a true legend in the industry, like the Chuck Norris of programming.

The line between good and bad is very thin

I’ve witnessed skilled developers write suboptimal code. Even with over a decade of experience, some choose to copy and paste code rather than refactoring it into an elegant solution. On the other hand, I’ve seen brilliant programmers proficient in concurrent programming and judicious use of locks, yet they maintain everything in a lengthy file. So, what label do we assign to them: bad or good?

You see, there are different perspectives, just like a coin has two sides. How can a person be entirely good or entirely bad?

Don’t set the expectation too high.

Think about the scenario where you’re a small startup company aiming to develop the MVP (Minimal Viable Product). How would all the microservices and complex systems save you money and time? Wouldn’t you prefer a small, monolithic program that could remain stable with the first 1000 customers?

Now, imagine you’re Google, and your technical lead decides to consolidate everything into a single place, violating many best practices. Would you be happy with that? Of course not. Such a move would harm the company’s reputation and result in lost revenue.

One becomes bad because he is not allowed to be one.

I’ve observed individuals who initially deliver exceptional performance, but their productivity declines over time. If you’ve been in the industry for a while, you’ve likely noticed this as well. They are people, just like us, and they also have expectations. Sometimes, people don’t get what they want, and they become frustrated. Employers should be honest about the benefits they offer and not hesitate to invest a significant amount of money in someone who consistently delivers exceptional performance, as this contributes to the company’s growth.

Detach

If you keep punching hard all the time, you may not realize your true strength. It’s important to take the time to review your code critically. Even better, engage in cross-reviews and participate in code review sessions. Contributing to open-source software is an excellent way to hone your coding skills. When you contribute, your code will be reviewed by others, and you’ll also have the opportunity to study their code to learn new things.

“If you don’t remember your lives, you can’t change your lives”. Certainly, it’s not about life itself, but if we were to apply the metaphor of this quote, we must grasp our current level, understand the path that led us here, and determine how to ascend to the next level.

Team leader and writing bad code with impunity

Avoid being a team leader who writes code without seeking reviews because you believe you’re the best in the team. Keep in mind that individuals have diverse perspectives; they might notice aspects you’ve missed. There could be simpler solutions to a problem or more efficient ways to utilize different data structures.

While this is a coding post, I haven’t included any code here. Nonetheless, I hope you found it insightful. If you enjoyed the post, please consider supporting me and following me for future update😉.