11–20 of 87 posts
http://www.amazon.com/Writing-Solid-Code-Microsoft-Programmi...
http://www.amazon.com/Practice-Programming-Addison-Wesley-Pr...
http://www.amazon.com/Code-Complete-Practical-Handbook-Const...
I know these are old books and are C and C++ oriented, but it helped me a lot during my formative years and helped me transition from being a decent programmer to being a decent engineer. They are short books which are well written and not very dense.
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.
You cannot sit and review each commit, the best you can do is to make them care about code.
[1] http://www.amazon.com/Clean-Code-Handbook-Software-Craftsman...
We do team based pull request reviews. (in github) You need two other seniors to give you +1 to move on. The number "two" comes from the fact that we are still a small team. People can will still review stuff that has already two +1's but the commiter could already move on if needed. The advantage of pull requests is less "teaching how to do it properly" but more "learning from each other" and "continous exposure to…
The other part is encouraging them to be engineers, not "coders". Coding implies write code and shoot it out. Engineering is a mindset of continuous improvement and complete examination of the problem and solution.
As for my specific suggestions, I would recommend "The Pragmatic Programmer: From Journeyman to Master", and actually apply the principles in the book yourself. Use unit tests, setup CI (such as Jenkins), a code review system (such as Gerrit), a bug tracker, code analysis (such as Sonar), and use tools (linters, etc). Also, cranking up warnings on your compilers/interpreters and not allowing in anything that doesn't pass muster is a good start. This might all seem like a lot, but you can do little parts of it at a time. It is worrisome that you say you can't review every commit. Perhaps you could assign members of your team to review each other's commits? This would also have the bonus of giving them a feel for what it's like to be on the receiving end of bad code, and to teach each other.
Just put them on mandatory level 2/3 support 20% of the time for the code that is written.
When you have to maintain code you fully grasp the concept of «well written code»: just code that is easy to maintain.
And every month try to have them talk about their top 3 reasons that makes them loose time when fixing code.
My fear with peer review is that it is very artificial, what I like with maintaining code is that you see your mistakes sometimes due to trying to write «clean» code.
Magic number deserves a bullet in the kneecap, but magic numbers disguised as factories are worse. A good code is a code where mistakes are obvious. Value these coders.