How should I deal with a team member who rejects "good" programming practices?

I was requested to get in charge of a small team working on a new feature

[...]

Internally in the team I've made a coding convention, which I borrowed from one of my previous projects, which John simply rejects with the same reasoning. What is worse, the entire team leans to agree with John, because it prevents them from progressing so I'm not sure I'm not in the wrong here.

What does "in charge" actually look like in your firm?

Generally speaking, the time for imposing conventions is during initial training, delivered by those with substantial experience to those with none.

When it comes to imposing conventions on experienced technical staff, you'd generally have to seek consensus and demonstrate that there is a problem and that the convention is a clear and logical solution.

Or at best, you'd have to establish that a diversity of styles or approaches is creating a serious problem, and that you've been forced to make a decision on a standard approach using the recognised leadership you command from your skill and experience in the activity.

It doesn't sound at all like you're a trainer, that your working from consensus of colleagues, or that you're a recognised leader and technical authority figure.

My advice frankly would be to drop your schemes, and either get on with some real work coding, focus on coordinating the activity of multiple people together rather than interfering in the minutiae of the work of (apparently very) experienced staff, or hand the baton back on the role.

Generally speaking, if a particular area of coding is extremely sensitive to fine details and overall orchestration, then it should be assigned to one person of the appropriate grade/calibre to do that level of work.

The feeling that teams need complex new conventions is often a sign that too many cooks have been assigned to make one broth. A lack of confidence delegating can be a sign that a particular area has become too complex, that individual responsibilities are changing too often with too little handover, or that there isn't enough skill and experience to go around.

they [have] never been in pure C++ teams before

I clearly recall the one evening when, as a C coder for many years, the brain shift toward OO design pardigms suddenly crystalised for me. (Was trying to write a sophisticated app in C++, from the ground up.) This is my testimony that it can take a lot of subconscious reconfiguration for a "dyed in the wool" C-hack to grok new-and-strange OO paradigms.

...just recommendations and not rules...

'John' is proud, and can look back on many years of 'great coding' writing in C.
And, change is hard(!), moreso as experience builds and hazards and pitfalls become 'tagged'.
Familiarity is comfortable, much like the frog in the pot atop the stove...
And, the unknown 'beyond' may be where dragons reside...

How much has the company invested in 're-training' its staff to use C++?
Commitment from on-high would encourage coalface workers to branch out.
If management doesn't understand C++ is not 'C tweaked a bit', then John is justified to feel likewise.

I suggest you start small, and give frequent well-considered, bite-sized encouragements that illustrate your objectives. Bring the group along, but do it slowly and progressively. Like starting a fire from a glowing ember; at first you blow gently so as not to extinguish what you're trying to achieve...

I'd written 'branch out'. This is a massive understatement. OO principles are completely different from 'imperative' conceptulisations. C++ is a different language, not an outgrowth of C. It's not just a few more datatypes and operators. It's a whole new way of thinking about problems. John's approach - like mine was - is that "C++ is just overly complicated C". It is more complicated. Your job (re John & Co.) is to find GOOD examples of how complicated OO solutions are better at data hiding and, for instance, polymorphisms.

Analogy: Having used (primarily) English for 40 years, I found myself living in Germany for some years. Many of the words spoken were understandable (with some effort), but, for instance, German uses a bevy of articles instead of familiar and simple 'the' and 'a'. German nouns have genders that English nouns do not. German grammar follows its own set of rules that differ from English. The basics appear to be similar, but one must THINK differently when speaking German. Likewise, one must THINK differently when writing C++ code (as compared to C).

