How do you educate your teammates without seeming condescending or superior?

Question

I work with three other guys; I'll call them Adam, Brian, and Chris.

Adam and Brian are bright guys. Give them a problem; they will figure out a way to solve it. When it comes to OOP, though, they know very little about it and aren't particularly interested in learning. Pure procedural code is their MO.

Chris, on the other hand, is an OOP guy all the way -- and a cocky, condescending one at that. He is constantly criticizing the work Adam and Brian do and talking to me as if I must share his disdain for the two of them. When I say that Adam and Brian aren't interested in learning about OOP, I suspect Chris is the primary reason.

This hasn't bothered me too much for the most part, but there have been times when, looking at some code Adam or Brian wrote, it has pained me to think about how a problem could have been solved so simply using inheritance or some other OOP concept instead of the unmaintainable mess of 1,000 lines of code that ended up being written instead.

And now that the company is starting a rather ambitious new project, with Adam assigned to the task of getting the core functionality in place, I fear the result.

Really, I just want to help these guys out. But I know that if I come across as just another holier-than-thou developer like Chris, it's going to be massively counterproductive.

I've considered:

1. Team code reviews -- everybody reviews everybody's code. This way no one person is really in a position to look down on anyone else; besides, I know I could learn plenty from the other members on the team as well. But this would be time-consuming, and with such a small team, I have trouble picturing it gaining much traction as a team practice.
2. Periodic e-mails to the team -- this would entail me sending out an e-mail every now and then discussing some concept that, based on my observation, at least one team member would benefit from learning about. The downside to this approach is I do think it could easily make me come across as a self-appointed expert.
3. Keeping a blog -- I already do this, actually; but so far my blog has been more about esoteric little programming tidbits than straightforward practical advice. And anyway, I suspect it would get old pretty fast if I were constantly telling my coworkers, "Hey guys, remember to check out my new blog post!"

This question doesn't need to be specifically about OOP or any particular programming paradigm or technology. I just want to know: how have you found success in teaching new concepts to your coworkers without seeming like a condescending know-it-all? It's pretty clear to me there isn't going to be a sure-fire answer, but any helpful advice (including methods that have worked as well as those that have proved ineffective or even backfired) would be greatly appreciated.

---

UPDATE: I am not the Team Lead on this team. Chris is.

---

UPDATE 2: Made community wiki to accord with the general sentiment of the community (fancy that).

Answer 1

My answer is a little simplistic but I always try to get them to have the idea to ask me about something themselves. That way they do not feel like I imposed my knowledge to them and it gives them a chance to learn it on there own.

In the end they learn it and everybody wins.

Answer 2

Sticky wicket, there.

The issue is that when you're educating someone, you're going to come off (to some degree) as condescending or superior because, well, you're condescending or superior. Strive for the later, rather than the former (superiority has a higher chance of actually being merited).

That said, it sounds like you're the Team Lead. Mandate OOP. Tell the two guys who aren't interested the truth: it's painful to maintain their code, and its harder to break things into pieces with which the other developers can help when they insist on using procedural code. Then, highlight specific areas in their code that could have been made better by using some OO practice.

Be prepared for some push-back, but if you can pick out the proverbial "low hanging fruit" which are both easy to implement in an OO fashion and provide great value, I would guess you'd make believers out of them in just a few weeks.

Oh, and tell Chris to sit down, shut up, and that if you need his help with the other two, you'll ask.

Answer 3

Well, the direct approach would look like inviting everyone to a meeting, expressing your concerns for the upcoming project, and talking about them.

I'm guessing, however, that won't work well, so instead I think you should raise your concerns with your mgr and let him take it from there.

If he doesn't see it as a problem, it's not a problem.

Answer 4

Share the codebase, this works really well in a small team, that way there's no strict ownership and you won't feel bad if someone changes your code or vice versa. You'll easily be able to justify any changes to a more OO approach. Also, the other developers will have to look at your code at some point and may start to like your ways. You will learn a lot too.

