Clashing Coding Styles: Learning to Work with a Growing Team of Programmers
Programmers come and go. Teams expand and contract. How you deal with the varying coding styles of new hires (and sometimes veterans) can be either a deterrent or encouragement – depending on your process.
“It's not at all important to get it right the first time. It's vitally important to get it right the last time.”—Andrew Hunt and David Thomas
One goal of a strong development team is optimum productivity. Concurrently, you want to keep an eye towards keeping all the programmers motivated to make a valuable contribution to the project.
If employee turnover is non-existent, then this is certainly attainable. The reality is that there is turnover in even the strongest and most rewarding team setup.
It’s a good idea to create a process that handles the addition of a new programmer. Someone who is new to the code can bring your project to a screeching halt while the new hire takes time to learn. Additionally, if you expand your development team with a new hire you add more levels of complication to the entire process.
It behooves you to establish a process to integrate new developers with the rest of the team and help (not hinder) the project momentum. This is also a positive way to keep up team morale and help you meet deadlines.
Establish Coding Standards
No matter what programming methodology your team has adopted (waterfall, scrum, test driven, extreme, or Agile) maintaining a standard for your code base is vital to project momentum.
Consider establishing code standards either through a pretty-printer or adding a coding formatter style sheet to the company’s preferred IDE. This removes a couple prevailing issues with team development including improving version control and taking ego out of the mix. Removing signature coding styles makes the end-result (your code base) seamless and alleviates the concern that one developer is changing another developer’s code.
Using some sort of style sheet to compare against provides clarity and ownership as a group to the entire team. It also protects against the potential for having to clean up after a code import that causes widespread issues in readability and functionality.
Mentor Junior Programmers
Code reviews and pair programming are the most prevalent ways to bring a newly hired developer up to speed. Both processes have their own issues, but if used in the way they are intended they can help facilitate a smooth on-boarding process – and benefit the team bonding, too.
Code reviews involve providing a new programmer with a set of tasks that update trivial aspects of the code: FAQ’s, content updates, aging non-vital bug fixes, and tasks that do not affect the software’s overall functionality. When the new developer has that complete, he submits his code to a senior programmer. She reviews the code and offers suggestions to improve both the code structure and functionality.
Mentoring through review is an excellent way to learn; the junior can traverse the code base on his own terms and absorb at his own pace. The success of this process is entirely dependent on the learning process of the junior programmer but allows him to contribute meaningful code on trivial tasks and ask questions as he learns the code base.
Pair programming, on the other hand, is a bit more effective in walking a junior programmer through the core components of the code base. Pair programming can also provide encouragement and establish some camaraderie between developers working side-by-side at the same computer with their own keyboard and mouse. The exchange between programmers as they work on the same code block can provide some valuable learning experience.
The downside is that it creates a significant reduction in productivity for your senior programmer while she mentors the new team member. Pair programming, even in short stints, still can be very useful for both senior and junior programmer. Where it becomes an issue is when the senior and junior programmer work side-by-side for 8 hours a day. A combination of code review and pair programming is a good policy as it allows the junior developer to learn from the senior developer through shared coding sprints, and allows him to go back to his computer to recreate what was learned for code review later.
Encouraging proper commenting and documentation
How many times have you solved a programming dilemma and added that brilliant code to your project to go back later and discover you forgot why it worked? Programmers are highly focused people who hate distractions. Commenting and documentation feels like a distraction.
“Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.” - Rick Osborne
In encouraging a sane commenting and documentation process, ask your team what they would expect if they inherit code from another developer or development team. “How much is too much?” will always be debated. Keep it simple. Encourage reasonable commenting versus creating long variable names to avoid having to put in a comment; that’s worse than just putting in a simple comment to explain the intended function.
Reward quality code
Give your programming team incentives to push out code that is both beautiful in structure and functional. I’m not suggesting that we use gamification (badges for quality code) but find ways to recognize consistent contribution to the code base and reward the entire team.
If you are leading a team of hard working developers surprise them with things that make sense: take them out to lunch and give them the rest of the day off, give them a voucher for a free day off (that doesn’t count toward sick day/vacation), bring in pizza and beer on a Friday afternoon, or offer them a “lazy Monday” and let them come in late that day.
Don’t base rewards on milestones but on a consistent team effort. Some may chuckle at the team-building tone but it’s been proven again and again that allowing your team to bond over something that is not coding related helps to create a much more rewarding work environment. Developers who feel appreciated are twice as likely to stay with a team. This is especially challenging when you remove the individuality by standardizing on the code base but it’s not impossible and should be the focus of the development team leader.