Back in November, a reader sent me a really good question about how to handle another developer who is stuck in the '80s. Unfortunately, because of how the e-mail was sent, I was unable to reply. Here is the reader's e-mail, along with my recommendations about how to handle this tough situation.
I follow your and Chip Camden's blogs on TechRepublic.com, but I have yet to see a post on a particular issue that keeps bugging me.
How do you (or do you?) deal with clients on the issue of technical expertise? I grew up with OOP, and this guy wants to basically do procedural programming (this is an ASP.NET project). He uses external functions and methods sparingly, preferring to only use Page_Load. Any time an error occurs, he begins debugging by blaming the fact that code is in a different page event (e.g., PreInit or PreRender).
When he notices that I use classes, he goes nuts and starts explaining about why it's better to program 'transparently,' which is basically the non-OOP way of doing things. I'm more of an n-tier guy, myself, and no matter what he says, I can't bring myself to code down to his level.
I keep trying to explain to him the reason why I program the way I do, and that there are benefits to using the different page lifecycle events, but he won't take the time to learn new things.
Another example of weird behavior: he doesn't know how to use the debug menu buttons, such as Step Into or Step Over. He was using Step Into using the correct function key, but he didn't understand that he could jump over, or out of, a piece of code. Then he would complain that there are too many layers in the project, so I would hide that code from the debugger by using an attribute on classes he didn't need to go into.
By the way, there is an age difference of about 40 years, so I'm assuming that, mixed with the PhD, is causing an issue of trust. How would you deal with this?
From the sound of it, I get the impression that this other person is not just a coworker, but someone whose opinion can make or break your career. Unfortunately, having spent decades in the "stone ages" has made it hard for this other developer to be open-minded about the benefits of modern programming techniques. In addition, it seems like this developer is unwilling to put forth even the smallest amount of effort to learn new tools and techniques.
Some things to keep in mind while working with this developer include the following:
- He is filled with a ton of old school tricks and tips that he would probably love to share with someone, and he could give you an insight into this business that you can't get elsewhere.
- At the end of the day, all of the mainstream object-oriented languages end up being imperative code at the method level. While his experiences may not be directly useful or pertinent to your current projects, there are probably a lot of ideas that he has that can be used, but maybe not in the way that he thinks they should be.
- Very few people are 100% impervious to change. Oftentimes, the "latest and greatest" does not have an obvious benefit to them, or things that you think are benefits seem like drawbacks to someone else. For example, to you, object-oriented code is great because it abstracts out the implementation details; to him, that is frightening because it means he has no idea what is happening "under the hood." Both viewpoints have merit.
- Object-oriented programming came about to address the same problems that more traditional techniques were trying to solve, but from a different angle that hopefully minimizes the problems that those techniques had too.
- Given the length of his career, your coworker has some evidence to believe that his way is right. This doesn't mean that it is the best way, but it seems to be working for him up to this point.
- For better or worse, he may have some influence over your career. Whether it is through a supervisory role or even just as the seasoned veteran passing on his opinions to the boss, when an experienced pro speaks ill of someone, management often listens.
- As much as watching him floundering with the tools may drive you nuts, it probably does not actually affect you as much as it feels like.
What does this mean to you? Tread lightly. The last thing you want is to have someone with decades of experience telling the boss that you are impossible to work with. In these uncertain times, not being viewed as a team player will sink you.
From what you've written, it sounds like you have tried to show him the light on modern techniques, but it may be the way you approached the topic. Did you talk about the techniques in a way that addressed his concerns? It's one thing, for example, to say, "OOP abstracts the details away." As someone who was taught in a more old school environment, I can tell you that this is a scary thought. Most of the more experienced developers I know turn green when they see the call chains that object-oriented code often contains; to them, it looks like a fancy version of spaghetti code. You know what? They're right. The same thing goes for "overly architected" object-oriented solutions, where someone took what could have been a 1,000 line application and turned it into a 20,000 line "framework" complete with interfaces, abstract classes, factory classes, and so on. I am not saying that these ideas don't have a place; but in so many of the examples that are out there in books and magazines and on the Internet, it is really hard to see the benefits of object-oriented programming.
There are a number of things that you can do that will help this situation become more pleasant. You won't be able to change who he is or what his experiences have been, but take the time to get to know what his past experiences have been. Maybe he is really turned off by object-oriented programming because he used to work with someone who tried to ram it down his throat. Or maybe he has been involved in some really poorly architected object-oriented projects. Maybe he has never been properly introduced to object-oriented programming, and all he knows about it is what some "guru" has said. But you won't be able to approach him with a chance of success without knowing what his fears about modern ideas are.
Fears can be divided into a three major categories: rational fears, irrational fears, and past-based fears. Rational fears are those that make sense, but there are no experiences to back them up. For example, this person may have a rational fear that using object-oriented techniques will make it harder to find which piece of code is responsible for generating an error. An irrational fear is one with no logical basis. If this developer does not like object-oriented programming because he feels that it would lead to mass hysteria, it is an irrational fear. Past-based fears are rational fears with actual experience to back them up. For instance, if he worked on a project where 10,000 lines of code were object-oriented architecture with only 500 lines of actual code, his fear of object-oriented programming would fall into this category.
This matters because it affects how you want to settle these fears. Rational fears are the easiest to deal with: simply acknowledge and respect them. If he has a rational fear, show him how you can mitigate the risk as best as possible and move on. If his fear is irrational, you can try to defuse it, but remember, irrational fears are often immune to reason, and you may need to just leave it alone. If the problem is that he has had bad experiences in the past, then you need to show him through the quality of your work that object-oriented code does not always have to violate traditional principles of good coding.
In terms of his issues about using the tools, I know it can be frustrating. At the same time, try to keep in mind that, if his debugging work goes slower than it could because he does not know much about how to use the IDE, that's his problem and not yours. If it does impact your job (maybe you are waiting for his work to integrate with yours, for example), then you need to find a way to educate him without offending him. Sometimes the best approach is to be blunt but gentle. Something like, "It seems like you are not familiar with some of the more useful debugging methods in this IDE. Would you like me to show you some tricks? They might save you a lot of time." This puts it out on the table that you know something that could help him out, without making him feel like he is stupid. Things like eye rolling, muttering, etc. are never helpful. Another trick that might help would be to compile a list of IDE cheats and send it out to the entire team so he doesn't feel he's being picked on. This puts the information in his hands in a format that he can use and allows him to learn these things on his own and feel a sense of accomplishment.
One thing I must caution you about: under no circumstances should you "call him out" in public. If there is one surefire way of making a permanent enemy, it is making someone feel like a coworker is calling them stupid in front of others, even if you aren't. These conversations should be held away from others, preferably in a private office, closed conference room, or possibly at a friendly lunch. I've found that sometimes the exact same message will get a very different reception depending on who else is around. Even if you are trying your best to be polite and positive, the presence of others can make him defensive and cause him to ignore you or become hostile.
I hope this advice is helpful. If you've been in a similar situation, what words of wisdom would offer this developer? Share your thoughts in the discussion.
J.JaDisclosure of Justin's industry affiliations: Justin James has a working arrangement with Microsoft to write an article for MSDN Magazine. He also has a contract with Spiceworks to write product buying guides. --------------------------------------------------------------------------------------------------------------- Get weekly development tips in your inbox Keep your developer skills sharp by signing up for TechRepublic's free Web Developer newsletter, delivered each Tuesday. Automatically subscribe today!
Justin James is the Lead Architect for Conigent.