Show off some cool OOP design patterns, there are plenty of design patterns you can easily implement that will quickly display the power of OOP.

You could also start your new project with the aim to write a large suite of unit tests, making use of a mocking framework. You can't design a system that supports the principles of dependency injection and facilitates mocking without understanding OOP. As for approaching this subject just have a big meeting and go through some code katas implementing applications using a Test Driven approach.

Answer 5

For paradigm clashes such as a Procedural v OO I don't see any easy answer.

In a team where everyone is attempting to solve the problems in the same way then I think code reviews and design walkthroughs are useful. You need discussion rather than "telling" if education is to happen.

For a new project there needs to be a clear technical direction, I really don't see how you can have half of the code written OO and the other half not. So this is a scenario where it's not so much risking being seen as condescending as a need for firm leadership. "We are doing this, do it this way." Where this might be procedural is that's the defined direction.

This will not necessarily be popular, but leaders do not need to be popular, at least not all the time. Once folks are trying to do some new technique, for example OO, then there's plenty of scope for more subtle techniques, but the direction does need to be set.

Answer 6

Pair programming. You discuss design TOGETHER, and come up with solutions TOGETHER, so there is no feeling of "he is condescending me and forcing his way upon me" because you mutually decide what is a good design and WHY it is s good design. The discussion gets him to see the value in the different object oriented principles.

Answer 7

For me, I was the local "expert" on a newly intoduced language and was the go-to guy for anyone who had a question. That helped me teach the new programming techniques, but also our company standards for it at the same time, as the dev team was experienced, just not with this tool.

In your situation, I'm not sure that would apply, as it sounds like you're all using the same technology and tools, just in different ways. Would they be offended if you offered to help solve a coding problem using OOP/OOD? That assumes they'd come to you for help in the first place or accept unsolicited help. This way they would see the benefits first hand, applied directly to something they're doing.

Answer 8

You should deal with Chris first. He is an OOP ally but he's not helping improve the team because he is being a jerk. But the fact that Chris feels comfortable dumping on his colleagues in front of you means that you have enabled it or at the very least allowed it to go on unchecked.

I'm not sure how you might go about grounding Chris but here are some general thoughts:

• Charge Chris with mentoring Adam (extra responsibility often helps people gain perspective)
• You should charge yourself with mentoring Brian
• Challenge Chris to be a better mentor than you
• Challenge Brian and Adam with learning and using OOP concepts
• Set goals and rewards for everyone, including yourself
• Do not accept the belittlement of Adam and Brian any more, zero tolerance
• Do not accept crying from Adam and Brian - time to grow
• Be patient with everyone, including yourself

UPDATE: Turns out that Chris is the one in charge! Yikes. Still, your position is not untenable. You can still be a leader and show leadership even if such a title is not written in stone. And some other ideas:

• Read and digest Joel's Getting things done when you're only a grunt
• Lead by example
• Do not partake in colleague dumping sessions. It doesn't matter if the lowliest of the grunts. You do not have to accept such behavior. You just need a little bit of brass to stand up to the bully.
• Carefully and tactfully ally yourself with Chris superior and make the situation known (a.k.a. Go over his head) This can be very risky though and I recommend it only as an action of last resort

Answer 9

Wait: Chris is the team lead. Chris wants them to do OOP. They don't. Right?

IMO there's a management problem to address in the first place. Your target should be Chris, not the other programmers. Tell him that those programmers aren't going to train themselves just by being made fun of. And then you could propose that you teach them. This could bring you into a position where you don't have to apologize for teaching your peers since it's about the special topic OOP, not about general grandiosity, and since you've been asked to do it. And they'll be happy it's you and not Chris who's teaching ;)

Answer 10

One of the keys to avoid offending the rest of the team is to broadcast your advice. Don't focus your efforts on a particular person or group of people, or it might appear that you feel they need extra help that others don't.

Also, you may be able to get your teammates wanting to teach themselves. If they are shown (preferably indirectly) the benefits of using an OO design, they will become more curious about it and want to learn more about it. This is a good opportunity to lend your own expertise or to point team members to useful resources.

