Fog Creek Software
Discussion Board




should I begin the process of firing her?

Ive just spent 3 hours rewriting some c++ code previously created by an employee....<g> Im trying to decide how serious/stupid their mistake was (maybe Im just tired and grumpy)

So for the last day and a half they have been chasing a subtle bug that only occurs in particular circumstances (ok, nothing new there...).  I was talking to them about it at lunch today and it seems that this class has certain state variables which are set as certain events take place.  The bug apparently had something to do with these state variables getting out of sync with the actual status of the class.
...funny how state variables _always_ do that.

So she spent yesterday replicating the problem and getting a handle on it so she could tidy things up.  This morning she had apparently found the problem and was putting some code in place to fix it.  At around lunch time I checked in to see how she was going and she was getting frustrated, we had a quickie chat about it and I mentioned my general dislike/suspicion of state variables (again) and vaguely suggested that she might want to take another look at her design.

A couple of hours later I checked back in and she nearly had it nailed....then a while later...and a while later, then she knocked off and I decided to take a look at what she was doing.

So it turns out that there are actual OS calls available that return the actual state of the thing she is dealing with.
...Ive started a branch where Ive whipped through, removed all the relevant state vars and replaced them with actual OS calls, she _did_ have getters/setters so its been pretty quick..biggest part was reading up on the domain and bringing myself up to speed and trying to avoid stupid mistakes.

So 3 hours later its completed and the tests she had setup show that this particular bug is definitely finished in this branch.
Now, I dont yet know whether Ive broken something else, and frankly Im too tired to care anymore tonight.
However tomorrow Im going to tell her what Ive done and get her to go through the rest of the tests and finish off what Ive started.

It feels to me however that Ive just about had enough, shes smart, quick, capable and cheerful with a good grasp of REALbasic and a much weaker grasp of c++, she also reached the level she is at now pretty *amn quick IMO
.  But its been 14 _months_ now and she appears to have stalled at this level.

So, thoughts?  how obvious was the fix?  how quickly should she have come to it?  should I have been more patient?  more clear about telling her what to do at lunch?  my preference is to give as little direction as possible, allowing people to find their own way forward, but this means Im always at least a little responsible if they take a long time getting there....

FullNameRequired
Wednesday, August 13, 2003

FullNameRequired,

She had unit tests and had used getter setters.  Good practice.  It seems her only mistake was to not look into OS calls properly.  You must have made a similar mistake yourself sometime.

I know your annoyed at all that spam and telemarketing, but give the poor girl a break.

Ged Byrne
Wednesday, August 13, 2003

In my experience, decent C++ programmers are very hard to find.

John K.
Wednesday, August 13, 2003

I often ask my self how long I should continue giving subtle and not-so-subtle hints about how to approach a problem that co-workers are having trouble with. And when it is time to say:
DO IT LIKE THIS AND NOT LIKE THAT! WHY? BECAUSE I SAY SO!
Especially if the quality of the overall result is my responsibility. You don't want to do everything yourself. You do want to give others room to think up their own solutions (I'm not excluding the possibility that they might do better than I would have ;) ) But when it's my ass on the line when it comes to meeting deadlines and requirements, it's hard to call when to step in.

Geert-Jan Thomas
Wednesday, August 13, 2003

Do a debrief with her and get her to verbalize how she came to her decisions and more importantly why she locked herself into them once they were in place.  It takes time, but if you give her good leading questions that get her to think things through, she will learn something valuable that you can capitalize on next time around.  Plus you won't look like an impatient crabass.

anon
Wednesday, August 13, 2003

Yes.  Please fire her and send me her contact info.  We are always looking for people that are "smart, quick, capable and cheerful". 

You however, should consider getting out of management or taking some classes or _something_.  If this incident has you this worked up, you're headed for a heart attack.


Wednesday, August 13, 2003

The last thing you should do is get worked up over it and give her a verbal beating. When you argue that her side is wrong, so her ego takes a blow, she's much, much more likely to defend her stance and disapprove of yours - regardless of who's right or wrong.

Mickey Petersen
Wednesday, August 13, 2003

