I've seen this argument many times, but as someone else who has done a lot of both, I've never really understood it. It's just programming, like any other software project. Sure, you might use different languages and each might have its own tool chain, but unless you're using radically different languages or tools in the two cases, those are probably superficial differences. Most experienced professional developers can probably work in several languages, and you pick up a new tool chain in days if you need to. But the fundamentals of programming are still much the same whatever you're building. Certainly different applications also have different knowledge and skills -- writing a business automation tool is likely to be quite a different experience to writing a control system for ABS in a car, say -- but for a typical web app, the front and back ends are usually going to overlap a lot in this respect.

As I mentioned in another comment, the huge exception to this is junior roles, because at that stage in someone's career they probably haven't gained much diversity of experience yet and you probably should start by focussing on one particular aspect. So if your project team consists of many relatively junior people and not so many seniors with broader experience, sure, you're going to put most people specifically on front-end or back-end, at least to start with.

I think the problem here, though, is trying to overgeneralize. I've worked on projects where you want to split things vertically (apps / plugins / etc. which have isolated functionality and handle back+front end), and horizontally (front-end / back-end split).

That comes back to what the system does, as well as the make-up of the team (full stack developers will do different things well than teams of specialists).

The danger comes in when you try to mix pieces of the two. I had a system with a simple, elegant architecture with a vertical abstraction. A junior engineering team came in, who had only seen horizontal abstractions. They didn't understand it. They didn't get functional code either (they had only seen OO). They decided it was all very confusing spaghetti code, broke all the vertical abstractions, put in half-done horizontal splits, and the system became unmaintainable.... You can blame that on junior team from the high-level descriptions, but the deeper problem for that system was mixing abstractions and programming models.

Yes, I have seen "senior engineers" who tend to be more biased in doing back-end or front-end work, and in some cases, those same people actually prefer one or the other, too, but to expect them to be ABLE to work efficiently up, down, and around the entire stack vertically and horizontally is not at all unreasonable. And yes, you have to know "a lot" to get there but that's what years and years of experience gives you if you have successfully built working software for a long time.

I'd expect senior folks to be able to not get confused by an HTML tag, of course, and to be able to build a good end-to-end system, but the really good front-end devs I've worked with think through really subtle details of interaction design -- how long a slider slides, subtle changes to colors during mouse-overs and other actions, and just thousands of details that make a world of difference in how the product feels.

Conversely, anyone who's coded for more than a few years should be able to do a database query. But a really senior back-end dev will be able to think through how to, for example, make an architecture capable of streaming through thousands of events per second with 100ms latency, how to shard a system to work in data centers around the world to maintain data coherence while minimizing user latency, or hundreds of similar complex algorithmic tasks.

There are plenty of full stack people who can make an app responsive, have a coherent SASS/CSS framework, and efficiently organize a typical database (I can do all of that too, for that matter), but doing either side well takes many years of experience on its own.

There are times to go with a generalist. And there are times to go with a specialist.

I've worked with really good senior engineers, but part of what made them good was that they /weren't/ getting involved with the nitty gritty of centering a div or making something work cross-browser. This was the domain of the front-end-only masochists.

I sort of consider myself a full-stack developer, but I'm quite aware of the lack of 'stuff I should just know' in all the stuff involved with that (devops, front-end UI/UX, front-end 'making it looks right' CSS/HTML, back-end DB design, back-end application structure, etc.)

My 'broad' knowledge is perfect for many of my clients, but I wouldn't sell (or guarantee quality) to anyone demanding proper expertise in most of these particular areas. I'll probably fuck up something setting up the Postgres db that only becomes apparent under high load. I might forget some crucial element about hardening the server(s). My JS knowledge is probably already out of date because the last time I did serious JS development it was Webpack with React (without hooks) and mostly no css-in-js. I'd probably still pick sass/scss for comfort. And webworkers are fascinating but I never got to it.

Now I'm pretty smart, and as an autist I spend what my therapist would consider potentially an unhealthy amount of time reading up on ALL of this stuff. My work is my hobby. As I'm nearing my forties I'm definitely giving that some thought, but I digress.

My point is that except for a few unusually gifted people, I find it truly hard to believe that it's possible to be a full-stack web developer who is actually /skilled/ at all parts of the stack. There's way too much domain-specific knowledge (that is constantly changing and evolving) for a normal human to be able to stay on top of, let alone be an expert in.

