How to convert a copy/paste/spaghetti programmer to see the light?

Question

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.

Answer 1

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.}

Answer 2

"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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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...

Answer 7

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.