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

This. The general form of this question is, "How do I help someone increase their skill level?"

If the topic were math, you'd immediately see that a tutor and a lot of practice were essential parts of the equation.

If the topic were baseball a coach and a lot of practice would leap instantly to mind.

However, it is too often the case that employers and managers draw a line between the "educational" period of a persons career and the "work" period of their career. They also draw a line between what is their responsibility (in terms of improving an employees skill set) and the individuals. Combined these two lines means it is easy to get into a situation where, as a manager or employers, you are likely to think "You should have learned this 'before'" or "You should learn this 'on your own time.'" Neither of which thoughts actually help get you closer to a more skilled employee.

I honestly think this complaint is poorly argumented. It depends on the nature of the project. When you say "findeventsfromthelast6hours" that's perfectly reasonable name for disposable code or private implementation. You should only be concerned about such name if it made it to the API somewhere. Hardcoding things is also not a bad thing by itself. If I had to guess, your team is under the impression the code they write is prototype and will be rewritten anyway, not API to be consumed by other parties or doesn't have a direction that allows them to make the proper abstractions. Sure you can demand nothing to be hardcoded, but you must remember eventually those params will have to come from somewhere. I see so many people move hardcoded values Java -> IOC/DB config or Erlang -> DB not realizing it's more difficult to reinitialize the component than to do a hot reload and speed up your development process at the very least. Whatever you do it must be for a well-defined reason. It's also possible your team developed their own process where it's easier or faster to fix these issues on the go rather than planning in advance.

Below are a few things that could help but you said it yourself. If you don't have time to review then my guess is you are also pressuring the devs for time. Sometimes to make your deadlines they might have to cut corners. Maybe you can switch to a more agile process and instead of crazy deadlines you ask them what they can get done the next 2 weeks (correctly).

- Setup process for them to review each others commits (Code Reviews)

- Add a tool like FxCop, JsLint or JsHint to the build and commit process

- Hire more senior programmers that they will look up too.

- Paired programming

- Be a team and do stuff as the team (We are not factory workers)

What I've seen work is a combination of code reviews and ongoing continuing education.

----- CODE REVIEW SIDE -----

This can include automated tools, human interaction, and computer-assisted human interaction. To start with, pick a set of command code standards and style guidelines. Google has nice ones for many languages that you can use as a starting point (https://google-styleguide.googlecode.com/svn/trunk/).

Secondly, enforce them through automated tools (e.g. in a Java shop, these might include PMD, FindBugs, Checkstyle, etc). Have everyone install the IDE plugins for those tools (along with your common config). Incorporate them into your continuous integration build process. Perhaps put in place a static analysis tool like Sonar to send regular reports on code issues.

The human element would start by having someone review committed code before it's allowed to be merged downstream. Git's pull requests, along with diff view systems like GitHub's, make this easy... but you can use workable practices with Subversion or whatever also.

There are limits to "pull request"-based code reviews, though. When change sets grow too large, it's difficult for the reviewer to understand the high-level vision for the changes. You start reviewing the trees, rather than the forest. So I think you still need periodic in-person code reviews, to walk through the state of a codebase at certain milestones and discuss higher-level issues.

----- CONTINUING EDUCATION SIDE -----

The thing that I've seen work best here is a regular, ongoing lunch-and-learn type series. Take any of the standard code quality treatises (e.g. "Pragmatic Programmer", "Code Complete", "Clean Code", etc), and tackle a chapter per week. Better yet, split up the chapters and have the team members themselves present a chapter. It's great experience for them (if they're not TOO freaked out by public speaking), and you'll never learn something as deeply as you do through the process of teaching it to others.

The problem with lunch-n-learns is that you MUST have buy-in from management to make them a serious and ongoing part of your team culture. When deadlines are tight and there are fires to put out (and when are there not?), a lot of companies are quick to cancel that week's lunch-n-learn. When that happens, they lose traction and fall apart.