I was having a discussion with a fellow software engineer, and he asked something to the effect of "Why does software always become a mess?"  We talked about how the problem can be seen across the industry, and how premature-abstraction is partly to blame. But the most significant thing we noted is:

When you open up a software project to the democratic process, everyone has a say, and you lose a single direction.

At first, I thought maybe engineers are just bored.  That would explain why we can end up with five state management packages. But no, that's not it. Then, for some reason, I remembered something I had read about "nonlinear thinkers", which relates to the hunter vs. farmer hypothesis.  The general idea is that our ancestors were one of two things... you guessed it: hunters or farmers.  Hunters need to be quick on their feet, they can't just follow a series of repeatable steps -- every situation is different.  And farmers are able to succeed through linear actions; mow the field, plant the seed, water, repeat.  The latter is the majority of our jobs as engineers, there is a reason todo apps are used to demonstrate how a library or framework will work for you.  Build a list, build a detail screen, build an edit state, add a delete button... over and over.

There's one more thing to know:

Hunters are rare.  

An extension of the hunter vs. farmer hypothesis states the number of hunters thinned with time.  Compared with farmers, they had the more dangerous jobs, but they were also best equipped to protect the village from invaders.  Their nonlinear thinking and specialized tools (i.e. a bow) could better fend off attackers than a pitchfork.  

If we are all hunters or farmers and today hunters are rare, what does that mean for software engineers?  Well, many of them desire to be the alpha.  Being an alpha comes with clout and respect. But there's also only room for one and many want to assert dominance and take the crown. But in software engineering there needs to be one hunter, with a group of farmers to support them. In practice this isn't what usually happens though, many want the spotlight.  As a result, we end up with five ways to manage state, two ways to fetch data, and three ways to add styles to your component.  

I have seen it done right though, with room for people to specialize, and the key is is hiring a strong, highly objective technical leader who can build a solid foundation and enforce how things are made.

In a previous life, I witnessed it (I swear).  A small startup hired a hands-on VP of engineering and he created their architecture with enough flexibility to solve almost any problem.  He carefully hired a small, expert team around him (all senior level or above), they hired mid level developers, and those people brought on juniors.  It created a natural hierarchy, leaders from each level surfaced over time, that shared the vision of the VP.  

But there was still room for people to take ownership!  No one is a master of everything; in this case, the front-end lacked a bit.  We had to use !important waaaay too often, the selectors got so long that it would break old versions of Internet Explorer, and I once counted how many times we overrode the styles of our "action bar" component... there were more than 70.  So during a "practice week", I went to work and proposed a new way (BEM). Everyone loved it, including product, since they were aware it was a bottleneck for us, and the rest is history --  I was known as the CSS guy.  

You see... there is only room for one hunter, but that doesn't mean there is not room to be a leader.  It does not mean you always have to follow pattern or be hyper-obedient.  Our job is often to color in the lines, but there will always be cracks. There is opportunity for you stretch out your leadership legs, and you can do so from the smallest break in the cement – even if you're a farmer.