5 ms·

A developer leaving the company is not responsible for a successful handover or that the documentation is correct.

szszrk 4y ago
I want to agree with you, but actually can't. He should not be responsible. Because he already failed - he should have had that under control while he was working on it, from the very first day. Not on his notice period. We push a mentality of devops and the whole team (regardless of their position) being responsible for the final product. Push interdisciplinary attitude, where fine defined borders of each team/job fade. That developer IS responsible for that and if it's not covered by the time of his notice period it means both him and his management failed in some extent.
fooqux 4y ago
> A developer leaving the company is not responsible ... that the documentation is correct. I completely disagree. Documentation, however it exists, should always be correct. Whether you document by flowchart, code comments, self-reading code, or some other means, I always maintain that it should be updated as you update the code itself. Just like tests. If you only update it when you need to use it, you're missing the point of it.
- gsibble 4y ago
  I was working 100 hour weeks and not given any time for documentation or knowledge transfer. The code was certainly self-reading but it was a very complex system, especially security wise as it was a bank. Their other developers were juniors and couldn't understand it so they threw it out and started from scratch. I quit with no notice because I was burnt out and promised a vacation when the product launched. They renegged after denying me a raise multiple times. So I left.
- tluyben2 4y ago
  If you get paid and if there is space to do that. There is often the ‘yeah yeah let’s add the rest of the features first the do docs’. I agree with you but this often goes wrong, especially at startups.
  - dustymcp 4y ago
    adding docs meanwhile isnt always working either as the feature product might change heavily, this is a hard discipline since you need to balance when to doc what.
- Forgeties79 4y ago
  I don’t think he is saying that a developer is in no way responsible for documentation, that is a pretty uncharitable interpretation of the comment. I think they’re saying it is not up to the developer to make sure it happening writ large/that there is a system in place. That’s pretty much why we have managers and processes in place that everyone follows beforehand (ideally). If a company doesn’t implement systems, it’s not really up to me to do it. Often I will because it makes my life easier and I’m not a rigid “not my department” personality, but I’m not going to feel personally responsible when they drop the ball and wanted to plow ahead without putting the systems in place upfront. Especially because this often happens despite folks bringing up the need in the first place.
- jumpman500 4y ago
  A company should demand the documentation they need to understand things when the feature is under-development or shortly afterwards. Documentation takes time. It's their fault for cutting corners and pushing out a product/service that's undocumented spaghetti code.
  - gsibble 4y ago
    They never asked for documentation and instead pushed for more development faster.
- icedchai 4y ago
  Right or wrong, docs and tests are often given the lowest priority. Everything is good in moderation: you want some docs (especially for external APIs), some tests (integration > unit in many cases), but don't go overboard. You don't need 1000 unit tests for a little CRUD app. Documentation is subject to drift. For internal APIs, you're better off looking at the code.
  - gsibble 4y ago
    It was a bank with high security, so the code actually had 100% coverage in tests.
- ElectricalUnion 4y ago
  > self-reading code I always strive to make my code simple and readable, but there's a saying that "one person organization is another hot mess".
afpx 4y ago
thank you
tablespoon 4y ago
> A developer leaving the company is not responsible for a successful handover or that the documentation is correct. But if the handover was unsuccessful, it can call into question the skills of that developer. I mean, instead of being a "10x" developer, maybe they were actually a 1x developer that look a lot of shortcuts and wrote unmaintainable spaghetti code (or somewhere in between). Maybe they were someone who hoarded domain knowledge and refused to share it. In any case, the employer didn't realize the claimed value of that employee's work.
- AtlasBarfed 4y ago
  No it doesn't, it calls into question how much redundant knowledge, code quality, documentation, and support the org values. Which 90% of the time for anything but features and UI appearance is no value. That allows the construction of micro-empires and dependence. Orgs either recognize that and provide resources, or they rely on shorter-term one man hero efficiencies, and pay the piper later. They paid the piper later. And who knows what "19" means. 19 offshores, so that's more like 6x the cost? And offshores are probably short term so they assume they'll hire one or two offshores long term which will ... maybe ... eventually get cheaper. That's the beancounter logic. So they think long term they saved money.
  - gsibble 4y ago
    Exactly. I was working 100 hour weeks, almost all spent writing code and given no time for documentation, knowledge transfer, etc.. They bet the house on me and wouldn't pay me appropriately.
ellisv 4y ago
> A developer leaving the company is not responsible for a successful handover or that the documentation is correct. It is a mutual responsibility. More often then not I've found that my manager, coworkers, etc. didn't ask any questions about my work during my notice period.
Joeri 4y ago
I am of the opinion that a developer should always act like a professional, with the best interests of their employer in mind, and that this means doing their best to assure a smooth handover until their very last day of work. After their last day, if they were fired, all bets are off.
- gsibble 4y ago
  They refused me a raise on multiple occassions, worked me for 100 hours a week for 3 months straight, promised me three weeks off when the product launched, which they then renegged on. I quit with no notice to save my mental and physical health which had severely deteriorated.
- BlargMcLarg 4y ago
  So until that day, you basically accept fate if you are put in a bad situation and search around for a better job, should you get baited into taking a bad job. Surely I don't need to tell you why many people opt for a day-by-day basis instead. Play stupid games, win stupid prizes.
- ratww 4y ago
  > I am of the opinion that a developer should always act like a professional, with the best interests of their employer in mind Sorry but bets are also off once an employer gives them the middle finger, like in this case. If someone is admittedly trying to pay you only the minimal amount possible, it is completely reasonable that you also work the minimal amount not to be fired or sued. It goes both ways.
