Mixing
Preparing for retirement [closed]
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
2
down vote
favorite
I'm going to retire within the next year or two, and I'm wondering what I can do to minimize any negative impact on my company. They have been good to me (in some ways, at least), so I want to help, if I can.
I have almost 40 years experience in one particular branch of the software industry, and I'm a recognised authority in my field. No-one knows all the things I know, but a combination of a few other people could probably cover the technical areas adequately, so no big problems there, maybe.
If I have any unique capability, it may be that I seem to be good at explaining complex concepts and situations, and making them understandable (and credible) to non-experts. For example, I am called upon, from time to time, to explain to a customer why we can't do the impossible thing they're asking. Or, I am asked to explain why our products/solutions are better than those from our competitors, which wins us big deals, sometimes. I don't know if I can teach this. I'm not even sure how I learned to do it.
My management tell me to "mentor a replacement", but they have no specific ideas about who this should be, or how I should help the person. Maybe this indicates that they don't care very much, in which case maybe I shouldn't care, either.
Any thoughts on this? Should I care? If so, have y'all seen examples of effective transition/succession programs? What do they involve?
software-industry quitting
asked Mar 27 '16 at 10:47
bubba
50127
closed as too broad by Jim G., gnat, paparazzo, AndreiROM, JakeGould Mar 28 '16 at 6:12
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
suggest improvements |Â
up vote
2
down vote
favorite
I'm going to retire within the next year or two, and I'm wondering what I can do to minimize any negative impact on my company. They have been good to me (in some ways, at least), so I want to help, if I can.
I have almost 40 years experience in one particular branch of the software industry, and I'm a recognised authority in my field. No-one knows all the things I know, but a combination of a few other people could probably cover the technical areas adequately, so no big problems there, maybe.
If I have any unique capability, it may be that I seem to be good at explaining complex concepts and situations, and making them understandable (and credible) to non-experts. For example, I am called upon, from time to time, to explain to a customer why we can't do the impossible thing they're asking. Or, I am asked to explain why our products/solutions are better than those from our competitors, which wins us big deals, sometimes. I don't know if I can teach this. I'm not even sure how I learned to do it.
My management tell me to "mentor a replacement", but they have no specific ideas about who this should be, or how I should help the person. Maybe this indicates that they don't care very much, in which case maybe I shouldn't care, either.
Any thoughts on this? Should I care? If so, have y'all seen examples of effective transition/succession programs? What do they involve?
software-industry quitting
asked Mar 27 '16 at 10:47
bubba
50127
closed as too broad by Jim G., gnat, paparazzo, AndreiROM, JakeGould Mar 28 '16 at 6:12
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Yes, I've told them. That's what precipitated the "mentor a replacement" discussions, which don't seem to be going anywhere. What can you tell me about the succession plans that worked well?
– bubba
Mar 27 '16 at 11:02
1
Related: How can I prepare for getting hit by a bus? Not a duplicate though, because here we see the bus coming and can hand knowledge and responsibilities off in a controlled manner.
– Stephan Kolassa
Mar 27 '16 at 15:35
<cynicism>Most management I've worked for have had the attitude that they only need to develop employees for management, not for "do-er"/grunt level jobs. Those they figured they could hire replacements for when there's an opening.</cynicism>
– Nolo Problemo
Mar 28 '16 at 17:43
suggest improvements |Â
up vote
2
down vote
favorite
up vote
2
down vote
favorite
I'm going to retire within the next year or two, and I'm wondering what I can do to minimize any negative impact on my company. They have been good to me (in some ways, at least), so I want to help, if I can.
I have almost 40 years experience in one particular branch of the software industry, and I'm a recognised authority in my field. No-one knows all the things I know, but a combination of a few other people could probably cover the technical areas adequately, so no big problems there, maybe.
If I have any unique capability, it may be that I seem to be good at explaining complex concepts and situations, and making them understandable (and credible) to non-experts. For example, I am called upon, from time to time, to explain to a customer why we can't do the impossible thing they're asking. Or, I am asked to explain why our products/solutions are better than those from our competitors, which wins us big deals, sometimes. I don't know if I can teach this. I'm not even sure how I learned to do it.
My management tell me to "mentor a replacement", but they have no specific ideas about who this should be, or how I should help the person. Maybe this indicates that they don't care very much, in which case maybe I shouldn't care, either.
Any thoughts on this? Should I care? If so, have y'all seen examples of effective transition/succession programs? What do they involve?
software-industry quitting
asked Mar 27 '16 at 10:47
bubba
50127
I'm going to retire within the next year or two, and I'm wondering what I can do to minimize any negative impact on my company. They have been good to me (in some ways, at least), so I want to help, if I can.
I have almost 40 years experience in one particular branch of the software industry, and I'm a recognised authority in my field. No-one knows all the things I know, but a combination of a few other people could probably cover the technical areas adequately, so no big problems there, maybe.
If I have any unique capability, it may be that I seem to be good at explaining complex concepts and situations, and making them understandable (and credible) to non-experts. For example, I am called upon, from time to time, to explain to a customer why we can't do the impossible thing they're asking. Or, I am asked to explain why our products/solutions are better than those from our competitors, which wins us big deals, sometimes. I don't know if I can teach this. I'm not even sure how I learned to do it.
My management tell me to "mentor a replacement", but they have no specific ideas about who this should be, or how I should help the person. Maybe this indicates that they don't care very much, in which case maybe I shouldn't care, either.
Any thoughts on this? Should I care? If so, have y'all seen examples of effective transition/succession programs? What do they involve?
software-industry quitting
asked Mar 27 '16 at 10:47
bubba
50127
asked Mar 27 '16 at 10:47
bubba
50127
asked Mar 27 '16 at 10:47
bubba
50127
asked Mar 27 '16 at 10:47
bubba
50127
50127
closed as too broad by Jim G., gnat, paparazzo, AndreiROM, JakeGould Mar 28 '16 at 6:12
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
closed as too broad by Jim G., gnat, paparazzo, AndreiROM, JakeGould Mar 28 '16 at 6:12
Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.
Yes, I've told them. That's what precipitated the "mentor a replacement" discussions, which don't seem to be going anywhere. What can you tell me about the succession plans that worked well?
– bubba
Mar 27 '16 at 11:02
1
Related: How can I prepare for getting hit by a bus? Not a duplicate though, because here we see the bus coming and can hand knowledge and responsibilities off in a controlled manner.
– Stephan Kolassa
Mar 27 '16 at 15:35
<cynicism>Most management I've worked for have had the attitude that they only need to develop employees for management, not for "do-er"/grunt level jobs. Those they figured they could hire replacements for when there's an opening.</cynicism>
– Nolo Problemo
Mar 28 '16 at 17:43
suggest improvements |Â
Yes, I've told them. That's what precipitated the "mentor a replacement" discussions, which don't seem to be going anywhere. What can you tell me about the succession plans that worked well?
– bubba
Mar 27 '16 at 11:02
1
Related: How can I prepare for getting hit by a bus? Not a duplicate though, because here we see the bus coming and can hand knowledge and responsibilities off in a controlled manner.
– Stephan Kolassa
Mar 27 '16 at 15:35
<cynicism>Most management I've worked for have had the attitude that they only need to develop employees for management, not for "do-er"/grunt level jobs. Those they figured they could hire replacements for when there's an opening.</cynicism>
– Nolo Problemo
Mar 28 '16 at 17:43
Yes, I've told them. That's what precipitated the "mentor a replacement" discussions, which don't seem to be going anywhere. What can you tell me about the succession plans that worked well?
– bubba
Mar 27 '16 at 11:02
Yes, I've told them. That's what precipitated the "mentor a replacement" discussions, which don't seem to be going anywhere. What can you tell me about the succession plans that worked well?
– bubba
Mar 27 '16 at 11:02
1
1
Related: How can I prepare for getting hit by a bus? Not a duplicate though, because here we see the bus coming and can hand knowledge and responsibilities off in a controlled manner.
– Stephan Kolassa
Mar 27 '16 at 15:35
Related: How can I prepare for getting hit by a bus? Not a duplicate though, because here we see the bus coming and can hand knowledge and responsibilities off in a controlled manner.
– Stephan Kolassa
Mar 27 '16 at 15:35
<cynicism>Most management I've worked for have had the attitude that they only need to develop employees for management, not for "do-er"/grunt level jobs. Those they figured they could hire replacements for when there's an opening.</cynicism>– Nolo Problemo
Mar 28 '16 at 17:43
<cynicism>Most management I've worked for have had the attitude that they only need to develop employees for management, not for "do-er"/grunt level jobs. Those they figured they could hire replacements for when there's an opening.</cynicism>– Nolo Problemo
Mar 28 '16 at 17:43
suggest improvements |Â
3 Answers
3
active
oldest
votes
up vote
1
down vote
It's really managements problem to ensure you leaving does not impact badly on the company. Your main responsibility is to handover in whatever fashion they want and focus on the big change in life you're about to start.
Your 'special skills' seem to come from experience, this isn't something it's possible to teach I would think. They can always call you in from retirement and pay you to help out if they need to.
As far as plans go, this is what works for me. A handover document is prepared which contains a break down of all duties that go with the role. All passwords and things like that, ip addresses whatever. This is not a transfer of all your knowledge, it's a reference for your successor. It should document all procedures that are relevant and importantly, any workarounds and modifications that you have made up over the years.
Then when the time comes for you to leave, you work with your successor for a few days, using this document as a baseline and modifying it as need be until you actually leave. This pretty much gives them a nice overview of everything and a reference to fall back on. From time to time I've been called to ask clarification on something, but very rarely have they needed me to go back in for anything. So long as the document is thorough it should go smoothly.
It doesn't take long to create this document, I'm assuming you don't have a million different roles. In the past it has taken me a couple of hours, to a day or two at most, with a bit of tweaking as I recall something left out. Possibly I have even spent more time formatting it for prettiness and putting logo's on and suchlike than actually composing the doc.
answered Mar 27 '16 at 20:40
Kilisi
94.5k50216376
suggest improvements |Â
up vote
0
down vote
If possible, checkout a open source product called twiki or a similar product. Check with your company , if you can use it to document everything you know.
It is searchable by topics or keywords. You can use know how to write articles which might seem complex and try to explain and tag them with keywords.
This way it stays as knowledge base and is accessible to anyone. Make sure that credit is attributed to you ( if you care ).
It is very simple to use with many features.
Of course you can also try to mentor someone. The risk is they leave
answered Mar 27 '16 at 11:12
Learner_101
1,99158
Thanks. Funny you should mention it, but there have been an alarming number of resignations among the group of people I have mentored in the past. I can't imagine how anyone could "document everything they know". I wouldn't know where to begin, and it sounds like a pretty unpleasant way to spend the last two years of my career. I want to help, but there are limits to my generosity.
– bubba
Mar 27 '16 at 11:20
You must think about what is important and complicated that needs documentation/explanation and do it gradually. It will be boring to document it in a start to finish mode. Use your creativity and objectivity to document whats needed.
– Learner_101
Mar 27 '16 at 11:22
suggest improvements |Â
up vote
0
down vote
Perhaps an example from the perspective of a company that didn't plan well would be instructive? I started working for my current company about 3-1/2 years ago as a developer on a team of two working on internal tools. We had another developer who worked solely on customer facing software who planned to retire. This developer had worked for years with no oversight, no code reviews, no test team, no unit tests, just toss it over the fence, our users were our testers (and still are).
As a result, their code was without comments, has an incredible number of useless dependencies (literally thousands) and is all but impenetrable. Three months prior to their retirement they began looking for a replacement who was eventually found. This poor soul never stood a chance and quit several months after the other person retired having accomplished nearly nothing other than moving the source from VSS to SVN in the interim. They've never hired a replacement.
They farmed the code out to one of our sister companies because they were supposed to handle customer facing code. Except they didn't have the original computer to work with that had all the dependencies that never got checked in (that now sits on my desk).
Eventually the code ended up back in our laps because the entire company depends on two of the pieces and modifications and maintenance were required. It took over a week just to resolve dependencies on the original machine, another week to be able to check out, build and run from my dev box. For quite some time, we could only get both pieces to build on my machine, we couldn't get one of them to build on my colleague's machine. A year later, it still takes weeks to do what should take a few hours even after lots of refactoring. We have plans to rewrite it from scratch and make it easy to add new devices as they come down the pike, but it's very difficult to find the time.
So, after my long story, my advice to you is to make sure your code is well documented with comments (comments explaining your thinking are golden), make sure it has no unresolved dependencies (it can be checked out of your repository onto a different machine with no problems), make sure your dev & test teams are aware of places where you believe there are weaknesses. Hold code reviews to get your successors up to speed on your code while you still have time.
answered Mar 28 '16 at 5:29
delliottg
520210
suggest improvements |Â
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
It's really managements problem to ensure you leaving does not impact badly on the company. Your main responsibility is to handover in whatever fashion they want and focus on the big change in life you're about to start.
Your 'special skills' seem to come from experience, this isn't something it's possible to teach I would think. They can always call you in from retirement and pay you to help out if they need to.
As far as plans go, this is what works for me. A handover document is prepared which contains a break down of all duties that go with the role. All passwords and things like that, ip addresses whatever. This is not a transfer of all your knowledge, it's a reference for your successor. It should document all procedures that are relevant and importantly, any workarounds and modifications that you have made up over the years.
Then when the time comes for you to leave, you work with your successor for a few days, using this document as a baseline and modifying it as need be until you actually leave. This pretty much gives them a nice overview of everything and a reference to fall back on. From time to time I've been called to ask clarification on something, but very rarely have they needed me to go back in for anything. So long as the document is thorough it should go smoothly.
It doesn't take long to create this document, I'm assuming you don't have a million different roles. In the past it has taken me a couple of hours, to a day or two at most, with a bit of tweaking as I recall something left out. Possibly I have even spent more time formatting it for prettiness and putting logo's on and suchlike than actually composing the doc.
answered Mar 27 '16 at 20:40
Kilisi
94.5k50216376
suggest improvements |Â
up vote
1
down vote
It's really managements problem to ensure you leaving does not impact badly on the company. Your main responsibility is to handover in whatever fashion they want and focus on the big change in life you're about to start.
Your 'special skills' seem to come from experience, this isn't something it's possible to teach I would think. They can always call you in from retirement and pay you to help out if they need to.
As far as plans go, this is what works for me. A handover document is prepared which contains a break down of all duties that go with the role. All passwords and things like that, ip addresses whatever. This is not a transfer of all your knowledge, it's a reference for your successor. It should document all procedures that are relevant and importantly, any workarounds and modifications that you have made up over the years.
Then when the time comes for you to leave, you work with your successor for a few days, using this document as a baseline and modifying it as need be until you actually leave. This pretty much gives them a nice overview of everything and a reference to fall back on. From time to time I've been called to ask clarification on something, but very rarely have they needed me to go back in for anything. So long as the document is thorough it should go smoothly.
It doesn't take long to create this document, I'm assuming you don't have a million different roles. In the past it has taken me a couple of hours, to a day or two at most, with a bit of tweaking as I recall something left out. Possibly I have even spent more time formatting it for prettiness and putting logo's on and suchlike than actually composing the doc.
answered Mar 27 '16 at 20:40
Kilisi
94.5k50216376
suggest improvements |Â
up vote
1
down vote
up vote
1
down vote
It's really managements problem to ensure you leaving does not impact badly on the company. Your main responsibility is to handover in whatever fashion they want and focus on the big change in life you're about to start.
Your 'special skills' seem to come from experience, this isn't something it's possible to teach I would think. They can always call you in from retirement and pay you to help out if they need to.
As far as plans go, this is what works for me. A handover document is prepared which contains a break down of all duties that go with the role. All passwords and things like that, ip addresses whatever. This is not a transfer of all your knowledge, it's a reference for your successor. It should document all procedures that are relevant and importantly, any workarounds and modifications that you have made up over the years.
Then when the time comes for you to leave, you work with your successor for a few days, using this document as a baseline and modifying it as need be until you actually leave. This pretty much gives them a nice overview of everything and a reference to fall back on. From time to time I've been called to ask clarification on something, but very rarely have they needed me to go back in for anything. So long as the document is thorough it should go smoothly.
It doesn't take long to create this document, I'm assuming you don't have a million different roles. In the past it has taken me a couple of hours, to a day or two at most, with a bit of tweaking as I recall something left out. Possibly I have even spent more time formatting it for prettiness and putting logo's on and suchlike than actually composing the doc.
answered Mar 27 '16 at 20:40
Kilisi
94.5k50216376
It's really managements problem to ensure you leaving does not impact badly on the company. Your main responsibility is to handover in whatever fashion they want and focus on the big change in life you're about to start.
Your 'special skills' seem to come from experience, this isn't something it's possible to teach I would think. They can always call you in from retirement and pay you to help out if they need to.
As far as plans go, this is what works for me. A handover document is prepared which contains a break down of all duties that go with the role. All passwords and things like that, ip addresses whatever. This is not a transfer of all your knowledge, it's a reference for your successor. It should document all procedures that are relevant and importantly, any workarounds and modifications that you have made up over the years.
Then when the time comes for you to leave, you work with your successor for a few days, using this document as a baseline and modifying it as need be until you actually leave. This pretty much gives them a nice overview of everything and a reference to fall back on. From time to time I've been called to ask clarification on something, but very rarely have they needed me to go back in for anything. So long as the document is thorough it should go smoothly.
It doesn't take long to create this document, I'm assuming you don't have a million different roles. In the past it has taken me a couple of hours, to a day or two at most, with a bit of tweaking as I recall something left out. Possibly I have even spent more time formatting it for prettiness and putting logo's on and suchlike than actually composing the doc.
answered Mar 27 '16 at 20:40
Kilisi
94.5k50216376
edited Mar 27 '16 at 21:11
answered Mar 27 '16 at 20:40
Kilisi
94.5k50216376
answered Mar 27 '16 at 20:40
Kilisi
94.5k50216376
answered Mar 27 '16 at 20:40
Kilisi
94.5k50216376
94.5k50216376
suggest improvements |Â
suggest improvements |Â
up vote
0
down vote
If possible, checkout a open source product called twiki or a similar product. Check with your company , if you can use it to document everything you know.
It is searchable by topics or keywords. You can use know how to write articles which might seem complex and try to explain and tag them with keywords.
This way it stays as knowledge base and is accessible to anyone. Make sure that credit is attributed to you ( if you care ).
It is very simple to use with many features.
Of course you can also try to mentor someone. The risk is they leave
answered Mar 27 '16 at 11:12
Learner_101
1,99158
Thanks. Funny you should mention it, but there have been an alarming number of resignations among the group of people I have mentored in the past. I can't imagine how anyone could "document everything they know". I wouldn't know where to begin, and it sounds like a pretty unpleasant way to spend the last two years of my career. I want to help, but there are limits to my generosity.
– bubba
Mar 27 '16 at 11:20
You must think about what is important and complicated that needs documentation/explanation and do it gradually. It will be boring to document it in a start to finish mode. Use your creativity and objectivity to document whats needed.
– Learner_101
Mar 27 '16 at 11:22
suggest improvements |Â
up vote
0
down vote
If possible, checkout a open source product called twiki or a similar product. Check with your company , if you can use it to document everything you know.
It is searchable by topics or keywords. You can use know how to write articles which might seem complex and try to explain and tag them with keywords.
This way it stays as knowledge base and is accessible to anyone. Make sure that credit is attributed to you ( if you care ).
It is very simple to use with many features.
Of course you can also try to mentor someone. The risk is they leave
answered Mar 27 '16 at 11:12
Learner_101
1,99158
Thanks. Funny you should mention it, but there have been an alarming number of resignations among the group of people I have mentored in the past. I can't imagine how anyone could "document everything they know". I wouldn't know where to begin, and it sounds like a pretty unpleasant way to spend the last two years of my career. I want to help, but there are limits to my generosity.
– bubba
Mar 27 '16 at 11:20
You must think about what is important and complicated that needs documentation/explanation and do it gradually. It will be boring to document it in a start to finish mode. Use your creativity and objectivity to document whats needed.
– Learner_101
Mar 27 '16 at 11:22
suggest improvements |Â
up vote
0
down vote
up vote
0
down vote
If possible, checkout a open source product called twiki or a similar product. Check with your company , if you can use it to document everything you know.
It is searchable by topics or keywords. You can use know how to write articles which might seem complex and try to explain and tag them with keywords.
This way it stays as knowledge base and is accessible to anyone. Make sure that credit is attributed to you ( if you care ).
It is very simple to use with many features.
Of course you can also try to mentor someone. The risk is they leave
answered Mar 27 '16 at 11:12
Learner_101
1,99158
If possible, checkout a open source product called twiki or a similar product. Check with your company , if you can use it to document everything you know.
It is searchable by topics or keywords. You can use know how to write articles which might seem complex and try to explain and tag them with keywords.
This way it stays as knowledge base and is accessible to anyone. Make sure that credit is attributed to you ( if you care ).
It is very simple to use with many features.
Of course you can also try to mentor someone. The risk is they leave
answered Mar 27 '16 at 11:12
Learner_101
1,99158
answered Mar 27 '16 at 11:12
Learner_101
1,99158
answered Mar 27 '16 at 11:12
Learner_101
1,99158
answered Mar 27 '16 at 11:12
Learner_101
1,99158
1,99158
Thanks. Funny you should mention it, but there have been an alarming number of resignations among the group of people I have mentored in the past. I can't imagine how anyone could "document everything they know". I wouldn't know where to begin, and it sounds like a pretty unpleasant way to spend the last two years of my career. I want to help, but there are limits to my generosity.
– bubba
Mar 27 '16 at 11:20
You must think about what is important and complicated that needs documentation/explanation and do it gradually. It will be boring to document it in a start to finish mode. Use your creativity and objectivity to document whats needed.
– Learner_101
Mar 27 '16 at 11:22
suggest improvements |Â
Thanks. Funny you should mention it, but there have been an alarming number of resignations among the group of people I have mentored in the past. I can't imagine how anyone could "document everything they know". I wouldn't know where to begin, and it sounds like a pretty unpleasant way to spend the last two years of my career. I want to help, but there are limits to my generosity.
– bubba
Mar 27 '16 at 11:20
You must think about what is important and complicated that needs documentation/explanation and do it gradually. It will be boring to document it in a start to finish mode. Use your creativity and objectivity to document whats needed.
– Learner_101
Mar 27 '16 at 11:22
Thanks. Funny you should mention it, but there have been an alarming number of resignations among the group of people I have mentored in the past. I can't imagine how anyone could "document everything they know". I wouldn't know where to begin, and it sounds like a pretty unpleasant way to spend the last two years of my career. I want to help, but there are limits to my generosity.
– bubba
Mar 27 '16 at 11:20
Thanks. Funny you should mention it, but there have been an alarming number of resignations among the group of people I have mentored in the past. I can't imagine how anyone could "document everything they know". I wouldn't know where to begin, and it sounds like a pretty unpleasant way to spend the last two years of my career. I want to help, but there are limits to my generosity.
– bubba
Mar 27 '16 at 11:20
You must think about what is important and complicated that needs documentation/explanation and do it gradually. It will be boring to document it in a start to finish mode. Use your creativity and objectivity to document whats needed.
– Learner_101
Mar 27 '16 at 11:22
You must think about what is important and complicated that needs documentation/explanation and do it gradually. It will be boring to document it in a start to finish mode. Use your creativity and objectivity to document whats needed.
– Learner_101
Mar 27 '16 at 11:22
suggest improvements |Â
up vote
0
down vote
Perhaps an example from the perspective of a company that didn't plan well would be instructive? I started working for my current company about 3-1/2 years ago as a developer on a team of two working on internal tools. We had another developer who worked solely on customer facing software who planned to retire. This developer had worked for years with no oversight, no code reviews, no test team, no unit tests, just toss it over the fence, our users were our testers (and still are).
As a result, their code was without comments, has an incredible number of useless dependencies (literally thousands) and is all but impenetrable. Three months prior to their retirement they began looking for a replacement who was eventually found. This poor soul never stood a chance and quit several months after the other person retired having accomplished nearly nothing other than moving the source from VSS to SVN in the interim. They've never hired a replacement.
They farmed the code out to one of our sister companies because they were supposed to handle customer facing code. Except they didn't have the original computer to work with that had all the dependencies that never got checked in (that now sits on my desk).
Eventually the code ended up back in our laps because the entire company depends on two of the pieces and modifications and maintenance were required. It took over a week just to resolve dependencies on the original machine, another week to be able to check out, build and run from my dev box. For quite some time, we could only get both pieces to build on my machine, we couldn't get one of them to build on my colleague's machine. A year later, it still takes weeks to do what should take a few hours even after lots of refactoring. We have plans to rewrite it from scratch and make it easy to add new devices as they come down the pike, but it's very difficult to find the time.
So, after my long story, my advice to you is to make sure your code is well documented with comments (comments explaining your thinking are golden), make sure it has no unresolved dependencies (it can be checked out of your repository onto a different machine with no problems), make sure your dev & test teams are aware of places where you believe there are weaknesses. Hold code reviews to get your successors up to speed on your code while you still have time.
answered Mar 28 '16 at 5:29
delliottg
520210
suggest improvements |Â
up vote
0
down vote
Perhaps an example from the perspective of a company that didn't plan well would be instructive? I started working for my current company about 3-1/2 years ago as a developer on a team of two working on internal tools. We had another developer who worked solely on customer facing software who planned to retire. This developer had worked for years with no oversight, no code reviews, no test team, no unit tests, just toss it over the fence, our users were our testers (and still are).
As a result, their code was without comments, has an incredible number of useless dependencies (literally thousands) and is all but impenetrable. Three months prior to their retirement they began looking for a replacement who was eventually found. This poor soul never stood a chance and quit several months after the other person retired having accomplished nearly nothing other than moving the source from VSS to SVN in the interim. They've never hired a replacement.
They farmed the code out to one of our sister companies because they were supposed to handle customer facing code. Except they didn't have the original computer to work with that had all the dependencies that never got checked in (that now sits on my desk).
Eventually the code ended up back in our laps because the entire company depends on two of the pieces and modifications and maintenance were required. It took over a week just to resolve dependencies on the original machine, another week to be able to check out, build and run from my dev box. For quite some time, we could only get both pieces to build on my machine, we couldn't get one of them to build on my colleague's machine. A year later, it still takes weeks to do what should take a few hours even after lots of refactoring. We have plans to rewrite it from scratch and make it easy to add new devices as they come down the pike, but it's very difficult to find the time.
So, after my long story, my advice to you is to make sure your code is well documented with comments (comments explaining your thinking are golden), make sure it has no unresolved dependencies (it can be checked out of your repository onto a different machine with no problems), make sure your dev & test teams are aware of places where you believe there are weaknesses. Hold code reviews to get your successors up to speed on your code while you still have time.
answered Mar 28 '16 at 5:29
delliottg
520210
suggest improvements |Â
up vote
0
down vote
up vote
0
down vote
Perhaps an example from the perspective of a company that didn't plan well would be instructive? I started working for my current company about 3-1/2 years ago as a developer on a team of two working on internal tools. We had another developer who worked solely on customer facing software who planned to retire. This developer had worked for years with no oversight, no code reviews, no test team, no unit tests, just toss it over the fence, our users were our testers (and still are).
As a result, their code was without comments, has an incredible number of useless dependencies (literally thousands) and is all but impenetrable. Three months prior to their retirement they began looking for a replacement who was eventually found. This poor soul never stood a chance and quit several months after the other person retired having accomplished nearly nothing other than moving the source from VSS to SVN in the interim. They've never hired a replacement.
They farmed the code out to one of our sister companies because they were supposed to handle customer facing code. Except they didn't have the original computer to work with that had all the dependencies that never got checked in (that now sits on my desk).
Eventually the code ended up back in our laps because the entire company depends on two of the pieces and modifications and maintenance were required. It took over a week just to resolve dependencies on the original machine, another week to be able to check out, build and run from my dev box. For quite some time, we could only get both pieces to build on my machine, we couldn't get one of them to build on my colleague's machine. A year later, it still takes weeks to do what should take a few hours even after lots of refactoring. We have plans to rewrite it from scratch and make it easy to add new devices as they come down the pike, but it's very difficult to find the time.
So, after my long story, my advice to you is to make sure your code is well documented with comments (comments explaining your thinking are golden), make sure it has no unresolved dependencies (it can be checked out of your repository onto a different machine with no problems), make sure your dev & test teams are aware of places where you believe there are weaknesses. Hold code reviews to get your successors up to speed on your code while you still have time.
answered Mar 28 '16 at 5:29
delliottg
520210
Perhaps an example from the perspective of a company that didn't plan well would be instructive? I started working for my current company about 3-1/2 years ago as a developer on a team of two working on internal tools. We had another developer who worked solely on customer facing software who planned to retire. This developer had worked for years with no oversight, no code reviews, no test team, no unit tests, just toss it over the fence, our users were our testers (and still are).
As a result, their code was without comments, has an incredible number of useless dependencies (literally thousands) and is all but impenetrable. Three months prior to their retirement they began looking for a replacement who was eventually found. This poor soul never stood a chance and quit several months after the other person retired having accomplished nearly nothing other than moving the source from VSS to SVN in the interim. They've never hired a replacement.
They farmed the code out to one of our sister companies because they were supposed to handle customer facing code. Except they didn't have the original computer to work with that had all the dependencies that never got checked in (that now sits on my desk).
Eventually the code ended up back in our laps because the entire company depends on two of the pieces and modifications and maintenance were required. It took over a week just to resolve dependencies on the original machine, another week to be able to check out, build and run from my dev box. For quite some time, we could only get both pieces to build on my machine, we couldn't get one of them to build on my colleague's machine. A year later, it still takes weeks to do what should take a few hours even after lots of refactoring. We have plans to rewrite it from scratch and make it easy to add new devices as they come down the pike, but it's very difficult to find the time.
So, after my long story, my advice to you is to make sure your code is well documented with comments (comments explaining your thinking are golden), make sure it has no unresolved dependencies (it can be checked out of your repository onto a different machine with no problems), make sure your dev & test teams are aware of places where you believe there are weaknesses. Hold code reviews to get your successors up to speed on your code while you still have time.
answered Mar 28 '16 at 5:29
delliottg
520210
answered Mar 28 '16 at 5:29
delliottg
520210
answered Mar 28 '16 at 5:29
delliottg
520210
answered Mar 28 '16 at 5:29
delliottg
520210
520210
suggest improvements |Â
suggest improvements |Â
Yes, I've told them. That's what precipitated the "mentor a replacement" discussions, which don't seem to be going anywhere. What can you tell me about the succession plans that worked well?
– bubba
Mar 27 '16 at 11:02
1
Related: How can I prepare for getting hit by a bus? Not a duplicate though, because here we see the bus coming and can hand knowledge and responsibilities off in a controlled manner.
– Stephan Kolassa
Mar 27 '16 at 15:35
<cynicism>Most management I've worked for have had the attitude that they only need to develop employees for management, not for "do-er"/grunt level jobs. Those they figured they could hire replacements for when there's an opening.</cynicism>– Nolo Problemo
Mar 28 '16 at 17:43