Not Being a Jerk Made Me a Better Coder

I’ve seen a lot of developers talk about their “aha” moment - the time they realized that clean, readable code actually matters. For many, it comes after years of writing messy functions and coming back months later to find their own code completely unreadable. But in my case, there wasn’t a turning point. I didn’t need one.

From the very beginning, I just didn’t want to make things harder for the next person.

Maybe that’s because I didn’t start out writing code from scratch. I started by reading code - lots of it. Code in books, tutorials, Stack Overflow posts, GitHub gists. And what struck me early on was how wildly different the experiences were. Some code was easy to understand, almost like reading a well-written sentence. Other code felt like deciphering ancient hieroglyphics written under duress.

That contrast stayed with me. It taught me a lesson that has shaped my entire approach to writing software: code is a conversation, and the person on the other side is not always you. It could be a teammate, a new hire, or a tired developer trying to fix a bug at 2 a.m. And if I can make their life just a little bit easier by writing clearer, better-structured code - why wouldn’t I?

I didn’t think of this as some noble act or a productivity hack. I just saw it as common sense. If I appreciated clean code when I was learning, why wouldn’t I pay that forward?

Learning from Other People’s Code

My first steps into programming weren’t through building things - they were through reading things. I spent hours going through books, tutorials, and Stack Overflow threads, trying to understand how things worked. And very quickly, I noticed a pattern.

Some code made sense instantly. The logic flowed, the variable names meant something, the structure helped me follow along. Other code felt like it was written just to make my life harder - cryptic names, no comments, no structure. Just chaos.

That stuck with me.

So from early on, I decided that if someone else had to read my code - whether it was a colleague or a stranger online - I wanted it to feel like the first kind. The kind that respects the reader.

The French Touch

Most of my professional experience has been with French companies - and if there’s one thing I’ve learned, it’s that the French are very meticulous. Whether it’s a technical spec, a design doc, or a piece of code, precision and clarity matter.

That mindset naturally extended into the way code was written and reviewed. Code wasn’t just supposed to work - it had to communicate well. It had to read well. That environment reinforced what I already believed: writing clean, understandable code isn’t a nice-to-have - it’s part of the job.

Coding with Others in Mind

I’ve never thought of clean code as some abstract ideal. For me, it’s always been about one simple question: Will the next person understand this without swearing?

That mindset shows up in small, consistent ways:

• I use clear, descriptive names - not just what the code does, but why it exists.

• I structure things so the logic flows naturally, top to bottom.

• I leave comments only when they add context - not to explain what, but to explain why.

• I avoid clever tricks unless they’re absolutely necessary. Clarity always wins.

It’s not about being perfect - it’s about being thoughtful.

Even the AI Appreciates It

Now that AI tools are part of the development process, writing clear code matters more than ever. Whether it's GitHub Copilot suggesting completions, or an LLM helping refactor your code - these tools rely on patterns, structure, and context.

If your code is a mess - unclear names, inconsistent formatting, logic scattered all over - AI will struggle just like any human would. Worse, it might confidently suggest something completely wrong.

So even in the age of smart tools, clarity still wins.

And let’s be honest - if AI ever takes over, I’d rather not be on the list of developers who wrote unreadable code in production.

Final Thoughts

I didn’t need a dramatic turning point to start writing better code. I just kept in mind what helped me learn and what made my life harder—and chose not to pass the pain forward.

Writing readable, thoughtful code isn’t about following rules or showing off—it’s about respecting the people (and now tools) who will come after you. And more often than not, that person is you, just a few months later.

In the end, it's simple: write code like someone else is going to read it—because someone always will.