While I don't necessarily agree with most of this article, it's very good. It really just illustrates why so many people get jaded with tech.
I believe you can absolutely build your own well-documented framework and be successful, but ultimately some little sh*t is probably going to come in either say, "Why aren't we using React? Let's rewrite in React!" or "I don't like how this is done so I'm just going to redo it some other way I like in this one place." From here you have your camp of people who say, "Just don't let that happen!" and then your other camp of people who say, "I need to hire people, and nobody wants our custom stuff on their resume so let's just use TodaysFlavour.js so we can hire whoever and make the investors happy". And that's, like, two scenarios of many.
I guess all I'm saying is that it's really hard to find value from articles like this one when the surface area of the context is pretty much unimaginably wide.
I like frameworks and two of my professional anecdotes are: I once worked for a company with an absolutely horrid culture yet their codebase was rails done "the rails way (tm)" and it was great! I got my bearings immediately and pretty much had no questions about where anything was (which was good because I didn't want to talk to my coworkers... don't worry, I didn't stay there long). I also worked at a much better company where one or two people were hell-bent on coming up with their own ideas while everyone else mostly didn't care and just wanted to get the work done. This is well-and-good but these people had already decided a previous defined way of doing things was no good so they changed that, and when they leave, I can bet that whoever replaces them will decide that their well-documented way of doing things was no good. I wish people would just follow the framework unless it doesn't make sense to (which you only actually know after you've tried to do it the framework's way).
Well, I've written way too much already for a comment... But I'll add that I think the biggest thing this article misses is its points around "speed of development". Speed of development is always important in the beginning. Once the idea has been proven to work market fit, then the generators this article talks about are no longer important.
Anyway ya, Imma shut up now. Overall, good article. I'm going to read it again tomorrow as I'm sure I missed a lot.
I believe you can absolutely build your own well-documented framework and be successful, but ultimately some little sh*t is probably going to come in either say, "Why aren't we using React? Let's rewrite in React!" or "I don't like how this is done so I'm just going to redo it some other way I like in this one place." From here you have your camp of people who say, "Just don't let that happen!" and then your other camp of people who say, "I need to hire people, and nobody wants our custom stuff on their resume so let's just use TodaysFlavour.js so we can hire whoever and make the investors happy". And that's, like, two scenarios of many.
I guess all I'm saying is that it's really hard to find value from articles like this one when the surface area of the context is pretty much unimaginably wide.
I like frameworks and two of my professional anecdotes are: I once worked for a company with an absolutely horrid culture yet their codebase was rails done "the rails way (tm)" and it was great! I got my bearings immediately and pretty much had no questions about where anything was (which was good because I didn't want to talk to my coworkers... don't worry, I didn't stay there long). I also worked at a much better company where one or two people were hell-bent on coming up with their own ideas while everyone else mostly didn't care and just wanted to get the work done. This is well-and-good but these people had already decided a previous defined way of doing things was no good so they changed that, and when they leave, I can bet that whoever replaces them will decide that their well-documented way of doing things was no good. I wish people would just follow the framework unless it doesn't make sense to (which you only actually know after you've tried to do it the framework's way).
Well, I've written way too much already for a comment... But I'll add that I think the biggest thing this article misses is its points around "speed of development". Speed of development is always important in the beginning. Once the idea has been proven to work market fit, then the generators this article talks about are no longer important.
Anyway ya, Imma shut up now. Overall, good article. I'm going to read it again tomorrow as I'm sure I missed a lot.