I'm a full-stack engineer turned front-end engineer at my current role... let's see > First, "front-end" is chalk-full of people who don't know what they're do

I'm a full-stack engineer turned front-end engineer at my current role... let's see > First, "front-end" is chalk-full of people who don't know what they're doing or talking about I've seen no shortage of this in backend roles, and in any technical role there's been no hesitation to let go of underperforming developers. If there is you have a culture problem > The front-end is the most visible part of the product even though it is often the smallest piece of the product so business leaders, who have little technical experience, will often put the front-end team in a position of de-facto authority over the product or at least give them out-sized input From previous job experience I agree with this. One role where I was the backend developer the project failed because the UI was prioritized to the extent that the API was fully fleshed out, but the infrastructure and user migration plan was nonexistent. But it's a leadership failure, not a technical one. I'd also caution against seeing the front-end team as "de-facto authority" to business leaders. They're more visible to the business so they have more frequent communications, but I've learned that it's naive to think them as having _any_ authority. If anything I now spend most of my time fighting against impractical requirements that would impede a successful, timely product launch (sometimes at the expense of launching at all), and business leaders are deaf to it. It's an exercise in frustration if anything. > The stereotype that emerges is that front-end teams often get more resources then they need, get to rewrite the front-end once a year using the front-end framework du jour The team I'm on is on its 3rd or 4th front-end rewrite of the same application. You say 'framework du jour', I say "technology that has been abandoned by the vendor, is not meaningfully cross-platform, is too difficult to hire for". I've not been involved in the previous 3 rewrites, but I can tell you the company would lose the business if the rewrites weren't done. When technology at large moves on, front-end developers are rarely to blame > Two thirds of our users interactions (as evidenced by our server logs) were through the CLI that the back-end team maintained and wrote. It's true that depending on the application, a front-end may not even be necessary. But I would say that given a 2/3rd 1/3rd split, it's worth the investment for marketing purposes alone. Unless your salespeople are out there selling CLIs/APIs to clients (which in my experience, even if you're selling APIs, it's rarely the case). > Users often had no idea how to do something on the front-end, because there was so much feature clutter. In my case the feature clutter is likely a business requirement by a team of designers that the front-end developers can't meaningfully influence. I'd love nothing more than to have buttons with meaningful labels instead of implementing a designer's shitty iconography for the Nth time.