(again, with some incredibly impressive exceptions).

When I was a junior programmer doing my first job, I knew exactly how to check the length of a list in the language I was using, and hundreds of other everyday little details like that, without needing to look anything up. But back then, I was only using one language, and I was mostly doing basic implementation work all day.

Fast forward a few decades, and I can't always remember those little details any more. Sometimes I get them wrong or have to look them up. So am I a less competent programmer than my junior self?

Of course not. It's easier to confuse details like that when you've seen subtly different versions of them in each of the dozen or more languages you've programmed in professionally. But is it really important to remember many variations of each of a thousand little programming tasks, when I can look them up in moments if I haven't used them for a while and then need them? Would that really be a better use of my mental abilities than understanding what makes a good abstraction or how to evolve a useful software architecture or how to develop a robust testing strategy or how to quickly recognise a missing edge case that could lead to a bug or how to design out that edge case in the first place or how to find or build tools to help?

The reality is that Me 2020 Edition would outclass Me Junior Edition by a huge margin in any skill that matters: productivity, code quality, communicating effectively, anything. The extra depth of understanding and breadth of knowledge far outweighs the trivial effort of looking up a detail now and then if I'm starting to work on something with a language or library or tool I haven't used for a while. Those little details are superficial, and it's the more substantial changes that really dictate how effective I am.

In fact, I'd argue that a pretty good benchmark of someone's level as a developer (and probably a lot of other things, too) is where their threshold for something being a superficial detail lies. What areas of understanding are so simple to that developer that they don't need to know or remember them, they can just pick them up quickly and reliably on demand whenever they need them? To a junior front-end developer, that might be things like learning the DOM elements for semantic markup. To a more experienced developer, it might be remembering how `this` works in JavaScript. To a more experienced developer still, it might be entire libraries and frameworks: it doesn't matter much whether your project using Angular or React or Vue or TheNextOne if they can just pick up whichever it is and be using it fluently within hours anyway even if they've never touched it before.

Of course someone might have both front-end programming and user interface design responsibilities on the same project, but I would no more assume that than I would assume the same person would have both front- and back-end programming roles, and the skills for the latter combination are much more closely related. My point here is just that everyone has a different mix of skills and trying to pigeonhole people or restrict anything to only certain combinations is not necessarily either realistic or helpful.

I don't think you can break things up like this. Good developers can work one, sometimes two layers in each direction. A back-end developer who can't design a database is a lousy back-end developer. A front-end developer who implements user interfaces handed over from a designer is a lousy front-end developer.

Pigeonholing people isn't helpful, but it is helpful to

(1) Recognize that there are distinct, deep skill sets

(2) Known when and how to organize teams and software. Some benefit from vertical splits, and some from horizontal. There aren't universals here.

I'm just arguing, following the spirit of the article we're discussing here, that there is no inherent reason the same person can't have both front-end and back-end programming skills, and can't perform both of those functions proficiently.

Of course there are many non-programming skills involved as well, but I don't accept your premise that a back-end developer should necessarily know how to design a database or that a front-end developer should necessarily know how to do all the design work for a UI. Plenty of web applications aren't backed by a database at all, so the first claim is clearly not universally true. Plenty of organisations have people dedicated to their design and branding, and that might be shared across all media, so again it's clearly not always the case that someone doing front-end programming must also be able to handle those aspects in order to be competent or useful.

Given that front- and back-end programming are much closer in the skills required than either is to user interface design, graphic design, creating digital art, understanding accessibility and usability issues, designing and maintaining an efficient database or system administration, among other relevant skill sets, it seems entirely reasonable to me that a project might want to have the same team responsible for all programming, and have different people doing things like the UI design and the database and system administration. Another team might have people with different mixes of skills and might use them more along the lines you described. All projects and all project teams are different.

"Of course there are many non-programming skills involved as well, but I don't accept your premise that a __junior__ back-end developer should necessarily know how to design a database or that a __junior__ front-end developer should necessarily know how to do all the design work for a UI."

I agree with this for a junior developer working on a simple project:

"Plenty of organisations have people dedicated to their design and branding, and that might be shared across all media, so again it's clearly not always the case that someone doing front-end programming must also be able to handle those aspects in order to be competent or useful."

