Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?

(OT) Motivating the Unmotivated Programmer

by Ovid (Cardinal)
on Jan 16, 2002 at 00:05 UTC ( #139013=perlmeditation: print w/replies, xml ) Need Help??

I was talking to a friend of mine last night who posed an interesting question. He works in a Perl shop and one of the programmers is a "jack of all trades, master of none". He can do basic administration of Linux and Windows boxes. He can rebuild boxes. His Perl is mediocre, at best. I was shown some of the code and was just horrified by some of it. No data validation, plenty of duplicate code, and bugs galore.

I asked the obvious question "why is this person still employed?" As it turns out, he's a really, really nice guy who is also the only in-house programmer who knows one of their largest systems. If he's hit by a bus, they're in trouble. He was constantly moving buggy code into production and the only way my friend managed to get a handle on the problem was by really getting on this programmer's case about rigorously testing his code.

Since this person has a large, albeit limited, skill set, and since this person is well-liked at the company (though everyone is apparently aware of his limitations), my friend feels that it's worth the effort to find a way to motivate this person to do better. He's looking for carrots, not sticks.

Does anyone have any suggestions for motivating someone who justs wants to do his eight hours? (to be fair, this programmer is willing to work overtime whenever necessary) The programmer means well, but the only reason he has a job is his business knowledge and he doesn't appear motivated to really get better.


Join the Perlmonks Setiathome Group or just click on the the link and check out our stats.

  • Comment on (OT) Motivating the Unmotivated Programmer

Replies are listed 'Best First'.
Re: (OT) Motivating the Unmotivated Programmer
by mstone (Deacon) on Jan 16, 2002 at 03:35 UTC

    First, run, don't walk, to the nearest bookstore and find a copy of The Deadline -- A Novel About Project Management by Tom DeMarco. It's the single most useful book on software development I've ever read, and a fun little adventure story to boot. DeMarco is a well known writer and analyst, and I can't begin to praise him highly enough.

    Second, I've always found that one simple rule of thumb works very well: "when you see something you like, applaud like hell." People will crawl through barbed wire for positive feedback, but in most business settings, you bust ass and hear, "oh.. okay. Here's your next assignment." And often as not, you get a list of "things that could be improved."

    By and large, techs are especially eager to please. We crawl around in the dark places of technology trying to make something neat happen, and when the neatness does happen, we want a pat on the head, dammit. I hold it as a point of faith that a plate of home-made chocolate chip cookies will get you access to just about anything not actually secured for life-safety reasons.

    Break the requirements down into simple "do X" language, then haul out the chocolate chip cookies when somebody does X. And remember that statements like "validate your data" may mean something to you, but they're meaningless noise to someone who lacks a definition for that term. Programmers don't usually code significantly worse than they can, so recognize that you're probably dealing with a lack of knowledge, and find ways to teach this guy new ideas.

      ++ Excellent! ++

      I can't tell you how much flack I got (for other stuff) at work, and next to nada in the way of chocolate chip cookies. I was good at my stuff and eveybody knew it, but nobody ever said it in a way that meant anything.

      And as for "data validation"/ frame of reference also too true. Not everyone who can code is a CS major; nor do they feel the need to bone up on the relevant theoretical material ;-).

      perl -pe "s/\b;([st])/'\1/mg"

Re: (OT) Motivating the Unmotivated Programmer
by chromatic (Archbishop) on Jan 16, 2002 at 02:30 UTC
    Whenever I write an article exhorting people to do things the right way (or at least my way :), I like to appeal to their sense of pride. That usually doesn't work, so my next shot is laziness and a desire for entertainment. That's why this testing article spends so much time describing messy maintenance programming. It's only fun to really sick people.

    There's one carrot already -- if you develop the habit of testing, it's much easier to maintain and to continue to develop your software.

    Of course, a bigger demotivator is fear. Some people are afraid of change. Some people are afraid of learning new things. Some people are afraid of trying things on their own and need to have someone say, "It's okay to write a small test program to see exactly what happens." Some people are afraid of things they don't understand, and spend their time reimplementing something instead of reading its man page. (Fear can be a positive motivator too, but I advise against it.)

    If the fear is "I don't understand testing", then a good and simple explanation (of good and acceptably simple tools) will help. If the fear is "I don't have time for testing", the proper response is "You don't have time not to test". If the fear is, "I'll be replacable", then hit him with a bus. (A toy one.)

    That's a little more flippant than I intended, but the best way to approach this is cultural (peer pressure) and from a business value standpoint. If the manager can understand hidden and direct maintenance costs, there's a stick. (A good manager may be able to find a carrot there too.) If there's peer pressure to improve things, there's a carrot too.

    If all that fails, get successively larger toy buses until he gets the point.

