Hacker News new | ask | show | jobs
by Matthias247 1455 days ago
There seems an assumption in the article, that frontend/app development is less technical than backend development, and therefore not eligible for promotions. E.g.

> And honestly speaking, the skillset you develop are of lesser value for principal / staff software engineer positions in most companies.

As a principal engineer with experience in all of those areas, I don't think it's true. I actually think that the average backend development role is far less technical than app development. Most people there are just gluing together a database and an application framework on top of a webserver to build mostly stateless services. There's far less interactivity on the frontend, less concerns about multithreading, etc - which makes it actually easier. Same as on the frontend, the world's favorite framework also changes over the years and now some people use Go and Rust instead of Java servlets.

Both roles will have options to go deeper and wider. E.g. depth-wise, on the backend side some people might write their own webservers and databases, which requires an extensive amount of domain knowledge. On the frontend, some engineers might build libraries for realtime audio or videoprocessing. All roles will benefit from knowledge about debugging (and potentially debugging remotely and at scale).

There's also plenty of things to explore in terms of breadth. Backend developers usually need to understand the how dozens of backened services interact with each other, (continuos) deployment, metrics, alarming, operations, failure modes of distributed systems, etc. A lot of that also makes sense for Frontend/Apps.

And both sides obviously need to understand how the complete system works, and how it fulfills actual customer and business needs. The skillset for a staff/principal role is a lot about the latter: Helping the business and the team, by identifying gaps in and improvements for the product, and helping other engineers to implement it. It will in most cases be a wide role, with a bit more depth in one or the other area - and I would assume that can be either frontend, backend, security, or even something completely different. But it will almost never be a role which is purely about contributing code towards a small subset of the system.

1 comments

> There's far less interactivity [than] on the frontend, less concerns about multithreading, etc

This really depends on a particular project a lot. Sometimes (often?) it's backend that does all the actual work, while frontend is just a glue for the user.

>just a glue for the user.

This is fairly contradictory. The reason gluing APIs together can be easy is because APIs are (usually) documented, mostly deterministic, have a limited set of operations, are designed to be glued to, and various other complexity-mitigating characteristics that don't apply to humans. "Gluing" with a human is intrinsically complex, so the way we use the word "glue" doesn't really apply.

Some UIs absolutely are simple enough to be considered glues for underlying backend.