21–30 of 87 posts
I'd also recommend choosing a strict language with useful conventions like Go (www.golang.org) if you have the possibility to switch. If will prevent many (not all) headaches in the long run, even if it's not immediately obvious.
For Clojure development: https://github.com/bbatsov/clojure-style-guide
For Scala: https://github.com/alexandru/scala-best-practices/ or http://docs.scala-lang.org/style/
Basically you get everyone in a room. The basic premise here is that everybody brings their "A game" and shares it with everybody else. One person types, everybody else decides what to type. Sounds chaotic, but as long as folks stay focused, what happens is that very quickly the entire group gets on the same page about IDE, coding standards, patterns, and whatnot.
I'd plan for a few days, but you might see results just in a solid morning of doing it. Don't know.
Of course, you probably don't have a few days. But -- how much time are you losing to this other stuff? Couldn't hurt. Beats giving people a book to read.
You absolutely cannot control people. The only way to get people to do things, and i mean the ONLY way is to get them to WANT to do it. Therefore, you have to ignore the people who aren't cooperating with you and focus on the one's who do. Treat them like gold and be willing to make compromises with your quality standards because they will not be the same as yours. Then, as you make inroads on the project together, the rest of the team members either have a choice to get on board or get left behind. It is that simple.
Saw something interesting at a conference a while back. If you have a few days, it might be worth trying. It's called "mob programming" Basically you get everyone in a room. The basic premise here is that everybody brings their "A game" and shares it with everybody else. One person types, everybody else decides what to type. Sounds chaotic, but as long as folks stay focused, what happens is that very quickly the enti…
Communicate.
Tell them what you are seeing, and just as importantly, why it can be a problem. Many times, beginner mistakes arise simply because they never have been exposed to the reasons for them being "mistakes" in the first place. So teach them. Nicely.
Think of them as students, and you are their teacher/mentor. Help them grow, support them and act as a resource so they can do their own jobs better. Treat the whole experience as an opportunity for growth, not a judgment on their skills.
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 commi…
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.
2. Rotate who reviews so everyone gets a chance to review everyone and put yourself in the rotation.
3. Lead by example. Write some code into production and submit yourself to review. Everyone writes code, everyone reviews, everyone gets reviewed.
4. Each review find just one thing to refactor and let them know they should be looking for the same thing in other people's code.