Re: (OT) Motivating the Unmotivated Programmer
by dws (Chancellor) on Jan 16, 2002 at 00:27 UTC
    Does anyone have any suggestions for motivating someone who justs wants to do his eight hours?

    This sound more like a management problem.

    Some people just aren't motivated by the intrinsic nature of their work. These people need clearly-stated objectives and constraints. It sounds like one of the requirements that management needs to lay on this guy is "though shalt test", and then follow that up with period reminders (or dings, or praise). There needs to be a feedback loop that has visible consequences for actions.

    There can be a lot of benefit to an organization to having a person around who is friendly, knows their way around some big system, and can be trusted to do an acceptable job in a number of non-mission-critical areas. But their management needs to be clear on where the boundaries around their scope should be.

    One way to motivate management is to put things in dollar terms. "Cleaning up after this guy is taking X% of my time. That translates to Y$. The consequences of my not doing this are Z."

Re: (OT) Motivating the Unmotivated Programmer
by redsquirrel (Hermit) on Jan 16, 2002 at 03:06 UTC
    I recently read The Psychology of Computer Programming by Gerald Weinberg. It was an awesome book and provides some incredible insights into the mind of the programmer and successful programming teams.

    Regarding the irreplaceable programmer, this is a Bad Thing for everyone involved. It keeps the programmer stagnant, mucking around in the same old code-bog. It keeps management fearful of losing the programmer, taking away some of thier motivational options. As Weinberg suggests, when a programmer becomes irreplaceable, it's time to replace him.

    The company may lose some productivity in the short term, but in the long term it will be better for all involved if they let him go. The company will have learned from its mistake and will always keep more than one programmer trained on the system. When the programmer finds new employment, he will be faced with a new system to learn and hopefully this will bring about a new wave of motivation to increase his knowledge.

    The fact that he's well liked makes the firing more emotionally difficult, but a good manager should be able to put those emotions aside and make the right decision for the company.


Re: (OT) Motivating the Unmotivated Programmer
by VSarkiss (Monsignor) on Jan 16, 2002 at 03:09 UTC

    The root of the problem is that your definition of "better" and his are very far apart. As far as he's concerned, he's at the top of his game: he's got job security and he does what he likes. What's to improve? He doesn't really care that his programs are messy and hard to maintain: he'll go in and fix it when it's necessary, right? Unless he really doesn't like spending time fixing bugs, he'll see no reason to change his style. (He lacks laziness, impatience, and hubris. ;-)

    If you are going to try the carrot, find out what kind of carrots he likes. If he's turned on by tinkering, give him a box of his own to develop new ideas on ("Say Joe, what about this Zope thing? Bring it up and see if it's any good.") But make it absolutely clear that any and all production problems take precedence. That way he has a reason to write robust code.

    Sadly, I've been in this situation a few times, and the only good solution I've found that worked was to bring in another person to train on the old system. That at least reduced my risk exposure, and allowed me to move the person into a position of less responsibility. (Although it sounds like you've got the additional problem in that he's an FOB: friend of boss. ;-) But it doesn't sound like that's an option for you.

    I don't envy you. It's a tough problem.

      He does not lack laziness, he just choses to put off til tomorrow what can be done today. That is a form of laziness, just not the form I assume you were referring to which is "an ounce of prevention beats a pound of cure" ;-).

      perl -pe "s/\b;([st])/'\1/mg"

Re: (OT) Motivating the Unmotivated Programmer
by perrin (Chancellor) on Jan 16, 2002 at 02:28 UTC
    There's a lot of info on this in the classic book "PeopleWare." The bottom line is that you respectfully tell this person what you want him to do, give him lots of support as he learns how to do it (including removing obstacles that the company may be putting in his way), and be appreciative when he succeeds.
