I've been working in the industry for a bit now and I lead a small team of developers (those are not always the same depending on the project I work on). When writing code I normally receive feedback that my code is very clean and understandable. I try to explain to people how important is in general to write good and clean code but I don't think I ever succeed in my goal.

At first, I used to base my explanation based on my own experience but one way or another I got counter arguments to those, which essentially can be summarized as "nobody cares so why should I". More recently then I took the approach of reading more academic literature on the subject with the hope of elaborating my thoughts better and using more compelling arguments. On one side this worked better in the sense that at the very least I am "heard" but not quite "listened to" yet.

In code reviews, I always see the same sort of badly written code (like too many nested loops, faulty programming logic, overly engineered etc). For example this week everyone was on holiday so I took some of the code over and there's a bug but I am spending most of my time understanding what was written than actually fixing it.

In the past, I was a bit accused of not providing examples so I took my reviews to the next level and beyond and sometimes I rewrite their code or adjust it/refactor it etc. One effect that this had was to arouse feelings of guilt in some developers, they actually apologized for their code, I still see committed code which I wouldn't say is clean. I've been also using some CI tools to ensure code quality, but human review is always required and they miss many things.

Another problem is that despite being a team leader I am still a developer. And managers who deal with customers mainly care about delivering what was promised rather than the quality of the code. Although I understand that in different roles we care about different things it is a bit frustrating not always getting the quality I would like to deliver. As part of my role, however, I have to ensure good practices are adopted.

I don't know if I am taking the right approach here. So I wonder if someone can maybe share some common ways to tackle this problem (which I am sure is quite common, especially among junior developers).


7 Answers 7


I don't know if I am taking the right approach here.

If your current approach isn't providing the desired results, then you aren't taking the right aproach.

Any time you ask people to change their behavior, you must answer the unstated question "What's in it for me?"

If they are correct that "nobody cares", then you will be unable to change their behavior.

If they are not correct, and management does in fact care, you should be able to demonstrate cases where they did care, and point out the specific rewards that follow writing clean code.

You need to show how schedules don't get in the way of writing clean code, if that's actually the case. You must find a way to counter the "managers who deal with customers mainly care about delivering what was promised rather than the quality of the code" problem.

I've seen many cases where one lead tries to emphasize quality, while everyone else emphasizes and rewards speed. If that's the case in your shop, I wish you luck, but don't predict success.

  • 3
    "If your current approach isn't providing the desired results, then you aren't taking the right aproach." - I disagree with that in general. Sometimes it just takes time. Sounds like the OP is making progress and just needs to keep on doing it, maybe tweak it a little, but not try an entire new approach which will then again take months to make an impact. Commented Aug 29, 2023 at 18:25
  • 1
    "You need to show how schedules don't get in the way of writing clean code" - more so, you need to show how writing clean code doesn't get in the way of schedules. And that in the long term it actually improves the capacity of the team to deliver (because modifying code is quicker when it's well written, bugs stand out more when they're not hidden deep in messy code, etc.) - you don't write clean code just to write clean code, you write it so that the team is more efficient. Commented Aug 30, 2023 at 14:39

I think you need a multi-step approach.

  • First, you should for yourself get more familiar with reasoning why Clean Code is important, and what Clean Code really means. I'd recommend Uncle Bob's series as a start, e.g. available at YouTube: https://www.youtube.com/playlist?list=PLmmYSbUCWJ4x1GO839azG_BBw8rkh-zOj
  • Second, spread the word. Either book an external speaker, or prepare sessions yourself. Give your developers a chance outside of Code Reviews to learn and understand these principles. Note that a Code Review is a delicate point, as you are directly criticizing the work of a developer. Humans rarely learn best when directly criticized for their work.
  • Third, what you already started: establish a tooling for helping developers. I personally recommend SonarQube / SonarCloud, where an interested developer easily can learn why a used pattern or block of code should not be used. Also, when set up correctly, it makes the proficiency levels of your teams transparent. Note that you can spend lots of time setting such a tool up in a way that it really helps.