Problems with state variables?  I've programmed lots of multithreaded state machines.  Used the GOF State pattern quite a bit.  Haven't had any problems.  At least none that weren't easily solvable.

I hate to say this because it sounds harsh and I don't like being a d*ck, but maybe the problem is with the mentor instead of the mentee?  Maybe you have a lot of years of experience, but not that broad of experience? 

She sounds like a typical inexperienced C++ programmer, to me.  It takes a while to get a good grasp of everything, especially if you're throwing in learning OS calls (never programmed in basic, maybe she already know the OS, couldn't quite tell from your post). 

It'd be a little immature to fire her at this point, unless there's a lot else you haven't told us.


Wednesday, August 13, 2003

sorry.  premature, not immature


Wednesday, August 13, 2003

I'm with everyone else - this thread should be "should my boss begin the process of firing me?"
(I've got a project manager that wants to fire one of our more dedicated programmers because she made a mistake anyone can make...)

Debrief her. Explain to her what you did, how you approached the problem, etc etc.

Watch her reactions. If she's appreciative and happy to have learned something, you have a definite keeper. If she gets moody and defensive, *then* you might have an issue (but only if the defensiveness becomes a pattern - recognize that you're both pretty edgy right now; heisenbugs can be real morale killers)

Take it easy. And if you're the project manager, take your team out to lunch Friday. Just because. :-)

Philo

Philo
Wednesday, August 13, 2003

"In my experience, decent C++ programmers are very hard to find."

Been there, done that. That's the best reason I know of to stop using C++: it's simply too complex for most developers.

Brad Wilson (dotnetguy.techieswithcats.com)
Wednesday, August 13, 2003

Seems her only mistake was that she did not notice the existence of an API call. It happens. Hey, I am writing code at this very moment that I know will be superceded by build-in platform functionality in a few months (but I need it now :-( ).
I feel either there is a lott more to this than you are letting on. If not, it might be best for you to review why exactly you were (are) getting so worked up about this, even to the point of considering termination.

Just me (Sir to you)
Wednesday, August 13, 2003

Let's see here.  This person is "smart, quick, capable and cheerful" and also "reached the level she is at now pretty *amn quick ".  You aren't giving us much rationale for firing her except she has "stalled at this level".  Sounds like if she were a slow learner and had just reached her current level you wouldn't be considering firing her.

There may well be more to the problem than you presented to us.  If this is just one of a series of problems, then there might be a stronger argument for getting rid of her.  There are hordes of unemployed C++ programmers out there ready to take her place.

But I don't think I would do to well in your work environment myself.  I tend to learn in stages.  That is, learn up to a certain level and get stuck there for a while until I get enough experience to advance to another level.

mackinac
Wednesday, August 13, 2003

I'll vote with everyone else -- do not fire her.

The Real PC
Wednesday, August 13, 2003


She did a mistake that I assume everybody has done in some point of their career: violating the golden rule "don't fall in love with your idea." In this case, she fell in love with her current implementation.

My 0.5 cents: Don't fire her. Tell her what you did, be polite, let her to decide to use your approach. Be persuasive.

Leonardo Herrera
Wednesday, August 13, 2003

So let me get this straight -- you knew how to help her do something, didn't want to tell her so she could figure it out on her own, then got impatient and did it for her anyway, and now you wonder if you should fire her for it?  You know, I just read something like that on the Onion...

"Avid Fisherman Forever Ruins Fishing For Son
MANKATO, MN—Thanks to his nitpicking, impatience, and insistence on absolute silence in the boat, avid angler Don Gillespie, 41, forever ruined fishing for his 10-year-old son Douglas Tuesday. "No, no, no— you're casting all wrong," said a visibly seething Gillespie after Douglas' line landed a mere three feet from the stern of the rowboat. "Forget it! Just let me do it, and I'll hand you the rod afterward." Douglas was further put off fishing when his father threw back the only fish the boy caught all day because it was not big enough."

And as for the "stalled at this level" comment, people reach plateaus.  They learn a lot of stuff, then spend some time letting it soak in (or out, if it was useless) before they're ready to go bite off another chunk.  See also http://www.joelonsoftware.com/articles/fog0000000356.html

Sam Livingston-Gray
Wednesday, August 13, 2003

Maybe she deliberately didn't use your approach because a canadian company, which holds the 'use api call to track state' patent, will ask you for $10,000.

How many times will you make the same mistake :)

