Following up on my post from a week ago, I have another point to make about consulting, specifically as a developer. If you are working with developers on the client side, you can’t just go barreling into the project with a mindset that the coding standard/process/whatever needs to be a certain way. Conversely, consultants shouldn’t let clients write bad code. There’s a happy medium between the two where you can meet the client’s coding standards but still suggest changes in coding standards/processes. You might think code is more readable with an extra carriage return after every opening bracket and before every closing bracket and an extra space before and after parentheses. They might praise you, but you can’t be butthurt if they disagree. You might also believe that peer code review is better than pair programming. Some people will agree, others will not. That’s just the way the world works.

This all comes back down to being a cooperative and helpful person. Developers can be very passionate, stubborn people who often stand their ground if they are arguing a point. That’s all fine and dandy if you’re arguing over something where money is not on the line, about which clients tend to be very sensitive. Baselessly arguing with the client is a waste of time and money; at the end of the day, the code you write for them is their property. After all, their developers will be the people maintaining it if and when your stint with them ends. If you’re going to argue a point to your client, make sure you’re making your points clearly and with logic, rather than emotion, backing them. It’s your job to help them reach a goal or avoid a problem, not to become a blocker or a problem for them.

Different coding standards and processes work for different people and teams. You can’t judge others on that stuff if that’s what works best for them. There’s no one “right way” for every situation. What’s awesome is that if they haven’t found the best process or if they simply don’t have one, you can suggest one. If they have a process that works for them, then you shouldn’t be rejecting pull requests or arguing during pair programming when their code meets the team’s agreed-upon coding standards, but not your personal ones.