251–260 of 431 posts
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…
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…
This can go wrong, as I found. Management and Tech leadership are focussed on the new projects with latest technology - they pay the biggest bucks for these and no one really cares about the devs maintaining the old stuff - even if important. The second problem is looking for new roles you resume is filled with old tech rather than new stuff that is in demand.
Over here in the UK, if I constantly chase the new hotness I will have plenty of new startups to choose from but I’ll almost always be low-balled on pay with some practically meaningless equity package.
Gaining more in-depth experience opens up the better paying positions further up the ladder in more established companies.
Don’t want to keep your head in the sand for years but at the same time, there are a lot of skills that can’t be learned if you stay exclusively at the bleeding edge.
Earlier quoted context omitted.
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…
> 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. The "on borrowed time" is an odd conclusion. When someone takes over, it's typically a priority change ("We want everyone working on new projects, just freeze this old stuff") rather than some kind revenge path against an…
Long-term ownership and careerist jockeying don't go well together.
Earlier quoted context omitted.
This is literally the approach recommended in Team Topologies. The same team should own vN and vN+1, so that they both have to operate their own design and have the opportunity not to make the same mistakes again. It should be the default.
That would require staying in one company for more than 2 years, which means you probably lost out on 20-30% of income over next 2 years.
Earlier quoted context omitted.
tell me you don't have ADHD without telling me you don't have ADHD
For what it's worth, I find it much easier for my ADHD to debug and improve existing code than to greenfield - it's actually interesting . Debugging is like a detective's work with small dopamine hit at each step of unraveling the situation and a huge reward once you finally grasp it. It's best to do on someone else's code, so you don't get too frustrated with your past self ;) Greenfielding provides some rewards too…
We sometimes get incidents that things someone remembers should exist do not work, only to find out that that product was retired several years ago (but someone forgot to delete some DNS records, so there's an error message from... someone's server!). But only because we asked half the company on Teams.
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…
Additionally, reading through other people's code is educational and it also builds self-esteem.
Unfortunately, we had this level of luxury because we had growth, especially new business scenarios that involved thousands of companies and millions and millions of users, thanks to the confluence of internet, mobile, social network, cloud, and machine learning applications. I'm not sure we are going to have similar growth in the coming 10 years, but I hope I'm dead wrong.
[1] The downside, of course, is that engineers tended to abandon a project after version 0.1, like what Twitter engineers did to their Manhattan project.
I've run into a few engineers, very capable people and I'd be happy to work with them, but their experience was limited to very structured environments. It sounded like they were in well organized organizations. One in particular worked for a sort of "side ways competitor". They were horrified to hear about my deploying a fix all by myself, no review, for a legacy product that really didn't have a good testing enviro…
This sounds like a great way to cause a live-site incident.