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?").
Put your training rate at +25% over your normal hourly rate.
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.
Size up your replacement and drag out the releasing of information, especially vital bits.
Put a pile of books in front of him and let him start with the basics to slow him down and wear his resistance, after all they just left college and their books, now to have to face more books again. LOL
This way they always have to turn to you, perhaps the kid will screw up and they will have to replace him.
Get to start the whole game all over again. LOL
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"
Give that college boy a IT / coding skills test the last thing you want is come guy who is all theory does not take you work mess up and you take the fall.
Don't forget to jack your rate up WHEN the N00B crashes and burns.
If he's genuinely good enough to cope, not an issue.
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!
and you're getting paid to train a monkey. What's the problem?
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...
We all rely on those who came before us. As Einstein said: “If I have seen further than others, it is by standing upon the shoulders of giants.”
If you indeed have other clients, money is not a factor so I suggest you have a moral obligation to pass on your hard won knowledge and insights to a younger generation.
How are the next generation of programmers supposed to learn anything if all the older generation do is ensure job security?
Those of you unwilling to impart your knowledge, wisdom and love for programming upon the coming generation; you should be ashamed of yourselves.
Look for another job. You don't want to leave them in a lurch to the point where it generates ill-will, because your reputation is at stake; they're sending a signal that they want to get rid of you. Do your best to make it an amicable split; but by all means make it a split.
Nowhere in TFA does the submitter state that he is being compensated, let alone that he's happy with the agreement.
I've been in the industry more than 17 years. I am annoyed when people try to make them selves important or indispensable by "holding onto the beans".
Contractors are whores... I do not mean this as a slight - as I prostitute my knowledge and tech experience as well (contractor). Your being paid, provide good service.
I'm with Rebill. Try to put yourself out of a job. Do fantastic work. Our industry changes fast. Our world is shrinking all the time. Word will spread and your reputation will set you up for better paying, more challenging gigs.
Is full of people who've never had a real job before... why?
From personal experience in the same situation, I say give the newbie as much information and help as he can handle.
Do as much as you can to bring him up to speed as soon as possible.
In every case except one, I've found this brings more work, not less. Often, the newbie catches fire and flames out in a few months. He can't usually handle all of the problems that come up, and often will quit within a few months because the problem is harder than he thought.
If he is one of the good ones that will eventually be a consultant, you've made a friend. If not, the people that hire you know have a positive feeling about you and will hire you back later when times get better. Or be forced to keep you when someone unexpectedly bails.
However, all generalizations are wrong, including this one, an this could be the one that goes south on you for no reason of yours. One went south on me. Within 3 months they were bankrupt. Another went south. Within six months they were out of business.
The last project I worked on at my old job was an especially tricky piece of code, I was eventually the only maintainer, and responsible for having written at least 60% of it myself.
There was ~sort of~ a hand over when I announced I was leaving the company. The replacement was inexperienced and had no clue about the frameworks used, and I could tell it'd be problematic at best. My best 'fix' to the problem was having management go through the trouble of maintaining my user ID, login, secure access, and set up a 'when we need help' line - a contract with a few quick fill in the blank sections - in case they needed me to come back and do some work at a premium, which they assured me they wouldn't.
It did take 3 months, but then I got that call. They had a few problems - not that the devs assigned couldn't figure it out, but ... uh... they had to be put on higher priority items, yeah, that's it - so if I could nail those out ... etc.
So, stay friendly, train your replacement as well as you can, and make sure they have your card and know they can call on you. They might not every time, but when they do, they already have accepted that premium rate for disruptive requests. I've never had anything bad come from maintaining a good professional relationship with my previous employers, be it contract work or other.
From my experience it takes a few years to teach someone the depth of knowledge that you are expected to pass on. Since this is not likely to happen, be prepared to be asked back for more in depth training after you and the paying contractee mutually agree that the newbie is ready to take on the world.
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.
I've always worked by the philosophy of "Open Kimono". Open books, no secrets from the customer, and open source. They hired you for "CONSULTING". A consultant provides professional and expert advice. As a consultant, you should have deeper level of expertise than would be feasible for them to retain in-house and that is why they hired you. If you are still working for them for 3+ years then they realize that they have retained a very expensive employee and they could be liable in some situations if they treated you as such. It would be professional of you to train your cohort to the best of your ability. Don't screw people over, that would be immoral. Do the right thing and plant a seed for the company to succeed based on the professional services you provided.
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!
Do your best to help the client achieve their goals, even if it puts you out in the cold. I've found that by doing so, * enthusiastically*, I've secured far bigger contracts with the same clients after they saw (on their own) the error of their ways.
The way I see it there are really two possible scenarios here. You've already decided that they want to replace you with a cheaper option so you are assuming your days on the contract are numbered.
Scenario 1- You resist being replaced. Doesn't really matter how you resist but ultimately the goal would be to make it take longer for the new programer to take over. Net result will be that you get a little more billable time now a the cost of damaging your reputation there. That means they likely won't rehire you later when they want or need someone to come in again and they aren't going to help you get any more business.
Scenario 2- You facilitate being replaced. Again, it doesn't really matter how. You do get replaced for this project at this time but you maintain and possibly even improve your relationship. Down the road this can lead to more jobs there, referrals for other jobs and just generally more opportunities in the future. You never know where that new programmer or a manager you worked with there could end up.
Unless you really need the work and money now Scenario two just seems like a much better option. The hardest part of contracting for most people is not doing their current "job" but making sure they have another one lined up. A good relationship is worth a lot more long term than a couple more months(if even that) of work right now.
If you do leave, be sure to negotiate a) your rates for training someone else and b) your support rates in case they need your advice/skills some time in the future. Most clients are not mature in this regard and might expect you to support your product forever and for free; you will need to educate them on how this works. It is a lot better to negotiate support in advance than when you are needed. It will feel awkward right now, but in the end, it leaves everybody happier. Most consultancy firms will do the same by the way: negotiate a price for the signed-off product and subsequently agree a price for future support.
Make sure that the client has signed off on your work ("Yes, we're happy with it"), as that will prevent future problems.
In summary: Take care of your own interest and don't be a dick to the client.
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.
If you are paid by the hour, I would be as helpful as possible, but charge for every hour.
As others have said, I wouldn't try to teach him general coding skills. You won't be able to anyway, not unless they are keeping you around for a long long time.
But I would go the extra mile and try to give them better service than they are minimally entitled to. Don't just give minimally answers, try to make sure he understands what he is doing, rather than just repeating it.
He either can do the work or not as well as you can or he can't.
If he can, he will want more than the minimal pay they are offering. If he can't, they will call you back for the 'special cases' - which chances are will be a better use of your time than dealing with the easy stuff all the time.
Oh, and when they DO call you back - raise your prices. Your contract with them has ended, you are entitled to up your price - especially as you should be dealing with higher level work.
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.
And they'll want you back.
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've done consulting for 15 years for a wide variety of industries including the high end firms (rates ranging from $250 to $388/hour). These rates are simply unaffordable and unsustainable in the long term and your clients should and have the right to demand a great transition. You should increase trust by doing a great job in the transition and take pride in doing it well. Don't just put the onus on the newbie to ask the right questions. Go out of your way to document things in a way that will support the transition, and do it well. For instance, if you have a database that your code relies on, try using a database documentation tool (such as DBDesc) and enter the required database metadata to enable auto-generated high quality, hyperlinked documentation for every table, view and field and even give them some useful diagrams -- and of course bill them for that. Create a nice table of contents with links to the various needed documents so they can quickly find the info they need. In my experience this sort of work is perceived as high value and the client won't mind paying for it. In my experience doing great transitions greatly increase trust, and results in more work from the same client because they know you are not out to bill them as much as possible on each project. For some this is counterintuitive but I've seen this virtuous cycle unfold as described many, many times.
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.
By posting this message here on Slashdot I'm going to assume you lack sufficient balls to directly call the client out on their shenanigans (which is my recommended/preferred method of dealing with a situation). You'll find that calling shenanigans on the client will often be the most direct route to solving the situation.
BUT if you must play it close to the vest - here is what you should do:
First thank your client - because by asking you to educate another it is anecdotal evidence of you reaching a mastery level of skill - which *should* correlate to a higher billable rate.
So in a polite, brief email - you should inform your client that you've been giving them a much lower rate - in part because you enjoyed working with them, and along the way you had the freedom of moving as fast as you could, without needing to consider how you should go about keeping other people in the loop. Since the status quo has been altered and it is outside the original scope of work in the contract. You are now in the unenviable role of mentoring/possibly debugging another persons work as such your new rate is 30% higher - and if you find yourself having to babysit the young tyke the rate may go higher, or you may terminate the contract - remind them you have other clients who are requesting more of your time.
If the client grumbles (and they will) then simply say that your life's calling was to mentor/audit/steward young padiwans you would have pursued a different career than contract programmer. Remind them you would have taken a job with a larger company that had better benefits, and more stability, and stock options - not pursued the nomadic life of a contract programmer. If you wanted to code in tandem you would have chosen a partner - but instead they chose your new dancing partner, and as such this is now the new rate.
If the client is really unhappy with your level of work or you aren't as good as you think you are - then you should expect to get fired on the spot. .. eventually they'll figure it out. A great spot to use this black magic are on input variables, database column names -- one of my particular favorites is to negate a database column and it's purpose. Beating the slaves does not necessarily correlate to an increase in productivity.
But if you don't get fired - then you should immediately begin plans to sabotage the young bloke. Crush him under your iron fist. Be sure to leave the billable rate higher after the little tyke fails and the body been properly disposed of -- if they hire another n00b then raise the rate again (be sure to remind the client how much time you wasted on the last guy) each time ratchet down productivity by about 7%, and also increase the poor coding practices by the same ("job security")
One of the most beautiful examples I've ever seen of how to sabotage the next guy is in the eBay trading API.
It's a *critical* response status that is in camel case -- it says: NoPaymentError -- depending on how you read it -- it could mean "Oh Shit -- NO PAYMENT -- ERROR!!!" or "All's well - there was No Payment Error" -- little gems like this insure the next guy is screwed. It's critical, but also obvious, but also totally non-obvious. The documentation for the field simply says "Will be set to the payment status of the order"
Be sure to assemble that string in different parties of the code ex. "No"+"Payment"+"Error" so it's not grep'able, worst case - make it mean something different based on the one or more other columns in the same table.
If you ever feel threatened, change the meaning of it.
Use lots of cryptic regular expressions whenever possible.
Clients who trust their entire project to a single developer without peer audits, documentation review or formalized testing save *A TON* of money - but they also assume a huge amount of "technical debt" which accrues with interest, and comes due the moment they try and pull shenanigans like this.
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/
You go form an hourly contract to a support service contract. $125/hour minimum. take your new free time to get some new customers.
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.
This is how it always works at government agencies. They have in-house staff that can do the job for 50% of the cost of contract staff, but they have civil service exams which prevent managers from installing inexperienced friends. There are established rules and procedures for discipline and relieving employees that do not apply to contractors. You can't fire an employee because he irritated you, but you can end a contractor's contract at any time. This drives poor quality managers the contractor route so they can hire inexperienced friends and colleagues, have the in-house staff train the inexperienced contractors that are billing three times what the in-house staff cost, and generally treat the contractors like dirt without fear of having a grievance filed against them.
I encountered this situation more than once in my life already. I was told by my boss at the time very directly that he was going to replace me with a team of people from India. He figured five Indian programmers overseas would amount to my skills. He flat out told me that I might as well get paid to manage / teach them to replace me since it was going to happen whether I liked it or not. He was pretty blatant about this, and not shy to insult me in this manner even though I had created their entire product from scratch by myself. I simply gave my notice and offered them two weeks, and they were shocked. On my way out they had brought an Indian contractor in and had him sit down with me and I helped him catch up to speed as best as I could out of professional courtesy. The contractor asked me for my email address and asked if he could contact me about the project after I was gone. I told him he could not contact me after my contract was through. And, he was stunned and said, "But, it's the professional thing to do." To which I replied, "No. The professional thing to do is to walk away." I got another job immediatley, was paid well and not required to undermine myself. I've been happy ever since. I also had another situation similar to this a very long time ago after I got out of college and had a job working with a private organization that developed security clearance-related software. They replaced me with an engineer from India who had only lived in the U.S. for less than two weeks. I know this because on my way out I asked him how long he had been here. I was really surprised by his answer due to the nature of their work. Anyways, don't ever let anyone step on you, have some balls. Companies don't care about you, you owe them no favors beyond what they're paying you to do within reason. That's my recommendation.
At the end of the day they have the right to replace you at least in good old America where our Republican Party has worked hard to weaken labor rights(rant over). Having said that, training requires additional effort. So tell them sure and do a 2x or 3x raise in your rate till he/she is trained. When they replace you then if they need you charge them the 2x or 3x to assist.
Your job as a contractor is to eliminate your job. If you're good at what you do you will keep trying to eliminate your job and they will keep you on for the next project, and the next, etc. The wrong attitude is that you want to keep the job going as long as you can, that's a sure way to get black listed and find out they've replaced you with someone who is half as good, but "gets 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 do understand why some of you value your knowledge, as it is the tool of which you live. But having done many many years of things outside of the scope of my contract, I have to say your going to write yourself right off the job. Bottom line they will get rid of you and see if the cheap kid can float. If not hire somebody on the spot at a higher pay rate than yours to deal with it and never look back.
Having said that...I kinda enjoy helping a new kid in the field. Any of you can attest the experience gained from an experienced pro in 2 weeks to somebody green can make the difference between an uprising star and somebody viewed as incompetent. Ignorance is not bliss, the more you know the more you realize you don't know.
Love the hours, get paid, help the kid, feel good about putting somebody on the right path for a decent living.
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'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.
More likely the client will ask the new coder to make changes, he'll blame any mistakes, bugs, etc. on the original poster and the bosses will think he's (the original poster) is a crap developer. I've seen this happen many times to contractor friends.
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.
1. Directly ask them what their intentions are with the new programmer.
2. If it is to replace you and you want to work there then point out the quality and experience you bring
3. If it is to replace you and you don't want to work there or they don't listen to you on point 2. then look for work elsewhere.
If they wanted in house they should have had a guy with you from the get go.
This guy wont even be able to code. Mark my words.
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.
You are being paid to write code, not to train up the staff - for FREE, tell them to go fuck !
Be sure to document topics covered. Answer all questions that new guy has and be sure to document that all Qs where answered. Your reputation depends on it. Once you leave and things start falling apart the blame game will begin.
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.
substitute the source code for imaps
Give her the following three letters, with instructions to open and read one per each major incident, in order:
Letter 1: Blame me.
Letter 2: Take responsiblity yourself.
Letter 3: Write three letters.
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 should do your best to train the person effectively, acknowledging your client's intent, and assuring them that, despite your knowledge of the likely outcome, you are going to do your very best to bring them up to speed. At the right time, you should have a frank conversation with your client. Once its clear that you both know what's happening, you should work together on things like a plan and a timeline.
Go over the design with the new guy, go over the code with the new guy, help him create documents that will help him when future problems come up. Document the "first places" to look for certain kinds of problems.
You should feel free to suggest to your client why you think that replacing you with New Guy is a mistake, but make sure to reassure them that you will not only not obstruct, but be as helpful as you can be during the transition.
Your professionalism and reliability are part of the value that you offer -- the reason why you are worth hiring. You should either do the work or not do the work, but you should never intentionally do less than your best because you are unhappy with the situation. If you don't think that you can put everything into the training, then you should have a frank conversation with your client about what you can or can not offer in the way of said training.
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.
If you are contracted to produce code, and teach them to use it, do that. Assuming teaching your direct, lower-cost replacement wasn't part of the original contract, you can say NO. If you want to do it, make sure you negotiate a contract for that. Don't do it for free. Helping yourself become obsolete is not a service you have to provide. Don't ever feel you are under any obligation to this, unless it was part of the original contract.
It's just like an employer saying that since you spend some late nights in the office, could you do the janitorial work, too?
Of course not!, (unless that was part of the original contract... and that would be an interesting contract...).
If you refuse to cooperate you will lose in the long run. Bad will never earns you respect.
I you manage to replace your self, then you have added value to the company. And they might come back for you when they need help in the future.
If you are as good as you claim. Your replacement might call for your assistance on new project, since your are viewed as a mentor. Someone you can rely on.
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!
if you can get a copy of the young kids resume, do what you can ,then 6 month to a year from now, get his resume to a head hunter. Then kid takes a job elsewhere and they come back to you for more work.
Tell them flat out that you are hired to code and not hired to be a teacher or a baby sitter. Just say no. If they press it get a crossword puzzle and relax. Can they afford to fire 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.
I spent 10 years working myself out of a job at every client site I went to. It's why you get more work. Clients don't recommend you if you have to stay and hand-hold their systems forever, they recommend the guy who came in, fixed things, made it better, and left - or if relevant - continues to fulfill a role that they want.
If you have concerns about the project/idea they are proposing (in this case, concerns about the candidate they want to use), then you raise those concerns, and if they say "do it anyway", you have two choices, walk away, or do it. In some cases, the right answer is "walk away", as being associated with a disaster, even if you predicted it, is a bad thing. But in this case, you train the guy. Any "disaster" aspect will fall on his shoulders, assuming you train him well.
But my main point is, your job, as a contract IT support, is to work yourself out of a job. Sure, there is ongoing work, but it should be minimal, and doable by anyone. The reason they'll keep you doing it, is you do a very good job.
I always try to make my customers successful when hired to do a job. Everything is in scope if its within reason for your compensation.
Even if this particular scenario means the end of your gig, you'll leave with a good reputation with the individuals you work with and create unpredictable numbers of new opportunities in the future.
And, given what I'm heading here, it sounds like the kind of situation where there's no way they can get rid of you in the end in any case. If you do everything you can to deliver their requests, they will feel good about deciding to keep you on board and value your work more.
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.
Done it 3 times in my career. They were always Australians, sunny, 'No Worries', and the annoying thing was that they always did better, simpler. Come to think of it, what's 'management succession'?
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.
It is AC's like this that are the bane of IT, little nobodies who are better at reading contracts then at coding.
A good coder, or in my case, a good developer has no competition to fear. Because sadly, there are not that many good developers out there. A good developer can be easily spotted, he/she is the guy/girl who doesn't fear positive discrimination to bring women/foreigners/kittens into the work place because to him/her/it they are NOT competition but co-workers who can help reduce the workload somewhat. If you are any good, I can find you a job before the day is out... of course... if you are any good... so can you. Only the not so good are jobless.
So... what would I do? I would train the guy, if he is any fun to train. I he isn't, I wouldn't and I also would simply say so and not take a contract to do so. It is the only way to remain sane in this job, say NO to jobs you don't want to do. Only do those jobs you enjoy doing. If you are any good, you can pick the jobs.
Because the trick to become good, apart from having some skill, it to be enthusiastic about your job. It doesn't matter what it is. I seen supermarket checkout workers who enjoyed their job and were very good at it because they enjoyed it and treated their customers friendly and worked fast. And then you are the one who gets the bonus hours where you are payed more and are promoted to team lead.
Same with a coding job, if you enjoy the work, you are going to do your best and be better then someone just filling the hours. But you can only do that on projects you enjoy.
So. Train the guy if you enjoy it, don't if you don't. And don't play political games about it if you don't enjoy playing political office games and do if you do.
As for how much you can train someone and whether it is realistic for them to learn everything you know... prepare to be disappointed. I just took over a project from a guy who also though training me was going to be hard.
Within a month he was gone and so was most of his code and all the performance problems with it. It might shock you, but even if you are good at your job, you are not unique. Lots of other people are good too. You are replaceable.
And on a further note, if your system requires years of training to understand... maybe you should have designed it better and documented it better. Frankly if I hear someone brag how hard it is for a new person to learn their system what I hear is "I wrote spaghetti code!".
Really? I wouldn't. They hired him to build a system not to build himself a little empire. If the newbie crashes and burns on HIS system, HE designed a bad system. If I ask you to build a car and then a newbie driver takes it out and crashes because the brakes are in the boot, I will indeed need you back. IN COURT!
People who think the newbie is going to crash and burn when they are booted out are sad little men who have an over-inflated ego. Your ex-employer will do fine without you, your ex-girlfriend will do fine with you and when you have run away your parents will NOT be SOOOO sorrry, they will dance in the streets to celebrate their regained freedom.
If your system crashes and burns, they won't blame the newbie. They will blame you. Your system, your ass.
The "training developer" requirement effectively means "engineering support" (seen offered by a big sw vendor) which is a totally different service from the contract sw development, very possibly not covered by the OP's original contract. Of course engineering support may be gladly offered by the OP at its respective terms.
The WTF in this situation is the client asking the contractor to voluntary extend his scope in order to reduce his own fee, while the client's total work requirement is not reduced, and of course while keeping the quality of service constant at the level provided by the contractor at its prime rate.
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.
Reminds me of when I was replaced at a company because Management foolishly thought they could "save" money by replacing my 20 years of experience with a fresh college graduate. The day after I was gone, the new guy quit. End of the story: they ended up replacing me with 2 full-time programmers.
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 :-).
You don't... Plain and simple -- this kid is your direct competitor. Only reason to do this is to make a present to your employer (assuming you'll get smth in return). Otherwise -- not. We work for corporations -- soulless profit-optimizing machines, it is imperative to operate with them on similar terms when dealing with them (or be at disadvantage).
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.
I agree with every comment I read about remaining professional and adhering to the terms of your contract, but if training a replacement is not in your contract, then I think it is actually a breach to ask you to do it.
They may be/have been a really good client, but they are creating a better option for themselves. There is nothing wrong with that per-se, but you should do the same. Although there must be far more eager young graduates than there are bigger and better clients, and that makes the prospect daunting, don't kid yourself. They have asked for a lot more than an expert senior coder. They are asking you to hand over some (presumably) very valuable intellectual property.
IMHO The sooner you find - or cultivate - a better option for yourself, the better. Whether it is a new client, starting a business, or something else, now is the time to do some soul searching and get moving.
Is it just me or do others bristle at the term "secrets"? If I have "secrets" (like my bank routing number), they are secret for a good reason.
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
Do it the Breaking Bad way.
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."
Is training going to look good on your resume? Or is it a waste of your time?
If you want to keep getting called back to work clean up after this noob, keep training him.
Or you could either re-negotiate with them since training is not your profession, or get out now. If they didn't mention this would be part of your work on their project, they have no reasonable expectation that you should do it. Is the "other tasks as assigned" loophole usually included in the legalese on a contract gig?