[rmcastil]

You need to stop thinking of them as 'coders'. When you think of them that way, you're putting them in a box and limiting them.

Instead consider them to be a team of people. As you said, each of them are at different stages in their career in programming. You need to understand this and sympathize with them and their code. This takes time and effort on your part to help lead the way.

You say that you review the commits now and then and find some of these issues, but do you bring them up? Do you show them how the code can look and read better?

If you do, make this a process and act as the person approving pull requests for the first several weeks. Then formalize this process and delegate this job to the next person who you feel writes high quality code.

Again a SHORT guide or book will not turn around the quality of your codebase and the team working on it. If you're interested in better code, invest in your team. Send them to conferences, give them a budget to spend on books, have book clubs and lunch and learns. Invest in the process of improving the skills of your team.

[ritchiea]

This 100%, but also OP says due to the nature of the timeline of the project he cannot review all of the commits, this leads me to ask: what are your developers' timelines for delivering work like? Equally important, what do they feel like their timelines are like?

It's really easy to write problematic code if you're being pushed to crank out work fast, all the time. The more stress and tighter the deadlines the more easily correctable problems you are going to see. Other than that you have to assess whether your team believes the errors you see are actual errors.

[kamakazizuru]

You're very right about the coders bit - I guess it was more an issue of framing it. I've corrected it now.

I do bring the issues up - but usually end up being really frustrated because I assume that these things should be obvious. A lot of the comments in this thread are forcing me to reflect though, and realize that I didnt "know" those things out of the box either - but learned them by seeing others' good code and learning from that or because someone was patient enough to walk my through my mistakes (of which I certainly still make many).

While a pull-request based system would be ideal - it's the timeline and the scope of work that has us a little bit stuck with setting up such a new process.

My key takeaways from this thread would be though that I should certainly do more of the code-reviewing & maybe even get some of the team more involved in code-reviews.

Really appreciate the tremendous feedback here and it makes me realize again why I end up spending so much time on HN - there's just so much to be learned here from some truly helpful folks!

[rmcastil]

> I assume that these things should be obvious.

I'm glad that you've gotten so many takeaways but be very mindful of this. As you've said you didn't see a lot of these things when you just started out. It's through experience that things became obvious.

It'll take time but if you focus on teaching and improving your team you will get there.

[jobu]

> Instead consider them to be a team of people.

It's easy to tell when a manager thinks of you as a "headcount", and it definitely doesn't inspire hard work or quality work.

In the process of connecting with your team as people it should become much more obvious what they need to improve. Sometimes it's encouragement and building confidence (especially for inexperienced devs). Sometimes it's asking questions about what they're trying to do. Also, if you have trust with your team, then offering suggestions for improvement and constructive criticism will be more well received.

The most important thing is to avoid them becoming defensive, and back off or move on when it does happen. It may sound like coddling, but there's a lot of psychological benefits for getting people to see their mistakes and possibly even come up with their own solutions. When people become defensive they come up with reasons to defend what they did, and are blind to the fact that there may be a better way.

[joshdance]

This is the first things I thought when reading this question. The are not 'your coders'. They are part of your team. They are your team. You need to let them know what you need, and why you hold them to a higher standard. Teach, don't demand.

[BillyMaize]

I agree with this other than the lunch and learns. Leave their one break in the day out of it.

[StevePerkins]

Heh... have a bad experience with lunch-n-learns at a previous gig? :)

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.

[rmcastil]

This all depends on the environment you're working in. When we used to do lunch and learns they were on Fridays which were blocked off for side projects.

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.

[tex0gen]

Agree 100%. My boss has invested in Treehouse to improve code practice. We also started pair programming to help each other identify potential bugs and teach each other new ways of doing things. It reduces tech debt as well.

[zo1]

Treehouse? All the searches for that keyword with this topic led me to some sort of beginner's course on programming... Link, please?

[seekingcharlie]

http://teamtreehouse.com/