It was to talk about "team restructuring"
this post was submitted on 30 Aug 2023
1461 points (99.4% liked)
Programmer Humor
32371 readers
611 users here now
Post funny things about programming here! (Or just rant about your favourite programming language.)
Rules:
- Posts must be relevant to programming, programmers, or computer science.
- No NSFW content.
- Jokes must be in good taste. No hate speech, bigotry, etc.
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
What the company likes about the old timer is that because he has been there for 10 years, he will likely be there for the next 10 years to support the complicated system he is creating now. If a younger team member creates something using a modern approach, there is the risk they will leave in a years time and no one knows how the system works.
No one knows how to use a well documented, publicly available service? No, I'd argue that no one knows how to use a private, internal only, custom solution.
That because you're an engineer (I assume). The people signing off on these kinds of projects don't know enough themselves, so they go to someone they trust (the old timers) to help them make the decision. The old timers don't keep up with new tech, so we keep reinventing the wheel.
"keeping up with new tech" is often just re-inventing the wheel. If it isn't broke, and can still be maintained, then why break it because you like the flavor of the week?
In this case, we're talking about the OPs example of someone implementing a complex message passing architecture in Java instead of using an off the shelf solution. There are devs with 20+ years at the same company who don't know the basics of networking/cloud, because they haven't improved their technical skills much in those 20 years and instead focused on corporate politics. Those are the people who tend to gets asked for advice from upper management.
So he'll rip an even bigger hole, when he is retiring because the company never bothered to get a new solution running. Then they get a hydra of legacy code that is poorly documented and probably using some old hacks based on even older forum posts, nowhere to be found again.
Oh god. I do a lot of PowerShell scripting at my place, and less than half my team is proficient in it. My co-workers who are almost never write comments in their scripts. Meanwhile, if it's anything that will live longer than ~5 manual runs, I spemd more time on comments and documentation than scripting.
That effort is valued, but I'm shocked that my team isn't more aware of the need for documentation. We literally experienced the "bus factor" situation a few years ago.