> You're bound to their bugs
If you do it yourself, you're bound to your own bugs. When they have bugs, it's fixed by a team of highly skilled contributors.
Not using frameworks is just an ego problem, or a lack of skills.
If you do it yourself, you're bound to your own bugs. When they have bugs, it's fixed by a team of highly skilled contributors.
Not using frameworks is just an ego problem, or a lack of skills.
If you use a really good framework, no framework is vastly worse.
From one day to the next there will probably be one or two frameworks which dominate your work. If it's really good you'll have an overall positive impression of them and vice versa.
Some brilliant folks are just bored by usual rather generic work, and their idea of 'fun' is to keep reinventing the wheel that specifically fits current problem. Actual benefits to business be damned, intellectual fun is more important. Once those folks leave (and they always leave eventually), its mayhem for the remainder of the team/company.
For me, this kind of 'autistic' brilliance is overall just professional incompetency that shows over long time period and I avoid hiring such folks. One can babysit them and steer them but its rarely worth it within usual teams.
I could write a dissertation on this statement alone. But let's use two examples. Python and Node. Both are very "never do anything yourself" languages. Lots of libraries, even more frameworks. What's the result?
1. CVEs all over that place that effect nearly anything people touch.
2. Library creep. Pulling in one library or framework pulls in the entire planet.
3. Libraries and frameworks exist for absolute trivia. Node is famous for this, including stupid packages that literally just color text (and not in a meaningful way like a logger).
So in exchange for avoiding your alleged "autistic brilliance" you increase your attack surface 10 fold. I use libraries all the time, I am absolutely sure to limit their scope as much as possible. I won't use libraries for trivia, and I evaluate frameworks extremely carefully. It's kind of funny how often your opinion is parroted in startup forums but for some reason I keep making more money every year despite every signal pointing to me somehow being in the class of engineer that are, according to you, better off without a job.
Companies are run by idiots. The hubris you show is the same hubris a VP of engineering shows having last programmed 10 years ago. It shows a complete lack of nuance and understanding of the engineer.
Three months later we find a few game breaking bugs. Do the right thing and send a report and hope the author's fix things. Things didn't get fixed in time. Now over budget and over the time limit I have VPs of engineering breathing down my neck (as the lead at the time) for why things aren't getting done.
This is not an isolated case. You might not run into this problem using a mature framework (the problem then is being bound by the author's idea of a good architecture), but if you're needing something better and venture into other languages for your needs you will run into this at some point. "Highly skilled contributors" often work for free. Perhaps I'd agree with you if you meant some professional, paid, framework. But I have never had an experience where these "high skill open sourced contributors" fix bugs inside my sprint cadence. The implication that I have an ego and skill problem for not using a framework, but these so-called contributors are "high skilled" is insulting to not only me but the entire profession.
I'd imagine the nuance is in what kind of language you use. Lowest common denominator languages like Ruby, Javascript, etc (things that can be learned quickly in a code camp) tend to be dominated by framework-first-and-always people since frameworks can be parsed easily by seat warmers. Engineering management loves frameworks because it takes the thinking out of writing code. The maligned view of engineers as people who will "screw things up when they're left to their own devices" is so pervasive they've even got other engineers parroting it.
If you believe it's a "lack of skill" or "ego" problem to honestly not use a framework in some cases you should probably stop hiring idiots. An actual "high skill" engineer will evaluate the cost and probability of needing to break out of a framework.
Using a framework you're not familiar with to build a project on a deadline is absolutely stupid.
Using a new framework without wide community support for, that you're not familiar with, and for a project is mind-blowingly stupid.
I'm hoping that you were a junior engineer at the time that didn't know better and that you learned from it.