Comment by cbushko | Hacker News Reader

Comment by cbushko | Hacker News Reader

Parent Full thread

I agree with you that most developers do their best work after 6-8 months and that developers get less productive after 24-36 months but for totally different reasons. Developers don't get 'lazy', 'bored' or 'comfortable', they get overburdened by the company.

It is common knowledge that the average developer leaves after the 2 year mark. When that happens, everyone else is left holding the bag and they become the new experts.

Companies are full of self created abandonware.

Another person leaves and it is now two extra things that the vet has to become the expert on. Then three, then four and on and on. Next thing you know, your vet isn't getting any work done because they are holding too many bags. As the expert, they are in too many meetings trying to keep other people productive. They are pulled into too many critical issues and they are trying to mentor new developers in your ever revolving door of new people.

But they are unproductive

No. They are keeping your company afloat and you aren't compensating them for it.

I think it's worse than that, as some of the bags they are holding are full of junk.

Yet they can't just throw them away, because their peers are not confident enough to support the conclusion that there's nothing of value in there. A litany of "How can we be sure that XXXX" are thrown at the expert to clear, creating continuous inertia.

The choice becomes to keep holding the bags eternally, or go elsewhere they can start fresh.

Sometimes yes, sometimes no.

Is it really junk or are we lacking in time/money/tribal knowledge to understand how it deeply works?

I like to think that I am a Very Good Engineer™ but I am sure that I would produce a similar piece of "junk" if I was under the same lack of requirements, training and time.

  who wrote this garbage??? 
  > git blame
  oh crap, it was me 2 years ago!

> Is it really junk or are we lacking in time/money/tribal knowledge to understand how it deeply works?

I think OP was talking not about code quality but code value. A lot of legacy systems are maintained simply because we don't know for sure that there's not something that relies on them, or that they won't be needed later. The expert wants to discard them, but everyone else insists on keeping them around just in case. That adds burden on the expert.

To me it is part of the problem.

> are we lacking time/money/tribal knowledge to understand how it deeply works?

This is a serious issue when a system becomes complex enough.

For instance you work there for 4 years, became the most versed into the system, and have a hunch that the manual process to validate all submissions to some system could be wildly simplified.

But then random managers come to ask “are you 100% sure there won’t be hidden issues ?”, and by definition the answer is “no”. And since you’re the only one on the proposition, you have to bear the risk alone if you push it through. You could, but it is hardly worth it (diminishing rewards at your level, heavy bashing in case of troubles).

And there’s ton of other subtle and not so subtle situations where you have some knowledge, you could do something, but you don’t have any backing to make it worth it because others just don’t know. So stuff keeps piling in.

TBF not all companies work like that, but you also don’t end up a lone expert in places where these kind of issues are solved early and organically.

I definitely agree and I have seen this. I can understand being risk averse to change and unknowns but debt and cognitive load should be a consideration too.

This is why teams creating a billion microservices because it is the pattern of the day gets me a little angry. It is just another unused thing to watch out for.

Reply on news.ycombinator.com