Slashdot Mirror
Ask Slashdot: How To (or How NOT To) Train Your Job Replacement?
An anonymous reader writes "I am a contract developer from a major U.S. city. My rate has never been the lowest, but it's nonetheless very competitive considering the speed and quality of the work I have always delivered, as well as the positive feedback I've received from most clients. In the past ~3 years, I have been working on a sizable project for a major client. For the most part it has been a happy arrangement for both parties. However, for various reasons (including the still ailing economy), starting this year they hired a fresh college graduate in-house, and asked me to teach him all 'secrets' of my code, even though they have the source code by contract. The implicit (although never openly stated) goal is of course for him to take over the project and hopefully reduce cost, at least in the short-term. I say 'hopefully' because I am pretty sure that, because they are unfamiliar with the software industry, they underestimated what it takes to make quality, production-ready code. I am not afraid of losing this particular client, as I have many others, but I want to ask Slashdot: how do you handle this type of situation — training someone whom you know will eventually replace you at your job?"
Give him the source code. Have him go over it. If he has any specific questions, answer then succinctly and accurately. But keep in mind that as a contractor you have no obligation to share any of your coding "secrets" with anyone, or teach anyone else how to code. Don't let your ego and desire to brag about how clever your coding solutions are make you forget that you are under no obligation to train anyone to take your place (no matter how much junior may flatter you).
You've given them the deliverables, you've presumably fulfilled your contract. Nowhere in said contract does it say anything about training other coders, I presume. Be professional and polite (don't refuse to answer questions they have about the code, for example). But also be firm about the limitations of your contract (it doesn't include answering questions like "Hey, can you teach me how to do this neat trick like you did?" and "Can you teach me how to do good memory management?").
They will probably need you back when the newbie crashes and burns.
You are obligated to only fulfill the terms of your contract. Part of being a contractor is doing things however you want as long as you are not in violation of your terms.
I am always in-favor of being a trusted agent. This way you might get a lead on the next contract as someone who can be trusted.
If you actually are willing to take on the job, then I would suggest you let the new developer lead the training. See if the new person is self motivated and willing to learn. Guide the conversation where it needs to go, but make the new developer do the homework and show they got the prerequisites.
I only look human.
My mother is a halfling and my dad is an ogre, so that makes me an Ogreling
You are a contractor. Your employer is paying you to train your replacement. So train him well, depart on good terms, and have a good reference for your upcoming interviews. Or don't train him, and leave now. Your choice. Did I miss something?
My primary goal as a contractor is to "put myself out of a job". It can be scary to let go of an existing income stream, but no job is a guarantee. If I walk out of a site with a happy customer, they have an incentive to hire me back ... and I get to work on something new (to me), rather than being stuck maintaining the same code for years.
There are risks, but if your replacement flames out, they can always come back to you, later.
Chivalry is not dead, it's just frequently misspelt. - M. Langley
Like this: http://dilbert.com/strips/comic/2004-02-07/
Your reputation is worth more than your ego. Be kind, be polite, and helpful ... to a point. Make a 30/60/90 day 'grace period' to answer "hey, can you remind me..." questions. Do this via email so it's all documented - use the excuse of "this way, you have it for reference".
You don't need to bend over backwards for your 'replacement', but as a contractor, your reputation and network are paramount.
Simple: if training their staff to do software development was not part of your scope of work under prior contracts, then offer to negotiate a new contract with them that does include that service. This being a dramatically different kind of work, you may want to charge different (higher) rates for that service than for doing the actual software development.
First, is training included? If not, well, make it worth your while. Generally when I've done (much smaller) projects, I generally make sure that the contract I sign lays out that the payment is for the code, and specifically covered training regarding the operation/implementation of the project. Bringing a fresh person up to speed on the code that I provide is not part of the contract, but can be for the right amount of money.
Since I also work full-time at my "real" job, are you sure that this isn't just them wanting to bring the project in-house, more under their control? It might not be about the money, specifically, which means that this might open other opportunities with them on other projects, or even a full-time job with them (if you want it.) Looking at it from the point of view of my real job, there are times when I want ta project done by a contractor/temp, and there are times when I want it done/supported in house. It's usually more about the strategic vs. tactical value of the project than the pure "how much am I paying the guy" number. Make sure that you understand the motivation of the client, so you can better position your next move...
#include "standard_disclaimer.h"
So jack your rates up and do the best damn job you know how to do.
"Cursed is he who rises early in the morning..." Isiah 5:11
He will absorb what he/she can and then with the new found skills find a better job someplace else. You will be called back at which point you can raise your rate. Everybody wins!
On your personal relationship with the client.. do you go out for beer together, understand their situation, get why they are doing this? Or do you feel like you have given your all, only to be tossed aside? You might cooperate fully, or cancel your contract and offer to start a training one at higher rates. Depends..
Have you fscked your local propeller head today?
You're on a per-hour, right?
You're going to walk him through the code; answer questions; answer the phone; bill a minimum for each. This is just good consultant practice. After that, you're on a per-hour basis to fix what he can't. No problem there, because these are the conditions under which you formed the contract.
However, you might want to pitch the writing of some documentation so he has a roadmap to your code and a description of how each (major) function/routine works. That's more hours for you, and less helplessness for him; this is important because when you're on another contract, you really don't want to take a couple hours out to put out fires at a dead-end gig (for you).
You do it well. You've obviously already determined that they're planning on cutting costs by getting an in-house developer to take over, and I'm assuming you know that means they're not planning on keeping you on that particular project forever. So rather than doing a half-assed job and leaving the newly-minted dev with the codebase, a handshake, and "good luck!" do them a favor and help them learn everything they should know to do a great job. You really have nothing to lose by training the new guy well; you've got other clients lined up, if you do a good job this client may have you come back in the future (when the economy has more fully recovered) and do more work for them, and you'll have built another relationship with a developer who remember that you took the time to help them out.
God, schmod. I want my monkey man!
Your a contractor. You should have lots of business ahead of you if you try and be professional with each and every client. Teach these developers as well as you can and to the best of your ability. (Unless you dislike training others enough you don't even have a rate you'd be willing to charge...) The people you have done business with in the past will likely want to do business with you again if you are professional and priced correctly. This includes the developers you train. They may end up wanting to hire you when they are in another job later.
Don't be a jerk. Be honest with your customers, too. If the developers have limitations try and express what they will be able to do well without over selling them.
If you can't be replaced you can't be promoted. If you can't be replaced you can't move on to something better without hurting your client. If your hurt your client by your leaving you will be remembered in a bad way.
Done this a few times ... become the new guys best friend - be as helpful as you can and make sure he and your bosses know the effort you are putting in.
After you leave, keep is friendly contact with both .. when the new guys need some help (or the client needs another project) then the job is yours.
Final tip .. if you can keep access to the workplace. Lots of smaller companies can be fairly relaxed about this if your still talking to the bosses ...
I know this will be screamed down by the psychotic anti-corporates on this site, but teach him.
No CS grad can compete with an experienced developer in the short term. You teach them and they will see how far short they are of being able to replace you. Take it like they had given you anyone else to train without the implied potential replacement side.
I don't get this argument on this site in particular. We scream for open source, free information, anti-copyright but the second we are asked to pass on any information of our own the response is the equivalent of closing the source, giving no documentation, and threatening lawsuits.
Did my share of contracts, some lasting over 3 years and some only going for a couple of weeks and many things in between.
That's the point of being a contractor - nothing is permanent, you get a different treatment and you get paid as much as you can manage given the market, and no bullshit, like pensions and benefits and all that nonsense. You get to deal with your own taxes without anybody withholding your money from you, that's the beauty of it.
You can't handle the truth.
as a joke."
Solving Unix problems since 1989...
I have evolved into a full-time trainer, travel all over the place to collect airmiles for my next holiday.
Of course I'm hired to (help) teach smart cookies to become The Best in field, they are not competition, they are going to pay my ticket.
Because our management is not stoopid I'm also required to pick up the phone at unholy hours to support the new guys.
"The likes of Facebook and WhatsApp are free to those whose privacy is of zero value."
Billable hours are billable hours. You could always charge a different rate for training as opposed to coding. However, billable hours after they replace you are at tripple the normal rate.
... you should inform them that day rates for training are 2-3 times day rates for remote development, and start from there...
Nowhere in TFA does the submitter state that he is being compensated, let alone that he's happy with the agreement.
Is full of people who've never had a real job before... why?
As programmers it is our ethical duty to destroy our own job. We reuse open source code because it take less hours to reuse code than to reinvent it. We test our code, so there is less bugs, so we bill less hours to the client. We write good documentation so other people can understand our code when we leave. We use standards and design metaphors for the same reason. Training other people is the same concept. We do a good job so we can move on to other things. Things that are more interesting and worth our large paychecks.
It's a new contract for new services, I'd think there might be a new price/rate attached.
I wise programmer once told me... The person with the safest job in the world is the person who is always looking to do themselves out of a job. In other words... When you put the clients best interests at heart you are far more valuable to them than someone who holds onto things, hides things and makes it generally difficult because you want to protect your job. Perhaps they wouldn't be looking to replace you if you had actually gone to them with a proposal to hire a graduate to replace you. Companies tend to hold onto people that do that sort of thing and get rid of the ones that are in job protection mode. I have found this out several times now and am reaping the rewards because companies really value what you bring to them and offer to pay you significantly more. Now, every day I come to work the first thing I think of is, how can I do myself out of a job. How can we automate, make more efficient or reduce the costs of the activities I'm doing. Sometimes you get a look of shock when you submit a proposal that effectively eliminates your job. However, without fail I have been re-deployed to other, higher paying roles to do exactly the same thing over and over again.
Usually if a company hires someone cheap n' incompetent to replace you because you cost too much, you'll find future work in fixing what they break. If you were a dick about it an the company feels you tried to screw them, they'll look for someone else. However if you did what you were asked and did it well, they may hire you back.
Remember as a contractor you are not an employee, but you are always a future contract hire if they like your work.
Then, mentor the young pup. Treat him like your son or daughter. Teach him everything. You can't teach experience though, so you're ahead no matter what. During this time, evaluate the person's capabilities, including the capability to listen and learn. Think of this as having an intern on somebody else's dollar.
If it all goes south and you lose your customer, you might be able to pull him with you (assuming he's worthy).
THEN you're in a nice bargaining position.
Red
As a contractor I've been through this more than once, and actually had very good experiences training / mentoring customer employees to "take over" the programming of my projects. In one case I met weekly with a guy over many months, and took him from hand-holding up to completing major releases. I don't see it as a threat, because if you're already sharing the source code (which I always do), then you're explicitly offering that the customer can take over the job in the future. So -- assuming that mentoring is a service you want to offer -- do the best job you can, and have fun. And it is a tremendous amount of fun to teach when you are good at what you do, have some communication skills, and also have a beginner student with decent aptitude along with a serious attitude toward learning. I had all of those. /toot-own-horn
Good luck, hope it goes well for you!
We're people and we suck. The only thing that matters is what this employer can do for you when you finish working there.
Are they going to be an asset for networking or as a reference? Are they going to get you more work by recommending you? Are they going to be bringing you back for more work?
Your answers to these questions will dictate how much time you should spend supporting the new hire.
It's just business.
Less *is* more.
If they want you to train employees instead of just code, you should insist on a new contract and negotiate a much higher rate.
And as I understand from contractor friends, you bill for "time and materials" not finished code. If you quote a deliverable you better be a good estimator and good at documenting the requirements up front, etc... To eliminate the uncertainty you bill for time and materials, and at that point it doesn't matter if they have you writing code, writing a manual, teaching, or shoveling shit.
;-)
IMHO he's best to document and teach everything he can to make his customer happy. If you want job security through obscurity get a direct position at a big company and take on something complex that nobody wants to touch. Of course then they won't pay so much, so you'll want to be a contractor.
Your job as a contractor is customer satisfaction within the bounds of the law. I've had long projects that I've completed or come close to completing, and then been asked to instrument a hand-off to a junior member. I've been paid to mentor the junior member and been called in to solve problems that were over his/her head with him/her watching while I solved the problems, answering questions as they ask. In at least one situation, the handoff was to free me up for a new project the customer was just about to start. They wanted me off the mostly complete project so I could start the next. In one other situation, the junior that I mentored eventually left that company, went to a new job, and then recommended me for some contract work at his new company.
People aren't stupid, they know when you're being a dick; even if you're being professional about it.
I can't disagree more, as this poster put it - if you've done a good job on the software and a good job on the training, you'll have a happy client more likely to recommend you or consult with you in the future. You'll have a client that wants to call you for their next project, instead of being stuck calling you for support on their past projects. Don't look at it as the client trying to replace you with somebody cheaper - look at it as the client freeing up your time for more valuable and interesting tasks than maintaining an old project. Do the best you can, try to save that company money, and you'll be viewed as an asset to them and see greater long-term gains from them and others they recommend you to. Do a halfhearted job and you'll be viewed as a leech just hanging out for more money - they'll be anxious to get rid of you. You say it's been a happy relationship for both parties, don't ruin it for your ego.
For a group that fosters the FOSS movement, why would you all be opposed to getting *paid* to train somebody else to maintain your old software? Let it go and move on to bigger and better things!
+1 Disagree
If they are paying you your rate, WTF do you care if its teaching someone or coding? Do you honestly believe that your all that? Get over yourself, and do your job. Last job I quit, they called me for a year with questions. Simple shit, as long as it was less than an hour I didn't even charge them.
I don't agree that you should get legalistic about what is and isn't in your contract. If you're writing software, answering questions about it and helping others understand it is part of the basic standards and practices of the profession. If you're a contractor, training up internal resources to take over your project is totally ordinary.
They've been a client for years. Take good care of them. If they want to move the role full-time, in-house, that's a good growth step for them.
If you're the kind of contractor who's hostile to that, and looking for ways to resist and debating what's in your contract, or being unprofessional when it comes to transitioning your role, expect not to be welcomed back, and don't look for them to give a glowing reference.
If you act like a pro, and take good care of them, then you're helping your reputation and chances for future work.
Tired of Political Trolls? Opt Out!
You're a professional, so there's really only one way to approach it: professionally. As a contractor, there's always the possibility that your services will no longer be required anyway. Show them they're making the wrong choice by approaching it as you would any other work. No holding back any tricks, no keeping secrets, no letting the new guy flounder (much... he needs to get his wings). Answer as fully and thoroughly as you can when asked about anything. Your actions with this will be one of the last things this customer may see for some time. If at a future date they realize they need someone with your skills, you want them to remember that good impression you left them with, and not someone who spent the last few weeks/months in a snit acting like a child.
"The urge to save humanity is almost always a false front for the urge to rule." --H.L. Mencken
Think of it another way. You are not training your replacement. You are being promoted to team lead or architect. This might be a lesson in whether or not your code is easy to maintain, or easy to learn, and how well you can mentor junior programmers on your team.
"Worker bees can leave
Even drones can fly away
The Queen is their slave."
Currently you are retained by the client as a developer. Continue within that role as long as that is mutually agreeable.
You should also discuss the possibility of training your replacement. I would suggest a different billing rate for that.
You might get lucky, but here is my experience with this issue:
- You act nicely, and teach the noob the "secrets" of your code
- You go away, the noob didn't understand shit, he gets lost.
- He eventually will either screw up big time, or just fail to produce new deliverables
- He gets pushed, blames you (he'll either say your code sucks, or he'll say you are keeping "secrets", or in any other way trying to protect your job by preventing him from doing his.
You'll end up forced to tell the customer to STFU and GTFO, or you'll be doing work for free.
My recommendation:
If you have fully documented the code (both inside the code, and in a standalone documentation that explains everything from coding style to APIs), tell the customer everything any competent coder might need is in the docs, and remain available for any specific questions the coder might have, under a pre-arranged hourly rate.
If your product hasn't been fully documented, send them a quote for full documentation, and go back to the previous stage.
WTF am I doing replying to an AC at 5 A.M on a Friday night?
Teach him as you write documentation: Literally type notes with him watching. He will forget & probably quit before you get asked back, so you need proof that you did impart "secrets".
But don't be surprised at some negativity to you when it all goes South. Well-known places (for new devs under new managers) to find your typed-up training info will be key to positive referrals.
Science & open-source build trust from peer review. Learn systems you can trust.
Sounds like to perfect opportunity to be the BOFH vs the PFY. Enjoy! http://en.wikipedia.org/wiki/Bastard_Operator_From_Hell && ofcourse http://www.theregister.co.uk/data_centre/bofh/
As you said yourself, creating good code is not something one would expect a beginning-wage employee fresh out of college to create. At best, your replacement might be able to maintain the code already created.
So, basically, whatever you do isn't going to be sufficient if the employer needs major changes to the code. Therefore, I guess it depends on your relationship with the contractor. If you say "here's the source code, good luck" and leave, or if you break it down "this is where the majority of the work is done" and "when the program counter wraps, it picks this instruction off the drum at 000, and that's how it exits the loop" ...oops, wrong story... where was I? Oh, yeah, how much you tell him is up to you, as whatever you say won't make a whole lot of difference.
Parenthetically, isn't it interesting how companies think that years of experience and expertise can be somehow magically transferred to a noob in a few weeks. There seems to be no understanding that programming (or most kinds of engineering) done well, involves a way of thinking, strategies for attacking a problem, in some cases skills in squirreling out information and a knack for implementation, that bears no resemblance to a "collection of secrets".
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
The way you train a "replacement" is the same way you train any new employee on a software team.
Start by giving them small tasks. Let them work their way through your backlog of things you haven't gotten around to doing. Bugs are great candidates for new members of the team. Ease them into the code base. Do code reviews with them before check-ins.
Personally, I like to do some pair programming during the first couple of days to help them set up their development environment and familiarize themselves with how I've been working on the code.
Unless this is a trivial project, you're never going to be able to impart all of the knowledge you have about it. If they're worth anything (and you're worth anything) it won't be so complex that they can't figure out how to extend / maintain it. Your job is to give them a leg up and ease the learning curve.
Be open and honest and helpful. The reality is that this new guy is either able to replace you or isn't. If a novice is able to successfully replace you, maybe the project has matured beyond the need for a senior-level developer and it's time for you to move on.
If that's not the case, it will become abundantly clear in due time and they will treasure you all the more for having seen the difference your skills & experience provide.
I didn't think so. It's not in mine, either. Documenting is, though, so I'd let the newbie learn to read.
now we need to go OSS in diesel cars
Years ago a client decided to save money by hiring a recent college graduate. I helped them in every way that I could. About two months later they asked me to help write the support documentation for the firing.
I've been on the other side, too. I had a client early on (mid 90s) that was paying me $60/hour. They had, according to them, never paid anyone more than $7/hour before. They were explaining this to me as part of a conversation about how I was actually much much cheaper than any of the $7/hour guys because I could easily finish in a few hours a chore that would take those guys a week to do.
Anybody who thinks that a lower hourly rate means a lower cost is an idiot.
Do you have ESP?
I would have told them what my rate is for short term consulting on an availability basis. Like $300 hour if I'm not busy. Offer me more to make me not busy.
now we need to go OSS in diesel cars
You're a contractor. Make a new contract.
You're obviously not going to do this for free, so approach it like any of your other services for hire. Work out how much time they want to dedicate to it or just get the to agree to a suitably high hourly rate for your new services, which are now essentially tier 2 support. Be sure to include enough of a 'get out free' clause so that if the new guy rips the code/configuration/hardware to shreds, you're not obligated to clean up his mess. Then just rake it in.
You say you've got other contracts. You've got a good rapport with the company, presumably a good recommendation as well. Sounds like they're by choice or by necessity moving the project to a maintenance mode rather than active development. (I'm just assuming that because you say you believe they're bringing on a junior guy to replace, not supplement, you.) Again, I'm guessing, but you'd probably rather be doing something more active, so be nice and try to teach the new guy what you know about the project. Of course, you can't just to a full brain-dump, but do your best. Work out a mutually-beneficial support agreement when you do get released. Maybe, if you've enjoyed the work, things will turn around for the company, and they'll have more work for you. If not, at least you're spared the tedious and potentially draining task of going down on a sinking ship.
I am not a crackpot.
You train them on the system and the clients business (assume you should have good idea of that), if he is capable of learning such then all is fine and dandy and your job as contractor is done and done well.
If he not capable of learning to do the job due to basic lack of fundamentals/programming skills you inform the client of such and leave them to figure out what to do. You do not teach him to "program" under any circumstances as training in such from you would probably cost the client more than sending him back to school/hiring someone more qualified. If they have gone so "cheap" that they have hired someone totally unqualified that is the hiring managers problem, not yours.
"Hand over" is about handing over the the necessary knowledge/skills for that particular project to someone qualified, not about training someone in the basics of design/development
So, I'm also a high earning contractor whose wages are consistently 30% above market rates, and have been for as long as I can remember...I also have (paid for myself) obtained complementary teaching qualifications so I can offer exactly what you're describing as a "value add" service to my clients. I always have a new contract waiting for me at the end of the current one, I've never been unintentionally unemployed (I like to sit on the beach a lot), I'm regularly re-hired by the same clients that have used my services previously, and usually they bid against each other for my services, I don't work very hard (can't remember the last time I even said the word "overtime") and I make buckets of money...why?
Because I approach every single contract with the view that at any point I could get a better offer somewhere else and I don't want to burn the current bridge. Every single thing I do, be it code, or architecture, or business process modelling, or teaching/mentoring is highly documented, and at least one full time staff member has had a walk through to the point where, in a pinch, they could get by without me. And every single client appreciates my approach and recommends me wholeheartedly to their business buddies.
"Knowledge lockin" is a petty and small way to build a career...if you have to rely on it, eventually you will have no career (I have seen it over and over again...cushy contractor locks in his position through knowledge bargaining rather than services provided and sure, he gets 5, maybe 10 very stressful years out of it...then his career is toast)
And teaching is fun...remember, that kid you teach today is going to be the project manager signing your very hefty invoice tomorrow. Many of the "kids" I taught at one point are now in very senior executive positions...who do you think they recommend when the job has to be done right?
And finally, the ethical aspect. My art teacher once said to me "Everything you learn in life is taught to you by someone...to die without passing that knowledge on is stealing from humanity."
My advice, don't just teach that kid...teach the hell out of him...make it obvious that you're more than happy to do it. Understand that, once a contract is coming to an end, it's a natural and expected part of the development cycle for your client to want to fund the maintenance of the project in a more cost effective manner (and who the hell wants to get stuck doing maintenance anyway?). And go out of your way to make it as visible as possible that you understand that part of the development cycle and are enthusiastic to have done such a great job at design that maintenance can be handle by a graduate. And through all this, keep asking...referrals, referrals, referrals.
Likewise, and in many cases the new guy is right. Of course, in some cases the new guy doesn't know anything, but there are many bad coders out there earning craploads as contractors.
Don't burn any bridges,
Start by giving him tasks maintaining the software. Give him an overview of how things are organized, then give him a task that needs done and answer his questions as they come up. Someone maintaining code will have to know how to figure it out, so let him get started on that now while you're around to answer questions. Once he's done, critique the code with an eye towards how many hidden problems it may have and how well it fits with the system. If he's doing good work, give him progressively more complex tasks.
Once you've got a feel for how he's doing, good or bad, bring some of the management you work for in on the critiques. If he's doing well, this lets you highlight how well you teach your replacement which can lead to good references later. If he's not doing well, this lets you highlight the problems while you can still demonstrate directly that it's not because your software's poorly-designed or poorly-documented and it's not because you're not clearly explaining the system to him.
If you're taking any other approach, namely one that will force your client to remain attached to you I'd have to question your ethics, motive, and ability because what you're doing is creating a dependence on you that is borderline blackmail (if that's something you're doing).
Why is it that employees are supposed to work hard, be as professional as possible, take pride in their work, be ethical etc? All these virtuous practices are things that largely benefit the employer. It's effectively work ethic propaganda that has been drilled into the population.
In contrast employers work you as hard as possible for as little reward as possible (often including unpaid overtime which is effectively theft of your time) then dump you for a cheaper college graduate at the first opportunity. Employers do not adopt a strategy that benefits the employee as much as possible, they adopt a strategy that benefits them as much as possible. Why then shouldn't employees be just as ruthless, conniving and unethical as employers?
"Virtuous" work ethics have been drilled into successive populations over the aeons by those who directly benefit from them, i.e. the powerful. Don't fall for them.
You agreed to provide the code, and they decided to replace you -- the rational thing to do is recapture as much profit you were going to lose as you can.
Negotiate a new rate for the training; under the justification, that your marginal costs are going up -- conducting a training session to professional standards requires extra preparation (a few extra hours of preparation for every hour of training, and additional resources, and time+energy to answer followup questions).
So get a rate that is 2 to 3x the rate of an hour development work, per hour of training, plus a flat fee.
Then reach an agreement about duration of the agreement, followup support questions, and future development work -- required retainer, and hourly rate scaled up, when fewer hours of development work are performed.
You are a contractor. You either take the contract and teach their new hire how to work with and support your code to the best of your ability or you do not take the contract.
Charging whatever rate you do. The next time they call you, just multiply your hourly rate by the number of hours you've lost to this and quote that to them. Sounds like a win-win to me!
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Think about it this way. If you want your application to live on and not end up on the junk-heap of dead/deprecated apps, train someone to keep it alive. I can tell you, there is nothing more rewarding in our industry than knowing that code you wrote 5/10/15 years ago is still useful. Build your apps to last, train your successors with enthusiasm. Do all you can to help them be successful in supporting your app. Be a professional.
Maybe they are trying to free you up for a separate project, for instance? At my last job, we had a contractor who did the majority of our programming, as well as some networking/admin. Part of my tasks, as an employee of the company, was to learn some of the networking/admin tasks to free his time up up for additional programming and higher-level network design. It may not hurt to ask the client what their future intentions are, just in case.
I've always tried to take the professional and ethical approach to such things, thinking that it would help me to earn trust with the company and the industry, leading to good references and more jobs down the road. But instead it's mostly lead to me being used, abused, and routinely thrown under the bus.
So as much as I hate to say it, if they asked me to train my replacement, while acting completely professional, I would deliberately mislead them and feed bad information. So down the road when I leave and everything turns to shit, they will beg me to come back and fix the shit that they broke. Doing good work rarely garners appreciation anymore. The only way I've seen much appreciation is retroactively, when they realize what a mistake it was to lose me.
In Soviet Russia, dot slashes YOU!
I think its usually a bad idea to try and hoard your job by keeping secrets. In this situation, I usually try and do a good job in handing the project over. Admittedly if they are stealing my job - a job that I want to keep, I might not go "all out" in telling every secret, but neither do I hold back important details either. Best to do your best, in all likelyhood this graduate won't work out for them anyway, then at least you'll still smell good.
Good programmers work to replace themselves with small shell scripts.
The people in the comments on this shit article are the other type of programmers.
Do you want respect or a paycheck? Letting employers push you around and shuttle you out the door to keep them from paying you so much is their objective; it doesn't have to be your objective too. find other work and give notice.
Remember kids, if you're not paying for the service, YOU ARE THE PRODUCT THAT IS BEING SOLD.
If you have the time, why not train him? You say you have enough other customers for now, so you don't have to worry about the short term, and when the economy gets better, you did a good service to a customer and they'll think of you again.
Plus...
You learn training skills, which is quite marketable.
If your replacement is really good, he'll probably be a good addition to your network. He'll remember that you trained him, and he'll move on to other positions where he can recommend you. And when he moves on, the company will need you again as well.
If he's not good, make sure that people can see that you tried. Powerpoints, handouts, recommended books, hours spent pair programming, etc. They'll need you again, make sure they understand that you tried to help them.
Try one of those 'Jedi Mind Melds" before you go. Could save you a lot of time explaining things the old fashioned way. :-)
Less *is* more.
The keywords were "sizable project." So what you're really saying is that it's going to take him 9 months to just to understand the data structures / schema of this project, before he can began changing anything beyond string level. Typical example of excellent business level thinking: programmers are fungible trade workers, unskilled, and can easily be replaced. I'm guessing it's going to take 1.5 years before they can begin to move forward again, with the help of a few extra developers...
So...I'm guessing that they will begin to panic in several months, double up with a few extras to try and cover up their mistake, then either try and scrap the project, or do something equally stupid. Now, I could be wrong...they might be hiring a MENSA candidate right out of college, complete with the passion or salary that is required to keep someone like him around...but I'm thinking not; I've known a few people like that...but then, they went on to earn six-figures as their starting salaries right out of college...and you're saying this company is cutting back because of the economy...so probably not. This will be a good lesson for them. Can you name some of their competitors? I have a mild interest in investing in them, and shorting your company's stock, seeing as the new project will probably be a crash and burn in a year's time...randomly guessing the probability to be something like 70% likelihood here...
I say that as long as they are willing to pay you to train him, do so. It's not like he's getting a copy of your trade secrets, or your thinking processes, or even the books you've read...he hasn't attended the same college, doesn't think the same way, etc. Chances are, he will get a broad overview of what you've done, with some stringy reasons (because the company doesn't want to pay you to train him a minute longer than it has to) why you did what you did, which he may or may not write down, and which will be complete gibberish in 3 months time, save for a few obvious things, like "I did this because this didn't work." It's true, you want businesses where executives know how to perform cost analysis situations...but studies have also shown that businesses run purely by the accounting department tend to do poorly, especially where IT / Technology / programming is concerned. Because you're fighting with Archimedes over a pitcher of water...and whether he can cost justify it to twelve decimal places...
I mean, come on, anyone who has studied business / economics in general knows that the business community is sick in general as of late. Heavyweights that have survived cataclysmic downfalls, and gotten back up, are being taken out like chumps through homicidal mismanagement. So, if you're a business guy, and you know (because you took business classes, which 'make sense' to you) how to run things, because you were taught how to do this, or it's what you believe, or how you feel things should be done...and that's also how your friends are doing things....but they're dying off like they've contracted the Black Plague...are you going to keep doing what you've been doing? Stick your fingers in your ears, say that your friends just got unlucky, it happens...or are you going to ask yourself if someone slipped you the wrong info? That the reason you're struggling isn't because you don't have what it takes (a separate discussion), but because someone told you that it was a good idea to cut your sales staff right before your sales biggest day of the year, or that you'd make more money by taking out a big loan that through interest and savings, was supposed to make you more money, instead of giant losses?
I am John Hurt.
At least quadruple your hourly rate-- if not more. Your IP is yours. If they want it, make them pay. Otherwise-- you'll get nothing out of this, they'll exploit you, nothing more. That's all there is to it.
Look at it as a valuable opportunity. First you get paid to train him on-top of the ongoing development whilst he gets up to speed.
Then if he is no good (or you aren't a very good trainer) then you haven't lost anything and they will revert to using you for ongoing development.
Alternatively if he picks it up well, then you will have a good working relationship with a competent and trained professional who fully understands your preferred coding practices, and who you happen to know is still on a rock-bottom contract that he agreed when he had no experience or training. Simply higher him away and grow your consulting business.
Make sure you have a few 'working' lunches with the new guy AND someone reasonably technical from the client. The purpose of which is to discuss (not at a low level) and issues the new guy has in taking the reigns. This will help make you look more professional and helpful, as well as have a mitigated any damage from you being thrown under the bus after you're gone. Just make sure the client knows the code/app worked as intended/designed before you left, and the new guy claimed to understand it as well as had all his questions answered. If he crashes and burns after you leave then it's on him. You need someone from the client side to has reasonable technical ability, so that they understand the problem if the new guy is asking for you to teach him how to design/code. If the client doesn't understand that, you will definitely be the the fall guy.
I see many opinions here, but I think the one that stands out most is the concept of customer service. If you treat your customer right, even if that means eventually losing them, you will come out ahead in the future. Word of mouth is a strong marketing tactic, but can also bite you if you don't act properly. For instance, let's assume that you take what I consider the selfish route and decide to only do what the contract states and no more. Your customer will notice and in the future may not use you, but worse they may provide a negative comment to other potential customers. If instead you remain professional, courteous, and service oriented to what's best for your client, they'll be your best marketing department. Remember, companies are made up of people. What happens when a manager or exec from your current company leaves for a new company? The way you treat them will affect their thoughts and decisions about bringing you to a new client with them. As professional engineers and developers, we should always take the high road and act with the best interests of our customers/clients even when it seems as if we're being screwed. It will help you in the future and also keep you from getting ulcers :-).
I've 30 years in the software consulting business. Every once in a while, a client will ask me to 'clone' myself so that some college graduate could 'take over'. I tell the client 'cloning' doesn't work, but that if the college graduate has any specific questions, I'll answer them. And, at the same time, I give them two weeks notice. When the contract is done, it's done. Never overstay your welcome. The site/job environment will turn quickly hostile and you don't want to be there when it does. Many times, I'll get a callback from the client, saying they are stuck, and could I come back for a day to unstick the college graduate. I typically decline, as my business model makes its money from long term contracts. Ok, they say, how about two weeks? I say ok but give them a rate that's double as there's an opportunity cost associated with not being available when the next client calls.
You get paid by the hour, right? So make sure you charge for the hours you spend training.
Even if training is not your usual balliwick, I'd say in this instance it was good practice to take the job. You're ensuring a happy customer from a job you've already started. If you're concerned about ending up in an endless cycle of training, set a time limit from the outset if thats all you're doing for them.
The danger though is getting blamed for a poor outcome if your trainee breaks things. If you have concerns about the quality of any code written by the new guy, make sure you voice them politely and unemotionally, and in documentable form. If they continue to have him write code and you think that code is substandard, tell them why, and then asked to be released from the project because you can no longer control the quality of the outcome.
Hate em. I am a sysadmin not a developer, but I always do some light to heavy dev in support of my environment. In my experience if you are really that good you can let the ideas and knowledge flow. Only half of what you say will sink in and that's only if the listener has the conceptual framework to remember the facts in context.
If they hired the right guy (or gal), he may actually be able to keep up. This will be obvious when you are peppered with smart contextual questions. Rejoice! Everybody is different, but there is a good shot you have an ally for life. Build enough of these and everybody will call you first for the interesting stuff.
It does sound like you have a bigger problem. Sounds like your client does not realize what an open ended thing they are asking you to do. If they do, can't hurt to clarify. If they don't get it, ask them what they are willing to pay for. Look at the longevity of training one guy vs improving docs. Consider the training and intelligence of the individual. You may need to spend ALOT of time with him. Consider the medium. Email is more defensible and cheaper than phone help, which is cheaper than in person visists, which is cheaper than full time in person training. Offer some cheap email responses for a period of time. That helps you to keep track of how well or badly this fellow is doing. Also ask them how you proceed if you have difficulty communicating with him.
Once you and your client knows what they actually want from you it won't be uncomfortable, perhaps it will even be fun. You don't really know something until you teach it.
Novel theory: Modern Man evolved from psychopath
Your employer is offering a false choice: sell your talent and experience cheaply until you are deemed no longer needed, else be terminated for insubordination. This is being set up to fail, but you probably have more control over who "fails" than you think. I believe the operative phrase in the business world is still "be cooperative without being forthcoming."