Beyond Frontend vs Backend: The Case for Fullstack Development

We are accustomed to the idea of distinct roles for Backend and Frontend development.

I used to like the idea and never undermined it; Fullstack development never appealed to me and I never believed in its effectiveness. Through most of my career I advocated for specialisation and perfection in a specific area. I chose Frontend Development to put all my efforts into.

Recently, though, I started getting increasingly convinced that such specialisation often does more harm than benefits to both parties - businesses and developers.

Why?

Firstly, that conviction has grown out of frustration of being a highly skilled and specialised Frontend developer. Deep knowledge and skills definitely helped me a lot in passing many interviews and acquiring confidence. But I rarely had a chance to make use of them at work. Most companies need just basic Frontend skills, they want you to build basic UIs, implement form validation, and apply component libraries. They don’t care about how readable, performant, maintainable and scalable code you write. They care only about the end result - delivering features. Honing frontend skills and perfecting in the ever-changing Frontend landscape was apparently not a good investment of my time and efforts.

Secondly, I’ve got to learn that some (most?) companies are really bad at managing their human resources and work load. I’ve seen many situations when frontend devs were out of work and were tasked to come up with some useless work to make themselves busy or had to learn and switch to backend development for a while until they have some frontend tasks. Examples of backend folks having too much on their plate were common as well. Both types of situations led to frustration and/or developers’ overwork. And I can see Why such situations are common - having separate Frontend and Backend developer roles means a lot of extra work of setting up proper communication and handover processes, separate interview and performance review processes, just to mention a few. There is simply too much overhead.

The trigger for changing my mind, though, was a story of ArsDigita company and its cofounder Philip Greensup that I read in the “Founders at work” book by Jessica Livingston. The company had a quite unique way of treating developers, utilising and growing their skills. Here are some quotes to give you an idea:

we tried to help each programmer develop an independent, professional reputation. We had this idea that programmers could be professionals, like doctors or lawyers, and, to that end, we wanted the programmers to be real engineers - to sit down face to face with the customer, find out what was needed … and then take a lot of responsibility for making it happen.

We pushed the profit-and-loss responsibility down to individual teams. For example, if there were two or three programmers working for HP, then those guys would be solely responsible for the project and making sure that it got delivered on time and that the customer was happy … Implicit in that was that, if it didn’t go well, we’d know whom to blame.

For programmers, I had a vision … that I didn’t like the way that programmer careers turned out. Now that I fly airplanes, I realize that the average programmer is really much less happy in his/her job than the average airplane mechanic… For $30,000 and a year and a half, you can become an airplane mechanic. You work in a small group, you meet the customer directly. You don’t have the alienation from the customer….

Airplane mechanics have a direct interaction with the customer. A lot of jobs require two to three people, so it’s kind of social, and I noticed that they’re just really happy. Programmers are isolated. They sit in their cubicle; they don’t think about the larger picture. To my mind, a programmer is not an engineer… If you look at civil engineers, architects, they’re all dealing directly with the customer and going through the whole process.

The programmers were in the corner doing what they were told. That’s one reason they were so easy to outsource. If a programmer really never talks to the customer, never thinks, just solves puzzles, well, that’s a perfect candidate for something to offshore.

You never really know what most programmers have accomplished. There are a handful of people that you can say that about. Linus Torvalds built the Linux kernel, but it’s hard to say what the average programmer working at a big company has ever accomplished… the projects are so big and their contributions were so small.

All that reasoning and observation lead me to change my mind. I realise now what most companies really need are fullstack generalists, rather than specialists. They need developers who are responsible for the whole cycle of product development, end-to-end. It’s much easier, cheaper and more efficient to manage a small team of generalists than a bunch of specialists. And developers, having and exercising that greater responsibility would be motivated better to deliver high quality results and would have more opportunities for creative work and clever solutions. It would be much easier for them to prove their accomplishments and grow professionally. And their job would be more satisfying.