Ged Byrne
Wednesday, August 13, 2003

The question to ask yourself is - "Is this a recurring pattern?" Everyone introduces bugs and make bad judgements now and then. Sometimes, it's hard to take a step back an reevaluate the design, especially if you're spending long hours trying to fix a subtle bug.

On the other hand, if you have to deal with this over and over AND have tried to get the person to improve, then I would consider firing and re-assigning her.

igor
Wednesday, August 13, 2003

I think you should fire her and outsource your development needs to India.

Henry Ford II
Wednesday, August 13, 2003

I mean no disrespect but you should start by firing yourself. I manager’s job is to use the available resources to get the project done on time. If you are the only one who knows to solve the problem, just solve it and move on. You have many other problems waiting for you. Also did it ever occur to you that at some point you might find a programmer who is better than you? Should he/she fire you?

19th floor
Wednesday, August 13, 2003

Maybe he's just tired and grumpy.

Johnny Bravo
Wednesday, August 13, 2003

"my preference is to give as little direction as possible, allowing people to find their own way forward, but this means Im always at least a little responsible if they take a long time getting there...."

This tells me that you already know the answer to your question.  Relax, then reflect on the possibility that your managerial style may work well with some folks and not others, and may not be suitable for someone who's still relatively new to the field.

If not you, does your employee have a mentor who's willing to give more help and direction?

Hardware Guy
Wednesday, August 13, 2003

You kinda came off like drama queen. Show her your solution, explain why you choose that path, and move on. Don't expect her to drop to her knees and kiss your feet in a show of respect for your vast knowledge. She might be a little embarassed and frustrated she could not solve it herself.  There is nothing worse then your moron boss solving your problem in a fraction of the time you could "not" solve it.

Lou
Wednesday, August 13, 2003

You don't how much training you've given her.  Buy her some books.  Send her to a C++ class.  Do code reviews.  Teach her yourself.  Give her a copy of "Thinking in C++" and tell her you expect to know it cold in 18 months.

If she doesn't improve, *then* fire her.  You don't say how long she's been doing C++, but it took me about 1.5 years before I wasn't dangerous, about another year to actually "get" OO, and another three years to get halfway good at it.

Grumpy Old-Timer
Wednesday, August 13, 2003

"my preference is to give as little direction as possible, allowing people to find their own way forward, but this means Im always at least a little responsible if they take a long time getting there...."


as her manager you are *completey* responsible, for the work she does and in the time frame it is done in...

let me guess, your a new manager who has to micro-manage everything....not uncommon to those who are still gathering managerial skills 

OR

before you became a manager you and her "had a thing" which didn't work out, now you're her manager and the easiest way to deal is to set her up for failure....

apw
Wednesday, August 13, 2003

Insufficient data.

Either there is a lot of other stuff you haven't told us about her performance, or theres a lot of stuff about you that makes you very lucky she hasn't walked out to another job yet.

Not enough here to say if anyone should be fired, let alone which one of you it should be.

Robert Moir
Wednesday, August 13, 2003

I don't see any reason why she should be fired.

She had a boneheaded bug that took a few days longer to fix than it should have.  Happens to everyone.

You're mad because she took three hours of your time?  Feel lucky.  Most industrial-strength idiots churn out code that takes *months* for others to rewrite.

The last thing you want to do is ostracize her for making a mistake.  If you do, she'll likely try to hide the NEXT problem that she has a hard time fixing.

