> This is the reality of having deep experience in a specific domain.

This seems like it should be true abstractly, but concretely I've never met anyone with deep experience in a specific domain who didn't in the process gain enough experience in other domains to have basic competence in multiple domains. Not necessarily as much as specialists in those domains, but it's practically required to achieve the depths of experience in the domain you think they specialized in.

(Which is not usually the domain they thought they were specializing in.)

This is particularly relevant where there isn't a clean separation of concerns and the involved skills are highly transferable.

Basic competence is just as you stated, basic. If you are BE with basic competence in FE then I would argue you're not a BE/FE. You're a BE who has basic knowledge of how FE work is done.

> As an attempt at an example, if you went to college and got an English minor and a CompSci minor you'd be capable in both areas but you would likely not be as knowledgeable as an English major nor a CompSci major within the respective domain.

I don't think this analogy works, because CompSci and English are pretty unrelated to each other as fields, whereas frontend and backend by definition work together to create a product. That makes a person experienced in both worth more when working on either, because they're more likely to have in mind the entire system when they do design decisions pertaining to their side of the network.

I did say it was an attempt. :)

I need to disagree with you here, I consider myself full stack, but if you were to ask, FE would be my deep experience. And for me this is perfect, I have no problems with any FE work, and the same goes for BE work. Sure, we have BE engineers with very deep experience, but I've never found myself in a position where I couldn't keep up with them. I acknowledge a lack some knowledge in BE, especially when it comes to deeper CompSci domains, but it has never held me back.

But in general, I think this is just a different mindset, I love being able to be independent, and complete a stories from FE to BE. I used to be in a position where I could only do FE work, and it really scared me. I had no clue where critical data was coming from, if something went wrong, I couldn't debug our APIs, I was in the dark constantly. Now if something goes wrong, I can switch over to our backend, debug, write extra test cases to cover the bug and push code. I also understand what BE engineers are talking about, and when designing a new feature, it's much easier to come up with new APIs.

Knowledge about how the other side of the fence works doesn't suddenly make a full-stack engineer. I'm sure if we actually came up with a ratio (80/20 vs 50/50) of work it would provide a clearer understanding about when a person is FE, BE, or FE/BE. Alternatively, we could look at the type of work the individual is doing. For example, in your role are you going to be an architect doing solutions for the back-end?

It’s not just knowledge, I can actually do all the work, and yes, I could design solutions. It’s just that my real deep knowledge would be FE. But I consider myself full stack because I can do both sides without a problem.

In my team I’m just the only FE, so naturally most of that work falls on me. There are months where I only did BE stories.

It's often the case that a company decides to filter down the infinite possibilities of the programming world to a strict subset. What's left can often be a little boring, and that's on purpose.

So in a world where your choices are 1) learn other tech within our toolbox or 2) learn stuff in your domain but outside of the scope of your current work... only one of those is okay to do much of on work time.

All those ES2018 features and CSS variables may be cool things a front-end engineer should be learning, but if we have to support older browsers then I don't get to use any of it.

Until suddenly the requirement to support older browsers is dropped, or you get shifted to another project, and then these ES2018 features would come in handy.

Learning only the stuff that covers your immediate working needs isn't a winning strategy, neither for you nor for the company.

If you are 'learning' stuff open-loop (with no feedback from users or peers), then you are deluding yourself about how much you've actually learned. You're one important but terribly insufficient step above book learning.

No battle plan survives contact with the enemy. There are tons of strategies I know to solve problems that I never use because it confuses other people (and some of them confuse me too when I look at them six months later). That's experience. That's wisdom. You won't find that in a private github repository, and only those who already know what they're looking for will find it in a book.

> If you are 'learning' stuff open-loop (with no feedback from users or peers), then you are deluding yourself about how much you've actually learned. You're one important but terribly insufficient step above book learning.

Book learning ain't bad; in my experience, most of the developers I know would do well if they picked an actual book every now and then. It's not as good as hands-on experience, but still miles ahead of "learning" by StackOverflow-driven development. Experience is an important piece of the puzzle of wisdom, but it's not the whole thing. You need to also have understanding, and reading (and thinking about what you read) is a good way to acquire insight.

WRT. closing the loop, your users and peers aren't the only way to close a loop (and arguably, they can only provide certain kinds of feedback that are very context-specific). Trying things out for yourself is also a good way to close the loop through feedback from reality itself (e.g. whether something works, or how difficult you find it, are such pieces of feedback). On top of that, peer/customer feedback makes no sense for a lot of useful knowledge - for instance the new ES2018 and CSS features you've mentioned upthread.

I disagree, there is a point when having too much 'deep experience' in either BE or FE (usually BE) becomes counter-productive to performing useful work.

Then why do Google (and others) hire specifically for FE and BE roles?

I have no opinion on the issue being discussed, but the fact that Google does things a particular way is not evidence that that way is correct. It is entirely possible that Google would be better off hiring full-stack developers.

I double majored in English and Economics and consider myself an amazing full stack developer.

"But in practice, and accounting for exceptions..."