A few years ago, I was talking about D.R.Y. and K.I.S.S. Not the band. The methodology. After the talk, I was taken aback by a young guy asking a question. Something like:

I don’t get why devs don’t write complex code on purpose. If they did, that would guarantee their job in the company, right?

I told him that, by doing this, he wouldn’t last long in my (or any) team. I then started to explain why obfuscating code on purpose is a really bad idea.

Let’s dive in.

Maintainability is Key

Software is not static, it’s constantly living.

It‘s updated, fixed, and refactored, improved…

Obfuscated code makes this loop a nightmare. When something breaks, it’s so much harder to spot, diagnose, and fix the problem.

In the end, this leads to costly delays, frustration among team members and customers, and growing technical debt — a major concern for startups that need to move fast and adapt quickly.

A Collaborative Dead End

Software development is (most of the time) a collaborative effort. Obfuscated code slows down collaboration.

If you make it hard for other developers to understand your work, you slow down the entire team. That will probably lead to resentment and frustration, too.

You’re Not Irreplaceable

No one is irreplaceable. Sure, it may be hard to replace extremely experienced developers or hard-to-find skills.

But if you write code that no one else can understand, on purpose or not, you’re creating a liability (and debt) for your team.

If you were to leave the company, no one would be able to maintain your code. The company would have to rewrite entire sections of its solution: a huge waste of time and resources.

As a CTO, that’s a risk I can’t take. It’s my responsibility to make sure that the project runs smoothly, is maintainable, and is scalable.

Professionalism, Reputation, and Job Security Myths

Coding while respecting best practices and standards is a mark of professionalism. Writing complex code can, and will, harm your reputation among colleagues and supervisors.

Employers value developers who contribute positively to the team. More than those who create unnecessary complexity. No matter how complex your code is, it can be replaced.

Transparent coding builds trust within your team and with your employers. Being known for writing complex code will damage your professional integrity.

Plus, people will be less inclined to collaborate with you.

You and Future You

Even if you work alone, at the end of the day, you don’t. You work with the future you.

I don’t have enough fingers to count how many times I came back to a codebase, read it, and shouted “Who the h*** coded this sh**!?”.
Of course, that was me. Had I taken some time to think ahead, comment, use relevant variable names, etc., I’d have saved myself countless hours of frustration and rework.

Be kind to your future self.

Why Focus on Readability Instead

Instead of writing obfuscated code, focus on writing clear, readable (and maintainable) code.

This is the mark of a skilled developer. It shows that you care about the quality of your work and the success of your team.

Here are some tips I share with my team:

• Use meaningful variable and function names: Choose names that clearly describe their purpose. Don’t make them too long, though. Don’t use abstract names, such as function_a…
• Write clear comments: Explain the purpose of your code and the logic behind it. You don’t need to comment on obvious portions of the code. But if some parts are not self-explanatory, please add a short comment
• Follow coding conventions: This makes your code more consistent and easier to understand. Use your language standards and docs. To make it easier to apply within your team, use linters. To automate the process, work on and deploy an editorconfig all your developers can use, regardless of their preferred IDE.
• Refactor regularly: Break down complex code into smaller, more manageable functions.

Your code will be easy to understand, maintain, and extend. This will benefit your team, your company, and your career.

Conclusion

Don’t write obfuscated code. It’s a short-sighted and counterproductive approach. That will get you disliked at best, and fired at worst.

Instead, focus on readability and clarity, and write high-quality code that will stand the test of time.

Any fool can write code that a computer can understand. Good programmers write code that humans can understand. — Martin Fowler