Alyosha`
Wednesday, August 13, 2003

A few things:

1) In general, this person sounds competent and motivated. You've said so. "Sitting" on someone with constant checkpoints is generally demeaning and distracting to most people. I personally stop trying or thinking when someone is browbeating me and stopped by every 5 minutes to see if I'm doing work they approve of. If that treatment continues, I usually convey a message like: "FINE, take the job and shove it up your @$$ if you know so *** d*mn better." Point is, there are far better ways to educate someone on the job.

2) Is her thought process freezing up because she is being micromanaged so much?  (per 1).

3) On the issue of using an external and previously defined means to keep track of the object state vs. rolling her own: it *may* be that there is something about the object state that is not reflected completely in the system call results. And she may not be very good at describing what the overall context is, esp. when she's being confronted skeptically all the time. The situation may be too adversarial for her to tell you.

4) Assuming you're right, the best lesson for most people in this kind of situation is to "eat their own dog food", at times suggest that they are overcomplicating the problem, and evaulate them after the fact on the result of their work, which is really what is important. Most developers who aren't idiots catch on when they are personally responsible for buggy code that never works quite right and they have to pull a few all nighters to bandage something that was "supposed" to be really simple...

These are things I haven't seen mentioned yet. I agree that firing someone with the personality, work ethic  and characteristics cited is the height of idiocy.

Bored Bystander
Wednesday, August 13, 2003

It's hard when you have got a bug and your boss is waiting impatient and excited. It's the worst scenario to solve the damned thing.

Ross
Wednesday, August 13, 2003

FullName, to be honest, you sound like the problem. You've given someone a task, then she comes in next day and finds you've done it for her and now want to make her look stupid.

The biggest problem in this industry is incompetent management.

Must be a manager
Wednesday, August 13, 2003

Occasionally I make a bad decision.

I know it's hard to believe, but it's true.

However, I sleep like a baby at night, safe in the knowledge that should I ever do so, I will be immediately fired.

dude
Wednesday, August 13, 2003

Hi,

<g> so the vote is for me being a grumpy old fart then?...

A couple of things I didn't mention last night.
First is im the owner/boss myself.
its a pretty small company (me and 3 others at the moment) so a day and a half of a programmer not moving forward, while acceptable occasionally because it _does_ happen, is worth avoiding and actually makes a surprisingly obvious hole in my finances.
Im a self taught programmer, 4 years since I went from "not used a computer since teenager hood" to today, I worked for another company for 1 1/2 years as a programmer while I was learning (nepotism, i was related to the owner there) and then moved cities (wife was offered a good job somewhere else) and decided it would be more interesting to run my own business than to work for someone else.
That business is now doing pretty well, theres no such thing as venture capital in new zealand so its based on working hard and delivering the goods to our clients.

Im _not_ a particularly good boss, I make a better peer.  I prefer working with people who know what they are doing, and jump on other peoples ideas if they are good and ignore them if they are not.

<g> Ive _had_ to hire programmers who are smarter, more experienced and better qualified than myself because for a long time thats been all that has been out there.
I hired this programmer 14 months ago, she was a neophyte but had lots of the good qualities I mentioned.
At first I was rapt with her progress and didn't mind explaining stuff as she went, over the last 2-3 months or  so Ive felt as though Im _still_ spending a lot of time dealing with her issues when Id rather be dealing with my own.

Someone posted something stating that they questioned my managing expertise and experience in teaching people, and they were of course absolutely correct. 
I have _no idea_ what to expect from people, ever since Ive been a programmer Ive been almost entirely been dealing with people who knew more than me.  I _did_ pick up programming pretty quick, the question now is how long would it _normally_ take?  if she is good enough to be a programmer, when should I begin being able to treat her the same way as I do the other two?  (ie, ignore her and assume shes doing things right)
After I first hired the other two I would check on them from time to time, just browsing their code after hours when they were at home...in 90% of cases I had no problems and in the other 10% I was happy to just let it go (and raise a vague conversation a few days later on that general topic so I could see what the idea behind it was).
She _does_ have a mathematical/programming degree, but has no experience other than that.

so....how long does it take for someone with a uni programmers degree to become useful in a programming shop? 

FullNameRequired
Wednesday, August 13, 2003

Sounds like you're looking for any excuse to fire her. She turned you down huh?

whats the real story?
Wednesday, August 13, 2003

"so....how long does it take for someone with a uni programmers degree to become useful in a programming shop?"

What type of programming shop are we talking about?

If we are talking about a programming position that is purely heads down coding -- the time frame typically depends on:

* The technologies and programming languages being used
* The type of applications/systems being developed
* How motivated the programmer is
* The talent level of fellow co-workers
* The manager's definition of "being useful"
* At least a dozen other things that I didn't mentioned here

One Programmer's Opinion
Wednesday, August 13, 2003

FullNameRequired -

It sounds like you're at least admitting that you could be part of the problem, which is good.

But I reiterate: you may be causing this person to screw up more by breathing down her neck.

Yeah, yeah, you want to get the full value out of her time. You see dollars running down the drain. Etc. But don't you realize that this is probably a classic case of inducing the problem by worrying over it?

If you're this concerned about short term results, then my impression is that you may not be able to afford the calibre of person you desire, and you don't have the right attitude to be an employer anyway. Money pressure will do that, which is why I say you may not be able to afford a permanent employee. Your treatment of the person would be appropriate for a contractor, but definitely not for a permanent employee.

My impression is that you would have served your business better by doing all high end development work yourself and delegating administrative functions instead.

Is there anything else this person can do that is of value to you that you feel confident she can do satisfactorily?

>> so....how long does it take for someone with a uni programmers degree to become useful in a programming shop? 

We both know that it varies tremendously, from instant comprehension to months and months of learning curve to... never.

Bored Bystander
Wednesday, August 13, 2003

"Sounds like you're looking for any excuse to fire her. "

LOL...actually no, if I was looking for _any_ excuse to fire her she would already be gone.  Oddly enough Im kind of looking for reasons _not_ to fire her.

"She turned you down huh?"

:) Im sure she would.

FullNameRequired
Wednesday, August 13, 2003

FullName: it's my impression she's useful already.  If, on balance, you make more money with her than without her, then by all means keep her.  If not, let her go.  It's not necessarily her fault; it's just a simple business decision.  Sometimes it's just not worth it hiring more employees.

There's nothing wrong with checking up on people's code (and having them check up on yours).  It spreads the knowledge around.  If you have an issue, most times a simple "I saw you did this; did you consider doing it this other way?" should suffice.  You should never force the issue: a good idea always sells itself.

Alyosha`
Wednesday, August 13, 2003