Example: When my team recently converted our build system from batch files (shudder) to make files, most of the team had little to no experience using make. Unfortunately, these were also some of the senior developers who had been working here the longest and were the last people that you wanted upset with you. In order to educate them subversively, I gathered together several articles, manuals, and websites that I had found and made a "list of useful bookmarks" out on our shared server. I sent an email out to the whole team that was worded something like "I have been working on learning the new build system and I found several web resources were very helpful. I wanted to share them with the group in case you might find them helpful as well, I posted them to <<server>>". Very non-confrontational and non-directed. Later, as some developers started having problems with the new build system, I would answer their questions by referring them to the documentation I had posted. Saying something like "there's an article that answers that question better than I can off of the top of my head" is a good, neutral way to get someone to read something that they might not normally have taken the time to read. In the end, the people who really needed the extra education ended up learning what they needed to learn without realizing that we were trying to teach them specifically. The actual educating was done by an impersonal third party (the documentation), so there wasn't any ill will sent back our direction.

You can adopt a similar approach with your situation. Gather together some resources on OOP design and have them easily available for sharing. If you have some relevant books at home, bring several to your office and leave them on a shelf. Keep a bookmarks folder full of links to relevant online resources and discussions. When Adam or Brian asks you for help or expresses that they are stuck on something, you can teach them about OOP design while helping them out. You can start with "well, here's the first thing that popped into my head", and then demonstrate an OO solution to their problem. You can also refer them to an existing OO solution (or solution to a similar problem); it's hard to turn down an existing solution and even if they don't write all the code themselves, merely working with it will increase their exposure to and understanding of OO programming. If you can get Chris on your side, talk to him about occasionally assigning tasks to Adam and Brian that involve working with a part of your code base that is already OO, and assigning you to work on part of the code that is not OO. They will slowly learn more and more about designing and implementing OO code as their exposure to it increases, and any trouble that they may have can give you another opportunity to demonstrate (in a matter less confrontational than Chris) how an OO approach would attack the problem. Presenting the material as "here is one way to solve it..." goes over far better than "this method is better than your solution, you should do it this way...".

Answer 11

Everything else aside - I consider code reviews extremely valuable, regardless of how good the developers are and if they all 'get it'. It's good that you mentioned them. You may be thinking of traditional code reviews where everyone gets in a room together and spends hours going over a large chunk of code after it is already done. This can be done in a far less time consuming manner, using only one other developer - done at the time of commit.

At my workplace we call these less formal (but mandatory) code reviews 'code walkthroughs'. When code is ready to be committed - you must get another developer to review the diffs with you, explain your changes, and demonstrate that they work. Demonstration can be in the form of unit tests passing or demonstrating the application functionality directly. Once done, the initials of the reviewer are put at the front of your commit message, signifying the process was followed and who reviewed the changes. Occasionally, if it is a particularly important piece of code you may call in an additional developer to look at it too.

The majority of these walkthroughs should not take longer than 5-10 minutes. When they do, it is usually evidence that smaller, incremental commits should be happening instead of week long dev with giant commits that would take an hour to explain.

This offers all kinds of benefits:

• a second set of eyes to find bugs before they are committed (when it is cheapest to fix them)
• opportunity to discuss alternate implementations, and what things were considered already when writing the code.
• knowledge distribution, more than one person will at least be somewhat familiar with a given section of code
• enforcement of any required practices (unit testing, code hygiene, etc) can happen during walkthroughs, prior to code entering version control.

This alone won't solve your problem, but it would help. It gives both sides a chance to see the other's methods, and is a good learning opportunity for all parties. Rotation of who you get to do a code review can happen any number of ways, so long as the review process goes both ways. If you do a code walkthrough for Adam, Adam should get do a walkthrough for one of your commits too.

