111–120 of 431 posts
And I would add, you are not an "expert" until you had to reverse engineer a program who's source disappeared a decade or more ago :) But an interesting article for modern times.
A big problem I see in software is that developers don't stick around on projects long enough to see that their mistakes are mistakes. Instead, they move on to the next greenfield project or rewrite the project in the newest shiny tech without ever actually addressing the core complexity of the problem they're trying to solve.
As an embedded engineer in a new position I always volunteer to take up an old crusty legacy product that nobody else wants to touch. It's a quick education into how the company approaches projects and all the ghosts they had to fight along the way. All the business logic is there, and sometimes it's even documented. And once you have a semblance of knowledge about how the thing works and how to make fixes, you've bu…
Small, but not insurmountable. The time always comes when a new leader and their lieutenants come into the org and prioritize new features over maintenance, at which point your moat is null and void and you’re on borrowed time. I’ve yet to find a way to build a moat that withstands that level of hostility without actively harming the organization in the process. I’d love to hear how others deal with this inevitabilit…
One of the old specialty C ERPs I've worked on has literally buried more than 3 (the ones I know of) "great Ruby rewrites". There are just _so many_ features, that the newcomers always ended up on the chopping block after 5-10 years and before they could achieve real customer traction. The old project just ended up getting some more interface fixes instead (aka even more features to catch up to) and to this day the compiler for the core hasn't even been upgraded to a version that can run on anything newer than XP SP1 (the improvements in SP2 break it).
Now they're doing another modernization project with some web services and stuff. We're happy to take their money for those as well. I'd be quite shocked if those do anything other than enlarge the moat of the core.
You're also not a senior engineer until you've been forced to adopt the coding style and practices of that legacy project. A lot of younger developers like to come into a new project and slap on the latest frameworks or coding practices that they've picked up recently, without acknowledging that breaking the standards of the project lead to higher mental load to maintain that code over the long term.
"checkout project, reformat all source files, commit"
I'd be happy to have a look at anyone's legacy code to at least write an analysis paper on it. (I'm currently seeking contract work, been doing code for a long time.)
As an embedded engineer in a new position I always volunteer to take up an old crusty legacy product that nobody else wants to touch. It's a quick education into how the company approaches projects and all the ghosts they had to fight along the way. All the business logic is there, and sometimes it's even documented. And once you have a semblance of knowledge about how the thing works and how to make fixes, you've bu…
Haven’t you also often made a moat between yourself and doing literally anything else more interesting at the company?
Why? Because I very quickly made a name for myself as someone who learns quickly and then gets stuff done even in contexts where everyone else struggles. Solving problems that have long been considered intractable is a good way to show your value.
Earlier quoted context omitted.
It isn’t just younger developers doing this, nor even inexperienced ones. I’ve seen a ton of experienced people do this to themselves and their teams, mostly it seems to be able to pad their resume, but some honestly believe newest and shiniest is best.
Juniors with tons of experience aren't very uncommon.
Do you mean that there are seniors with a lack of experience? I believe yes I was also making that same point.
Ageism in the industry also encourages seniors to appear to be plugged in with the newest shiniest thing, so we kind of do it to ourselves with our hiring practices.
We need to divorce seniority from talent.