"What type of programming shop are we talking about? "

in her case c++ and REALbasic, shes not bad @ the REALbasic stuff, but pretty weak on the c++

FullNameRequired
Wednesday, August 13, 2003

"you may be causing this person to screw up more by breathing down her neck. "

that is an interesting point.  <g> the flipside to that is whether or not  I really want to be hiring someone who is actually scared of me...

"you may not be able to afford the calibre of person you desire, "

hrrm...I mostly can, certainly my other 2 employees are more than good enough.  But then they have the experience etc.


"and you don't have the right attitude to be an employer anyway"

_that_ is the truth.  Turns out all I really want to do is write code, running a business is something I just dont enjoy.
Managing people is something I _do_ enjoy, but Im finding I dont have the patience to manage people who actually _need_ managing, <g> Im much better at managing people who already know what they have to do and how to do it.

"My impression is that you would have served your business better by doing all high end development work yourself and delegating administrative functions instead."

now _thats_ an interesting idea.  oddly enough I had never even considered taking this approach, but I will certainly do so now.
I _would_ enjoy just being a coder again.

"Is there anything else this person can do that is of value to you that you feel confident she can do satisfactorily? "

As I said, her REALbasic isn't bad, her grasp on the design elements there is a little better and shes collected a fair bit of knowledge about the language.
She is _good_ at writing quotes for work, I used to do them all but now I only do them for the other two, she writes her own, and emails them to me for a final polish and then I fire them off.
The last 3 shes done have needed no extra work. (which _is_ pretty impressive, the other two more competent programmers cannot write a decent quote to save their lives.)  this means she got the pricing about right, the estimated time about right (IMO at least) and the phrasing etc of the quote about right.

"We both know that it varies tremendously, from instant comprehension to months and months of learning curve to... never."

<sigh>  you are correct of course.

FullNameRequired
Wednesday, August 13, 2003

Ok, well, good, you're able to critique yourself and take in evaluation reasonably objectively.