But a senior developer working on a complex project should be able to work a couple of levels up and down wherever they are in the stack:

* If building a complex web app (e.g. Google Docs an online game, etc.), there isn't a clear separation here.

* On simpler projects, even just implementing corporate branding from a designer, little pieces of cross-cutting work come up.

* Even where there isn't cross-cutting work, being able to leverage synergies requires people to be familiar with both domains. If a designer comes with a design, and the engineer can modify it to be 90% as good (or sometimes 110% as good) for 50% of the effort, that's a conversation a senior front-end developer should be able to hold with the designer on relatively level ground (e.g. know the jargon, constraints, modes of thought, etc.).

There are jobs for full-stack engineers, and I agree with your current comment ("it seems entirely reasonable to me that a project might want to have the same team responsible for all programming"), but that's a few steps divorced from your original claim ("'ve seen this argument many times ... I've never really understood it. It's just programming, like any other software project. Sure, you might use different languages and each might have its own tool chain, but unless you're using radically different languages or tools in the two cases, those are probably superficial differences.") Since you said you never understood this argument, I thought I would elucidate.

I've worked with really good front-end people, and really good back-end people, and it's an entirely different skillsets. Beyond the (relatively junior) skill of being able to write code and understand a "for" loop, the more senior level stuff goes off in two deep and very different directions.

It's definitely different for junior positions, when someone hasn't had enough time to build up a breadth of experience yet and getting to a useful depth of understanding in at least one area is more important.

FWIW, I also think it's different at elite levels. If you actually are the person who had to, say, develop a data storage system for Facebook at a scale no-one had ever done before, you're probably a database specialist with skills and knowledge in that area far beyond any generalist's. But these positions are rare, as is the need to have someone with that level of specialist skills on your team.

For seniors at a high but not exceptional level -- that is, the most senior people you're likely to find in most organisations doing web development -- it's definitely normal for someone to develop both breadth and depth of skill and understanding throughout their career. No doubt many front-end developers (in the programming sense) do also have some level of ability with design work, and many back-end developers (ditto) do also have some level of ability with database design. There's certainly nothing wrong with that, and it's certainly helpful to have that level of understanding whether it's to use the skills directly or just to communicate more effectively with a colleague who has responsibility for that aspect of the work.

The only area where perhaps we would slightly disagree is in the idea that being a senior front-end or back-end developer necessarily requires advanced skills in specific related areas as well. The industry is huge and the number of related skills that are potentially useful is large, and which ones are useful for a particular person playing a particular role can vary widely.

For example, I've met someone who is very capable when it comes to writing server-side code yet who as far as I know has never touched a database in well over a decade. Their speciality is interfaces for network-connected devices. While a recent project for them might well have had a snazzy SPA on the front-end and a super-dooper GraphQL API running server-side, what is behind that API is probably nothing like a SQL or NoSQL database at all. On the other hand, they probably know a lot more about calling local C APIs from server-side languages like JS or Python than most. I would certainly call that person a senior level developer -- I doubt there are more than a few thousand people in the entire world with the combination of skills and experience they have, maybe not even that many -- but it seems they would not clear the bar for you because they lack significant database expertise?

At least in companies I've been, someone who can code but cannot design a database, that's a junior backend position, no questions asked. Likewise, someone who can code, but can't do UI/UX design work, that's a junior design position, no questions asked.

I think one issue is that if someone has depth in algorithms, computer architectures, and similar, becoming a competent DBA isn't too much work. SQL isn't rocket science, and neither is how databases are organized. If you don't understand B-trees, have background in what sorts of operations to nanoseconds, microseconds, or milliseconds, cache hierarchies, and so on, that's a pretty generally-applicable back-end data set, and you can pick up databases in a few months. That's something I'd expect a senior back-end engineer to have done at some point in their career. If not, I'd hire them in a more junior role, and then advance them quickly. Coincidentally, with that skillset, you can also design something new, like that Facebook back-end. That's also what FAANG interviews try to screen for, although they've had the narrowing effect that people try to master FAANG interview questions, without necessarily that depth.

In line with that, I also don't think positions like the Facebook one you described are rare. A lot of positions I've seen require that level of background. I also think you underestimate the number of people at that level.

