I don't see a problem with my programming skills, but with my ability to play the corporate game.
Probably because i have a lot of experience, i kind of know when a manager wants to push a team too much because he wants to play some game of thrones with another manager. I know when they decide to ignore all warnings to get to a deadline, and then when everything explodes they blame someone else. I know when someone has no idea on what he is doing but has too much power. I know when they are demanding world class results on half the time and a tenth of the resources any serious company would dedicate to the effort.
Today you have this "go fast, break things" mentality, which sounds cool and "based", but justifies breaking any rule of software engineering (who has time to write test, amirite?).
And now with IA, is even worse, any manager thinks they can rewrite their stack because they got "hello world" running on localhost.
If you want to be a programmer past the age of forty, you have to accept watching your manager learn things about software development (and management) that you learned years ago.
And that's okay. If it drives you crazy, either let it go, or bite the bullet and apply for the job yourself.
> Today you have this "go fast, break things" mentality
Not in most of the big tech companies, even in the bay area. It's amazing that the bay area companies have managed to grow themselves into giant bureaucratic organizations and they console themselves with bullshit like slow is fast.
That's because "go fast and break things" was a stupid plan for children and criminals. It worked sometimes in the same way that some people who move to LA to become A-list actors succeed, but that doesn't make it a good plan. Slow IS faster. But slow can also be slow; you can go slow because you're doing it right, or you can go slow because you're dragging cinderblocks behind you for no reason. The trick is telling those two things apart.
"Go fast and break things" is a good thing if you're working on stuff nobody needs, or stuff that doesn't make a lot of money.
Breaking a social network that 2,000 people use and makes no revenue is fine as long as you learned something from it that makes it easier to get that 2,001st user or first dollar. Breaking a hospital's IT network could kill someone and should have consequences. Breaking amazon.com costs tens or hundreds of millions of dollars and should have consequences.
GFBT's usefulness, like most things, changes based on the scale at which you apply it. Calling it stupid is reductive at best.
Yup, or EM pitches the big five year vision rearchitecture because that's what builds their empire, even though a cron job that takes a couple days to write would solve the business need.
And you know that you'll come back in five years and nothing will have changed, except five new services that do half of what the vision required, most systems still depend on what was originally there, the team has tripled in size and most of them are just there to maintain the workarounds of the half-implemented systems, latency, cost, storage, and bug count are all way up, and no new functionality has been built that the original cron job couldn't have handled.
Probably because i have a lot of experience, i kind of know when a manager wants to push a team too much because he wants to play some game of thrones with another manager. I know when they decide to ignore all warnings to get to a deadline, and then when everything explodes they blame someone else. I know when someone has no idea on what he is doing but has too much power. I know when they are demanding world class results on half the time and a tenth of the resources any serious company would dedicate to the effort.
Today you have this "go fast, break things" mentality, which sounds cool and "based", but justifies breaking any rule of software engineering (who has time to write test, amirite?).
And now with IA, is even worse, any manager thinks they can rewrite their stack because they got "hello world" running on localhost.
Maybe i'm getting old...