A succinct way I’ve framed the split is that a front-of-the-front-end developer determines the look and feel of a button, while a back-of-the-front-end developer determines what happens when that button is clicked.
Doing it right requires a different pace of working and a much broader thought process than “ok, let’s get this thing out the door.” Which is super tough because most workplaces place a huge emphasis on getting things out the door, and fast. Little agile tickets that are expected to be completed in micro sprints to me seem to be antithetical to doing it right.
I’m a historian of innovation. I write mostly about the causes of Britain’s Industrial Revolution, focusing on the lives of the individual innovators who made it happen. I’m interested in everything from the exploits of sixteenth-century alchemists to the schemes of Victorian engineers. My research explores why they became innovators, and the institutions they created to promote innovation even further.
To truly increase innovation, I think we need policies focused on what goes on even further upstream, before much of the supply of new inventors is inevitably siphoned off into distractions, dead ends, and failure. Most policies inevitably have a marginal effect, but a slight expansion of the incoming swell of potential inventors can have a much greater impact than fiddling with the incentives of the few hundred who’ve already somewhat made it to the final trickle. Increase the strength of the flow upstream, and everything downstream flows the faster too.