> I for one believe that the best solutions I've produced over the years were things that side-stepped the popular or established frameworks and were more customized and focused solutions. They gave the business an undeniable edge over the cookie cutter competition, and by being well versed in the full stack, my team was able to implement new features at a fraction of the cost.
Yes but that's different from being a cowboy coder or a cynic who rejects the concept of frameworks in the first place. You built a new framework customized to your business needs. To do that, you needed to understand the context of the business and your tech stack, understand why existing frameworks didn't fit, and build a new one that works well. It's a good example of not being a cog, which is what I was encouraging in my comment.
That's just it though - I wouldn't call anything we've built a "framework" at all. All of the projects were much simpler at their core than most frameworks I've ever dealt with.
Of course, "framework" might have different definitions for different people. To me, by definition, a framework tries to be more generic than a custom solution, has more features that appeal to more than one use-case, and is designed to be flexible and fit multiple projects.
The solutions I've had major success with were none of those things because the benefits we got (deeper knowledge of our stack, faster iterations, and features no one else could touch) way outweighed any perceived benefits of using something mostly off-the-shelf.
Yes but that's different from being a cowboy coder or a cynic who rejects the concept of frameworks in the first place. You built a new framework customized to your business needs. To do that, you needed to understand the context of the business and your tech stack, understand why existing frameworks didn't fit, and build a new one that works well. It's a good example of not being a cog, which is what I was encouraging in my comment.