I would also recommend exactly this order, to keep frustration levels low.

  • 1
    I worked somewhere where the team was taken through Robert C. Martin's video series, and this instilled the idea of clean code. But, there was an architect who made this happen, and it was a company trying to build a platform instead of custom sites etc. for customers. Both of which may have made it more appetizing to developers and product owners. Commented Sep 1, 2023 at 13:09
  • 1
    I watched the first video so far. But I was already reading the book. Thank you for this. Commented Sep 2, 2023 at 3:35
  • I've seen this work, but I feel it typically needs guidance by at least one person that has already bought into it and has enough experience to make up their mind about balancing issues. Cause I've seen a few colleagues then veer off into the other extreme, where they take one statement by uncle Bob and run with it to the extreme in an ideological craze, like for example "no we don't put comments, cause uncle Bob says they're bad, I won't agree to this PR with comments in it, remove them!". Just as a warning that one needs to still be involved and look out for...sideeffects. Commented Sep 16, 2023 at 14:41

This question is unanswerable as it stands as because the understanding of "clean code" is very different from one person to the next. Engineers understand "clean code" as "code that does the job" and often include the criteria of "and is as terse as possible". At one time, I worked with an engineer whose code was crunched into as little space as possible so that he could have it all on the screen at once.

Engineers and programmers write code in different styles. Systems programmers and business programmers write code in different styles. It is a matter of style rather than the language or application.

You are fighting the wrong battle. Instead of trying to get people (that you do not manage) to write code in a similar style to yours, the battle needs to be about getting code standards that the business stands behind. The support for coding style needs to come from upper management as a "cost control measure". A standard style of writing code reduces costs as different programmers will be able to read and fix code quicker and at a lower cost.

I saw one company start to address code styles when a manager put out a memo on certain aspects of code. This memo included statements such as "comments, variable names, and module names shall be in English." as a programmer had commented his code in Farsi which nobody else understood. Again, this came as a "cost control measure" as the company needed to not pay to translate Farsi for the next programmer.

  • if the problem is not agreeing on a understanding of a popular concept of one's profession then addressing that is the first step towards clean code - defining what means clean code for one's team. The aims of clean code and what it should accomplish is pretty well defined, so agreeing on team/tooling specific details should be a process professionals can accomplish. While that needs manager support, it feels you want a manager to drive move towards clean code and what it should mean. That sounds to me like CEO trying to tell engineers how to build a bridge such that it lasts 100 years. Commented Sep 16, 2023 at 14:31
  • i.e. normally a manager has no idea and rather needs to be made aware that there is a trade off of getting something fast the first couple of months and getting stuff fast and without issues the next years too and then ideally buys in to some degree of making sure their goals of fast delivery are supported in the long run by having a bit slower delivery in the short run. The details of how to achieve that however are typically not their area of expertise (unless you deal with the lower level of technical managers like OP is...) . I'm saying this to point out how I read your answer Commented Sep 16, 2023 at 14:33
  • and perhaps I misread it - then some clarification might improve the answer. Or maybe I get it right and we just disagree - then perhaps you can improve by fleshing out why management should deal with the details and how if they are not developers they would do that (or one would make them do it). Perhaps it's just the last paragraph that gets me on the "wrong" track because I mostly agree with the middle one as the central bit (but as my essay teachers always said: put your most important argument last and finish with a summary that wraps up your thoughts...kinda^^) Commented Sep 16, 2023 at 14:37
  • @FrankHopkins Management doesn't decide the details, but management has to be behind setting standards - especially since different groups have different of what those details should be. In my experience, attempting to get people from different professional backgrounds to agree on common standards without such management support has not worked. Communicating company standards to new employees is a management function. Remember than in a group of enough people, there will be the 10% who do not want to follow the rules.
    – David R
    Commented Sep 16, 2023 at 15:07
  • okay, I guess the details then was a misreading from your last section where some details were communicated by management as I read it, perhaps put that as an outlier. In general in my experience the management level of OP would be enough to provide that management support - with higher management only needing to support that managers decisions as to how they ensure long term quality within their team but sure higher level support at some level can be helpful. Especially due to the differences though I've rarely seen cross-team rules on what clean code is (beyond platitudes). Commented Sep 16, 2023 at 15:16

