Ramblings of an old-school software developer, father, and woodworker.

Recent Posts

Frontend and Backend: What's so different?
Thoughts on Development Domains

We Are All 10x Developers
What a 10x developer really is, and why sometimes we’re all 10x.

The Parable of the Two Programmers
A classic anecdote about skill vs. experience in programming.

How to Debug Anything
If you’re having trouble fixing anything, try one of these strategies.

Frontend and Backend: What's so different?

· by Tim Mensch · Read in about 10 min · (1922 Words)
developer programming productivity

Developers and Categories

There’s a common meme in web software development circles: Frontend developers are perceived to have less status than backend developers. This shows up in a series of questions on Quora, for instance. 1 I’ve tried my hand at answering a couple. 2

Good front end development today, though, can actually be harder than back end development. At the extreme end of the spectrum, it can require a much stronger developer. So where does this perception come from? Complexity.

I’m going to diverge from the original topic here and talk about what I mean by complexity, but I promise I’ll return to the underlying question.

Degrees of Complexity

I want to start talking about degrees of complexity. In first degree complexity you have applications that are straightforward and linear.

A “Hello World” app has the lowest degree of complexity. Let’s call that our base level of complexity: Level Zero.

Hello World Example

Adding a for loop that prints out a series of values adds some complexity, if not a lot, but we can call that Level One. Even after adding a loop we haven’t gone beyond linear complexity, where we can draw one path through the application and know what will execute in what order.

Loop Example

An application with a single layer of complexity can do a lot. But it doesn’t exhibit emergent behavior. But the moment you have an application that has a loop that’s doing work and asynchonous events that change global state, you can end up with more complexity.

Event Example

The fact that events can modify global state is where the complexity comes from, by the way. This is the sweet spot for so-called “pure functional” approaches to design, for precisely the reason that pure functional prevents you from modifying globals. The problem is that sometimes it’s hard to learn how to decompose problems into pure-functional designs, so the learning curve can be pretty steep. It’s a tradeoff: It’s harder to learn the skill, but it reduces the complexity of the resulting program, making it accessible to developers who can’t handle as much complexity.

That said, some tasks don’t decompose well at all, or the mapping onto functional approaches actually adds enough overhead that the code can be harder to understand than if you took the traditional imperative approach. And there are some algorithms that are innately complex, where using functional approaches doesn’t save you anything at all, because even the functional approach will require you to understand the complexity.

When you get to the second degree of complexity, you need to not only understand the basics, you need to be able to hold in your brain a second layer of abstraction and/or complexity. Another example of second degree complexity is the ability to understand pointers in C or assembly language. I’ve worked with people who can handle “first degree” tasks without batting an eye, but who can seem to barely wrap their head around pointers.

Another example of second degree complexity is recursion. I don’t mean understanding the definition of recursion, but full and deep understanding of how to write a non-trivial recursive algorithm. 3 This is true for functional languages as well; pure functional is no panacea.

Additional degrees of complexity occur when various aspects of a program interact in a non-linear manner, or when you’re manipulating or processing multiple data sources in complex permutations and combinations of ways. Adding more state to a program can increase its complexity, for instance.

As nothing in programming is quite so simple, these quantum “degree” levels are really rough estimates. And developers can probably manipulate different degrees with different levels of skill – a first degree developer who has just started coding will be slower and less precise in their code output than a more experienced first degree developer.

Complexity and the Front End

Even though frontend development is event-based, I’m going to say right now that basic frontend development is first degree complexity. Many aspects of front end development are easy to understand. Junior developers often start there. When you are mostly manipulating HTML and CSS, you can see the results instantly. Especially in old-school static pages or even JQuery-based pages, development rarely ever exceeded a single layer of complexity. And places where it does get more complex are exactly the places where problems surface.

But with frontend frameworks like React, Angular, and Vue.js, you can write an entire application entirely in frontend code. Some of that development will exceed first degree complexity. Think for a minute about the Gmail interface, for instance. Lots of real time interaction. Lots of drag and drop. A sophisticated editor that’s entirely custom designed (not just a drop-in component). That’s probably a notch above most back end work in complexity, and overall has a number of operations that reach second degree complexity or beyond. Google Sheets is yet another step up in complexity.

