Fog Creek Software
Discussion Board

Dealing with obstinate nerds

How do folks deal with these types?  I'm talking about developers who are smart, but  are inflexible.  They don't follow the de-facto shop standards in existing code; their code works and is efficient but they do things like modularize and abstract to an absurd degree, and use arcane constructs when a slightly longer but vastly more understandable (and thus maintainable) approach would work.

They reject suggestions that would require them to re-work their code.  For example if something comes back from a usability test that indicates users are having a problem with an aspect of their UI implementation, they are just "stupid" users.

They are difficult to talk to and have the personality of a microprocessor.

Hope this gives an idea of the type of person I am talking about.  In our case we are an academic institution and don't always have a lot of choice on who is assigned to projects, and it's hard to get rid of people.

Used to deliver pizza
Friday, April 04, 2003

You use the same techniques that have been successfully used on nerds for ages:  Beat the crap out of 'em.

Friday, April 04, 2003

Well, if you can't fire them, then make sure their phone number and email address are featured prominantly in the program.

Let the users take care of them for you.

Steve Barbour
Friday, April 04, 2003

Fire them anyway.

Actually, the formal termination process isn't supposed to be a termination process - it's a counseling process meant to try NOT to fire people.

You counsel them. Start with "if you have problems with the standards, perhaps you can discuss what your issues are. But if we decide not to change, I expect you to work within the established guidelines."

If the nerd doesn't deal with that well, then a manager explains to him/her, in a formal setting, why their attitude is a problem. The manager gives them guidance and suggestions towards resolving the issue.

If, two months later, they show no signs of change, you have another little sit-down. You explain again that they are not the department chairman and they are expected to follow standards and react favorably to feedback.

Make it constructive. If it were me I probably couldn't resist the urge to suggest they can't be that smart if they can't work within published guidelines... [grin]

But ultimately, if you've tried to work with the person and they simply refuse to work with the team, you get rid of them.


Friday, April 04, 2003

Let them go work for an employer who appreciates their ability to create working code efficiently. this will enable you to take over their project, mess up their working code, and blame it on then while talking about how superior you are.

Friday, April 04, 2003

You might try to at least write down some coding standards.  It is a bit unreasonable to expect anyone to follow "defacto standards".  When can they be sure they are doing it right?  You seem to have an idea in your head of what the standards are and you expect these developers to be able to figure out what's in your head.

Friday, April 04, 2003

Ed's onto something.

It sounds like this isn't really about what the developers are doing - to some degree or another, it's about ego.

As for the "stupid users" comment - if you are the boss, make a decision, and inform them of your decision to change screen X to do Y.  Then if they don't do it, you're dealing with insubordination, which is a different problem, altogether.

If not, lobby the decision-maker.

Likewise, if you're not in charge, a lot of this stuff is personal opinion.  You might need to take a careful look at, relatively, how well off you are.  The code works.  It's created quickly.

If you are a decision-maker, well, then, make it clear how you want things done, and talk to your boss about ways to influence people.

If you're in some-sorta-wierd project-manager-with-borrowed-reports-and-you-don't-write-the-annual-review situtation, you need to call the real boss and involve them.

Final thought:  Take another step back to make sure it's not just that these guys are "different."  When ego's are invovled, it's easy to confuse "different" and "wrong." 

Different is not the same style or attitude as you.  Wrong is insubordination,  the peddling of 'solutions' that don't work, or incompetance.  If you have an objective way to measure it, taking months to develop a solution that more than 50% of your people could bang out in a couplea weeks is problably also "wrong."

just my $0.02 ...

Matt H.
Friday, April 04, 2003

The days of the nerd BOFH using his IObfuscate interface are over. No one wants to see clever obfuscated code, they want to see code that is easy to understand and maintain. Human costs outweigh the cost of machines. Adding one's clever hack to get the nth degree of efficiency is usually not worth the human costs of maintainability. Software is dynamic and requires constant tweaking until you reach a state of acceptable quality. Until that state is reached you are not finished.

Software development requires teamwork and the ability to absorb contructive criticism. Let them know they need to focus on the user and not their nerd ego trip.

If that fails then beat their ass into submission with a few good back handed - baby powder laced - pimp smacks and tell them to get over themselves.

Friday, April 04, 2003

Certain people can only code well if they can do it in their own way. As a teacher I see these types quite often as there are usually 3 or 4 in every batch of 40 that I come across.
They dont respond well to teaching in the regular sense but once you hammer the basics of something into them, they can take it and experiment with it with much better results than the avarage student.
The reason you might have trouble making your coders follow rules may actually be insecurity. They learned what know by finding out for themselvs and doing things their own way. They have never been forced to performe on someone elses terms so they dont really know if they even can.