In a sense, code walkthroughs offer some of the benefits of pair programming, but with less time investment. I am a big fan of pair programming, but it can be hard to switch to after the fact. It may similarly be hard to transition to code walkthroughs - though I would expect less so than full pair programming. The only investment other than time is potentially a second set of chairs for convenience, rather than wheeling chairs between offices or cubes.

Given the updated info that you are not the team lead - I would suggest to Chris giving this process a try. The 'walkthrough' naming in particular sounds less threatening than 'review', and it happening 1-on-1 in both directions means no one is the de-facto superior. The person performing the walkthrough is the gate by which the commit is allowed - they have a right to say no, or yes but only after you fix A and B.

Answer 12

Motivation is the best way to learn anything new. As long as Adam and Brian don't want to learn OOP, they will never get good at it, even if they are smart guys. So you should think of ways how to motivate them. I guess that's what you meant with sending weekly mails that address one particular concept that might help anyone. But as long as they see obvious ways on how to solve that problem in their procedural way, they won't get too exited.

Maybe you can get them playing with something that can only be solved with deeper knowledge of OOP, for example a specific library that does something useful/cool but requires you to write subclasses or follow a specific design pattern. That way they'll have to write OO code instead of just reading about it in your blog/mail or seeing it in a code review and perhaps they'll see how easy some tasks get if one adjusts to the rules.

And just because I'm curious: What language do you guys use?

Answer 13

Your team sounds fairly free and loose. Seeing as you don't have any real control, try and write the code you have responsibility for as best you can. People are often more swayed by sensible examples rather than being told. If you write good code and they come to maintain it, they will probably start to see the reasons for writing in an OO fashion.

As a question, how 'good' is the code that Chris produces? Is it just OOP for the sake of it? There's a world of difference between blindly following what you believe is best practice and writing decent sensible OOP style code that actually makes life more simple.

Answer 14

I'm a firm believer in the 80-20 rule. 80% of the problems are caused by 20% of the people.

I suspect the reason why Chris tends to make shortcuts in his code is because he has other responsibilities.

Chris has to switch gears and become more a real manager of people than a their competitor.

I've seen many companies require that their technical managers also be working developers rather than technical leaders who work with and through their people so the situation becomes one you describe.

So it's not entirely his fault also.

Answer 15

I think the best way is to start discussing politely about the topic instead of criticizing their point of view, showing personal points of views as suggestions, not as ultimate truths.

Personally I think that being a little emotionally intelligent might help.

Answer 16

Implement code standardization (web, db) within your team--this way, everyone (current and future newbies) would have no choice but to follow the standards. Reason out also that this has to be done to enable everyone to understand each others' code, especially when projects are passed on from one developer to another.

Answer 17

If the high-level architecture of the app is sane, then it will be maintainable no matter what the low level code looks like. The object-level is too low-level to dictate these kinds of details--break your app into reasonably sized modules, agree on the the design of those modules and the interfaces between them with the team, and then stop worrying about the programming style within a particular module.

Once you've broken up the work sanely among your developers, it's mostly about personal responsibility for each of them. I don't care if a developer I'm working with writes "bad" code so long as he can maintain it as the product direction changes, he can fix it when it breaks, and it doesn't cause excessive problems in the field or for other developers.

If a module becomes unmanageable over a period of time, and product direction demands it to do something that it can't, it may be time to rewrite that module. If your software is architected well, this shouldn't be a big deal.

In the long haul, letting people do things their way will give them a sense of ownership + responsibility that you will destroy if you dictate the low-level details of their implementation. This sense of ownership will be much more valuable to you as a manager than code that you find a bit more tasteful.

If letting people do things "their way" is causing real business problems for the team (not "i-dont-like-how-their-code-looks" problems), then you treat it as a business problem, have a post-mortem, analyze to find the root cause, and make a plan for avoiding repeats in the future. If you do this process genuinely and avoid obviously pushing agenda, you will push people in better directions over time.

Answer 18