Even with those advanced frameworks and projects, though, most frontend development remains firmly in the first-degree realm. It’s important work, and I never disparage frontend developers. And the fact is that there’s a need for better frontend developers. Just look at all the web sites out there full of cruft and bogged down by loading 30 libraries they don’t need, with no optimization at all, and that take 20 seconds or more until they’re done rendering. That’s what happens when all the good programmers abandon the frontend.

Complexity and the Back End

Not all backend development is above first-degree complexity, either. Basic CRUD backend work is solidly first degree. It’s so simple, in fact, that you can automate it entirely away. 4

But a lot of the data manipulation that occurs on the backend does make it into the second-degree realm. And thinking in terms of security and potential ways to hack a backend definitely benefit from having a second degree or higher ability.

Complexity and Development Velocity

In the 1970s, Fred Brooks wrote The Mythical Man Month. In it he suggested that the best developers he measured produced about 10x as much code as a “mediocre” developer, and the code was of higher quality.

I claim to be one of those so-called 10x developers (though I also talk about how we’re all 10x developers). When I can work on second and higher degree complexity algorithms, I can often write them out at basically the speed I can type. Yet it’s my experience that working on frontend code, I am basically no faster than any other experienced frontend developer.

Frontend development is kryptonite for 10x developers.

So anyone who is 10x will sense this, and will want to get away from (simple) frontend development. I still learn frontend frameworks and work with frontend developers, but I find that my time is much higher leverage in dealing with more complex algorithms, because that’s where other developers tend to take 10x as much time as I do.

Another twist is the fact that single-page frontend apps can actually reach the complexity of a full application, with all the innate complexity that implies. Instead of doing one simple thing in response to an event, you might be changing global state and switching pages around, and the additional layers of complexity can stump a “level one” developer.

Complexity and Impostor Syndrome

I’m going to theorize that almost all professional developers of at least median skill can fully handle one degree of complexity, and that a large percentage of developers who experience impostor syndrome are attempting to work beyond their complexity degree comfort zone.

For me, there are tasks that I know how to complete, and there are tasks that I could attack with various heuristics, but there aren’t many tasks that I’m not sure I can complete. I just don’t suffer from impostor syndrome. My hypothesis is that I just understand enough of how I will accomplish any coding task that I don’t need to doubt that I’m capable of finishing it. I think my own capacity is somewhere around third or fourth degree, so most programming tasks come pretty easily to me.

Why Backend Developers are Jerks

Frontend development, despite being first degree in complexity, is hard. It’s a lot of work. Many backend developers run away from it and work on backend development that’s devoid of designer input and arbitrary UI decisions that make your life harder. And different developers have different strengths and interests. A more artistically-oriented developer may enjoy working on frontend, despite the challenges, even if they have the ability to work on more complex backend data manipulation and security.

So why do backend developers keep making frontend developers feel bad, when frontend can actually be more difficult than backend?

Cognitive dissonance.

They don’t want to think they are avoiding hard work, so they come up with elaborate reasons why backend is “better.” Better is a value judgment, and it’s a shortsighted one considering that any product eventually needs a strong user interface, and you won’t achieve that without a solid frontend developer.

There is also the seed of truth that some backend development skills require a higher complexity level to be able to handle well, and developers that can handle those tasks with grace may like to feel “better” than those who can’t. Some people simply feel the need to put others down to validate themselves. But it’s also true that some frontend applications are more complex than the median backend task, so it’s not even strictly true that backend is more complex than frontend.

And it’s stupid to call one kind of development better than another when both are equally necessary. Yes, for me, I prefer backend development because it’s a better match for my personal skills. But a frontend developer who is really good at frontend development may have similar skills in that domain. And maybe there are even 10x frontend developers; given how slow I am when I work on frontend code, there’s certainly a lot of potential for someone to be faster.

Frontend requires specialized skills and knowledge. Actual user experience design takes even more skill and knowledge. Backend developers need to remember that. It may be true that advanced backend code is beyond some frontend developers, but the same can be said of advanced frontend code and some backend developers. So let’s all just work together in peace and cut out these competitive “My Domain Is Better Than Yours” matches, OK?

Comments