Comment by szszrk | Hacker News Reader

Comment by szszrk | Hacker News Reader

Parent Full thread

I generally see what you are aiming at, but I don't think you are weighting all aspects and showing the whole story. There could be so many different views of such situation.

Was it actually rebuild from scratch? Rebuilding and taking over maintenance and support are two different efforts.

Why it had to be rebuilt? Was there a really unsuccessful attempt of a handover? Why was it so hard to hand over? Are we certain that documentation and training was sufficient for it to succeed?

Was ongoing support taken into account? Maintenance, new features, patching, monitoring - was it hard, was it clear for others how to approach those topics? Was the architecture easy to follow and pick up by others?

Expecting that others will be as genius as you may be seen as positive aim at perfection. It may also be seen as bad teamwork that will build up costs later on. Companies create standards, use "approved" frameworks and copy-paste solutions because it's then easier to support and require less people with less skill. It's hard to recruit already, you don't have to over-complicate solutions and make it even harder. Then there is a day in which your product dies on production and there is just one person who can figure out what is going on. For me it's a clear sign of poor management and we should all stay away from such practices.

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

> 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.

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.

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.

> 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.

> 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.

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.

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.

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.

They never asked for documentation and instead pushed for more development faster.

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.

> 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".

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.

It was a bank with high security, so the code actually had 100% coverage in tests.

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.

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.

> 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.

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.

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.

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.

thank you

u/gsibble's story sounds familiar to me. People aren't rational, nothing ever makes any sense.

I once build a budgeting and estimating tool (for architecture). Super simple, just worked. The PHBs brought in consultants to "solve the problem". Two years later, my tool was being used on the downlow, like some kind of contraband, because the replacement never worked.

Another time, another place, I was brought in to rescue a project. Four devs spent about a year on an enterprisey monstrosity. It wouldn't even compile. Once I understood the task, I banged out a tool, using node.js & AWS for the first time, in two weeks. Then another 2 weeks to get into production. Clients were ecstatic.

I have many more examples.

FWIW, I'm a very average programmer; I just try to solve the problem in front of me. But I like to think I'm really good at requirements, analysis, customer communications, etc.

> But I like to think I'm really good at requirements, analysis, customer communications, etc.

This goes so much farther than people think. So many people think that if they learn to write code, they'll be effective in this line of work. Writing effective code is one part of a balanced skillset necessary to do good work.

the company may have decided that the product is just more important than when OP was still working there so it requires more engineers to expand it etc.

however other than that if OP isn't lying I can't see any way how a 1 vs 19 situation is anything but a failure for the company lol. maybe 1 vs 2 or 1 vs 3.

I am very senior (25+ years experience) and they used all jrs (1-3 yrs). They seemed of the mindset that monkeys can write Shakespeare.

>> Why it had to be rebuilt? Was there a really unsuccessful attempt of a handover?

This is a good question. It could be either that management is incompetent or that the code was unmaintainable. But still, the fact that it took a team of people much longer to build does prove a point. For projects of this size, it's difficult to build them fast unless the code is maintainable, even if it's just a team of 1.

There can be some extreme cases of corner-cutting which can deliver fast short term results but even this has its limits. The complexity or security issues tend to catch up with you quite quickly.

Management was incompetent and I have proof. Their stock hit a high of $15 less than six months ago. It's currently sitting at $0.66. They went from $5.5 billion to $255 million in market cap in less than six months.

They had many problems.

I quit with no notice so there was no attempt to hand over. I was the only senior at the company (25+ years experience) and the rest were jrs (1-3 years). The 19 people that replaced me were juniors who developed whole new software based upon a monolithic architecture since they couldn't understand my complex Microservices based one.

Reply on news.ycombinator.com