Good code is maintainable.

Your example is a good one - when subsequent developers need to modify code, having properly built and remarked code helps the business. "No one ever looks at it" is false. Also, it typically doesn't take any more time to write good code than bad. Poorly built code takes more time to test and change later, adding to the organization's problems of productivity.

Ideally, your business has coding standards that can be referenced. These standards are used during code review to determine what is and isn't "good" code. Here's is an example from my world: do WHERE clauses in WHERE clauses, not in JOIN statements; they may function the same, but one is easier to understand. Code with no remarks and confusing references should be rejected. The developer this happens to won't feel good, but they will learn to do better. Certainly if you're worried about making someone feel bad it's hard to hold them accountable.

  • IME, the longer you work on the same codebase — and have to return to and maintain your own code, especially after long intervals — the easier it is to see the benefits of clean, clear code. And, conversely, much harder if you only work on new stuff. (Also IME, nearly all code can be improved, no matter how many improvements you've made before…) So maybe one approach is to ensure that all developers get at least some time maintaining existing code. And be wary of developers who move between projects too often!
    – gidds
    Commented Sep 14, 2023 at 19:24

Take a structured approach

Implementing change in an organization, even a small one, is a job unto itself. If the ad hoc/informal approach (talking to people 1:1) isn't working, you can try a more structured and formal approach.

  1. Develop a clear problem statement. Avoid terms like "good" or "clean," which imply value judgments that are not defined and are not parsed well by engineers. In this situation I might refer to low code consistency, higher developer ramp-up time, higher risks of defects, or lower development velocity.

  2. Support. Compile a list of examples or some body of evidence showing the problem is real. If possible, come up with an example where different code would have avoided some serious or expensive issue.

  3. Armed with your information, develop consensus both above and below. Your manager has to buy into this problem, and with his support you need to develop consensus with the engineers as well.

  4. Run a brainstorming/solutioning session with the affected teams. This will help with consensus-building as well, as engineers generally prefer ideas for which they feel some sort of ownership.

  5. With the output of the brainstorming session, develop a proposal and action plan. For example, you might suggest the team introduce code reviews or pull requests, or adopt a specific code style guides. It is greatly preferred that the actions and outcomes are measurable.

  6. Get signoff on the action plan. It would be best if everyone would agree to it but if your team is particularly stubborn you might just need to plow ahead only with manager signoff.

  7. Measure results and follow up.

If your team is particularly stubborn, see if you convince your boss to add your metrics to their performance evaluations, i.e. their pay becomes dependent on adhering to the standards.

See also DMAIC.


You made need to teach your management team to suck eggs here. You wrote in a comment

[management agree that] In project X we had an incredible amount of technical debt

and you state that

managers [...] mainly care about delivering what was promised

At this point, you should just need to point out why delivery is slower than it could have been; once you have the support of management it should be easy to get the team onboard.

  • I think to be honest your answer and points are valid but they put excessive focus on management side. My question has more to do (as the tags suggests) on effective mentoring to follow good practices whatever they're. You took one bit of the question and put a lot of emphasis on that. If you work in a kitchen in a big restaurant you want to be clean and tidy even if the costumer doesn't see that and only he sees is the final outcome of your work. Commented Aug 29, 2023 at 16:17
  • 3
    @user8469759 Trying to do anything without management buy-in pretty much guarantees frustration. I've learnt that lesson the hard way in my career. Commented Aug 29, 2023 at 16:37
  • It is literally part of my job (i.e. agreed goals) to get the code up to a certain quality. And again I don't want to put emphasis on management because it has very little to do with my question. Commented Aug 29, 2023 at 16:44
  • So if it's part of your goals, why do you have "managers who [...] mainly care about delivering what was promised rather than the quality of the code"? Commented Aug 29, 2023 at 16:49
  • I don't know the way you work in your company... in mine managers give you goals and you have to achieve those. When they assign a goal is part of my job to achieve it. If they would step in this would become their job and not mine, that's the philosophy. I think the point you're trying to prove is that my question is nonsense cause management doesn't care but if they give me that as a goal it doesn't matter... it becomes my job. What I am highlighting in the question is that management will never step in this issue cause it is delegated to me... (for my team). Commented Aug 29, 2023 at 17:07

There are few things that need to be cleared up first to be able to provide an answer.

In code reviews, I always see the same sort of badly written code (like too many nested loops, faulty programming logic, overly engineered etc

Does the code fit the requirements? If yes, it's not a bad code. It may not be great code, it may not live up to some standard, but if it does what's required of it, it's inherently not bad.

Honestly it sounds like you are in growing pains of first foray into management and there are two clear signs of it:

  1. Struggle to accept that as imperfect as code may be, it's good enough, especially if it's done in different way than you would do.

This comes shining through when you refer to common sense, and XYZ as "the right thing" where there really are no absolutes in this regard.

  1. Struggle to translate up what you want (code done your way) into business problems it solves, and how to then convey it to get support from the management.

Clear example: management says there is technical debt, but the way you want to solve it doesn't pass up the chain. Probably because it doesn't explain how it tackles the delivery deadlines, but instead talks about how better it would be to just do it the XYZ way.

The problem with that? It gives non-technical people anything to hang onto, just some promises (that they heard million times) that only if we rewrite everything to some magical standard, all problems will be resolved and delivery of features will be flying at the speed of light.

There is no single answer solution to your problems, what I do recommend is some management courses, spending more time on the business side and learning to understand their needs. Only then you can properly translate your wants (better code standard) into actual business needs as those need to be accounted for. It will require compromise, this is something you must be ready for, and that's also why you cannot just separate those two topics as they are extremely intertwined.

  • 2
    I downvoted because the idea that "as imperfect as code may be, it's good enough". At my last job I was handed a library of communications code that was shot through with threads, timers, and wait loops. It worked... a lot of the time. I literally spent weeks diagramming and tracing trying to understand it and why it sometimes failed. I finally gave up, sat back and spent a couple of hours thinking about it and got much cleaner, more reliable code. Sometimes bad code isn't a style issue, it's a business issue.
    – DaveG
    Commented Aug 29, 2023 at 15:13
  • 1
    @DaveG you are most welcome to! And sure, bad code can very well be bad for business, but that line needs to be proven. Often enough good code is detrimental to business, and I know more than 1 firm that had serious setbacks over making their code right, one actually dying because of it. Nice, designed and reviewed is ALWAYS more expensive, at least at the start.
    – Aida Paul
    Commented Aug 29, 2023 at 15:15
  • I think, again, this answer has too much to do with involving management. I don't want to find way to enforce a rule since I think it would make things worse. Rather I want to inspire them to do better because good code can only lead to good, and also that's what a good leader should do (i.e. inspire and not boss around). The question has very little to do with management. Although you insist on that side this is more about instillate a better work attitude. Commented Aug 29, 2023 at 16:35
  • 1
    Forgive me for insisting but you're making sound like I want beautiful code, which isn't the case. I gave some examples in a comment I gave in the original question of what kind of issues I am trying to address. There's no "beautiful" here or "tested" is simply "readable for someone else to work on" and common sense solutions to known basic problems. I don't think I disagree that much with what you say but the emphasis is on the wrong subject. It isn't much about imposing the good practices but rather inspire them or motivate them to do better. Commented Aug 29, 2023 at 16:53
  • 1
    @keshlam some would even say that maintaining "unreadable" code is a skill in itself.
    – Aida Paul
    Commented Aug 31, 2023 at 7:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .