This question was inspired by this one. While that other question was deemed localized, I believe the underlying problem is something that is extremely common in our industry. I know there are some developers, who will read this and think I'm making this stuff up and then they might reply how everyone cares about their work and wants to learn, but just looking at other Programmers SE posts (case in point), I know that's not universally true.

So let's say you have someone on your team (or maybe majority) who's standard operating procedure is to copy/paste and who believes that everything can be solved if only you add enough function calls and variables. This person never heard of TDD, DRY or SOLID and outside of 40 hours at work when they are busy working, they never once read a single methodology/pratices/design book.

In the past I (and others) have asked, how to do you teach OOD. But now I'm thinking that's not the right question. The real question is how do you approach such a person/team and make them curious about better way of doing things? How do you inspire them to learn? Without that, it seems that all the teaching, meetings, lectures, discussions are useless if they are perfectly happy going back to their desk and doing what they've always done.

I work with a bunch of people like that. They are actually quite bright individuals, but I hate when I hear, "I'm done coding, just need to refactor and split into multiple classes to make DXM happy". They don't refactor for cleaner, readable, maintainable code, but only because otherwise they'll get scolded. I know they are capable of learning, just seems that there's a general lack of motivation.

When I deliver work, it generally has way fewer bugs and the work I owned never became 5000-line monstrosity of a class. Other's would make comments like, "your code is much cleaner and readable than our stuff", so they see the difference. But at the same time, I feel like they believe they get paid for 40 hours regardless of what they do, so they actually don't mind if they spend 3 full days in QA looking for a bug that shouldn't have been introduced in the first place. Or that they take a week to modify one class because there are so many dependencies they end up touching. The though, "maybe that class should have been written differently" never seems to pop up.

Can anything be done in these situations? Has anyone succeeded? Or is it best to isolate such mindset to non-critical parts of the project and minimize the damage?

NOTE: When I say "lack of motivation". I don't think it's lack of motivation to work or do a good job because they simply stopped caring. Most of our team is actually quite the opposite. They definitely care about the product. We have guys that will work nights and weekends. The part I'm trying to get through is with improved habits and skills, they actually wouldn't have to work as much. I guess that "40 hours" thing made this post sound a little too negative.

  • What country is this?
    – user1249
    Commented Dec 27, 2011 at 10:21
  • 3
    @ThorbjørnRavnAndersen - USA. now you have to write a response because I'm very curious how that piece of info affected it :) I always though we were all human and this type of stuff was universal. And no, this question has nothing to do with outsourcing.
    – DXM
    Commented Dec 27, 2011 at 10:45
  • 8
    Cultural differences between countries can be substantial, and any attempt to introduce change must take this in account. What works in one culture will most likely not work in another. In your case I believe the best way is to have management officially raise the bar of what is acceptable.
    – user1249
    Commented Dec 27, 2011 at 14:59

7 Answers 7


You found yourself the reason: "I know they are capable of learning, just seems that there's a general lack of motivation."

There are people who are passionate about their work. And there are others who, being sometimes competent enough, are working just for money. They know their stuff, but they don't enjoy their work. They will not spend extra time doing additional refactoring to make code readable or solving an intriguing problem when a quick and ugly hack can do the job.

This phenomenon exists in every job. It's just that some jobs are not extremely exciting (have you seen an accountant who loves his job and dreamed about it already when he was a child?), but in programming, there are plenty of people who really love what they are doing (otherwise Programmers.SE will be pretty empty). This means that as passionate developers, who talk daily to other passionate developers, we have more chances to be surprised seeing a person who does programming just for money.

What can we do? Not too much. In all cases, it's not to you, but to the human resources to choose people who are truly motivated¹. And fire people who are not.

You can try to motivate your colleagues yourself, but it's extremely hard. If you give them books to read, they will return them unopened a few weeks later. If you give them an advice, they will not listen, because they don't care².

You can:

  • Convince your boss to set a number of strict rules in your company: style guidelines, etc. This will not motivate those people to do a better job, but at least they will not be able to commit source code which doesn't match the requirements.

  • Work on the requirements, especially non-functional requirements. What about a requirement which tells that a specific project must contain less than 5 000 lines of IL code (no, I'm not talking about the meaningless LOC)³? What about requiring to obtain specific results at cyclomatic complexity or class coupling?

  • Increase the number of hours you spend in your company doing code reviews. Specify what is reviewed: if you have a checklist, add the points related to refactoring, readability, clean and useful comments, etc. If you don't have a checklist, you must.

  • Use [more] pair programming. It may help improve the code quality and motivate the less motivated coworkers.

  • Use the compensation system similar to what is used at Fog Creek.

¹ That's what interviews are about: before hiring you, the human resources must asset not only your technical level, but also your motivation. Sadly, some companies forget about this second part of the interview, and hire people who don't enjoy programming too much. Happily, in most cases, the work in those companies is never enjoyable, and Joel test rarely exceeds 2.

² They really don't care, even if they gain less money. I'm pretty close to one of my customers (I'm a freelancer) who believes that his work is to develop websites for his own customers. He also have a designer. I told them many times about the ways they can increase their productivity by 2 or more. If they just hired somebody competent, they would increase their revenue by at least 3. But they have enough money, and don't care about quality or how much they cost to the ignorant customers, compared to somebody productive.

³ What I mean is the number of lines of IL code which you see in Code Metrics in Visual Studio, the metric which actually means something. The real LOC doesn't matter and you don't have to measure it; it's one of the most stupid metrics ever. Enforcing IL lines of code means that developers will be forced to actually refactor code, and not just to collapse ten lines of code in a single unreadable line.

  • 3
    I disagree: Motivation to work and motivation to learn are two entirely separate things. For example, some people love their work and the job, but they might think "SOLID" is just another bullshit-bingo buzzword or "TDD" is some ivory-tower concept with no use in the real world.
    – nikie
    Commented Dec 27, 2011 at 11:58
  • 5
    @maple_shaft is right: Some people work 70 hour-weeks and produce the worst amount of spaghetti code without any tests (they don't have time for such nonsense!). While are passionate and constantly improve their skills, but go home after 40 hours, because they know they can't be productive longer than that anyway. Don't mix the two things up!
    – nikie
    Commented Dec 27, 2011 at 12:03
  • 13
    No, No, NO. Willingness to be exploited by an employer != ability to produce quality code. There's way too much of this "stay until 2am to get it done" nonsense happening in our industry already without our conflating that with some mythical Ideal Developer. If YOU love working 80 hour weeks, more power to you. I have things that are important to me besides work. To conclude I'm bad at what I do because of that is spurious at best. No other industry gets away with what ours gets away with, and it's up to us to change that, if it's going to change.
    – Dan Ray
    Commented Dec 27, 2011 at 14:01
  • 6
    Having to work until 2 AM to work on a project is a very efficient way of killing any love for said project, especially for those with family obligations.
    – user1249
    Commented Dec 27, 2011 at 15:01
  • 2
    I think all the points made here are valid, but some of you may have misunderstood MainMa. He never said work till 2 AM because you are forced due to deadlines. Instead, he simply referred to people who get so caught up in excitement of seeing something work that sometimes, they'd rather get it done than go to sleep. I can relate to this. For me one extreme example was a task I was working on to add tunneling support to our video streaming library. It was estimated at 5 days, but with our new pipeline architecture, everything was coming together so well, I started on friday afternoon...
    – DXM
    Commented Dec 27, 2011 at 18:50

"I'm done coding, just need to refactor and split into multiple classes to make DXM happy".

That line of thinking right there is a cancer on any team and will kill the motivation of the entire team if not taken care of immediately. I am referring of course to the fact that by seniority and/or merit you happen to be in a position of technical authority, giving you the power to help influence and bring about good practices into your team.

This is all well and good, however if your team was clearly sold on these processes they wouldn't single you out in statements like this to each other that clearly show a lack of respect for the process and a lack of respect in you. They still see these best practices as a hindrance caused by you and not a process owned by the team that your team will defend of its own merits.

You mention in previous comments that other team members are indeed following these practices and standards well and applying them correctly. Focus attention first at bolstering support from them, ask them what works, what doesn't work, what they like and what they would like to see changed. If you do this and take their opinions seriously they will feel very differently about the standards as if they were a community decision instead of a procedure handed down to them from a superior.

You bolster support for best practices and standards by pointing out to the team how they have improved the software development process or quality of software.

Hold a vote on the matters up for discussion and document the results, ideally every decision should be unanimous for the sake of legitimacy but if you are dealing with hard line obstructionists this may be impossible and could just stall out every issue. Use a majority vote in this situation. If the majority are against your proposed standards and practices then you have lost the room already, just give it up at that point.

They will own those standards and procedures and will enforce them so that you don't have to. As a tech lead you shouldn't have to declare edicts and decrees, that is a poor way to be a leader.

Once the team feels as if they own the procedures then members of the team who begin to label you to certain procedures and best practices will be illegitimate to think so. Your team will help to correct this attitude in others.

  • 1
    +1 for emphasis on focussing on relationships rather than principles
    – sunwukung
    Commented Dec 27, 2011 at 23:27

Good question! I think the answer depends on why people don't want to improve their skills. Possible answers are:

  • They think they are too busy to learn something new or they think the new way of doing things (like writing all those tests) will take them longer and they don't have time for that. Then the obvious answer would be: give them more time. Learning something or trying something like TDD when you've always done things differently will take more time the first couple of times. If your programmers don't have that time, you can't blame them for not trying.
  • They have a different perception of their own skills, i.e. they think they're very good programmers producing high-quality code. This is difficult psychological terrain, because shattering that belief can be very demotivating. Maybe some kind of informal competition can help (who produces the fewest defects/feature? the shortest code? the fewest WTF's/minute in a code review?).
  • There might be an actual motivation problem (i.e. they just want to "do their time and get left alone" until closing time). Luckily, this is too general/not programming-related, because I really don't have an answer for that.
  • They're beginners and they don't know better. In that case, training, code reviews might help, or a "book club" where a team member has to discuss a new technical book every month.
  • They've seen silver bullets before, (and were bitterly disappointed) and they think whatever you're trying to sell them is just another new buzzword that sounds good in theory and is little use in practice. In that case, demonstrating the advantages during code reviews and pair programming sessions might work. Try not to be a total know-it-all when you do that.

The best solution really depends on the root problem: For example, formal coding guidelines, metrics and reviews can work for beginners, but people in the "wrong perception of their own skills"-crowd might struggle against them or play the metrics because they see them as counterproductive bureaucratic obstacles to getting their work done.

  • Good points. I especially like the first one - and I'd even generalize: You first have to make it clear that learning on the job is encouraged, and that it's okay to explicitly set aside time for it.
    – sleske
    Commented Dec 27, 2011 at 13:29
  • If people have different perception of their skills, maybe they're just measuring success in different parameter? If you're measuring quality of the code, and they're thinking of how fast the code can be created, obviously the result will be different -- in this kind of cases, should ask how they measure success. Different people have different way to think about this.
    – tp1
    Commented Dec 27, 2011 at 18:16

The real question is how do you approach such a person/team and make them curious about better way of doing things? How do you inspire them to learn? Without that, it seems that all the teaching, meetings, lectures, discussions are useless if they are perfectly happy going back to their desk and doing what they've always done.

That's it! This indeed is a real question.

To give some backgound, We simply don't have time to put in a lot of formal training - but occasionally if i do - it still see no light.I have also been part of the companies where formal training becomes a process itself but and i am so often a witness that they hardly teach them how to think.

So question that i pose to them is not how to teach them - but how to make them learn? The difference is subtle but it is what is going to make all the difference.

I don't know if i am right; but often i believe in a dialog of a Matrix the movie - "It's the question that drives us!" What is most important is to make them think, make them ask why! And of course, most who think they already know everything about some design patterns because they got good marks in university courses - are the most difficult there.

How do you get make them such questions? My general approach is "that throw them in the pond if you want them to learn to swim". I agree that people may disagree; and i will gladly agree to disagree with them. When you throw them in the pond - they actually don't learn to swim automatically; but it sparks off a survival instinct that makes them think - once that happens they will naturally think of HOW and WHY.

A practical example i give folks is to put them in a significantly complex project than what they have hoped to get one on it and let them fight their own battle. As they begun to unravel the code and find it difficult to trace it through - you realize they start asking good question.

This may sound a bit extremist, this may sound waste of resource. And i am sure, there are many others who will give me the advice not to do this. But this has worked for me!

No matter what pay packages and HR tags you assign it wont solve basic motivation problem. For that only path is that they are challenged; If you spark of this basic human spirit - everything else works. If you cann't it's a loose loose game.

PS: Just incidentally i posted an answer here https://softwareengineering.stackexchange.com/questions/127021/how-do-you-train-freshers/127034 - and i got all the bashing; primarily most people believe that somehow businesses cann't afford to waste resources! I am sure, this answer may get similar treatment here. But the truth is, making people to work and making them believe in doing a good job is a subject of human psychology over how to craft the syllabus of the course.

Anyway, the task you are describing to here amounts to igniting the inner passion to do great change. And larger the system more difficult it gets. Begin with younger fellows who are still built in with i-won't-to-do-good-job spirit and challenge the status quo.

  • thanks for bringing up matrix, now I have to spend 2 hours of my life watching it again :) It's funny but I found that "freshers" are the ones that will absorb anything you throw at them. Having been a graduate of a fine CS program myself, I make it very clear what I think of their "education" and mostly they agree with me. I find biggest issues are the guys who've been doing this for 10, 15, 20+ years. I also agree with your "trial by fire" approach. That's exactly how I learned what not to do. Problem is a) it takes a long time that most teams can't afford and b) when working in a team...
    – DXM
    Commented Dec 27, 2011 at 6:51
  • .. setting (dare I say "semi-agile", don't hate me S.Lott :) ), we don't have sole ownership, which trial-by-fire requires. If they write something that fails, someone will step in and fix it. As someone who's been in the pond and mostly made it out, I'd like to think, I was curious if there's something that could be done to transfer that mindset without having your entire team go through the pond.
    – DXM
    Commented Dec 27, 2011 at 6:54
  • @DXM I agree with your concerns that better not throw the entire team to pond at once. Yes. The point is, start throwing some of them one-by-one then! At least that is a good agreement between us. I think the mindset which has grown up for many years - will take some time and perseverance to change. Commented Dec 27, 2011 at 7:00
  • @DXM to give you things more concrete - try small initiatives at a time - show case the achievements and show that management means business for doing good job here. And promote the mind set - one-step-at-a-time. persistence would be a must, but i had achieved such a thing in my last company. Over time, management kept giving my team as an example of how to do it well. Commented Dec 27, 2011 at 7:03
  • 1
    I like your answer, especially if it does work for you, so the following is not a criticism, but just a note: sadly, this doesn't work in every case. I had several cases where non-motivated developers started large projects. It ended the same every time: project failed, and they blamed the management or their colleagues or the fact that there was no enough time or resources or that requirements were not clear enough. I wonder what makes the difference between those who will learn how to swim and those who will more likely blame the water. Commented Dec 27, 2011 at 7:13

As you point out, its motivation. Dont mistake them not caring for them not knowing. They clearly know what to do. They just dont care. If thats the case, the real question here is... what is your management doing wrong that keeps them so unmotivated? Are you the newest member of the team? Perhaps they've been through all this before, with it only leading to problems from their management. So they just stick to doing the very lowest amount of work needed to keep their job because they dont think doing more will be responded to by the employer.

  • I'm the team lead and been with the team for almost 9 years but was made the lead roughly a year ago. I think there's a difference between "don't care about work or quality of my code" and "don't care about learning new skills". We've actually made a lot of improvements on management side and a lot of our teammates are now quite happy. However, some are quite content doing what they've always done. They actually put in extra hours without even being asked, very responsive but still seem quite content debugging their own bugs 75% of the time.
    – DXM
    Commented Dec 27, 2011 at 7:04
  • 1
    Well, then like in every profession, not everyone is going to be on the top half of the bell curve. Its possible you just have some folks only in it for the paycheck. Commented Dec 27, 2011 at 7:56
  • You know, every year we pick a team quote and 2011's was "it is what it is", but we are about to start a new year and at least for the time being, I will refuse to accept that it is what it is, although I agree with you that most of the time it really is. I've been thinking more about this question and actually have an idea which might have potential. Since I can't answer my own question (personal thing, not system limitation), if 2 more people vote to reopen programmers.stackexchange.com/questions/127080/… I'll post in there :)
    – DXM
    Commented Dec 27, 2011 at 8:41

It seems to me that this is a management and leadership problem - if its your team then you can work to make improvement (personal and of the code) a core attribute of your team, the question is will that be supported by your management - because you're going to want to do things that will take time (they'll get a net win as you should reduce new technical debt and will be repaying existing technical debt).

So, you assert that you want the team to improve, you get their agreement that this is a good thing (that the team, as a whole, works to improve the quality of its code) and you then start on a programme to make this happen - it sounds so easy... I'm aware its not!

I think there are two parts to this - education and working practices.

  • Education you can start one lunchtime a week - everyone eats together, you run a 20~30 minute presentation with Q&A. You start with the basics you want - SOLID can occupy the first 2~4 weeks - over time you get the team to speak in rotation and you can work out how to decide who talks on what between you. Allow speakers some prep time within work. Beyond that encourage attendance of local user groups (by making it at least partly social thing if possible)
  • Working practices... well it depends on what you do now and what tooling you've got, but you might want to look at agreeing coding standards, introducing peer code review (is it solid), unit testing (not necessarily test first), running a continuous integration server and looking at more automated testing (in addition to unit tests). But these have substantially to be introduced with consent/agreement (not the build/CI server!) and you have to want to drive quality forward as a team. There are always things one can improve (Kaizen)

Its also worth looking at Kanban (which is seen by as a driver for change/improvement).