Eric DeBois
Friday, April 04, 2003

If de facto standards aren't followed, they're not really de facto are they? As a previous poster said, the standards should be written down.  The tough part will be to get everyone's buy-in (or agree-ence, as Fred Durst would say) on the standards. You'll need to look to the management for that - whatever that may be in an academic setting.

Friday, April 04, 2003

Issues like this are almost always an ego issue - but there are other considerations too.

But first, do these people generally get the job done, well (by the standards of the user's experience) and on time? Yeah, a lot of programmers have the personalities of reptiles. It goes with the territory. A people person would not last 3 hours in a coding job. If you want the job done, you *have* to hire people whose personalities suck. I get tired of programmers being bashed because we're not Dale Carnegie acolytes.

Secondly - let me turn your contention around. I am in a region where the average IT worker is kind of an undereducated dolt who doesn't grasp abstractions, and the local managements don't much respect competency and they certainly don't respect brains.  I've been in the position of being accused of writing code in EXACTLY  the 'overly complex' way that you describe, except that given the deliverable I was assigned it *appeared* to be the only way to do things. And curiously, everyone within 10 miles treated the task I was asked to do like a tar baby and as career punishment.  It was like - I was being criticized and critiqued for being "too ivory tower" by people who had no clue how to go about doing the same thing. I've had stupid wankers criticize my code who thought *subroutines* were excessive, for God's sake!! So, I'd need to know more about your background and your organization's standards in order to take a side in this. I generally don't respect back seat drivers since I've been trashed a lot with the same kind of so called intentions.

That leads into a third point. What may seem like "excessive" use of abstraction may be rather an appropriate way to gain generality in the finished code so that the wheel doesn't have to be reinvented later for similar applications. Someone with lesser experience may not see the opportunities to make the code more general and will rip their hair out at the "obfuscation".

In general - I sympathize but, not being there, I don't know if this is a real problem, or a mismatch of styles.

Bored Bystander
Friday, April 04, 2003

Bored - If you feel all coders must be antisocial, where do your software architects come from?
I'm not saying coders *can't* be antisocial, but a good software architect *must* understand both sides of the keyboard to develop a successful product.


Friday, April 04, 2003

Philo, I'm guessing that software architects happen to be programmers who learned to develop their socialibility over time, and therefore wanted to combine their technical skills with more interpersonal interaction.

Bored Bystander
Friday, April 04, 2003

Bored -

As opposed to genial people who developed their programming skills over time? As was covered in another thread, learning one thing neither destroys the skills one already has nor leaves one incapable of learning more.

Devil's Advocate
Friday, April 04, 2003

Incidentally, this would explain some of the crap software products - most people view "software architect" as a natural progression in seniority without realizing there are additional skills required beyond simply being a good coder...


Friday, April 04, 2003

This sounds frustrating. I've had to deal with it for almost twenty years, so I feel the pain...

From the point about not controlling who's on the team, I can say that if you don't hire and fire, you have limited accountability for their actions. Do your best, but realize that you need to invest only as much effort as is reasonable for someone with limited authority.

Also, code that meets objective acceptance tests, including performance, ought to be acceptable. I'm no fan of excessive abstraction: I believe in writing what's needed and no more.

But Coding Standards are supposed to enable and support the basic activity of developing code that works. If their code works, perhaps you shouldn't worry about a maintenance problem that may never arise.

This is the joy and the pain of managing by results: you have to let go of telling people how to do things and instead focus on what they accomplish.

The good news is that when you let go of telling them how to write code, you have more time and attention available to discuss what needs to be done, such as the usability fixes you've identified.

Good luck, and please post a follow up letting us know what does and doesn't work in your situation.

Reginald Braithwaite-Lee
Friday, April 04, 2003

I think the frustration has to do with developers residing in one of two camps:

Camp one:  Those who go home at night and think "how could I have done that in less code" "what would be a simpler approach" "will it be obvious what I'm doing in there" "what's the easiest way to satisfy the user and satisfy marketing?" "how can I make the product something I would want to use?"

Camp two:  Those who go home at night and think "wouldn't it be cool if we could use the XYZ API?" "maybe I should write an optimized hash table to sort those 8 entries" "4th normal form requires us to add 19 new tables to our database" "every operation should be wrapped with three deep of accessor classes, you know, in case we radically change the system" "man it's getting late and I want to watch my taped video of TechTV highlights, but I really need to go download some more Anime"

The single most frustrating thing in my job is dealing with that one person in camp two that can't look at a simple problem and see it for what it is.  EVERY conversation is "how can we complicate this?".

PLEASE, if anyone has suggestions on how to deal with this person, POST NOW.  I feel my project is being drained by having to endlessly fight the simple vs. obfuscated debate.

Bill Carlson
Friday, April 04, 2003

Bill, I know what you mean, but I've also had trouble dealing with people who have the mindset of "they haven't requested that feature NOW, why should we plan ahead at ALL?".  The fact is, requirements change, and while over designing something is bad, you shouldn't "just" build exactly what the current requirements dictate leaving *no* room for scale. 

Vincent Marquez
Friday, April 04, 2003

Bill -

Have you tried saying, "We can refactor that later as necessary"?

Devil's Advocate
Friday, April 04, 2003

I've tried to explain refactoring to my colleague.  What I can't seem to communicate is relative cost/benefit.  Personally, I view code as a liability.  Solving a given problem with less (or no!) code is always a win.

This isn't univerally shared.  Some of it comes from perfectionist tendencies inherant with some developers.  Yes, a stored procedure is almost always faster than an ad-hoc query.  But is it worth it to bind the parameters, change the DB script, etc., for a query that takes 5ms and is called once a day?

Camp one says no.  Camp two says yes, because "it's better, isn't it?".

The analogy I use is home construction.  People would be horrified if they knew the shoddy techniques used to build a typical house.  If you're morbidly curious, measure the supposed "right angles" with a T-Square.  Sure, you could build a house with perfect 90 degree angles.  It would cost a ton more to build and you wouldn't be able to charge a dime more.

Vincent's point is well taken.  There's a fine balance between "hardwire it to the extreme" and "in the name of expandability, lets complicate and generalize it to the point that only one person can ever understand it."

Much of "enterprise development" is repetitive and boring.  The engineer that gets his stuff done by 11am and surfs the net the rest of the day contributes and is worth more than someone who works until 8pm writing lots of code to do the same thing.

Love the solution; don't love the code.

Any more thoughts?

Bill Carlson
Friday, April 04, 2003

Bill Carlson - your camp 1 and camp 2 descriptions *perfectly* match what I've seen in this industry. Another hated generalization follows from this: most programmers tend to be excessive and most lack the common sense to modify their approach given compelling evidence to do so.

In my work I've tried to tread the middle ground btwn the "hardwired to one set of data" camp and the "let's write a 100K LOC api to read and write text files" types, and it's rarely appreciated as such. I get drooling incomprehension from the types that are probably snowed by the object model in Visual Basic, and I'm obliterated and slandered by the self-aggrandizing pseudo academician types who look down their noses at "mundane" problem solving. In my experience, one almost might as well puff their code up with a bunch of unnecessary crap because it will look more impressive to the geek chain of command... if you get down to business you'll be scrutinized as to why you're not overworked like everyone else. Cynical - who, me.

The "obstinate nerd" title of this thread set me off because it came off like the standard value judgement of someone without much skin in the game. Maybe that's wrong of me to assume that, and the lack of the ability of his co-workers to deal with end users points to some arrogance there. At any rate, I think this thread has been a great exploration of "NURD" psychology.  I hope the O.P. gets something out of it to deal with this "problem".

Bored Bystander
Friday, April 04, 2003

I think this is a management failure rather than a failure of the developer.

If his interfaces are poor --- and I stress the IF --- then change the architecture so the developer's work is accessed through an interface put together by someone else.

However I have a feeling you are not really describing the problem. If the developer is paying attention to code interfaces and architecture, I suspect he's probably quite good and the problem you describe is something else.

Must be a manager
Friday, April 04, 2003

Bored Bystander, thanks for agreeing with me and for providing sympathy.

I'm in a lead position and have some ability to direct other developers and set coding standards.  I'm a pretty "loose" manager.  Our developers are mostly middle age and can be trusted to get it right.  All but one person in our department is basically "lazy".  And I mean "lazy" in only the most positive light.  We accomplish a great deal, mostly agree on stuff and waste little time or energy.  We are a stable group and have only moderate need for structured process.

I expend quite a lot of effort butting horns with one person, though.  Anything the group comes up with, he has a new, better, more "advanced" way of doing.  His attitude is good; he's a self-improver.  I don't want to stomp on his ideas, but anything that triples the lines-of-code without improving the user-experience is usually a bad idea.  He's 3 years out of school and is somewhat of a "purist".

I don't have the direct authority to give him "the lecture".  Maybe I can communicate this to my boss.  However, my boss is decidedly non-technical (though she does a good job) and has trouble seeing this persons suggestions to improve reliability and performance for what they are - a big mess with microscopic gains.  He's willing to work long hours to achieve his goals.

What's a nice way to tell one's non-technical boss that a coworkers hard, dilligent work is really counterproductive to the success of the project?  I haven't figured this one out without appearing jealous or lazy.

Bill Carlson
Friday, April 04, 2003

This all seems a bunch of speculation to me since not enough information is presented to allow anyone to give relevant advise.


#1 what is your position and experience and what is the position and experience of the employee in question. And what is your relationship to him.

#2 please show an example of the overly-factored code in question that you find to be unacceptable quality.

#3 what exactly did the employee say word by word when he displayed this arrogant insubordination to you.

Without more information, this discussion is like the job interviewee who was asked how to approach creating a payroll system and he starts talking about languages and packages and libraries without first asking whether the payroll system will be for a pizza shop with six employees, for the US Navy with x hundred thousands of employees, or for an international conglomerate with employees recieving salary in multiple currencies and deductions made under scores of tax jurisdictions.

Dennis Atkins
Saturday, April 05, 2003

People who work together exert a normalizing force on each other.  Get people working together whenever possible.  Combine indivdual-sized tasks together and assign teams of two to four people to solve each larger problem.

If your developer does things differently than everyone else, don't panic yet.  Different doesn't always mean wrong.  Manage by results.

If they're not getting their stuff done because they're the overarchitecting type, move their deadlines up so they don't have time to be too-clever-by-half.

If they're the sort that rewrite standard library functions, it's because of inexperience.  Invite them to more code reviews so they can learn from other people's code.

If they're the kind that write sloppy, buggy code, pull them from developing new code and put them on bug-fixing and user-support detail.

If they tend to go into hiding for weeks in their offices, require weekly status reports from them.  Demand visible progress.

If you absolutely must give them "the Lecture", remember three things.  First, don't get angry and don't criticise them in front of other people; programmer egos are fragile.  Second, don't waste time assigning blame or arguing past history.  Third, be specific on how you expect their behaviour to change.

If they continue to produce unacceptable work despite your best efforts to help, do what it takes to get them out of your group.

Saturday, April 05, 2003

Bill, my advice in that situation would be to just go with the flow.

If he's getting the work at great cost to him, but that's what he wants to do, let him be and turn your attention to other stuff.

I think the only reasonable way to let your manager know the guy's approaches are resource-intensive is to be relatively cool about it.

Must be a manager
Saturday, April 05, 2003

Too much fuzz about nothing. I've been on the nerd-side and the manager-side, and usually these kind of problems are political. Do their code works? If the answer is yes, I can't find any reason to have a problem with it. If not only works, but works well, great.

There is a good advice: treat nerd-types as spoiled childs. Bribe them: create a task schedule with specifically one hour daily to "fix stuff". What needs to be fixed is up to them. You said they are good developers; let them loose. Use emotional traps on them, nerds are known for not know when they are being manipulated.

(Any grammatical/spelling error it's not mine.)

Saturday, April 05, 2003

Heh, this could so easily have been posted the other way around:

My "peers" don't understand the value of modularisation and abstraction. They have poor coding standards and refuse to change them. My code is efficient and bug-free and yet I have complaints because my "peers" are stuck in their obsolete habits.

What do I do?

It's a political problem, what do you do when a developer doesn't fit into your group culture? You don't enjoy it, and I bet he doesn't either. If it's a real pain, I'm sure he'll move on soon enough....

Saturday, April 05, 2003

Bill, if you're working on enterprise apps, it's probably not the best fit for your guy.  Young people are often better on research projects.  I just researched about Crays today, and noticed Cray liked designing with young people because they had less preconceptions and didn't know what was impossible.  Whereas you're more optimized.

To the original poster, writing good code is no sin, but refusing to change their UIs because users are stupid is.  You should ask them to explain why their UIs are so badly designed that they can't rework them to suit the users.  Though of course you'll need good arguments why your approach is correct; these programmers may be right.

Sunday, April 06, 2003

The trouble with-know-it-alls is that sometimes, they really do know it all. At my former "really big company" we could often find niche's for folks like this.  Let Reagan be Reagan.

Sunday, April 06, 2003

I sort of agree with Philo. Set fire to them.

Monday, April 07, 2003

*  Recent Topics

*  Fog Creek Home