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?

  • 4
    You should definitely NOT ignore your boss's explicit instructions. Argue with him if you want to about bringing your coworkers up to speed, but go with his final decision.
    – Hellion
    Commented May 29, 2014 at 21:02
  • 2
    Linq isn't really necessarily a best practice or efficient coding. Neither is threadsafe coding. But in general, you will have to balance the need to have robust code with maintainable code based on your (non-functional) requirements.
    – Telastyn
    Commented May 29, 2014 at 21:03
  • 4
    As long as you wish to earn money for your work, you will always work in some sort of constrained environment. Were that not the case, there would be no need for software requirements. Commented May 29, 2014 at 21:10
  • 1
    Then you should just quit. Your manager is doing his work, by ensuring that the code you produce can be modified by the rest of your team (no matter how briliant you are, you may get sick, take some holidays, leave the job, and the team must be able to keep going).
    – SJuan76
    Commented May 29, 2014 at 21:11
  • 2
    possible duplicate of If my team has low skill, should I lower the skill of my code?
    – user53019
    Commented May 30, 2014 at 1:04

5 Answers 5


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.

  • really inspiring, just for the info, I'm not showing off, I'm solving a problem at hand->naturally, thanks for your answer, really helpful Commented May 29, 2014 at 21:43
  • A think the code review idea is great and makes me wonder if better procedures & communication were in place with this team the OP would have learned about this issue sooner.
    – JeffO
    Commented May 29, 2014 at 23:00
  • "My second draft still requires basic understanding of functional programming...": You pointed out an important aspect: readability also depends on how familiar other team members are with a given technology or programming style. A different programming style (even one that is widely recognized as superior) will likely be rejected or considered too complex by a team that is not familiar with it. The goal of managers is to get a uniform code style that everybody understands (keep a high truck number), using the best possible solution is not the highest priority.
    – Giorgio
    Commented May 30, 2014 at 7:55
  • Agreed, to a point. If I'm on a C# team, but I want to write all my code in F# without getting consensus from my team, that's a problem. Frankly, on the other hand, if someone still doesn't understand a feature like LINQ that was introduced to their bread-and-butter language six years ago, they're not doing their job. That's why I suspect the problem isn't so much LINQ itself, as messily-written or inappropriately-applied LINQ. Commented May 30, 2014 at 14:26

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.

  • believe me, it's not preaching, it's just me stupidly disturbed because i'm giving my best and hearing this weird-feedback, i tend to spend a lot of time explaining things to other and aiding them when asked, but i can't do it all, u understand me right? Commented May 29, 2014 at 21:22
  • @sarepta: A group of co-workers is a team - like a little family. There needs to be mutual trust, friendship, and helpfulness. That's more important than programming techniques. I'm sure you know this, so you're doing the right thing. Then, keep your expectations low. Commented May 29, 2014 at 21:27

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.

  • this doesn't seem to offer anything substantial over points made and explained in a prior answer posted several hours ago
    – gnat
    Commented May 30, 2014 at 11:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.