Re: (OT) Motivating the Unmotivated Programmer
by little (Curate) on Jan 16, 2002 at 14:57 UTC
    "jack of all trades, master of none".
    That statement seems to me a key to the whole issue.
    Well, in my last company I started as responsible for maintaining a website, but as the management noticed some other skills I have, only if at a poor level, I got lots and lots of other tasks to solve as well. So what happend, was that my time, which was planned to be used to maintain a huge and fully through dynamic website, was shortened and the part left was filled with other tasks.
    Well, so I became also a jack of all trades but master of none.
    If one would ask me, I don't prefer nor like it to be that way.
    One ends up with plenty of different things to know and to learn, so the one and only way is to get as much knowledge you need to keep the system, so in my case the website, the intranet, including all clients, server, router up and running and to offer support to users. Sounds a bit different from what I've been hired for, right?
    And all I wanted, and truly wanted, was to get time to extend my knowledge in all the fields I was acting.
    So, to end that monolog, if one would have wanted to motivate me and make me happy, would have been: enroll "jack of all trades but master of none" to courses that help him to improve his skills
    In this way one
    • gets time to learn
    • can learn quicker than in a self study
    • will learn with choosable focus, eg. maintaining network security utilizing perl
    • etc.

    And I truly believe, that if an employer sends me to a course, spending money and time on improving my skills that is alike a gratification to me but helps me to take the time I need to learn, whereas normally I would fear to spend my working time with learning, even if needed, but that issue "learn and keep up with the tsate of art" in your working time might put your job at risk, because of all the important things that have to be done.
    Have a nice day
    All decision is left to your taste
      I have observed that training-as-incentive works very well. PerlMonks here probably tend to be self-motivated to improve their skills on their own time. Programmers who have chosen a different work-life balance can be greatly motivated by formal training on company time. Excellent training opportunities can be purchased from major database vendors and O'Reilly.

      You can tell that some people respond to training because they often refer to things they experienced during the training. In some cases they are referring to information, and at other times they are really talking about the prestige they feel from being enabled to participate in the training.

      Training can be anything from a genuine learing opportunity to the equivalent of a sales-quota rewards ceremony in Hawaii. TheDamian once remarked at an O'Reilly conference that his real purpose there was to warp our minds and stretch it into new positions. He's very good at it!

      Probably the ultimate training incentive for a perl programmer would be a single-occupancy ticket to a Perl Whirl.

      It's probably not a coincidence that all these courses are expensive. YAPC might be cheaper, and I'm still looking forward to filling out my first YAPC travel expense report!

      It should work perfectly the first time! - toma

Re: (OT) Motivating the Unmotivated Programmer
by Rich36 (Chaplain) on Jan 16, 2002 at 04:32 UTC

    Apart from motivation, one of the issues this brings up is quality control. Setting standards for production code forces the programmer to work within those boundaries. Make the release of the software conditional on meeting a set of criteria about the quality of the software and how the software is released. This not only benefits the programmer who's having problems, but the entire group.

    In working in release management, I've found that when you give developers a specific set of instructions regarding a process, explain why the steps are important, and make their production releases contingent on meeting certain criteria, quality goes up. This is something that you have to have management behind you for, and something that the developers have to understand fully. In a working situation, I think it's far easier to change behaviors than attitude. If you can show the quality process as a positive thing and beneficial to them and the company, their attitude about the tasks will become more positive.

    There's more than one way to screw it up...

Re: (OT) Motivating the Unmotivated Programmer
by derby (Abbot) on Jan 16, 2002 at 17:27 UTC

    In two words - code reviews. Heck, they can help everyone. Other devs benefit by having him in a code review because that forces him to share the knowledge about the "largest system" and he would, hopefully, benefit by having his code reviewed. I've heard plenty of arguments against not having code reviews but they're all really shallow in the long run.


