28

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?

yannis
  • 39,547
  • 40
  • 183
  • 216
Martijn
  • 1,016
  • 9
  • 14
  • 2
    "'yeah, sure you can use that library to do that for you, but that way you don't really understand what's going on'". What he means here is that HE doesn't understand what's going on. We do :) Seems he is afraid of learning something else to improve his productivity. – Damien Roche Dec 20 '10 at 17:33
  • 7
    Your co-worker is not antiquated, he just missed some important programming 101 lessons. Versioning, abstraction etc. these have all been very important 20 years ago as well as today. – Jas Dec 20 '10 at 17:59
  • 7
    The term "antiquated" is a rather loaded and unenlightened term. I have someone I work with who could be described in similar terms as you have used. However he is considerably YOUNGER than me. – Bill Dec 20 '10 at 18:20
  • 1
    The point about libraries is quite valid. You really do need an understanding of what they do - for example things in libraries that create threads or throw exceptions can make your life VERY miserable. A quick peek at their doco or source code is usually adequate in satisfying the curiosity though. This is NOT an argument to NOT use things in libraries, its just an argument to know what they do (and then use them happily instead of in ignorance). – quickly_now Dec 21 '10 at 05:52

13 Answers13

25

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.

Nicole
  • 28,111
  • 12
  • 95
  • 143
  • I agree with this just as much as @pierre 303's answer. He will leave the dark site when he seems to beautiful tools the good guys have. – Kortuk Dec 20 '10 at 17:32
  • 3
    It takes him very little to code it, but your code is maintainable. Your payoff will showup as code is maintained. A good department is tracking time spent on things like maintenance and will see shorter time spent on your code, which makes a little more time upfront worth it. – Kortuk Dec 20 '10 at 17:33
11

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.

  • 4
    303, I think this is the best advice, a new guy critiquing a very competent experienced coworker to the manager is going to result in some very negative feelings, with time you can adapt and help others adapt also. I have had new hires start with me and think they know something that works better and go to the boss, my boss will listen to anything but it makes me mad, as in 3 months they figure out why I was doing it the way I did and are complaining themselves about the change. I think it is a different level, as we SVN and OOP, but the basic premise applies. – Kortuk Dec 20 '10 at 17:24
  • I do not agree. Some practices are good only when you work solo, and this guy seems to be full of them. – Boris Yankov Jul 24 '11 at 16:32
  • Coming back to this question and this answer, after more than a year, option 3 turned out to be the proper solution – Martijn Feb 05 '12 at 15:13
  • @Martijn: thanks for the feedback. I think sometimes, it's preferable for you, for the company and the co-worker ! –  Feb 05 '12 at 15:57
6

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.

Robert S Ciaccio
  • 292
  • 1
  • 10
  • I have had bad experiences when 'trying to shine': a private repository doesnt help much when there is no definitve concept of 'revision' (what changes from the coworker to integrate? often, with people who dont use CVS, it's like 'this function, but not those'). Same thing for automated tests: what good is a build that does not get fixed by the one who breaks it? you refactor, and write the tests, he defactors and breaks the tests. again: your word against his, but now your tests 'fail', which 'prooves' that they dont catch anything valuable. You can't excel _against_ your team. – keppla Jul 13 '11 at 11:01
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).

Damien Roche
  • 880
  • 1
  • 7
  • 20
  • 1
    I can code much faster using nothing special on small projects, but, hell, you maintain a well designed code-base better. This is where good design pays off. The entire design of software code review banks on the fact that it takes more time in maintenance then in coding to fix bugs. – Kortuk Dec 20 '10 at 17:35
  • key part "on small projects". I doubt very much we're talking about small projects here (read: team effort). – Damien Roche Dec 20 '10 at 17:38
  • totally disagree. this doesn't say anything about Walter except that he knows what all these good practices are and how they can benefit the team. not using these practices is what RAD is about, because they slow you down. – Ross Dec 21 '10 at 02:57
4

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.

Darknight
  • 12,209
  • 1
  • 38
  • 58
  • Why spend time on reimplementing a toy project? –  Jul 13 '11 at 11:49
  • @Andersen because some programmes that do not want to listen to reason only accept evidence once it is laid out in front of them – Darknight Jul 13 '11 at 12:30
  • @Darknight, probably not, but still, why even consider spending time on reimplementing toy projects which doesn't apply to real life problems? –  Jul 14 '11 at 13:21
3

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.

ElGringoGrande
  • 2,913
  • 22
  • 20
2

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.

MrEdmundo
  • 285
  • 2
  • 9
2

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

guiman
  • 2,088
  • 13
  • 17
  • 5
    going up the chain of command makes enemies of every person you stepped on the head of, and often does not result well. – Kortuk Dec 20 '10 at 17:25
1

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.

Otávio Décio
  • 5,299
  • 23
  • 34
  • 1
    That is if he wants to change.. – Walter Dec 20 '10 at 17:16
  • 3
    A lot of managers I have had in the past do not value the new guy changing something that seems to work. They value a product done fast as they do not understand fully what you are doing. It seems you have a boss that is not technical which is of major detriment to your section, maybe. – Kortuk Dec 20 '10 at 17:17
  • 1
    If he doesn't then it is even more important that the manager (assuming there is one) knows about it. – Otávio Décio Dec 20 '10 at 17:17
  • @Kortuk - that is a very good point, and if that is true then the OP is in real trouble. – Otávio Décio Dec 20 '10 at 17:18
  • I think that if the OP tries action to try to suddenly change these things and force them fingers get stepped on. This makes enemies and could harm a work environment where he could learn a lot from his colleague. – Kortuk Dec 20 '10 at 17:26
  • Speaking as someone who has been in OP's position before, I'd advise caution. I got management to insist that we use SCM (like every other team in the company did). My cow-orker then took the project prototype, deleted it, then claimed that the SCM system had done it. Things went downhill from there. I'd urge the OP to try to resolve this within the team, somehow, without management involvement. – TMN Dec 20 '10 at 20:09
  • @Kortuk, for change to work you need to show that it will be beneficial. If you cannot do that, well, then there is something to work on right there... –  Dec 20 '10 at 22:43
1

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.

JB King
  • 16,795
  • 1
  • 40
  • 76
1

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).

dukeofgaming
  • 13,943
  • 6
  • 50
  • 77
1

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...

markhahn
  • 111
  • 1
  • version control also provides history. Important when people are no longer around. –  Jul 13 '11 at 11:51
0

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.

Ponk
  • 471
  • 4
  • 8
  • 1
    constantly stepping on each others' toes is a sign that the software is badly architectured. It has nothing to do with source control, and may get really worse without. – deadalnix Jul 13 '11 at 10:54
  • @deadlnix That could be the reason too, but I do think it can also be attributed, in some cases, to over-zealous use of branching when it is not the appropriate solution. – Nicole Jul 13 '11 at 15:25