Fog Creek Software
Discussion Board

Problem with colleague II

Since everyone was giving such good advice, I thought I'd post a problem that has been plaguing me for 7 mos.

An assistant was hired for me who thinks he is a programmer.  He has not taken any programming classes ever, he has never written any production code, he once "wrote" an Access app at home.  He is currently working through the "Faster/Smarter" series, "Beginning Programming".  I have no problem with helping newbies on their endeavor into the hell that is programming:)  However, he has no desire to be/understand what programming is, IMO.  He doesn't like problem solving, he won't/can't do thorough testing for me, etc.  I believe he likes the "idea" of being a programmer.  He's one of those who, if programming didn't pay well, he wouldn't do it. 

That being said, I find myself in discussions with him (we share an office) where he talks as if he were a veteran programmer.  For example:

Me: "The client wants a search added"
Him: "That shouldn't be too hard to implement"
Me Thinking: "How the HELL would he know how hard it would be to implement?"
Me: <sarcasm>"Ok, do you want to do it?"</sarcasm>
Him: "Sure"
Me Thinking: "Over my cold lifeless body!"

Him: ".NET is soooooooooo much better than Visual Studio.  They have improved so many things."
Me: "Oh, you used VS before?"
Him: "No but,.............more bs"

Boss: "A new client would like A,B,C functionality"
Him: "That should be no problem"
Me looking at my legs to make sure I haven't disappeard.

Those three conversations happend in ONE day.  It is getting to the point where management is calling him asking questions, which I answer and he gets back to them.  In addition, there is that annoying "We're programming buddies" feeling that is about to drive me insane! 