It doesn't matter if the underlying programming fundamentals are the same because the human brain still has preferences on what it wants to work on. The mistake is applying some "umbrella term" (i.e. "programming") for an activity and thinking that will automatically make all sub categories attract the same interest level. It doesn't work that way.

This same phenomenon happens in other intellectual activities such as mathematics, writing, painting, etc:

One mathematician might prefer to study algebraic topology while another mathematician prefers to work on number theory. Thus, saying, "I don't get it -- it's all _math_ so why should one person have more interest in one branch vs another?!?" ... does not remove the preference.

One writer may prefer to write political analysis essays and never writes fiction -- but another writer prefers to write fiction and never opinion pieces on current events. Therefore, saying, "I don't get the fiction/non-fiction dichotomy because both activities are just the same task of manipulating _words_?!?" ... doesn't make a preferred interest disappear. Yes, some authors write both fiction and non-fiction but the existence of them still doesn't remove the preference of other authors who specialize in just one. Even within sub-category of fiction, you get sub-specialization of "mystery novels" instead of "romance novels".

Likewise, saying "painting is painting" does not change the fact that an artist might prefer to always paint landscapes and never horses or people.

>It is becoming clear to me that much of the perceived difference of opinion here is just because of terminology. I was thinking of "development" as meaning specifically the programming side of things. [...] and trying to pigeonhole people or restrict anything to only certain combinations is not necessarily either realistic or helpful.

Some people naturally just want to pigeonhole themselves. I've done frontend work on old DOS machines (text-based UI), raw Win32 API, VB/C# GUI forms, Javascript/HTML -- and I don't like any of it. I prefer to program the backend algorithms. Yes, coding a loop to "iterate through all window controls to enlarge them by 10% in the GUI" has something in common with "iterate through all nodes of a graph to optimize a path" ... because they're both "loops" ... but they have very different levels of intellectual satisfaction. I won't argue with you if you feel that they should feel exactly the same because they're both "programming" but I can't help it that I don't derive the same enjoyment.

If I was employed by Google, I'd enjoy working on the backend ranking algorithms. To a lesser degree, I'd be ok with working on the spider crawlers. But I'd quit if they assigned me to work on the web frontend where users type in queries. But I'm also glad there are developers who prefer to work on the frontend instead of the backend because it allows people like me to stay with my preference.

My objection is to the common arguments that front-end and back-end dev are fundamentally different on a technical level and/or that they should be done by different people or that the same person can't be good at both. Compared to other programming fields, such as traditional desktop applications or embedded real time systems, front- and back-end on the web are quite similar in the skills and technologies they use, and I don't think drawing a clear line between them is very helpful (that is, I agree with the original article that started this discussion on this point).

back-end: perhaps less, uh, dynamic, but: db architecture, SQL, much more CLI/linuxy stuff, server security, API design, version control, deployment, containers, ansible, load-balancing, nginx config...

The difference not primarily being a sort of 'core' skillset, but rather purely learning and remembering the intricacies of all these things. That's too much for most people.

EDIT: I find that there's a definite sense of 'progress' or 'leveling-up' in all these areas put together. I get better at finding the right documentation, finding the best places to go for help, figuring out what the foot-guns are as well as distinguishing fads from truly worthwhile developments.

I get better at 'intuiting' where I might need to take a deep dive to truly understand things, or where I might need to consult an expert.

It gets easier to take lessons from one area and apply them to another.

But ultimately there's still so much 'domain knowledge', much of it shifting and changing, even if just because the client cares about it, that it's hard to keep up in both the front- and back-end world. And even if that shouldn't have to be necessary, in practice it often is.

For example, I've been doing more back-end stuff for the past few years. I keep an eye on what's happing in the js/React world as that is what I mostly did before. I struggle with setting up a new project because apparently Webpack changed, apparently we do CSS in js now, and apparently hooks are the hot new thing. I have a /lot/ of time to study all of this, but unless I actually work on a project that uses all this fancy new stuff, it doesn't really properly become part of my skillset.

The same goes for backend stuff. I can set up proper Linux servers 'in anger', but apparently now it's pretty useful to know how to use Amazon/Moft serverless stuff and I just never got to that. And I'm single and almost permanently reading up on all this fancy new stuff!

