> Anecdotally, the only framework-based projects I've signed on to ended up incurring more onboarding time because I had to learn the framework, how the framework does things, and then how the team does things in the framework. All of this "how" is a step before "why", of which, every step eventually needs to be repeated over the course of my tenure in order to be successful.
This is one of the most interesting replies, thank you.
The pitch for a lot of tools—be they frameworks, libraries, languages, &c.—is that if they’re popular, you get to hire people who arrive already knowing the basics of how things are done.
The reality is that popularity waxes and wanes, so when people are evaluating a tool’s fitness for purpose, they sometimes have to read tea leaves to decide if it’ll pay off or not.
A company making several such wrong bets in a row often has a trail of poorly supported ancient technologies lurking around. They still work—Joel Spolsky famously said that code doesn’t rust—but it’s aggravating to onboard, there are few productivity advantages, and sometimes the same thing is done three different ways because the company made two “wrong” bets before making the bet they currently think is “right.”
Would things be better had they just done their own thing and stuck to it? Possibly, I tried above NOT to make a claim that a popular framework is either the right thing to do or the wrong thing to do.
But it is good to read your comment pointing out that sometimes, a popular framework isn’t popular enough to harvest the benefits for people onboarding.
This is one of the most interesting replies, thank you.
The pitch for a lot of tools—be they frameworks, libraries, languages, &c.—is that if they’re popular, you get to hire people who arrive already knowing the basics of how things are done.
The reality is that popularity waxes and wanes, so when people are evaluating a tool’s fitness for purpose, they sometimes have to read tea leaves to decide if it’ll pay off or not.
A company making several such wrong bets in a row often has a trail of poorly supported ancient technologies lurking around. They still work—Joel Spolsky famously said that code doesn’t rust—but it’s aggravating to onboard, there are few productivity advantages, and sometimes the same thing is done three different ways because the company made two “wrong” bets before making the bet they currently think is “right.”
Would things be better had they just done their own thing and stuck to it? Possibly, I tried above NOT to make a claim that a popular framework is either the right thing to do or the wrong thing to do.
But it is good to read your comment pointing out that sometimes, a popular framework isn’t popular enough to harvest the benefits for people onboarding.