Just for fun: Speaking to a stranger (formal) or to my child (familiar), in English I would say simply "You ...". In German, I would say "Sie ..." vs "Du ..." (I think. It's been some years since.) This distinction could 'map' onto C++ distinctions of public: (formal API) and protected: (familiar for derived class access) class members; a distinction not available to C struct members. And, putting the verb at the end of the sentence always made me think of RPN vs algebraic notation. Spaß ohne Ende...

Upper management needs to get its act together and understand these differences. No factory owner would replace a table saw with a lathe and expect to whistle along as if production will not be affected.

The battle you need to be fighting is not with your team. The real battle is with your bosses. You're not just asking typists to change from manual to electric typewriters. You're asking them to change to full-blown typesetting artisans... perhaps without allowing time needed for re-training.

Proper design and implementation of a class in C++ versus a struct in C is not simply a different "idiom". It's an entirely different way of thinking about processing data. Perhaps you, the team leader, need more experience in pure C to better understand John's predicament.

A 'well known' metaphor?

"The Immitation Game" is a very well-acted, exceedingly(!) fictionalised account of the last years of the life of Alan Turing. (Please go with me on this...)

None of us here in cyberspace are aware of the nitty-gritty details of your environment (or even the extent of your credentials.)

The movie depicts Turing in a position roughly analogous to what you've described; facing opposition from "team associates", AND from "above". In this situation, Turing (Cumberbatch) sends a letter to Churchill (contents unknown) that results in, first: Turing being given full authority for the project (including the power to jettison two of the staff), and second: the power to proceed with his plan as he envisions the ultimate goal. Eventually, his reluctant team members come to appreciate where Turing wants to go and willing contribute to the progress. (All celebrate the success when they finally cross the finish line.)

This may be a poor analog for your predicament, but, to me, it sounds like you need a recognised authority to demonstrate their willingness to invest in "what it takes", and to make known to all YOUR authority in your current role.

Just something to think about... Best wishes.

Background: I was a senior software engineer, working in C++, for about 5 years in the prior millennium (now CS professor). I have not directly managed people.

Based on comments, the much larger issue is that you've been given a team of people to build a C++ project, none of whom are deeply knowledgeable in C++. The OP's team appears to be themselves, a junior C++ person, two C developers (including the combative senior), and one or more Java people.

I do agree that use of exceptions, proper initializations, smart pointers, and RAII should be basic expectations when working in modern C++, and probably don't need an extended debate.

My top recommendation would be to focus your efforts in a triage sense for this group of developers who need remedial C++ support. The entirety of Stroustrup's C++ guidelines are likely too much for people to digest at once.

Pick the biggest-ticket items that you care about, and those that have some clear automatable "Enforcement" strategy, per the guidelines. Enforce those with a linter or similar tool plugged into version control; code that violates those enforced principles can't be checked in, full stop. You need to reduce the amount of time you spend manually and repetitively giving feedback on overlooked rules. Either they get on board with the basics or they have no productivity to show.

For the more vague, disputable, lower-value, and unenforceable items, those can be ongoing conversations and/or human communications via merge request comments. On your side you will simultaneously have to accept that you're going to have some lower-quality, partly non-idiomatic C++ code in your project.

TL;DR You're wrong and not listening enough.

I'd suggest a core problem is your own view of "take charge".

That does not mean micro-manage a team's activities, it means facilitate a team's activities.

As they are experienced developers you should be listening to what they suggest, not the other way around. They'll have had years of experience and, unless they're unusual, will have had to learn and use multiple languages, platforms and toolsets.

You have to trust your team.

If you don't trust them, why on earth would you expect them to trust you?

What is worse, the entire team leans toward agreeing with John, because it prevents them from progressing. I'm not sure I'm not in the wrong here.

It sounds like they have decades of experience and are resisting your approach. This should tell you clearly that your approach is wrong. It's not everyone else that is wrong, it's you.

Within the team, I've made a coding convention I borrowed from one of my previous projects

"Hi, never mind the fact that you've to learn a new coding paradigm, but it's vitally important you follow my personal idea of what convention to follow in the language."

That's how that came across. It sounds arrogant and doesn't address what they really need: time and support in learning a new language and programming paradigm.

My impression is that your company (and that means you, as you're managing) have made no provision at all for time to learn the new language and new toolset and mindset. This is a major failing and it probably goes to the heart of your team's real issue.

You've got your priorities completely wrong here.

To me that would sound like an OCD manager who doesn't understand the real problem.

Ask them what resources (and time) they, as a team, need to learn the new language and tools properly and get them that.

Your company (and you) need to understand that you have to invest time (and that means money) in upskilling staff.

Do not tell them how to code. Ask them to make a recommendation for a code style convention, don't dump that idiotic standard on them as if it were of biblical importance. It's not.

At this point you sound like you have alienated your entire team. It is entirely up to you to tell them you accept that you did that, and will try and listen more and tell less. You need to own the problem and in this case, that's you.

Do not make the classic error of telling them "we" got off to a bad start. You got off to a bad start, own the problem. You'll get more of the team's respect doing that than by trying to spread the blame to them.

As a people leader, consensus is good to have but it is not necessary. If John is toxic to the team, then you (or his supervisor) need to have a word with him privately. That said, handing off control of the minutiae is part of climbing the ladder. You might be trying to hold on to too much.

On my team, I can rattle off examples of too many "styles" of code in the same project causing problems in the long run. Sure it may ship sooner, but what happens when someone needs to fix something they didn't write? Those standards act as guidelines so the whole team can reasonably follow along any code. It is a problem, but it's not one that will be solved over night.

Pick a senior member who's passionate about code quality and ask them to head up a software craftsmanship group. At first, the group's goal is to pick the low-hanging fruit. They can discuss amongst themselves what quality issues they see most often and they can share screen to mob code reviews. Have them ask questions and provide guidance. "Why did you select this architecture?" "Why is this list being pulled out of the DB for processing in memory?" And later on, "We have a standard for this situation. Why is this a better approach?" Those reviews will slowly trickle experience down.

From my experience, there is two kinds of software developers (probably "workers", but I know software developers best):

• Those that take pride in their work and want to deliver the best outcome possible. They want to be able to show their work to another fellow craftsman and have them nod approvingly.

• Those who don't give a damn what their workpiece looks like or their peers think of them, they just want to get the job done, get paid and go home.

You are working with the later version.

This is not about language familiarity. All software developers are familiar with multiple languages. Skill, experience and seniority means taking each in stride, using the respective mechanisms, conforming to the rules, practices and norms of professionally developed software in each language differently. There is a purpose to each language and it's environment reflects that. Ignoring that means you are not a software developer. You are a [$language] developer sometimes using a different compiler and language badly. And should be paid way less than your actual software developer colleagues who try their best in each language.

This is not your problem.

You cannot change mindsets. Maybe the mindset of a junior, by being their mentor and the person they look up to, but normally, whether someone does something with joy and pride or to "get it done" is baked into their brain. There are people who vaccuum with pride. I personally hate it and just want to get it done. Some people love and polish their cars. For me it's just a tool to get from A to B and I don't care if it gets scratched a little here and there. If you love vacuuming or cars, you will be very frustrated working with me on either. And there is very little that will change that, it's how my brain works, what I like and dislike.

The question is: what is the business goal of your current project? Why are you writing this software? Is it to write good, maintainable software to a high quality level to work well for years to come? Or is it to just build a ramshakle thing to "get it done" real quick now?

This is a question for your management.

Go ask them this question.

When you come back with an answer, you will either have managements approval to dictate guidelines to John (and maybe lose him as a contributor to get replaced by someone who is out to produce quality) or you have clarity that your fight for quality is entirely not what management wants. Then you can give out the "everybody as they like, I don't care, just make it work" order and not bother with fighting anyone on this. You may want to make a mental note to never work on that project again, after it's "done". It will be a steaming pile of cow manure a year down the road. If they ask who did it and who can fix those bugs... you better be in an even more important project. Or working for a company that values quality more.

This is not a seniority problem. Or a language problem. The quality focussed developers I know love to learn a new language, if that language can do something they had problems doing in their old language. And they love to crank up the linter/prettyfier/whatevertool to tell them about all the best practices and rules and how to make it the best it can be. Because they take pride in their job and their work result.

You cannot really change basic human behaviour. If your colleagues see their work product as more of a neccessity than something they want to do well, you cannot really change that. And if management is okay with that attitude, then the only way out might be to fire management (aka quitting) and find a new management that wants to produce quality and hires people accordingly.

If John, who seems to be a highly experienced developer, doesn't put up with this, and most everyone else in the team agrees with him, then maybe you should have a long look into the mirror and you will see where the problem lies. Your remark "because of his C background" is something that I can only call insulting - making the assumption that John gives any credence to your comments.

[This is much more of a software engineering answer than a workplace answer; hope that's not too inappropriate.]

I confess I haven't reviewed the specific tenets referenced in the question, but in my experience, coding guidelines/standards can be a two-edged sword. Yes, guidelines can be good things, but they need to be applied reasonably, with explicit "escape hatches" that let you consciously violate a guideline if, for whatever reason, forcing the code into compliance with a particular guideline would actually end up making it worse from a maintainability (or other -ity) standpoint.

Stated another way, too-rigid standards can be a productivity killer, especially if they become an end unto themselves. You don't want people blindly adopting certain idioms, and shunning others, just because "the rules say so", without any understanding of the sometimes subtle tradeoffs involved.

Similarly, code reviews shouldn't be a rule-enforcing exercise. In my opinion, the main focus of a code review should be, is this code comprehensible to the larger peer group, and is it likely to be maintainable? There are plenty of other goals of a code review, but I believe they're secondary. And if code reviews turn into a "gotcha" game, exhaustively cataloging every departure from a too-rigid coding standard, then, again, they can be a really productivity and morale killer.

Lead by example. You solve problems using best practices consistently. They will know it is the right and normal way because you are leading. And yes, I have led teams. Some people respond to guidelines and some only respond to seeing you lead. And even then it takes management supporting the right way 100% or some will always be doing it the wrong way because there's not incentive for them not to.

Ideally coding standards and guidelines are there to prevent anticipated problems. Sometimes the problem is that the author of the guidelines has too much time on his hands.

I suggest that your team should base its standards on real problems. A good way to start would be to introduce one practice from Scrum, the retrospective. At regular intervals, say each code release, have a meeting to answer three questions: what went well? what didn't go so well? what can we try next time?

In particular, if something went badly, would a change in coding practice have avoided the problem? Can we all try this new practice next time?

If your team uses retrospectives, and you find you have run out of things that didn't go well, then your coding standard is complete, at least for that project.

I have had similar experience in many projects and since I'm working through outsourcing I frequently (~once a year) change projects and experience different 3rd party companies and their managements.

My advice (speaking from experience)

• Teach the team to appreciate different competences. You have higher C++ skills than they, they have more project/business knowledge than you. Possibly, organize mutual knowledge/skills transfer - an investment into your and workers' skills.
• Change the code review process. A skilled programmer can review everyone else, but a junior can not review other juniors code. And vice versa, other people can review your tasks in regards to business logic because you are new and they have the knowledge about the product.
• Explain to the people of your team benefits of idiomatic code. If they are seasoned workers, they won't change their habits out of plain recommendation. You have to convince them why your way is better. That what you propose is in the interest of the project (and colleagues resumes), not just your authority.
• If the above doesn't work, escalate. This is a competency issue and if your management doesn't recognize it as such I don't have good prospects for the company. Explain benefits of higher code quality.

Rationale:

• I have seen a project completely collapse because of technical debt, in large part caused by issues you mentioned. There is still a chance the project will be delivered but the work will be very unpleasant.
• A frequent issue I experienced is what I call "privatization of Story Points, socialization of bugs and technical debt". This creates a very toxic workplace where a narrow set of people (including you) will be taking the burden of fixing technical debt and bugs caused by other people for no reward and possibly even punishment (tasks completed very slowly). I just can't work this way.

In short, first try to fix the issues in a very diplomatic way. If this doesn't work, escalate and use the powers you have.

At last, if nothing works - resign. I am too much of an idealist to work with such people and while I understand pragmatic approach is very reasonable for many cases, your case looks like just ignorance (especially John who didn't even read your document).

I know it sounds harsh but if you can't fix it, it is the only way to express this is significant for you. You want to perform "the art of code", they want to get the job done with minimal effort and receive the salary. This is not a job for you. I have personally rejected multiple project/job offers (even one promotion) precisely for this reason and looking back, I don't regret them. One resignation even caused a domino effect where few others resigned as well and the company started to do things I was initially told won't happen.

So, this is your situation:

• Two C developers
• One Java developer
• One C++ developer

=> You work in a team of five, and one of them doesn't want to improve him- or herself.

You mention some rules/recommendations not to be followed.

Let me tell you where I ended up:

• Three other employees: a "senior programmer", a junior "programmer" and a boss, who has claimed having programmed in the past.
• Hereby some rules/recommendations that were not followed:
  • Although it was the idea to have one program, to be used for all customers, a separate program was foreseen for every customer. That program (the source code) was present on customer's premises and some hard copies were sent to our firm.
  • When a developer wants to modify source code, he needs to do this on the customer's PC. Afterwards he needs to perform those same modifications manually on the local program, and it was very important that the developer did not forget anything, otherwise the boss would wave his finger!
  • The "senior" programmer didn't like parameters, so he put all information in global variables and used those inside the functions and procedures. The fact that this caused a complete mess in a debugging session was not an issue, because "Debugging (using a debugger), we don't do that around here!", according to that same "senior programmer".
  • Having two functions/procedures doing the same thing, using other values, was very "simple": just copy/paste that function/procedure and modify the values manually. As I stated just before, the usage of parameters in a function definition was not allowed by the "senior" programmer. One time I did solve a problem, just cutting a large procedure into four small ones, using other values as input parameters, at that moment I didn't understand why he was mad about that solution.
  • The people could not understand the difference between "What should I do?" and "How should I do it?", so one time I got a task, the "senior programmer" told me how to do it and when I asked why I needed it to do in that particular way he "told" me "YOU WILL DO WHAT I SAY!!!" (the capitals are not exaggerated).
  • The boss was also the vendor of the firm. As a vendor he had a strict rule: "Never say you don't know something!". I can relate to that rule when dealing with customers, but that rule was also enforced when dealing with colleagues: when I asked the "senior programmer" a question on which he did not know the answer, then he had the right to shout at me for asking such a motherf* question.
  • The boss and the "senior programmer" were shouting at each other on a daily basis. On a weekly basis, the boss said "I am doing this work for more than thirty years!". So one time, the boss gave me a task, I implemented it but the program itself cancelled my modifications (I modified the sequence of some columns, but the program afterwards used a default sequence. That part was not easy to disable). When the boss asked me (for the third time) when my task would be finished, I decided to shout back too (as that seemed to be appropriate there). The boss reached to his heart, whispering "I have never experienced such a reaction in my entire life". During the next discussion I found out that he had no clue that the program was applying a default sequence, so his 30-years experience was nothing but a big show-off, we have agreed not to shout to each other anymore and not even two months later he fired me for having shouted at him.

So, in a nutshell, I would say you're not in such a bad place 😀.
You program in your way, using the rules and recommendations you're used to, and you communicate this to your colleagues (as you are doing now). When an issue happened, which should have been avoided by your rules or recommendations, you solve that issue in that way and communicate this to the rest of the team. Bit by bit they will understand the importance of those rules and recommendations and after some time "John" will turn around to. Just hold on in there.