It sounds like you're well beyond solo entrepreneur status being that you have (at least) three technical employees. And you've admitted that you hate management and you're not too fond of other business activities.

So, consider utilizing this person as a marketing, sales, customer contact resource. She's plenty technical *enough* to contribute at the level you'd likely need in that capacity.

Bored Bystander
Wednesday, August 13, 2003

Almost forgot:

>> "you may be causing this person to screw up more by breathing down her neck. "

>> that is an interesting point.  <g> the flipside to that is whether or not  I really want to be hiring someone who is actually scared of me...

Doesn't matter. Constant inspection of this type of work is distracting. I don't fear anyone looking over my shoulder, but it is pretty annoying and I don't do my best...

Bored Bystander
Wednesday, August 13, 2003

  Is anyone else doing REALBasic code at your company ?  If so, isn't it possible to assign all or most of the RB coding for her, leaving the C++ coding for the other two?

  Everybody has strenghts and weakness.  You should take advantage off your employees strenghts, by assigning them the right tasks.

  Off course, it may not be possible.  Maybe the RB coding does not require a full developer.  But even though, you could try to assing her the "easy" part of the C++ coding, especially that part that bother the most experienced ones.

  With time, she'll get better at C++ coding, and will be able to take more challenging tasks (I hope).

Ricardo Antunes da Costa
Wednesday, August 13, 2003

Holy mother of god!

"She is _good_ at writing quotes for work, I used to do them all but now I only do them for the other two, she writes her own, and emails them to me for a final polish and then I fire them off.
The last 3 shes done have needed no extra work. (which _is_ pretty impressive, the other two more competent programmers cannot write a decent quote to save their lives.)  this means she got the pricing about right, the estimated time about right (IMO at least) and the phrasing etc of the quote about right."

You *do* realize that companies pay six figures for people that *only* do this? And you've got someone who does this on the side, but also writes code?

Do you have room for her to pick up this work for the other devs? Maybe she'd be a better fit working more admin/organizational tasks?

IMHO, a really good organization has people that are happy in different roles. Mind you - this is only a suggestion if it's something she *wants* to do. It doesn't work if she's forced into it.

Philo

Philo
Wednesday, August 13, 2003

Code reviews are the right way to approach this problem. It is the single most effective way to improve code quality. If done routniely it's also the best way to check programmer's egos and mentor junior staff.

"Turns out all I really want to do is write code, running a business is something I just dont enjoy." - That's actually a much bigger problem than you realize. You might get away with it for a while as a three person company, but you probably won't for much longer, and you definitely won't if the business gets any bigger.

My advice is to stop whatver you are doing right now and go buy a copy of Steve McConnell's "Rapid Development". It will give you a really solid foundation for approaching a whole raft fo software devleopment management issues and help you balance tech responsibilities and business responsibilities. Buy copies for the whole company while you're at it.

I agree with the consensus here that it sounds like you've got a gem of an employee in that woman. Everyone is ignorant. A good team builds an awareness of people's limitations and provides a safety net accordingly. Face it, in the real world, if you ask someone to do 10 largish things, they'll probably botch one or two and not have time for one or two. If you stretch or pressure them those numbers of poor outcomes are going to go up. Too often the standard is perfection and/or heroics.

Lastly, what you are trying to do - write good software, build a team, run a business - is really, really hard. Don't make the difficulties personal. Ever. (The only exception is outright maliciousness.)

Jim S.
Wednesday, August 13, 2003

Dude,

Start grooming her to take care of more of the business end of things.  Sounds like she's a natural, plus she knows software to boot.  That way you can concentrate on making great code.  I know what you're going through.  It's hard to take care of all the business crap while trying to write code.  Does she grok marketing? 

Man.
Wednesday, August 13, 2003

I agree with the suggestion to shift the work around to play to this employee's strengths. In particular, have her do all the Basic programming and write all the quotes. You might also want to team her up with one or both of the experienced programmers. Maybe have her maintain their code or repair defects in their code. Or, maybe have one of them act as her mentor.

