How do you get developers to want to write good code they can be proud of? [closed]

Question

Closed. This question is opinion-based. It is not currently accepting answers.

---

Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.

Closed 6 years ago.

Improve this question

In a team of developers, how do you get the developers to feel pride in their code and write good code (I realize this is subjective and everyone is different, but there is a point when I write code that i can say, this is a good piece of code that I am happy to show off).

To often I hear we have no time to write good code and all that matters is getting the defect fix closed. How do I change this outlook and make the coders create code they can be proud of.

This seems to be more prevalent in the younger coders, not all but most.

Answer 1

Short answer:

If you don't have the time to do it properly now, will you have the time to do it properly later?

Long answer:

Maintenance is 70% of the effort in developing software. The more technical debt you build up in the code, the more maintenance effort is required. Bugs cost more effort to fix the longer they go unfixed, because of the need to reacquire knowledge about the code, the costs incurred by customers dealing with those bugs, the cost of deploying fixes, etc...

Delaying bug fixing is expensive. You have to break out of the negative feedback loop of "no time":

1. No time to write good new code, let's rush through it as best as we can and ship bad code
2. Bad code has lots of bugs, now we need to fix them
3. Since the bad code was written a while ago and the fix needs to be deployed to the customer, fixing it takes a long time
4. Because we spend so much time fixing bugs, we have no time to write new code
5. Goto 1

Consider trying to put a number on how much effort it costs to fix a bug on average, and then make it a goal to reduce that number. The way to do that is to write things properly in the first place, because fixing bugs while you write the code (e.g. detecting them through unit tests) is a lot cheaper for the organization as a whole than waiting until a tester (or the customer) finds them. If you have the right numbers to back you up, deciding to take the time to do the job properly can be defended financially to management (the only language they really care about).

It sounds like your team must first start to take ownership of their work. If they feel unable to make the decision to write proper code in the first place, you have to figure out why that is, and possibly negotiate with management to figure out a way to solve that. Once they feel enabled to make the necessary changes, change will happen. Nobody likes to be bad at what they do.

Answer 2

I think you are coming at the problem from the wrong viewpoint - the code is not the most important aspect of all this. The product is. You can have the most elegant, beautifully designed, most carefully crafted code that produces a useless, slow, buggy, un-usable product that is so badly documented no-one can understand or use it.

In fact, I'd say the "best" code always results in bad products because the developer is not focussed on making something that is simple and easy to maintain, that works according to the compromises required to make something practical. If you're too worried about all the little buzzword bits that are going around nowadays, you spend all your time trying not to repeat yourself or keep things separate that you forget the reason you're doing these.

Now this doesn't mean you should just hack whatever awful code together, but it does mean you need to focus the pride on the results. Results also include measures like communication and maintainability of code, not just working product BTW. For example, if there's no documentation that goes with it, and no-one can figure out how to use your beautifully complex OO API, then its no use to anyone.

So, how to encourage your young coders that pride in their work is a good thing. You can implement a system of feedback - if someone uses some code that they found easy to use or helpful, they can acknowledge the creator of that with a quick flag (similar to how sometimes a customer will send feedback concerning particularly good service). Then you can do code reviews - not the usual ones where the peers are involved, but where you pick a bug at random and go ask the developer to explain to you all about it, what they did, why they chose that approach, what supporting features they provided. Chances are you'll get the bare minimum and you can highlight what you expect, those that achieve your expectations can get a reward.

Answer 3

This seems like 2 different questions: good code and being proud of your code. I'll just say something about the latter.

I'm almost never proud of what code I write as part of my job because:

• the projects are not my idea, it's the customer's idea. They're rarely something cool or awesome and therefore it's really hard for me to feel excited about them.
• the design and implementation of the project is a series of compromises: I have to agree to do it that way because otherwise that other module can't use my code; I have to agree to sacrifice some good design decisions because the rest of the team disagrees with them.

I think these aspects apply to most developers.

Probably the only way to make your developers proud of their code is to promote a culture in your company of "we deliver high quality products" versus "we deliver products fast and they work well enough". Making that change means delivering quality code which takes more time and therefore costs more. This is probably going to hurt your business, unless your business's foundation is quality, which it rarely actually is (HR and marketing bullsh*t almost never translates into real-world facts).

In software development, high quality code and business competitivity almost never go hand-in-hand. Just like you can't keep 2 dogs in the same bathtub :D .

Answer 4

There are three main areas that need to be addressed to handle such a broad problem. You may not be able to change all of them.

Business Strategy: sales, marketing, etc. - Getting to market sooner may just trump everything else. When you don't even know if anyone will buy your product, you take more risks in the area of technical debt. Customers who hate implementing your next release because you have a history of creating new bugs is just as bad as those who don't think you release fast enough and are willing to accept a few flaws.

Management, rewards and punishments. - If the only thing anyone recognizes is how many bugs everyone fixes in a fixed amount of time, that's the system everyone will learn to game. Is anyone aware that these quick-fixes introduce new bugs? Do you constantly have to push back on adding new features because the code is too difficult to understand which makes maintenance and enhancement more difficult? When it doesn't fit the Business is when it causes the most problems.

Training and Mentorship - Inexperienced devs (they don't have to be young) probably continue to program in the same way as the tutorials they learned from and what worked well enough on some smaller project. They have to be trained and that rarely gets done by someone else or on their own. It's too expensive to find and hire entry-level programmers, to just let them learn on their own. If they're not capable of learning from the mistakes pointed out in your code reviews (you have code reviews?) or unwilling to follow your coding standards (do you have any?), then you may be forced to replace them.

All of these are intertwined. I'm not sure those who program heart pacemakers are any better than those building social websites as long as they understand and work within the framework of the Business Strategy, Management and Training.

Answer 5

What I think (being a developer, not a manager), one thing is enough: allow them do TDD (and do not prohibit pair-programming). They will do such code, then.

But that's of course, only true for developers for want to write high quality code, but are not allowed by strict rules.

If you need to motivate people who "are good with anything that seems it's working", I can't help you :-( .