file-243119101

Clashing Coding Styles: Learning to Work with a Growing Team of Programmers

clashing-coding-styles

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.

See also:

  • Developer Dude

    Coding Standards – bleh

    I’ve worked on a number of different development teams, working in different problem domains from medical software, to a semantics repository, to legal process software, to advertising campaign s/w, to basic business order processing s/w. I’ve seen a lot of different coding styles and code style compliance or lack thereof has little correlation to code quality or productivity – and I’ve seen a LOT of really Really REALLY BAD code.

    Coding and design best practices – now those have an impact on code quality. On one team we pretty much adopted most of the first edition of “Effective Java” as a best practice guide for a given project – i.e., “What would Joshua do?”.

    Beyond that, code should be as readable as possible.

    I personally prefer curly braces on the next line – I think it is easier to read – but I don’t think the difference, same line or next line, or any of the other style guidelines, really impacts coding quality or productivity.

  • http://blog.aplikacja.info/ Dariusz Cieslak

    Coding standard in general is a very good idea, however I strongly discourage from manual reformatting of all source code after project is started. You probably see the obstacle there – the annotate / blame operation is blinded by the change.

    I prefer to have consistent version control history than unified coding style across all source code.

  • Pingback: New Team Members | Tales from a Trading Desk