Ask HN: How do I get my team to write better code?

Plus half the time we did lunches it was as a team and we always ended up talking shop.

We also welcomed free food and had other people in the community come and speak. Now if you're in a culture where it's 100% coding 9 to 5 then I'd completely agree with you.

* If some of the people on the team have more skills than others, you could try asking people to pair program for part of the day. You could try setting up a lab space for this if people are interested.

* Weekly brown bag sessions where you talk about a technical topic of interest. Let people on the team nominate ideas. Do it over lunch and have the company have food delivered. The better the food, the more people will want to attend.

* You should get an automated build in place, and encourage people to do some level of automated testing if they aren't already. Some people take this a step further and use the automated tests to help drive out the design (Test-Driven Development by Kent Beck is a good book on this topic).

* You could try starting a technical book club where people read a chapter a week, and then get together and discuss it over lunch. Given your situation, I'd strongly recommend starting with "The Practice of Programming" by Kernighan and Pike. Again, it helps a lot to have the company get good food delivered.

Don't make a million changes at once. I might start with the book club if I were in your position. None of this stuff will magically transform your team, but these kinds of things can start creating a culture where people start to care more about the quality of their work. You'll encounter people who have very strong religious feelings for or against any one of the things I listed above, usually based on some past experience. I've seen each of the above succeed big and fail hard with different groups. Just try what seems to make the most sense for your team.

One last note: when you try things, don't do stuff in fits and starts - talk with the team about what you're going to do, see if there's buy in, and if there is, commit to trying it for, say, four weeks. After the four week period is done, talk with the team about whether or not it's working for them, and if they'd like to stop or continue. Over time, you can add/remove/change more things in the same manner.

Good luck!

Pretty much everything in this comment thread describes approaches that only work with the buy-in and support of upper management. If OP (or anyone else) is truly in a position where code reviews are impossible, and lunch is everyone's "one break in the day", then there is very little you can do improve code quality in that environment.

In THAT kind of environment... you slog through, get what you can onto your resume in preparation for the next job search, and don't let yourself get too emotionally attached. Support for quality has to start from the top, you really can't "grassroots" it if upper management pays only lip service or doesn't really care at all.

Why not? I do.

I have 8 direct reports and I review every single line of code that they write. Some days this is all I do.

Others think I'm crazy but our group outperforms every other group by any measure. I'm convinced it's because of peer review.

A few thoughts:

1. Regarding resources and timelines: It's not when you start, it's when you finish. Every hour of peer review saves me at least 10 hours on the back end (systems testing, regression testing, user acceptance testing) and 100 hours on the back/back end (maintenance).

2. I never have to tell anyone anything more than once. I make sure I explain why. (When you do , you cause .) Then they learn and remember. This is not a religious debate; it's a way of conducting business. This won't work nearly as well if people are more interested in showing what they know than learning how to do it properly.

3. As I get to know different people, I know where I can skim and where I have to focus. I rarely return much to senior people. I often return a lot to junior people.

4. Everyone makes mistakes, even senior people, and even me. Peer review, like regression testing, is a pain in the ass, but it more than pays for itself on the back end.

5. As soon as you feel you're ready, you're senior people can take some of the peer review workload. I have done this before, but it hasn't lasted because of turnover.

6. Once people know everything will be peer reviewed, they become more careful about what they're doing.

7. Technical debt is a huge timebomb. I know of no better way of slowing it down than 100% peer review.

8. Everything is documented in the ticket. This provides some feedback on how it's working and what should be changed (programming standards, peer review methods, etc.)

9. Once you put your phone away, get off the internet, and stop going to useless meetings, it's amazing how much more time you have to do things that really make a difference, like peer review.

10. I hate doing this. I'd rather just code. But the only thing I hate more than peer review is fixing bugs. That's why I do this.

1) Take on the most brutal coding tasks/features yourself. You will have to cherry-pick the upcoming work to look for things that just about any other engineer would freak out about if they got it assigned to them.

2) Knock it out of the park in terms of time-to-market and code quality. You need to do both, to eliminate the concern of, “We don’t have time to write quality code.” The code should be so clean, so well factored, so well unit tested, that you would be comfortable getting a code review from Martin Fowler, Kent Beck, and Bob Martin all at the same time. This also implies that you’re read their books, and would know how to pass their code review.

3) Call a code review with the entire team, and aggressively code review your own code. There is always room for improvement in any code, depending on hour you interpreted current requirements and future needs. This has to include phrases like, “I didn’t know what to do here so I…”, “I really which I had more time to change this to…”, “I went back-and-forth on how best to abstract this, but ultimately I chose this abstraction because.” Basically, you’re looking to show them the worst possible code review on the best possible code.

4) Depending on the personalities involved (including your own), decide how you are going to coach each engineer 1-on-1. No two people are alike, so you will need to dial your approach to each person. Some people will thing you are a show-off, some will think you intimidating, as well any another other human emotion and concern that causes someone to not seek out or not take advice. This is where your emotional IQ and communication skills will be tested.

5) When you start coaching them, don’t go after every single flaw. Try to find the underlying root cause of the problem in the code, and address that. A common problem I run into is the people just don’t understand OOP but think they do. I usually have to coach them on basics like encapsulation and cohesion, working them up to design patterns, and further up to domain modeling, all the while instructing on proper implementation technique (such as unit testing.) Once they have the fundamentals in place, you can begin fine-tuning certain implementation patterns.

6) Over time, at least one member of your team will get good. With their permission, publicly review their code. In this, you want to be very positive: “I like what they did here…”, “That’s a good way to encapsulate that problem”, “That’s a powerful abstraction, especially the way it’s used…” This Rite of Passage should then become what other engineers are striving for, as only the best engineers are getting public praise fests.

This basic formula has served me very well with my current team, in that they are one-upping themselves on code-quality. Still, however, I take on the most grueling coding tasks to set the example and lead from the front. This acts to continue to demonstrate my commitment to code quality, as well and lets the team know I would not ask them to do something that I would not do myself.