4 ms·

I am a "back-end" engineer that could be said to "look down" on front-end development, but the truth is more nuanced than that. I actually think really great f

I am a "back-end" engineer that could be said to "look down" on front-end development, but the truth is more nuanced than that. I actually think really great front-end development, when necessary, is hard to do and the folks who are interested in it and good at it are great Engineers. I also think that good User Experience is what makes money, though this doesn't always mean lots of bells and whistles or even, what is traditionally thought to be, "front-end" development. Unfortunately the barrier to entry is probably lowest in front-end development and so there are a lot of folks, when seeking a career change into software development, naturally gravitate to front-end, when their natural aptitude would probably be better suited to something else in tech, like product manage, devops, or even "back-end" engineering (though I will admit that "back-end" engineers tend to be biased against folks with non-technical degrees/backgrounds). The way I see it this creates a chain of negative causal effects. First, "front-end" is chalk-full of people who don't know what they're doing or talking about. Second, naturally being biased to think that the work they do is valuable and important, "front-end" engineers often advocate for lots of front-end rewrites and Rube-Goldberg-esque front-ends that aren't actually necessary to the success of the product or business. 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. 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, when it is often not necessary to do so and a static website with few interfaces would actually not only be fine, but better. This is a trope that you will commonly find complained about on HN, and my own personal anecdotal experience confirms. I once worked at a company that had a massive back-end; not that VM count is always an indicator, but we had over 1000 large servers running our stack. Our front-end team was half the size of the back-end team and wrote their own CMS at one point. Two thirds of our users interactions (as evidenced by our server logs) were through the CLI that the back-end team maintained and wrote. Users often had no idea how to do something on the front-end, because there was so much feature clutter. My personal opinion is that a lot of products actually don't need as much front-end as they think and that hiring a design firm to come in at the beginning (and then once every two years) and hand off the front-end to a team of back-end engineers to keep up to date with features would probably be fine. Of course, of course, of course there are lots of exceptions to this, and I'm not suggesting a ratio of when this is true, but even if it's 50/50 that does not seem to justify the proliferation and front-end bloat that a lot of us have come to loathe. My two cents.

axaxs 8y ago
Fellow back end engineer, these are exactly my thoughts. In short, it's where most new people with no experience enter, and as a result a ton of questionable code. A great frontend engineer is worth their weight in gold... it's just that so many bad ones exist, the default thought when hearing 'front end engineer' is not a good one.
sngz 8y ago
100% agreed
arenaninja 8y ago
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.

axaxs 8y ago

Fellow back end engineer, these are exactly my thoughts. In short, it's where most new people with no experience enter, and as a result a ton of questionable code. A great frontend engineer is worth their weight in gold... it's just that so many bad ones exist, the default thought when hearing 'front end engineer' is not a good one.

sngz 8y ago

100% agreed

arenaninja 8y ago

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.