I have been managing software engineers and project managers for over 15 years. Some new college graduates *are* intiminated by their boss, especially if the boss is technical. That's ok -- they'll eventually learn that no one has *all* the answers. I like to team new college grads up with an experienced peer rather than with a manager. The peer is a colleague who has more skill than the college grad. (The boss is sometimes too much like teacher/parent).

I recommend McConnell's "Software Project Survival Guide" for new project managers. It is more of a cookbook for running a software project. I would guess that the newbie project manager, if they followed that book like a bible, would be more successful than most other newbie project managers using any other method. Rapid Development is more in depth, about 3x as long, and isn't really a "cookbook".

Elaine
Wednesday, August 13, 2003

My experience (coming from university into a software company) is that it took me approximately 1.5 years to get really comfortable in what I was doing (and of course I'm still learning, every day).

I consider myself a fairly bright individual and I certainly did well enough in school, but there's just a lot of C++/programming/development/funciton on a team _stuff_ to learn. 14 months and still needing some amount of hand holding doesn't seem to off to me, but perhaps my experience is atypical.

Steven C.
Wednesday, August 13, 2003

"should I begin the process of firing her?"

It depends on how good looking she is.

Clutch Cargo
Wednesday, August 13, 2003

If she's been there for 14 months, and you've given her no indication that her work is in any way unsatisfactory, I would imagine that NZ Employment Contracts Act will not make it easy to fire her unless you proceed strictly by the book, and have very good grounds to contest any complaint for unfair dismissal. She must have a written contract, anyway. Does it specifically mention competence in C++ as being required for the job? In any case, shouldn't you at least discuss your concerns with her first? Maybe there's some way she could improve her C++ skills, perhaps by studying in her own time if you pay for books or training materials?

ajs
Wednesday, August 13, 2003

How long does it take to become a fully proficient programmer?

This is what Joel has to say:
"Becoming proficient, really proficient, in just one programming world takes years. Sure, lots of bright teenagers learn Delphi one week and Python the next week and Perl the next week and think they are proficient. Yet they don't have the foggiest clue how much they're missing.

I've been working with ASP and VBScript since it first came out. VBScript is the dinkiest language on earth and ASP programming consists of learning about 5 classes, only two of which you use very often. And only now do I finally feel like I know the best way to architect an ASP/VBScript application. I finally think I know where the best place to put database access code is, the best way to use ADO to get recordsets, the best way to separate HTML and code, etc. And I finally use regexps instead of one-off string manipulation functions. Only last week, I learned how to get COM objects out of memory so you can recompile them (without restarting the whole web server)."

Ged Byrne
Thursday, August 14, 2003

http://www.joelonsoftware.com/articles/LordPalmerston.html

Ged Byrne
Thursday, August 14, 2003

You have a person there that knows your customer base, can write her own fixed price proposals, do the job and make a profit. If on top of that she can lay on the "girl power", fire her and you might as well pack in your business.

Just me (Sir to you)
Thursday, August 14, 2003

"Im _not_ a particularly good boss, I make a better peer. "

You own the company you will never make a good peer again.
You have to make the hard choices.

Play to her strengths. Lot of good advice above.

lou
Thursday, August 14, 2003

""Im _not_ a particularly good boss, I make a better peer. "

You own the company you will never make a good peer again. You have to make the hard choices."


exactly....
once you cross that bridge, it is very difficult to maintain a peer-like relationship with those you now manage....

I suggest reading this book "Herding Cats: A Primer for Programmers Who Lead Programmers"... and maybe start looking for someone to lead the business, if you don't like the managment thing....ala Bill Gates

apw
Thursday, August 14, 2003

Getting back to the original post...

You are probably wrong and do not have a full understanding of the issues.

If she could fire you, should she?

Realist
Thursday, August 14, 2003

Did this have such a tight deadline that you could not have suggested that she apply the approach you "required" (i.e. using the API) rather than doing it yourself?

Note that it's possible that your other two guys might leave for other opportunities. How would that leave you.

I'm of the opinion that everybody's code should be reviewed.

It seems that there is something "there" that would be worth developing.

This might also be an opportunity for _you_ to learn how to improve management skills.

njkayaker
Thursday, August 14, 2003

*  Recent Topics

*  Fog Creek Home