Re: (OT) Motivating the Unmotivated Programmer
by coreolyn (Parson) on Jan 16, 2002 at 17:16 UTC

    Sounds to me you need both carrot and stick. What he needs is a project that his clearly his in the eyes of his peers, has tangible objectives, and a deadline that is tight. The probability of success should be low (The first time around). At that point you should have his attention and it should be fairly obvious to him and the employer where his skills most need improvement and courses should be offered to him to improve those areas.

    Upon completion, rinse and repeat as necessary. Any nice guy that isn't motiviated by that cycle of opportunity and challenge, deters from the success of a team, and needs some unemployment therapy in order to get his priorities straight.

      I'd go for this as well, but would like to add: "make him need to work with his collegues to accomplish the project". As in this way "code review" is naturally supported by all team members, and it will show clearly the need to stick to coding conventions, modularization and open ones eyes for security issues as the other programmers don't want anyone to plug security holes in the code to which they provided secure scripts/ modules to.

      Have a nice day
      All decision is left to your taste
      I fully agree with coreolyn. After what i read in Ovid's description this guy needs the stick to get going but if he's going then put the stick away and the carrots out...
      I know the situation very well from myself (i have to admit, that i tend to be the same type of lazy programmer). As long as I'm not under pressure / dead line I tend to put things up till I have to absolutely do them now.

      My tips for you are:

      • Keep him focused! - Don't let him put up things. When it's out of sight he'll forget about them
      • Give him interesting problems to solve - If he's like me he will surely take the bait. So give him a problem that absolutely requires something his code lacks of (e.g. data validation)
      • Give him feedback - Either good or bad it doesn't matter cause nothing is duler than work for which you won't get a feedback
      Hope this helps you a bit

      "May you live in Interesting Times"
      -- Terry Pratchett, "Reaper Man"

Re: (OT) Motivating the Unmotivated Programmer
by hsmyers (Canon) on Jan 16, 2002 at 18:39 UTC
    I'm not sure this is advice for 'motivation', but I would suggest before any other suggestion, that someone take the time to make sure that all of the assumptions everyone else seems to have are correct. In short, someone needs to actually talk to this guy and point out the problems at hand. It may actually be the case that he is blissfully un-aware of the side effects he is leaving in his wake. The 'Assumption Game' is one of the things that always comes to play in management situations like this, how not, it's human nature. For whatever reason, most solutions are predicated on assumption. That the assumptions may be correct doesn't make the method any less poorly researched! Since the situation is second hand for you and third hand for the rest of us, you should get back to your source and at least eliminate this problem from the mix before going further.


    "Never try to teach a pig to sing…it wastes your time and it annoys the pig."
Re: (OT) Motivating the Unmotivated Programmer
by cerberus (Acolyte) on Jan 16, 2002 at 21:53 UTC

    I can somewhat relate to this programmers position. Being familiar with all (most) of the systems at my place of employment, I find myself constantly being asked "help me with this one thing". Email, file layouts, network issues, anti virus updates, even WebShots for crying out loud. This "one" thing adds up in a day and it takes away from my true position, creating software using PERL. I find myself breaking a cardinal rule of software engineering, not planning out the program in detail before I start to code because I am now in a pinch for time (I must say that PERL lends itself quite well to quick fixes). I am unable to focus on one project at a time and produce a high quality script because everyone has an emergency. I find myself going back and recoding my work on my own time to save from having headaches in the future. My advice would be to let the poor guy focus on one project at a time with clearly outlined parameters and expectations. If he likes programming, and it sounds like he does, he will hone his coding skills quickly. And as mentioned in the other informational posts here, a pat on the head, back, butt (if thats your thing) can go a LONG way in encouragement.

Re: (OT) Motivating the Unmotivated Programmer
by zuqif (Hermit) on Jan 16, 2002 at 16:53 UTC
    Hey - isn't there an easy and obvious answer here, fellow monks!?
    Get the guy onto the best perl resource out there!
    I knows its done wonders for my attitudes! (:
    the 'qif;
Re: (OT) Motivating the Unmotivated Programmer
by gwhite (Friar) on Jan 16, 2002 at 20:07 UTC

    Along with the fine suggestions already made, I have found putting the person with poor skills in an area responsible for giving an in-house seminar on that topic can really motivate them to become knowledgeable. That doesn't always equate to application.


Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: perlmeditation [id://139013]
Approved by root
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others rifling through the Monastery: (5)
As of 2018-07-23 10:05 GMT
Find Nodes?
    Voting Booth?
    It has been suggested to rename Perl 6 in order to boost its marketing potential. Which name would you prefer?

    Results (462 votes). Check out past polls.