Simplicity-efficiency tradeoff

The CTO called to inform me of a new project and in the process told me that my code is weird.

He explained that my colleagues find it difficult to understand due to the overly complex, often new concepts and technologies used, which they are not familiar with. He asked me to maintain a simple code base and to think of the others that will inherit my changes.

I’ve put considerable time into mastering LINQ and thread-safe coding. However, others don’t seem to care nor are impressed by anything other than their paycheck.

Do I have to keep it simple (stupid), just because others are not familiar with best practices and efficient coding? Or should I continue to do what I find best and write code my way?

We write code for other humans to read. New technologies are intended to make code easier to read, not harder. There are good and bad ways to use new technologies. If you’re trying to write “impressive” code, you’re doing it wrong.

I suspect it’s not just the use of the technologies that is concerning people. If the way you’re using LINQ made a huge difference in readability, then your peers most likely wouldn’t be whining to the CTO. They would say, “Wow, that looks really clean, even though I don’t fully understand it. That makes me want to learn it better.” Don’t just assume you can throw in a new technology and automatically get code of a higher caliber. Make it a challenge to make using the new technology look clean and appealing.

Take this answer of mine, for example. I wanted to highlight a functional-style solution since no one else did. I think functional programming often produces superior code, but my first draft was terribly unreadable, even though it was concise and well-commented. That bothered me, so I took another crack at it. My second draft still requires basic understanding of functional programming, but is much nicer, if I may say so myself.

My point is if you put more effort into writing cleaner code, your colleagues are going to be more excited about the new technology. If you can’t write LINQ code that is easier to read than the “old-fashioned” way, you shouldn’t use it in that situation. If you can’t tell if it’s easier to read, ask for a code review.

Three things come into my mind.

First: ‘simple’ is not ‘stupid’. Simplicity is the predecessor of elegance.

Second: in your job, the most important thing to do is to be is a team player. Your boss is a team player. Is job is to keep the team together, and that means making your code understandable to your team mates and by that making you a part of the team. It is good that you try to educate yourself and lift up your skills. But within a team that also means: Take over responsibility and share your knowledge.

Third: If you think that the overall knowledge and level of skills of your team mates is not sufficient, talk to your boss about it, offer help, training, code reviews, presentations etc. Discuss possibilities, pros and cons of your additional skills.

Never forget: Keep it simple. Always. Never sophisticated. This ruins efficient work.
Your main goal must be: Combine high level skills and simplicity. That is the art of programming. In fact, it’s the art of everything.

This is a difficult situation.

First, do not get into a negative relationship with your boss, or with your co-workers.
Above all, be positive, recognizing their valuable traits, and being helpful.

Then, see what you can do to expose your co-workers to newer techniques.
If necessary, include explanations in your code, so people can follow you.
Appeal to their higher motives.
Don’t say “You should do such-and-so”, say “This is what I do, and why I do it.”
Don’t preach.

And when it’s the right thing to do – Compromise.

In other words, be a leader.

It seems to me that you were given legitimate feedback from your manager. Not taking anything from it would be a lost opportunity for you. Whether or not your way is right or not your colleagues are struggling. If they’re struggling the company will struggle and you will struggle providing tons of support when they’re trying to debug, extend or otherwise maintain your code.

Definitely do everything you can to mentor them to be better developers, but also take the opportunity to review your coding practices. Ask yourself:

Am I over-engineering this?
Am I optimizing too early or too much (why design to support a million users if you know the user base will always be much smaller)?
Am I trying to appear “clever” with my solution? Don’t let ego drive you to unnecessary complexity or obscurity

I catch myself being guilty of all these things from time to time and find asking myself these questions helps keep my code simple. Just remember simple and efficient are not mutually exclusive.

As great and efficient as new technologies are sometimes, efficiency goes down the drain if your team has to spend hours on trying to understand your code.

Neat, structured and simple code is the easiest to maintain, which makes the team and business more efficient, therefore more profitable.

Implementing or just keeping up with new technologies/methods are definitely important, but if it comes at the cost of getting things done, then more focus needs to be placed on getting everyone else trained up, otherwise nobody wins.

Ultimately, it’s your bosses call, which means you’ll have to convince him, that it’s the best for the business.

Filed under: softwareengineering - @ 03:55

Thẻ: code-reviews, coding-style, complexity, efficiency, teamwork

Thiết kế website giá rẻ

Danh mục

Simplicity-efficiency tradeoff