Handling my antiquated coworker

Question

I'm a fairly young programmer, and I work at a medium sized company's IT department. I have a coworker, and he is a really good Visual Basic 6 programmer. And I mean really good. Honestly. He can deliver working applications, containing very few bugs, in the time I need to get my first cup of coffee, and boot my machine. He is just that good.

Thing is, we are working with a team, and his working style is completely antiquated. He doesn't believe in versioning software (if you just make sure your code is correct, you don't need all that nonsense). Doesn't believe in deployment (I can deliver a working executable. How that is deployed is for the sysadmins to figure out). Doesn't believe in abstraction. ('if you want to create a subroutine, go ahead, but don't call any subroutines from that subroutine. It gets messy that way, and the code is hard to follow. This way every one can follow every step on the way.' or 'yeah, sure you can use that library to do that for you, but that way you don't really understand what's going on') and certainly doesn't believe in OOP. (we work in VB.net)

He is so good in what he does, he can deliver applications way faster than I can. But it just doesn't work in a team. Our other team member is quiet, and doesn't like to speak out, though he tends to agree. Our manager thinks I make valid points, but is not a programmer.

I have a really hard time maintaining programs he has written, and it doesn't make for a good team atmosphere. What do you think is the best thing for me to do?

Answer 1

This sounds like one of those "He's a good guy but..." where you know the truth is coming. And the truth sounds like he isn't really that good of an engineer. Good software isn't just about working and development speed. It's also about the other things you mentioned - maintainability, compatibility, abstraction (for future efficiency), etc.

So, that being said, it sounds like you have a problem developer on your hands. What's worse for you is that he's proven and probably set in his ways. So what can you do?

• Work around him.
• Strive to produce your projects on as tight a schedule as he does.
• And if you can't, produce a better result.
• Over time those proven concepts which he dismisses will begin to pay off for you.

On the other hand, if you are forced to work his way, leave.

Answer 2

Don't try to change your colleague. You are describing him as someone able to deliver working software. It's probably too late to integrate it in the team either.

So you have two choices:

• Adapt yourself. Maybe with time you will be able to convince him of the utility of a source control system? You will have to increase your circle of influence. The more resistant to change he is, the more time you will need.

• Remove yourself from the team. You have lot of points to justify this. Maybe you should leave it maintain its own applications alone, and dedicate yourself on new stuff.

• Remove yourself from the company. Sometimes, this is the only solution.

Answer 3

If I were you I would set up my own source control system right now. Start using it for everything you code, and administer it so that your other team members have accounts and can access it. Your other coworkers will likely be enthusiastic about using it.

Your colleague who does not believe in such practices may not be easy to persuade. However, any code that you are forced to work with that was written by him should go into version control so that you can work with it. When he needs access to your changes, send him a simple step by step set of instructions on how to pull your code from the repository.

You don't have to be combative or go above him to get him involved in more modern processes. Sometimes just going your own way and being a leader with action is more effective than trying to convince somebody with words. Baby-steps. If he starts being more responsive to the version control, start refactoring subroutines and adding unit tests to protect against the changes. Automate the tests and show him how he can access the results as soon as he makes checkins.

A lot of times people are just resistant because they don't like change. But if the changes are presented to them in a gradual manner and in a way that makes it easy for them to follow, often they will see the benefits very quickly.

Above all, make it all as simple as possible for him (Keep It Simple Stupid). Allow him to start following these practices on his own terms. But don't let it drag you down.

Answer 4

I'll be honest, you're not painting a good picture of him. Archaic methods, hard-to-maintain software, stubborn to new ways of working, against abstraction etc etc

From what you've said, if he is producing largely bug-free software FASTER than you are without use of reusable libraries and design patterns aimed at rapid application development then it says more about yourself, than him...

..about him..yeh, find a way to NOT work with him and NOT be associated with his work. Seems like he has a typical selfish attitude towards his work. You can't work with someone like that, you can only observe them work and tidy up after them (like you currently are).

Answer 5

I've seen this before,

And I'm almost willing to bet: This type of guy only appears "fast" because he has a set of tried and tested "patterns" in his head. 99% of Line of Business apps is CRUD, basic stuff.

He probably uses a ton of Copy & Paste from his own existing code (nothing wrong with that).

But..

The moment he encounters anything remotely complex, it falls down, why? because it no longer fits any of the basic "patterns".

A little challenge...

I'd create a project on the side, a complex one that really benefits from OOP and code re-use.

Then show him that project and ask him to implement it feature for feature.

I'd then wager that his code will almost certainly be 10x times larger & 10x uglier if he had implemented it his way.

Answer 6

Look at this from the business side.

You take more time to produce buggier code. You produce less revenue therefore you suck.

If, over time, you can reverse this then you can reverse this.

But maybe, just maybe, this antiquated programmer can actually teach you a couple of things about producing code quickly that is so bug free? Maybe his techniques are not so old school as you think?

I find it suspect that somebody can produce such great code without some very good practices. You might be able to learn those practices and apply them to the "best practices" and trendy things that you understand.

Answer 7

If your manager isn't a programmer try and put it in terms that he will understand.

• We should use sourecontrol because if we don't we could have big problems recovering

• It takes me x amount of time longer because he refuses to follow some fairly basic processes.

On the other hand, make sure you don't get too caught up in perfection i.e. this is a best practice we must follow it. It's likely your co-worker has a lot to add, you might just have to nudge him in the right direction slowly.

Answer 8

Seems like you coworker have never developed in a team. That kind of solo guru kind of partner does not allow a good group dynamic. So tell your superior about it and try to discuss pro and cons with your partner fevor doing it. If you could do it the nicer way great, but if he declines, go up in the cahin of command

Answer 9

Talk to your manager, plain and simple like you did here. There is potential here for growth - if your coworker is good as you say he is it shouldn't take him much convincing to make him start converting to using source control and .Net with proper OO concepts.

Answer 10

I'd talk to others to get a broader picture of how things look where you are. Perhaps there are some separations there so that his code doesn't have to mix too much with others as there is the potential to segregate him into his own area for one way that this could be handled though this is more for a higher up like a director or CIO to make rather than a developer.

You may want to talk with him to see what kind of larger systems has he built as there are some big enterprise systems that tend to be a lot of building blocks where spaghetti code can run into the land of, "Oh, that is why OOP can be good!" though this does sometimes take the case where it proves quite useful to see how this can be a useful thing to have in one's toolbox.

Apathy may be another suspect to see if that is why he'd reject some things that I'd consider close to fundamental in terms of how I tend to design code but then maybe I've had too much of the Kool-aid.

Answer 11

Challenge him (in a good way) to prove you otherwise, show him the cool side of the tools and practices. Don't patronize.

For example, perhaps he doesn't believe in versioning as an aid, but show him how branching/merging and how he can work on several experimental features without needing to have a bloat of files.

Regarding OOP, show him some cool/complex design patterns, such as the command pattern, the task pattern and how it can save him valuable time, and all of your team .

If you don't have him interested in the slightest... he might be a lost case, but then again, you have the tools for your team and you to outperform him. Try to use a repository software that shows/emails commit messages your manager can see, that will bring transparency to your manager and leave your coworker out of the picture (bitbucket.org has free private repositories with unlimited space, if you use mercurial).

In the end, don't try to convince with words but with irrefutable actions, that is the best way to deal with stubborn people IMHO (reverse psychology works sometimes too, lol).

Answer 12

well, the techniques you mention are obviously good, but you also need to ask yourself whether you're pushing them as ideology. I find that younger programmers do tend to be a bit evangelical about what they picked up in college. remember that these techniques are good because of outcomes: version control enables concurrent development, clearer tracking of design, development, testing, bugfix stages. if your projects really are short-term, a lot of that is simply inappropriate, and will wind up making you less agile. it's simply not the case that best practice means using every possible best practice. abstraction, for instance, definitely can be more a liability than an aid, at least some times. version control makes the most sense when you have extended development timelines, complex code, multiple programmers - there's a sort of synergy, which is hard to get traction with piecemeal.

I think the place to start is keeping an eye out for potential reuse - as projects go by, think about commonalities, or more general frameworks. trying to get out in front of the projects would be a powerful move, and might let you work in more technique...

Answer 13

You should ask your supervisor to do a presentation for EVERYONE on why "versioning" software is good. Don't single your coworker out.

I'm a skeptic of source control software myself, because I see people misusing it all the time -- as a way to avoid work.

My coworkers are CONSTANTLY merging, constantly stepping on each others' toes. But a good friendly lecture on its benefits would be a nice thing and would spur discussions.