Front-end vs back-end

I recently finished Mindstorms, by Seymour Papert. I thoroughly enjoyed the book and felt that many of the arguments put forth resonated with my experience programming, my learning process, and my outlook on education. This post is not a review or summary of the book or my thoughts on it. Papert's opinions on societal views of math got me thinking about certain characterizations of software development, namely the dichotomy between front-end and back-end development. I wanted to share these reflections here.

Grammatical note: I use "front-end" as a modifier (e.g. front-end developer) and "frontend" to refer to a place in a system (e.g. application frontend). One can liken this to "e-mail" (verb) and "email" (noun); however, many people just use the latter term for both meanings these days. The same can be said of "frontend", but I decided to use both terms in this post to distinguish between the adjective and noun.

Papert talks at length about "Mathophobia", a cultural fear of mathematics. Math is seen by, and taught to many people as a complicated subject. This presentation alienates many people from math early on in their education. It leaves them feeling as if math is something far removed from them, which they can only hope to comprehend, as opposed to something all around them, to engage with. Perhaps they arrive at the conclusion that they're not a "math person"; math doesn't have a place in their life and is best left to the mathematicians.

Papert thinks this perspective is largely the symptom of how math is taught (e.g. rote learning and repetition). Through the course of the book, he describes how children can learn mathematics a different way, in interactive, computer "microworlds" facilitated by the LOGO programming environment. Through play and experimentation in these microworlds, children discover mathematical properties by programming a turtle to move, draw shapes, etc. They receive guidance from teachers who, rather than telling them something is correct, walk the path with them (and their turtle).

After reading Papert's take on Mathophobia and how math education has reinforced this perspective, I thought about whether similar views exist in software development and what might reinforce them. "Front-end" and "back-end" development, two terms often used in juxtaposition to one another, came to mind. I asked myself, how would I define these terms which I see on an almost hourly basis- in documentation, blog posts, job applications, you name it. Perhaps I've avoided a precise definition, despite the preponderance of these terms, by convincing myself that a sufficient understanding only requires that I be able to point to something and say "that's on the frontend" or "that's on the backend".

A common distinction I've seen: front-end development includes everything that's visible to the user when they're interacting with a website or application and back-end development consists of everything that's not visible. This definition falls short because there are many examples of invisible things that take place in, what I would consider, the frontend. For instance, sounds generated through the Web Audio API are not visible to the user, barring some interface or visual representation. However, it seems a bit of a stretch to consider this functionality back-end domain when it occurs in the user's browser. API requests, state management, realtime-communication over websockets all leverage invisible, client-side functionality that may or may not have visual ramifications.

A better definition might be: front-end development includes everything that happens on the user's device when they're interacting with a website or application and back-end development consists of everything that happens elsewhere. This definition lacks clear demarcation though; what device behavior falls under front-end development? Surely there's a lot happening on the operating system level that's necessary for the proper functioning of the application frontend but not considered part of that domain. So maybe we ammend everything on the user's machine to some things? I'm still not sure how and where to draw the lines that separate those some things from the other things.

We encounter similar classification issues on the backend. Where do you draw the line between the application backend and non-backend (it's not the frontend because it's not on the user's device)! Does the backend only consist of behavior deriving from code the developer(s) wrote? What's the heuristic for determining exactly what behavior derives from the application?

The second definition, while far from perfect, doesn't offend my sensibilities as much as the former. Trying to formulate this definition and answer the litany of follow-up questions make me wonder how helpful these terms, front-end and back-end, are in certain cases and how they might shape our views and behavior.

Over the past 5 years, I've characterized myself as a back-end developer who occasionally dabbles on the frontend. These areas of software development thus become professional identities. Jobs hire front-end developers, back-end developers, or people who can do both (full-stack). Candidates label themselves as such since it facilitates alignment between their supposed interests, skill sets, and the hiring needs of companies. If a front-end developer sees a back-end developer job posting, they'll likely scroll to the next. When they come across a front-end position, they'll have greater assurance the role is in their wheelhouse.

While the terms are collectively helpful in this regard, I believe they can be unhelpful to the individual. Similar to how the belief, "I'm not a math person", can be unhelpful in dissuading one from learning more about mathematics or engaging with it in different ways. What could have been "I didn't like learning math the way it was taught to me" or "the method of instruction didn't resonate with me" is taken as some indication that the individual is bad at math and shouldn't pursue it further.

Since I pegged myself as a back-end developer, I didn't put much time or effort into learning about front-end development. I had already made up my mind that front-end development wasn't my domain. It wasn't as interesting to me and I didn't have the eye or the patience to get webpages looking the way I wanted them to look.

Over the past month or so, I've been building a few websites and doing a fair amount of front-end development. I've found that I not only enjoy many aspects of it but there are different ways for me to creatively approach the parts of it that intrigue me. This includes but extends beyond "getting webpages to look a certain way". What previously sounded like a problem that sat squarely in the realm of front-end developers and designers, now presents itself as a new and compelling task with many interesting sub-tasks. I intend to discuss these at greater length in a subsequent post.

I had already decided I was uninterested in something I hadn't engaged with in different ways. When I happened to engage with in a different way, it gained a new appeal and sparked a fascination that wasn't there before.

I think the terms, front-end and back-end, are useful and expeditive in many circumstances. In others, they can be unclear, perhaps even muddying. When you say "front-end work", what kind of front-end work are you talking about? There are many kinds! Not to mention, you'll sometimes see patterns implemented on the frontend and backend (e.g. state machines), so these areas aren't completely dissimilar. When you say "full-stack", does that include knowledge of the operating system? I've found it often doesn't.

Finally, these terms can be unhelpful when they're given as immediate answers to questions we think we should be asking. What kind of software engineer are you? What kind of software development do you (want to) do? Front-end, back-end, or full-stack (pick one)? Again, the terms aren't intrinsically unhelpful. They are unhelpful in the context of these questions that prompt them and perhaps overlook other details.

These loaded questions come up a lot in job applications and interviews. I think there are more illuminating questions that can be asked by the interviewer or emphasized by the candidate. What problems do you want to work on? What things do you want to build? What kind of environment do you find most engaging? The list goes on, but a common thread between these kinds of questions is they focus on the nature and context of the work instead of its general classification.

I'm not advocating we drop front-end and back-end from the software engineer lexicon (as if). However, these terms and my association with them has materially affected my career path and personal learning journey. In other words, they have formed a dominant decision-making framework. "What do I want to do and how do I convey this to my manager?" When confronted by this question, it's convenient to answer in terms of front-end and back-end but, in doing so, easy to ignore specifics. As a result, I find myself working under an umbrella that should cover my interest but invariably doesn't.

Other engineers no doubt have a different association with these terms than I have. Still, I would be surprised to learn that these associations have in no way affected their professional and personal paths.

Drill down into the details. Speaking terms that are met with head nods from all parties doesn't necessarily mean a proper, mutual understanding has been reached.

Oh, and do read Mindstorms if you're at all interested in education theory, learning methodologies, and/or programming :)