One last thought - I'm a vocational programmer, and I'd like my team to be the same but working more than 40 hours a week is not actually a good thing so one's objective should be to have a team that gets its work done effectively and well within the normal working week and in respect of this the argument for improving working practice is that it is more likely e.g: adding unit tests to demonstrate the failing case when (before) bug-fixing gives you confidence that it is fixed; having a build server gives you confidence in your ability to build your solutions cleanly - if that build also generates deployment packages it means that deployment is dramatically simplified; SOLID code is, by definition, easier to modify; and across the board the less technical debt you incur the less you have to pay back...


I fell into programming by accident ~30 years ago. I was motivated to learn basic software engineering principles by being assigned to maintain/support other people's code. In these assignments, I learned how a code reader experiences code - how to empathize with the code reader. I did not want to inflict the pain of my poorly written code on others!

This practice of assigning new programmers to maintain/support other peoples code is not a magic bullet, and it does seem to provide motivation to learn how to produce solid code more often than not.

  • 1
    I started the same way, although not by accident. This is very similar to what Dipan Mehta said in his post. You throw a person in a pond, making sure it's not too deep, and let them swim. You were one of those that learned to swim, but that's not universal (see his answer w/ comments). Also I believe this type of approach works better for new people than those that already have ingrained habits. Then, not only do they need to swim, but it's also against the current of established practices.
    – DXM
    Commented Dec 27, 2011 at 19:02

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.