At the very top of each field, sure, there will always be those specialists who live and breathe that subject and can do the things no-one else can, but most people will never achieve such proficiency in any field during their career and most businesses will never hire anyone on that level, so I'm not sure it is going to generate much insight to talk about extreme cases. For anything below elite levels, you certainly can have the same person with expert skills in both front- and back-end dev, or in back-end dev and DB admin, or in front-end dev and UI design, or just about any other combination of relevant skills.

The opinion I've adopted from my designer friends, though, is that once you have a designer in-house and the site's basic design has been established, what is more important is that the developers notice and care about details. That's not something I would consider a frontend vs backend developer trait, just more of a general engineering attitude. Do you notice that the padding here doesn't match up, do you question why this form is laid out differently from all the other ones, how does this flow from page to page work, do you go find a designer and work with them until it's right.

I would posit that the same person who cares that the UI is consistent and makes sense would also be pointing out why is our code formatting all over the place, why we use different libraries in different places to do the same thing, why our patterns and architecture is inconsistent. If you just copy/paste in random UI pieces and call it done, then you're probably also copy/pasting in random stackoverflow snippets on the backend and just recompiling until the tests pass.

If you're building a relatively simple UI, using common features like buttons and text boxes and maybe some simple charts, you might well do what has been mentioned in this thread. You can identify reusable pieces that the designers can use to define layouts and specify styling and that the programmers can use to implement those things in code. This is an easy method of UI design and implementation, and often it is all you need.

If you're building something more challenging -- a rich document editor, a game, an interactive 3D visualisation of a complicated data set, basically anything that isn't just a combination of standard controls and UI patterns -- then the main part in your UI might not fit that component model very well at all. Now you're going to have to approach both the UI design and the programming from a different direction, just as you would in desktop, mobile or embedded software. This is harder, because you're moving away from patterns and tools that are well understood and readily available, and instead you're building something original. However, it's also much more flexible for the same reason, and sometimes that's what you need.

Even in the latter case, you will often need standard features in your UI that can be designed and built as individual components as well. There's no rule that says you can't have a hybrid with both reusable components for the simpler, recurring features and then one or more features that are more sophisticated.

I think the real distinction here is between programming and interface design, which are also separate skills that any given person might or might not have, but that is true whether they happen be coding for the front or the back end at the time.

The webserver code that renders web pages definitely belongs to frontend dev.

Maybe this explains the difference in our perspectives. To me, other than perhaps the very first data collection where maybe the source is only accessible from the back end, whether things like statistical analysis or rendering of the results happen on the front or the back end is something you will decide on its merits for each project, not something that is necessarily tied to the mechanical programming skills or libraries on one suffer or the other.

For example, say you're working on a web app that controls some device. On the back end, you might not be talking to a database, at least not in the sense of SQL or NoSQL we usually mean in the context of web apps. Maybe instead you're integrating with some internal API that controls the hardware.

In that situation, maybe you're exposing that internal functionality to the front-end web app via some HTTP-based API, which might be substantial but is mostly a wrapper for the internal functionality with things like security incorporated. Who should be responsible for that middle layer? Do you have a separate person/team whose responsibility is just to bridge between the front-end code and the internal API? Should the person/team responsible for the front-end also be responsible for the HTTP-based API it talks to, and hand off to some other person/team who work on the hardware-facing code behind the internal API? Should the internal team also be responsible for the HTTP-based API?

I don't think there are any "right" answers in a situation like this. You probably have people with front-end skills. You probably have people with low-level hardware hacking skills. Some or all of those people might also have back-end skills. You've certainly got three distinct but related areas here. Depending on the project and the mix of people you have available, there are several potential ways to handle this situation that might be effective.

Ah, yes. Quite.

User-facing applications just have different goals from an application consumed via API. Practically when you split up a system into a client facing application and an API application, from my experience and reasoning, it's always been because it results in a far easier to manage development process.

The simpler you can make your system the less likely it will be to fail by any measure. So breaking systems up into smaller systems is just easier and simpler. One such division that is really easy is the backend and frontend.

Model View Controller type frameworks are a great practical example of why breaking systems up makes them much easier to construct.

Or you have a horrid kludge, and regardless of how great your frontend team is, you are now stuck with a terrible mess.