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!