I've been a coder and have watched coders for a long time. I consistently see two trends.

As an agile guy, back in the day I wrote an Agile story tracker. Fun times. Then I saw some other Agile project management tools. Then for a while it seemed like every week or two I was getting emails asking me to evaluate yet another agile/to-do list tool.

It seemed that programmers were unable to grok the agile story concept without making their own tool to use it.

But I saw the same kind of thing in the code I wrote. I wouldn't just solve a problem; I'd solve a class of problems. Generalization was awesome! The more I generalize and account for edge cases, the more value I am creating! Woo!

Many of us programmers, myself included, are constitutionally incapable of just solving the exact problem we have using the minimal amount of code and then moving on. We confuse coding with value creation, so we build frameworks and tools out of everything. If you build a list sorter, that's okay, but if you build a 30KLOC list uber machine, that's better, right? After all, it does more. You worked harder at it.

The second thing I saw, which was even more painful to realize and accept, was that it was very easy to get "upside down" in a toolset or framework and not even be aware of what's going on.

The first time I saw it was when I was teaching a mainframe team Visual Basic, back in the 90s. We were building a simple form with a textbox and button. I had showed them the concepts and they were a smart bunch. I started the exercise, but a couple of developers were stumped.

Why?

When I walked over, the problem they had was the properties page. Sure, they got the concept of drag-and-drop. But once the button was dropped? There were like a million options in there! What was the right font size? What did this thing mean? And so on.

I thought that was pretty silly and tried to forget it. But then I noticed in my own work that I'd get sold on a new set of tools. For sake of argument let's use the old Infragistics web controls. They do everything! Amazing control and look-and-feel!

I'd drop them on a web page wanting to create a smart grid. But the grid didn't do X, and in my mind, X was what needed to happen. So I'd poke around at the help file. I'd go online. In some cases I'd tear apart the javascript and start fixing it myself. Hey, it's only web programming. I can do this.

But holy shit that took a lot of time. On my next project when I needed a grid? I dropped a HTML table in. Just added whatever functionality I needed directly from JS. Not only did it take less time, but the resulting codebase was easier to read.

Then I started watching the teams I coached. They very rarely talked about actually solving problems, or language/foundational issues. Instead they talked about tools and frameworks. This tool or framework would do this cool thing if you tweaked it like this. Joe spent 2 days trying to get Y to work.

For many, many teams, buying into the framework means buying into a complexity and cognitive overhead that's siomply not relevant to the actual problem they're trying to solve. I don't know. Maybe it makes them feel cool or something. One of the smart kids. But speaking as both a participant and an observer, it's whack.

tl;dr So sure, let a thousand flowers bloom. But your job isn't arranging flower baskets, it's helping somebody who's down feel better. You might not even need flowers at all. Stop focusing on the tools and start focusing on the solution. Then the tools will work themselves out.