You need to make them realise how oops can solve your project problem by examples. How hard you try to teach somebody oops concepts, they won't know the actual value till they don't realise practical value of it. I would also suggest to give more responsiblity to Adam and Brian, once they have responsiblity to maintain large code themseleves, they will automatically start using oops concept for better code management. Group design also helps to an greater extent.

Answer 19

Demonstrate the benefits using oop approach to your team members beyond the eye of sauron (Chris). Alternatively ask management for training?

Answer 20

Have you tried the time-tested tradition of telling the truth in a constructive manner?

"Guys. Something has been bothering me for a while and I want to address it today.

Chris: it is my perception that you can come across as arrogant and condescending when you master a concept that others don't.

You two: I admire your ability at procedural programming, but am disappointed to see little effort at learning OOP.

The consequence of this is a tense environment.

Guys: what can we do to fix this?

I propose: (your proposal)"

Truth can work wonders.

Answer 21

Leaving aside the question of how they were hired, how on earth were Adam and Brian assigned to this team in the first place if they can't do OOP? I would have thought it was an expected skill now for any modern working coder.

Now, I fully understand why someone might not like OOP. On first glance it appears to be code from Venus to someone who was trained in procedural coding in Ye Olde Days (like myself). I've fiddled with it a bit and I'm sure I would get the hang of it. I'm skeptical that it imparts all the benefits it is claimed to and I'm told that studies have confirmed that it actually doesn't. But I don't work as a developer so there is no urgency for me.

For someone working as a coder the story is very different. All of the coders in the teams in my current environment have to do OO. They do it in C (with GObject), C++ and Python. There really is no choice in the codebase they are working on. They wouldn't last if they couldn't do OOP any more than if they didn't understand pointers.

Here is what your team leader should do: send them on a training course to learn OOP! There's plenty of training outfits that do crash courses in various coding topics. It's probably tax deductible. Continuing training ought to be part of every workplace (but isn't I know). If they go on the course and still have an attitude that says "I won't do OOP", then it's disciplinary action time.

Moreover it sounds like there is something unhealthy about your team dynamic. Maybe a full and frank team discussion at which these issues are confronted, mediated by an independent person from outside the team, might work to shift the blockage. Admittedly that might be a high risk strategy. Coders sadly all to often often conform to the stereotype of not being good communicators.

Answer 22

Slack more.

Code review (informal, formal), pairing (promiscuous pairing), intervention(discussing politely, suggestions). All great. All point to the need for creative "slack", a term I picked up here: http://dhondtsayitsagile.blogspot.com/2010/04/slack-were-not-slacking-off.html

Add to this: allow more time for Design. (In the scrum process you get some of this in Sprint Planning 2)

Taking some time for design gives slack up front. This would allow communication of OO principles from C -> A,B. The key is to start percolating the concepts to arrive at a shared technical model for how to be writing code.

The concepts of Domain Driven Design apply equally when the domain in question is technical architecture. You need to make sure you can communicate using ubiquitous language and a coherent domain model, which is going to fall apart if you are doing different things. What you rightly want to avoid is the cludges and "dummy"-fixes that occur when two technical approaches (models) try to meld together in an "OK-ish" way.

(The "OK-ish" concept comes from Eric's excellent QCon talk: http://www.infoq.com/presentations/Sustainable-Design-for-Agile-Eric-Evans , worth a watch )

Time for design will also reveal how you all (A,B,C,D) think about the actual domain. The language used and diagrams drawn will hopefully reflect that everyone already thinks of the domain model in an OO way: are the diagrams that are drawn by A,B UML-esque? If not, maybe spend some design time working with the model, and each other.

Any change or conflict will probably be taken in a bad way if emotional bank accounts are low (Seven Habits, Stephen R. Covey) as evidenced in The Five Dysfunctions of a Team ( Patrick Lencioni, http://en.wikipedia.org/wiki/The_Five_Dysfunctions_of_a_Team ).

As a parting thought, take some more slack time for Tech Talks. An hour on a Friday afternoon to watch a good video or have team members prepare some presentations will help to spread the love.

Good luck.