mrguyorama 4y ago
A developer should ABSOLUTELY be responsible for ensuring something they have built is adequately documented to continue functioning despite being run over by a bus

I want to agree with you, but actually can't. He should not be responsible. Because he already failed - he should have had that under control while he was working on it, from the very first day. Not on his notice period. We push a mentality of devops and the whole team (regardless of their position) being responsible for the final product. Push interdisciplinary attitude, where fine defined borders of each team/job fade. That developer IS responsible for that and if it's not covered by the time of his notice period it means both him and his management failed in some extent.

fooqux 4y ago

> A developer leaving the company is not responsible ... that the documentation is correct. I completely disagree. Documentation, however it exists, should always be correct. Whether you document by flowchart, code comments, self-reading code, or some other means, I always maintain that it should be updated as you update the code itself. Just like tests. If you only update it when you need to use it, you're missing the point of it.

gsibble 4y ago
I was working 100 hour weeks and not given any time for documentation or knowledge transfer. The code was certainly self-reading but it was a very complex system, especially security wise as it was a bank. Their other developers were juniors and couldn't understand it so they threw it out and started from scratch. I quit with no notice because I was burnt out and promised a vacation when the product launched. They renegged after denying me a raise multiple times. So I left.
tluyben2 4y ago
If you get paid and if there is space to do that. There is often the ‘yeah yeah let’s add the rest of the features first the do docs’. I agree with you but this often goes wrong, especially at startups.
- dustymcp 4y ago
  adding docs meanwhile isnt always working either as the feature product might change heavily, this is a hard discipline since you need to balance when to doc what.
Forgeties79 4y ago
I don’t think he is saying that a developer is in no way responsible for documentation, that is a pretty uncharitable interpretation of the comment. I think they’re saying it is not up to the developer to make sure it happening writ large/that there is a system in place. That’s pretty much why we have managers and processes in place that everyone follows beforehand (ideally). If a company doesn’t implement systems, it’s not really up to me to do it. Often I will because it makes my life easier and I’m not a rigid “not my department” personality, but I’m not going to feel personally responsible when they drop the ball and wanted to plow ahead without putting the systems in place upfront. Especially because this often happens despite folks bringing up the need in the first place.
jumpman500 4y ago
A company should demand the documentation they need to understand things when the feature is under-development or shortly afterwards. Documentation takes time. It's their fault for cutting corners and pushing out a product/service that's undocumented spaghetti code.
- gsibble 4y ago
  They never asked for documentation and instead pushed for more development faster.
icedchai 4y ago
Right or wrong, docs and tests are often given the lowest priority. Everything is good in moderation: you want some docs (especially for external APIs), some tests (integration > unit in many cases), but don't go overboard. You don't need 1000 unit tests for a little CRUD app. Documentation is subject to drift. For internal APIs, you're better off looking at the code.
- gsibble 4y ago
  It was a bank with high security, so the code actually had 100% coverage in tests.
ElectricalUnion 4y ago
> self-reading code I always strive to make my code simple and readable, but there's a saying that "one person organization is another hot mess".

afpx 4y ago

thank you

tablespoon 4y ago

> A developer leaving the company is not responsible for a successful handover or that the documentation is correct. But if the handover was unsuccessful, it can call into question the skills of that developer. I mean, instead of being a "10x" developer, maybe they were actually a 1x developer that look a lot of shortcuts and wrote unmaintainable spaghetti code (or somewhere in between). Maybe they were someone who hoarded domain knowledge and refused to share it. In any case, the employer didn't realize the claimed value of that employee's work.

AtlasBarfed 4y ago
No it doesn't, it calls into question how much redundant knowledge, code quality, documentation, and support the org values. Which 90% of the time for anything but features and UI appearance is no value. That allows the construction of micro-empires and dependence. Orgs either recognize that and provide resources, or they rely on shorter-term one man hero efficiencies, and pay the piper later. They paid the piper later. And who knows what "19" means. 19 offshores, so that's more like 6x the cost? And offshores are probably short term so they assume they'll hire one or two offshores long term which will ... maybe ... eventually get cheaper. That's the beancounter logic. So they think long term they saved money.
- gsibble 4y ago
  Exactly. I was working 100 hour weeks, almost all spent writing code and given no time for documentation, knowledge transfer, etc.. They bet the house on me and wouldn't pay me appropriately.

ellisv 4y ago

> A developer leaving the company is not responsible for a successful handover or that the documentation is correct. It is a mutual responsibility. More often then not I've found that my manager, coworkers, etc. didn't ask any questions about my work during my notice period.

Joeri 4y ago

I am of the opinion that a developer should always act like a professional, with the best interests of their employer in mind, and that this means doing their best to assure a smooth handover until their very last day of work. After their last day, if they were fired, all bets are off.

gsibble 4y ago
They refused me a raise on multiple occassions, worked me for 100 hours a week for 3 months straight, promised me three weeks off when the product launched, which they then renegged on. I quit with no notice to save my mental and physical health which had severely deteriorated.
BlargMcLarg 4y ago
So until that day, you basically accept fate if you are put in a bad situation and search around for a better job, should you get baited into taking a bad job. Surely I don't need to tell you why many people opt for a day-by-day basis instead. Play stupid games, win stupid prizes.
ratww 4y ago
> I am of the opinion that a developer should always act like a professional, with the best interests of their employer in mind Sorry but bets are also off once an employer gives them the middle finger, like in this case. If someone is admittedly trying to pay you only the minimal amount possible, it is completely reasonable that you also work the minimal amount not to be fired or sued. It goes both ways.

mrguyorama 4y ago

A developer should ABSOLUTELY be responsible for ensuring something they have built is adequately documented to continue functioning despite being run over by a bus