I've developed this project for 3 years by myself.  He's been here 7 mos.  Am I being petty? (I'm pretty sure I am).  How to I let this person subtly know that they are NOT a programmer, just as I am NOT a graphic designer, engineer, giraffe, whatever?

At the very least, thanks for letting me get this off my chest.

Friday, June 27, 2003

What exactly are the actual duties of this assistant?

Friday, June 27, 2003

He was hired literally to help "shiggins".  So his duties are very vague.  We work for a manufacturing company.  I'm supposed to give him stuff to do, like documentation, create this graphic for me, etc. 

Friday, June 27, 2003

So just be very diplomatic about it...  Ask him to write a little web application that does something useful and make it so it isn't a trivial project.  When he's knee deep in it, he'll ask for help and you can say "Not as easy as you thought it was eh? Remember that." 

Friday, June 27, 2003

Tell him to write a class for you that does this and that and give him a timeline that you think a new programmer could finish the work in. Also tell him that programming doesn't pay that well; if you want to make money be  lawyer.

Friday, June 27, 2003

Tell him next time somebody asks "him" (meaning you) to do something, tell him that he must pass the question along to you and not to give off-the-cuff responses like "that won't be too hard". You're his boss. Tell him what to do.

Friday, June 27, 2003

I thought high paying jobs for inexperienced people left w/ the Dot-coms.  Can you post a Part III where he gives job searching/interviewing tips?

Friday, June 27, 2003

It's all about who you know. 

Friday, June 27, 2003

It's interesting that a number of the suggestions here are very confrontational, along the lines of "Give him a hard task, and tell him \"I told you so\" when he can't do it".

Of course, he has to discover his skill level for himself: if you tell him he's incompetent (not that I'm saying he is, I can't really judge) he'll assume you're an ass. Not that I wouldn't, were I in his shoes... is there anyone here so gracious it'd be different?

Perhaps you need to talk to the person who hired him (it wasn't you, was it?). Tell them you're stuck having to find work for him, because what he does is unsatisfactory (it *is* unsatisfactory, isn't it? Or is he doing what you ask?).

Mike Swieton
Friday, June 27, 2003

You need to find a project for him that is:

  * long enough to keep him off your back and away from anything important
  * short enough to keep his interest
  * unimportant enough that the world will keep spinning if and when he fails at it.
  * important enough so that he doesn't catch on to your plot.

Shunting the morons off to do the unimportant work is a time-honored tradition.

Friday, June 27, 2003


>>Give him a hard task, and tell him \"I told you so\" when he can't do it".

I have no intention of doing this and I don't think that's what the posters are suggesting.  I think the point is to give him some "real" programming work so HE can see how he does and whether he really likes it.

Here's my only concern, that it would make the problem worse instead of better.  Because he was given an actual project, regardless of whether he fails or succeeds, it would add fuel to his "I'm a programmer" fire.

I can't talk to the person that hired him because they've been friends for years.  See, it's all about who you know.

I like the suggestions though - keep 'em coming:)

Friday, June 27, 2003

Are you supposed to be programming yourself?
Or are you supposed to manging programmers?

If you want a programmer, hire a _programmer_.

Definitely, don't give him answers for him to give to management.

Is he your "full time" assistant? Do you really need a full time assistant? Maybe, you could share him with some other people. That way, he might have less time for "programming?

Friday, June 27, 2003

"Regardless of whether he fails or succeeds, it would add fuel to his "I'm a programmer" fire" ...

Don't knock it.  If it weren't for this, someone of us would have never turned out to be decent programmers in the end ...

We were all in our larval stage once, right?

Friday, June 27, 2003

>We were all in our larval stage once, right?

Absolutely.  That's why I like your idea.  I mean if he does well we're all better off right?

Friday, June 27, 2003

>Are you supposed to be programming yourself?
>Or are you supposed to manging programmers?

I am supposed to be programming, not managing

>Is he your "full time" assistant? Do you really need a full time assistant? Maybe, you could share him with some other people. That way, he might have less time for "programming?

He is my "full time" assistant, which I don't need.  I do share him with other departments right now.  He was actually asked to do other work because my immediate boss saw him "playing programmer" knowing he is not one.  I need another 3-5 exp. developer.  I don't have time to "train" someone who has never developed before.  I have no say in the hiring.  I've been asking for another developer for 1 year.  This is what I got :(

Friday, June 27, 2003

It looks to me like this person simply doesn't know programming well enough to estimate programming tasks accurately.  Is that correct, shiggins?

Okay, so he needs to learn programming.  I say, give him a significant programming task.  While I think you shouldn't come back and say "I told you so," I do think he needs enough practical experience to have a better grip on what's difficult.

Also, why is he answering the customer about features?  Isn't he the junior developer?  If so, he has no authority to answer the customer about features in a meeting like that.  You need to tell him to stop.

What happened when he talked to the customer like that?  Did you step in?

Brent P. Newhall
Friday, June 27, 2003


Actually, it was my boss, not a customer.  I didn't say anything.  I was wondering if I should talk to my boss.  Just to see if there was a specific reason, I was not asked, even though I was sitting right there.  It could be something as innocent as my boss knowing how swamped I am.  In which case, it would have been up to my assistant to say "I'm not qualified to answer that."  What do you think?

Friday, June 27, 2003

Sounds like an estimating exercise is in order.  If assistant proposes an unreasonable schedule, ask him to break it down into pieces.  Either there are individual estimates which are off base, there are pieces missing, or he's found a new way of doing things that is worth learning.

That this exercise is conducted on the spot, with no time for advanced prep, in front of an audience, may help accelerate the learning process.  Especially if you have hard data on tap that challenges those assumptions.

Friday, June 27, 2003

This guy is just doing what most young graduates and other young employees do - trying to "be sociable," impress the boss and demonstrate a strong "work ethic."

He has not yet learnt the importance of saying: "I don't know," "No, that can't be done," or whatever.

You need to be very direct with him and tell him when he doesn't know something or when he's doing something that's foolish. This can be done in a non-criticising way.

You also need to be direct with the manager who hired him, and point out the current limits to his capability, and the effect of this on you. Perhaps you could identify some role thing that would be more apprpriate for him.

Friday, June 27, 2003

Write the estimate yourself. When people see longer times and a smaller scope they will ask why. You will tell them.

You can do this without criticising or putting anyone down, you will simply let him dig his own hole. He can't refute your estimates, because he has no basis.

Give him simple tasks and tell him how to do them. Check his code, tell him what's wrong and make him correct it.

If he's smart he will start asking you for advice, he will learn and you will get a useful assistant. If he's not smart he will dig himself a huge hole and you will have no choice but to imform your boss.

Basically, you give the guy two choices, a good one and a bad one. Most people like the good choices. You should be able to do this without being harsh or nasty.

Finally, next time someone asks him a question that they should be asking you, simply interrupt. If that's not possible, correct him straight away, or say "Actually we need more information before we can give a proper estimate. I wouldn't want to mislead you."

Pete J
Friday, June 27, 2003

The true problem here is that you are threatened by your assistant.

Maybe the new guy could do it, even though he's only got 7mths experience.
I highly doubt it, but you're not sure about it and it's making you edgy.

Just because you think it's easy doesn't mean it is.

Not an idiot
Saturday, June 28, 2003

There are two alternate situations that I've seen in various workplaces:

-People give grossly bloated estimations that hint that either they're padding for months of Tetris playing, or they can't hack it and are building their own perpetual ignorance in. Furthermore, if anyone estimates a smaller number, or calls them on their estimate, they proclaim that it's their vast experience and Gandalf-like wisdom that leads them to their estimations, and anything less must be naive and misinformed. I've personally been in several situations where I've questioned estimates, and then provided my own (to be met by the poo-poos of "oh, that's just naive crazy talk!"), and then I take on the project and come in under time, under budget, and with all of the features, functionality and quality expected (and I don't work overtime as a general rule, though my output far exceeds most coworkers who work tremendous overtime. I've come to believe that overtime is largely a ruse to deflect blame for gross incompetence when deadlines come and go..."Oh, but I worked so much overtime ineffectively getting nothing done"). i.e. The lesson here is that simply sitting back, scratching your beard and proclaiming that it's all going to take forever doesn't make you a master. I should not that when I question overestimations I only do so with the approach that I'll do it if necessary, if they truly don't believe my estimates.

-On the exact flip side, I've seen young bucks who grossly underestimate the scale or scope of a project: Hierarchical data warehouse for a enterprise with a vast range of implementation requirements and details -- No problem! That should take a week at most! Of course these statements are made in a situation where they themselves will never have to implement, so basically their comments do nothing but to undercut the entire project: If you work 24 hours/7 days a week and pull some genius inventions out of your ear, you still haven't met the grand standard set by the "no problem" person. I suspect this is the problem that shiggins is having. I find this thread hilarious because an individual who did exactly what shiggins is describing (providing his opinion about the trivial, easy nature of everything) first name started with s, and last name was higgins.... Weird, no?

Jimmy Chonga
Saturday, June 28, 2003

I dealt with something similar to this once... actually, now that I think about it, more than once.  When I was working for a largish law firm, there were some people in the word processing department who wanted "database analyst" as their title because they Knew Access (capitalization intentional).  To their credit, they'd gone about as far as it's possible to go in Access while using only macros... ;>

What worked quite well, actually, was just offering some very basic direction.  They wanted to know how to accomplish some task or another, so I told them (at a relatively high level) how I'd do it, showed them what F1 did in a code module (this was 97, when the online help was actually still helpful), mentioned that the Recordset object was what they wanted to play with, and told them to poke around with it and call me when they had something for me to review.  Never heard back from 'em.

I'm always happy to help newbies get into programming (heck, in many ways, I'm still one myself, having only been doing it for five years), and would have been happy to play mentor, but it wasn't going to happen for them -- and this was a relatively gentle way of letting them discover that for themselves.

So I suppose I'm seconding the suggestion to stick him with a real programming project (real is in actually writing code, not real as in work product anyone will ever see), but with the difference that you allow him the possibility to succeed, and actually give him a hand when you have time.

If he's remotely clueful in other ways, you might email him a carefully-selected entry from the Jargon File... in fact, 'larval stage' might actually be appropriate.  ;>  But that's definitely a judgment call.

Sam Livingston-Gray
Sunday, June 29, 2003

Some observations, which may or may not apply..

I find myself guilty of sometimes "flipping the bozo switch" on someone, where after a few times where this person makes a mistake, I begin to discount everything he/she has to say.. while with the examples you cite, it certainly seems like he doesnt know what he's talking about, sometimes, he might just have a newbie/different/unique perspective on something that you can use... in short: listen to the guy, even if you're absolutely sure he's spouting bull.. sometimes its easy to get annoyed with a "techie god" who doesnt want to listen.. (been on both sides of this one)

Instead of dropping this guy off at the deep end, which is what some people seem to be advocating, I would suggest a slightly different approach. This would only work if you have time, though..  Walk him through the high level design, the architecture and finally the pseudocode/algorithm levels of a particular feature.. If he said feature A can be done, he might have just meant can be done in 3 weeks instead of what your boss meant (can be done today).. remember, he's been in the company for less time than you, so you may know your bosses' shorthand, he may not.  (been here too)

Walk him through the design of a feature, and then once you're sure he's going to do the feature the way you want it done (his estimate might have been for something less than the requirement), leave him to it, and make sure he accurately records how long it takes.. rinse, repeat.. if he's a good programmer, or a natural, then he'll deliver on time and everyone will be happy.. if not, he'll have more respect for your point of view, which means he's out of your hair, at least in the short term... (yep, experience talking here as well)

deja vu
Monday, June 30, 2003

Well, shiggins, if you say "do you want to do it?"
and he says "sure", where does the "over
my dead body" come from?

Most normal people would say, "ok, go do it."
That way, either he learns the task, or
realizes he isn't cut out for it, or amazes
you and your bosses by doing a wonderful
job (is that what you are afraid of?)

I mean, it looks like you haven't given him any
chance to prove himself (despite his clear willingness
to take tasks on,) and you have all kind of
rationalizations of why not.

How do you tell if someone is a programmer
or not, without giving them actual tasks?
By the cut of his clothes?

Tuesday, July 1, 2003

*  Recent Topics

*  Fog Creek Home