Using “Frontend” or “Backend” to describe the Engineering you like (2020) | Hacker News Reader

Using “Frontend” or “Backend” to describe the Engineering you like (2020)

michellelim.org

134 pointsloa_in_97 comments

> “Product-first” engineers are obsessed with using code to solve a user problem and they see code as just a means to an end.

> “Code-first” engineers are obsessed with the abstractions, architecture, tools and libraries in the code. Elegant code is the end.

Then aren't basically all professional software engineers "product-first" engineers?

Consumers or clients are the users to "product" engineers, who in turn are the users to "infrastructure" engineers. If the infrastructure engineers spend their time building elegant abstractions, tools, and libraries that don't solve the product engineers' problems, the product engineers will get their infrastructure needs met elsewhere (i.e. off the shelve, roll their own, or outsource) and the infrastructure engineers won't be necessary.

(I'm not arguing against infrastructure engineers per se, just that their primary goal isn't elegant code.)

I think it has a lot to do with motivation.

Some people are more motivated to solve the business problem. They may accrue more technical debt in exchange for important features and increasing revenue.

Some people are more motivated by clean, well documented, DRY code. They are probably going to fight to refactor parts of the codebase to prevent losing revenue.

Most people are probably somewhere in between.

This seems kind of like saying "some people are motivated by sleeping, while others are motivated by eating" - every software engineer in the industry is going to do both. There's one type of software engineer, and it's someone who juggles multiple competing constraints. You meet product needs quickly using a coherent and well-designed platform; you build a platform in response to real customer needs. It's a silly dichotomy, because there's always a point when product-focused engineers need a platform, and when platform-focused engineers look for customer impact.

This is what a product-focused engineer would say :)

There’s definitely a difference between the people who are more interested in the results of programming vs. the people who are really interested in the craft of programming as a process. They both end up having to think about product questions, but they tend to find their way into different parts of the company: the product-focused engineers are always working on splashy new features while the craft-focused are generally behind the scenes trying to figure out a way to make the DX of the codebase better (and sometimes even being called “architecture astronauts” as a result).

I'm usually the most platform-oriented or infrastructure-oriented engineer on my team. I consistently push for refactoring, test coverage, observability, automation, design sessions, and good documentation. This week I've been adding load shedding and backoff to things, rewriting some old tests that were disabled for being flaky, and rewrote a gigantic fanout query to use a task pool.

That you think I sound like a product engineer when I've been wearing the "I wish we had a real SRE" hat all week is illustrative of the original point: they're not categories that engineers conform to.

That's an improvement on the article's classification. I'd say it's "make the change now; clean up later" engineers vs "clean up now so the change is easy later" engineers. Too much of the former and productivity grinds to a halt under all the tech debt. Too much of the latter and there'll be zero new features shipped. A balance (ideally within each engineer) is ideal.

This pretty much sums up the challenges I've been facing the past week

And you really need everyone in your group to be the same type or you will have a lot of butting heads. I was once contracting on a project where I was building code to solve urgent business problems. By necessity of the timeline, the code was ok but not perfect.

Then they brought on a new manager, who immediately ran all my code through a linter and told me to stop all work until the linter came up clean. I told him that I was hired to make working code that solves an immediate problem, and he told me my services were no longer required.

I found out later the project was quickly moved to another team because his team was unable to meet the tight timelines.

That's the difference between process-oriented and result-oriented thinking. I've also heard the two extremes being referred to as "tool-worshipping fools" and "rule-breaking fools".

This seems incorrect. The archetypal process-oriented professional in my book is the money-making poker player.

In poker, you cannot control the result of any hand -- not even the result of a week's play. To achieve long-term success, you must have a good process for your playing, and not be influenced by the results.

A good process sets you up for the best chance of success, but it cannot guarantee success. If you start to adjust based on results (and not deeper changes to the causal matrix -- these are process-informed changes) you'll do worse. Edwards Deming called this "tampering".

The same thing applies, of course, in business. The greatest process will produce bad results if you're unlucky with uncontrollable external factors. A bad process can by chance produce good results if you're lucky with uncontrollable external factors.

You cannot judge a process by its results in individual instances alone. Judgment of a process must be made in terms of theory, repeated experiment, and long-term tendencies of the outcomes.

And, as in poker, any long-term successful business is process-oriented. They carefully build processes that set them up for greatest chance of repeated success.

Any results-oriented business has -- by de-emphasising the process -- no way to influence the outcome. They are "driving on the highway by looking at the centre line in the rear view mirror" as someone put it.

Theory and process is the only thing that can tell you anything about future results.

I strongly recommend reading Deming's The New Economics.

Organizations tend reward process-oriented thinking regardless of whether it succeeds or not, and results-oriented thinking only if it succeeds.

>Organizations tend reward process-oriented thinking regardless of whether it succeeds or not

I'm not sure if my experience aligns with this

Linters, Test Coverage, and Code quality reports are amazing and important. But these things don’t affect your customers directly. I think some engineers like spearheading these types of projects because they are safe to implement and easy to understand.

I see where you're going with this, but I think about it a little bit differently. Product-orientation and infrastruture-orientation are two different skill sets and professional software developers should have some development on both axes.

I have worked with developers all over the map on these axes and I think the fatal combination is someone who spikes on one axes but ignorance or even active disregard for the other. The failure modes look very different though. The "product-only" engineer quickly whips up something that satisfies their user's need, but over time the code becomes sphagetti that is buggy and painful to modify and the users are unhappy. The "infrastruture-only" engineer makes a puristic system that seems impressive from a technical point of view, but interfaces poorly with the customer's problems. Customers either have to go through contortions to make their problem fit into the architecture of the system or they just move on and find something that is better suited to them.

The first example isn’t a software engineer. The code is a spaghetti mess because the system wasn’t engineered - there are no design documents, because the system wasn’t designed it was just hacked together. There’s no memos describing why certain decisions were made.

The second is, ironically, usually the same, but instead of a lack of design there’s a lack of requirements, which is even worse.

So, in your terminology, a software engineer who is bad at programming is a "product-only", whereas a software engineer who is bad at business is "infrastructure-only"?

If so, why invent new terminology when we have the perfectly fine description "software engineer who is bad at business"? Isn't it bound to confuse more than it helps?

Why do we even go into negative descriptions?

Why don't we go thinking about people strengths and think how we create a team that is composed of people with different strengths?

Manager will have to make sure he makes it clear in the team that:

Joe might not be whipping perfect code but he is good at figuring out users vague requests and putting those into action.

Jane might be obsessed with her language of choice and does not like vague requirements, she likes something like we are having 20 requests per second make system to handle 50.

You don't want to describe people as "bad in something" because that is not productive. For a manager that should be obvious.

But even if someone is working in a team, describing colleagues/projects/workplace in negative ways is bad and not productive. While yes there are instances where it is bad and people should call bad things out, but most of what I see are mere annoyances that one can gloss over.

Agreed. I don't think everyone can be great at everything. There are some basic levels of competencies that are required though and, most importantly, people need to be able to respect the strengths of others that don't align with their own. My own examples were driven by working with developers who were actively disdainful for people and ideas that were not on their single axis of focus, which was bad for the team and for the product.

For the same reason I talk about security weaknesses, and not security strengths: pointing out a weakness is the first step to fixing them.

Even if you have no interest in fixing a weakness, it is absolutely essential that you're aware of it, and can engage in compensating behaviour.

What I see in "software engineer who is bad at business" is that is broad and not useful. We can discuss specific flaws with specific person and think about course of action to fix it.

Telling someone "you suck" is not first step to fixing anything.

Just like laughing someones system has so many holes as Swiss cheese.

You want to be specific like you have an XSS here and here, those are steps to fix it.

That part caught me too. I'm not obsessed with either one. People pay me to make computers do what they want them to do.

Can we start by not calling people lacking engineering degrees "engineers"? Nothing wrong with being a "developer" but everything wrong with being a CSS jockey who gives them self an extremely inflated title. Exceptions can be made for CS degree holders in my opinion.

I don't hold an engineering degree myself, so I am just "programmer". I still make more than most engineers, so why the fuss?

Because computer science is not an engineering degree, and (at least in the states) professional engineers are required at a minimum to hold a four year degree in an accredited engineering program, work under a certified engineer for a period of time, take an exam, etc. While this is for literal physical engineering, there is not an appropriate parallel for software engineering. There are people who hold doctorates in computer science that cannot build functioning software. And it’s not expected that they can — CS is not an engineering degree. If mathematicians were commonly employed like software engineers, they may find themselves adopting a Mathematic Engineer, but that doesn’t mean it bears any relationship to an engineering degree, let alone any degree.

In addition to that, the title is more descriptive of what other employees should expect from you. A programmer is a typist, tasks in results out, no creativity or problem solving expected. Developer creates something new so a little more creative. Engineers engineer stuff they plan and make things work. Architect strictly plans. I don't say thats what they do but a lot closer to what people expect.

> While this is for literal physical engineering, there is not an appropriate parallel for software engineering.

What you have described of an engineer applies to software engineers in Canada. There exist accredited software engineering degrees, some of which may be held under a computer science major with a further specialization in software engineering. There used to be a PE in software engineering in the US. So a parallel for software does exist.

Given that there is precedence for licensing and there exist programs attempting to focus on educating those who need to build systems, why is there such an aversion to hiring those graduates and following those processes? Do they produce worse software? Is there no need because of agile and move fast and ship things?

For one thing, there's absolutely no standard on the titles and they mean entirely different things at different companies.

Company A: A developer just installs and configures off-the-shelf software along with plugins or modules to develop a solution, but they can't really program. A programmer does all the hard work of planning and designing, understanding the system, creating custom code to solve problems, and instructing the developer what off-the-shelf parts to use and how to configure them.

Company B: A programmer just follows instructions from a developer to churn out code, they don't have to solve problems or understand the system. A developer develops the solution, from planning based on requirements, to figuring out the whole system and coding structure and giving instructions to programmers.

Same titles, opposite roles.

Then you get to Comp Sci vs Engineering discussion. That's a whole other can of worms.

Sure, someone might not be doing Big O analysis of a system or whatever. But how often do you really need to outside academia? In a lot of jobs, most performance problems are caused by a few things like cartesian products and/or bad indexes in a database query, or some code that loops doing a query for each thing to fetch data then processing the data, then looping to do additional queries to update the database (when the whole thing could be done with one query, at least with a minor change to the schema), or loops that call a network request for each item. You don't need a detailed theoretical mathematical analysis on a graphing calculator to recognize and solve things like that.

Another is an open endpoint - sure it might not do anything problematic from a security standpoint, and if you set up another system to call it once a day or once an hour it'll be fine. But what if some outsider sets up a system to call it once per second, or a botnet that calls it several times per second? Again, you don't need any complicated formulas to see that that will be a problem.

So sure, there might be some difference in attitude/approach of a comp sci person vs an engineer vs a developer vs a programmer vs an architect. But companies don't know the difference and just give you whatever title they think sounds good. As a pragmatic software person, I don't care what they call me; I just concern myself with whether I can recognize and solve (or better design to prevent) the problems.

Not even going to mention the credentialism regarding degrees.

For a long time, like you, I called myself "programmer", which to me encompasses all of it. But it turns out some business people take a very different view of the terms, so now I just go along with whatever title they want to give me. As long as I can handle the job well, that's what I am.

No, I don't think so. You don't need to be strictly in an infra-oriented position to do infra oriented work. The most common example is the proverbial senior developer setting stack standards for their more junior team (despite being in a role that is largely oriented towards shipping actual products).

Conversely, one could be a product-first infra person, who ships widely useful tools but whose code may be of questionable quality (e.g. someone might duck tape together some mission critical CI pipeline w/ python and bash and no tests)

I would not say obsessed. Instead I divide engineers to implementors (people who are masters of using frameworks/libraries to implement features, but are not capable of writing one) and developers (people who can write a framework/library if that is the ticket).

But yes, there are lots of implementors around and very few developers. We currently try to hire a developer and that is not easy.

Sometimes people ask me what I work on, I answer, "compilers", and they respond with "oh, so back end?". Which I guess is technically true but not really. I get that most development these days is for web facing applications but it's mildly amusing how people forget that plenty of code is written outside the front-end/back-end dichotomy.

It's funny because backend and frontend also have meanings in compilers. You could answer "No, frontend, obviously" and be accurate.

Let‘s keep this complicated please. Most code on back and frontend are written in something starting with ‚Java‘ which is compiled to an intermediate representation which is interpreted and on demand compiled to machine code which is interpreted and executed as micro-code.

Came here to say this. It drives me nuts when people unconsciously identify all software engineering with web application design.

I think of your area (compilers) not as outside the front-end/back-end dichotomy, but (to your point) outside the the world of web-apps, etc.

The front-end/back-end lens can be applied to compilers -- just the "front-end" (invocation options, error/status messages, maybe IDE integrations) is very thin, compared to the "back-end" (i.e., everything else).

> "front-end" (invocation options, error/status messages, maybe IDE integrations) is very thin

I thought the front end of a compiler was the parser and the associated code analysis steps (such as type checking), not "error messages".

The proposed split here between product and infrastructure doesn’t map to my experience or skill set well. In my last job, I was lead of a team called Security and Infrastructure, but the team was renamed by the CTO to Production Engineering. The tasks were substantially the same.

But it’s not just word choice bugging me — delivering for clients and writing good code are not orthogonal, even if there’s often a trade-off. Continually delivering for clients is enabled by a solid, well-factored, flexible base. System-level thinking needs both the how and the why.

When I read "product engineer" and "production engineering" I do not think they're the same.

Production Engineer sounds like an engineer whose goal is to enable the rest of the engineering team to deliver products. You're not directly delivering the products.

To me, the split between product and infrastructure is based on who your customers are. If your customers are other engineers within your company, then you're in infrastructure. If your clients are external then you're in product.

Frontend/backend is a perfetly fine division of primary skillset

I have started to wonder if the axis of UI / no UI might be more useful. There is room in the front end for infrastructural code.

I used to work on a product that had a bug component called (our product) > Frontend > Backend (of the frontend).

I worked on (our product) > Backend, and so whenever the frontend was sending me problematic requests I'd file bugs against the "Backend (of the frontend)". Their UI logic was irrelevant to me, more or less; I only observed their "backend" code's behavior.

Of course when I say I worked on the "backend" I mean the part of this product that talked to other backends and storage layers. In a large enough distributed system, "frontend" and "backend" are relative rather than absolute terms...

I agree with this. Modern applications in web browsers can be large and sophisticated enough that you have people building out business logic models while barely touching user interface code. I think this is fairly common based on my experience.

This maps to my experience (and preferences) well. On my current project, we have a Django backend with a Typescript/Vue.js frontend. I enjoy doing API access and data modelling code in Typescript, but will work to avoid picking up any pure UI tickets for the frontend. If I have to do UI work, it'll mostly be copying and pasting HTML and CSS from other parts of the codebase and writing the Typescript to tie it all together.

I feel like development has come full circle. Initially, it was all server side.

Then we had to use javascript to do some frontend stuff.

The javascript became frameworks which templated some of the patterns to make the frontend dev easier (led by React and Angular)

Frameworks like Blazor and Phoenix/Elixir are bringing the frontend dev back to serverside.

There's a bit more to frontend than knowledge of a framework. I can find my way around a Vue or React codebase, and I'm reasonably competent with CSS and associated frameworks, but there's a deep knowledge of the DOM and vanilla APIs, W3 standards, accessibility, device and browser differences and so on that really make a good frontend developer stand out. Often it's the frontend dev in the room - not the UI/UX experts - who calls out accessibility and usability concerns, as they've spent years working in the nuts and bolts of UI/UX.

If you moved to full server-side tomorrow and used Phoenix/Hotwire/HTMX/whatever, these skills would still be invaluable.

Frontend/backend is a speed of light issue. As long as the speed of light remains constant (and I've not heard any plans to change it) there will be a need to a have some code on the client and some code on the server.

Can you expound on this idea a bit? I don't get what you mean, but it sounds possibly interesting.

The latency of a communication travelling at the speed of light from say Japan to New York, is noticeable to humans. If you've ever tried to SSH into a machine on another continent, you know the feeling.

Even if the server is nearby, there's still many things that can add latency, most of which are not controllable (e.g. wifi interference, bad routers, bad ISPs, train tunnels).

So in general you cannot move all functions to the server because it will be terrible for UX. e.g. Google Stadia.

Couple months ago there is an HN Post about "front-of-the-frontend vs back-of-the-frontend" dichotomy. First time reading the title I thinks its complete nonsense, however those distinction may found follower in other places. I think your comment may have some similarity with that idea

Maybe even more specifically, GUI / no GUI.

With few exceptions, backend/infrastructure roles will still often involve exposing and designing APIs, CLI utilities, etc

I tend to agree, though. Most times when I talk about frontend vs backend profiles, this is what I actually mean.

Of web development skillset, maybe. Of software engineering, not even close!

I know lots of coders that don't want to be involved at the UI or presentation layer. Frontend and backend is a pretty close approximation to this.

I'm one of those. I took my GUI experience off my resume so people would stop asking me to do it. "Backend" has been serving me just fine.

Except when I'm feeling snarky, then it's "Backend ;)"

I am not a "frontend" or "backend" developer, I am a software developer. I hate the terms. A lot of programming people do doesn't involve writing HTML UIs, regardless where it is ran. I write programs to solve problems. I am not strong in UI design, but there are people who are good at that. Programming a UI is something I can do though. UI development has a different set of challenges also, whether it uses HTML, Qt or whatever.

I'd prefer if we go back to the time when "frontend" and "backend" were generic architectural terms. Not everything you do on a computer is a web application.

I think the frontend/backend distinction is mainly from the Web Development culture (that has unfortunately permeated everything else in software); it makes little sense if you're working on desktop applications, for example.

Back end makes sense if the desktop app is a client for a server. You just wouldn't say front end because people would think you meant web.

It can make sense if you're building a GUI app for Mac that's “scriptable and recordable”. I think you'd use VBA for that on Windows. The GUI communicates with the operational core via a message channel (analogous to HTTP requests and their responses) that can be recorded into a “script”. With those scripts you can automate tasks that would otherwise involve manually using the GUI. The “frontend” and “backend” wouldn't call each other's functions directly but use that interposed message channel instead. In that respect it's architecturally similar to a web app, but with all the code in one executable.

Why ‘unfortunately’? I figure most of us are grateful the internet exists and powers much of our lives (and livelihoods).

The blatant disregard for efficiency and constant churn are a huge problem.

Don't confuse the sane and stable Internet core protocols with the "web stack".

I've found the distinction kind of odd.

As a so-called "full stack" developer, every project I've worked on in which the frontend and backend developers were clearly delineated has led to a mismatch in needs between the two.

The frontend devs asking for the API they need for the UI they want to achieve, and the backend devs having to predict the ways the frontend will need this data for now and in the future as the UI evolves and as the backend system is built out.

The frontend devs are at the mercy of potential backend choices affecting the "feel" of the UI over time, and the backend devs at the mercy of their data model, infrastructure, and system design choices not meshing with the future needs of the frontend over time.

I know the projects this sort of thing has gone bad for me on had other communication issues, but I still don't know if I could deliver a solid end product nearly as effectively without being able to jump into either end, understand the problems and desired outcomes, and be able to help both evolve in a maintainable and scalable way, together.

I share the same experience.

I would even go further and say that when you have clearly set boundaries between teams in functional terms it goes bad. Like "backend/frontend", "dev/qa", "dev/ops" ,"engineering/business".

For me the most effective thing that I see are cross-functional product teams that have their own goal to ship things and all roles within that team.

Unfortunately not all software can be built that way and there is a lot of productivity loss, because you might not have enough work for some roles. Like ops engineer you will need at the beginning to setup infra and then he might be helping out here and there, but it is not going to be full time job on one project. Then QA might have "quiet days" because devs will have to work on things for couple days before delivering something.

I understand huge enterprise companies that they want to have "QA" "Dev" "Ops" just as a pool of reusable people, because they have to hire them full time and keep occupied.

What I see in the wild is that there are some long running projects that evolve all the time and those can be such teams as described earlier. There are ad-hoc projects that might pan out or not, maybe it would be better to hire freelancers, see if project turns into long runner and if yes, hire a proper team to work on it.

All of that requires unfortunately a lot of knowledge and work and a lot of political power inside of a company...

I disagree. Frontend/backend is a fine descriptor for web, mobile, etc. Anything that has a UI, "client", "frontend", etc, and then services that process and feed those "frontends" with data are "backend". Sure it's approximate, but a lot better than "product" and "infra" in my opinion.

> “Product-first” engineers are obsessed with using code to solve a user problem and they see code as just a means to an end.

> “Code-first” engineers are obsessed with the abstractions, architecture, tools and libraries in the code. Elegant code is the end.

Eh, from my experience it's quite the opposite, if we're talking frontend vs backend. Frontend is a complete abstraction these days, all about the tools & libraries, a bit less focused on sound architecture, and usually the only thing elegant is the cursive font JS devs use in VSCode.

My understanding of the article is that product-first doesn't equal frontend, but rather that frontend-vs-backend and product-vs-infra are two different ways to categorize engineers, and that looking at roles from the latter's lenses may help in placing candidates in roles that fit their preferences better. This is a good insight, especially because in big companies, attrition seems to be a constant HR issue.

In my experience though, the problem is that the premise of this article presupposes a large enough, diverse enough engineering organization. For smaller shops, there may not be such a thing as a frontend architecture oriented role, or there may not be upper management support for infra oriented roles, etc.

I like the product/infra distinction quite a bit more than frontend/backend. This is basically how Facebook describes its engineers - product engineers who typically work in the "product" repo and works on UI as well as API design and data fetching, vs infrastructure engineers who work in the "service" repo and work on what you typically think of infrastructure (data, systems, efficiency, etc).

After being here for a while and speaking with recruiters from other companies, I've really grown to dislike describing myself as "backend" since I have to make myself explicitly clear that I do not want to work on "backend" portion of product and enjoy myself in the infrastructure side of the world.

Alternative definition:

* product-first engineers have been tamed by the company and can be expected to obey orders and perform tricks for rewards (money, coffee, biscuits, etc). For them code is just a means to an end because they have strayed from the path.

* code-first engineers haven’t had the love of coding slowly but inevitably squeezed out of them yet. Companies hate them because they’re more interested in writing code poetry than working on their assigned widgets, as any good product-focused engineer should.

I can see how one could arrive at that cynical view but in the end it's not tenable. What's code poetry good for if nobody uses the result? Conversely, your product will eventually stop working if the code is a hot mess. It's always a trade-off and bad management (by whomever does the managing) can make some of the goals harder to achieve than they need to be.

In my experience the only concrete distinction between "Frontend" or "Backend" has been whether you touch CSS or not. Everything else has been a grey area.

Ehh. To me the major difference is people who obsess over UI and are motivated by that aspect of things and those who are motivated by models and (fat quotes) “scaling”. People who are skilled at either approach both with a focus on ergonomics, cleanliness, and expressivness.

I think the distinction usually comes from a lack of familiarity but is reinforced by the reward you get from solving the puzzle you care about.

What is considered a viral tweet? It seems like the signal to authority/knowledge/value ratio in this case is overblown

While the author is not someone who is an authority - she seems to pointed out interesting thing out.

I don't read it as something "true" or life changing. But it still is interesting enough that it sparked conversation. Conversation on the topic I am interested in and I am happy to read the comments on the topic here on HN.

Beauty of things going viral is that someone who is not an authority figure can share interesting thought that will be passed along.

I hadn't thought of it from this angle, thanks for sharing your perspective!

I have to give you +1 because there is still a lot of people who don't have experience but write on their blogs with tone that seems they want to be an authority. Which is off-putting for me of course and you also have good line of thinking. Only that for this specific one I don't see it.

Sloppy engineers:

- see programming as an obstacle.

- hate programming.

- never talk about technology.

- care about marking tasks as done.

- think that there are more important things than uptime.

- get favored by task-oriented managers and may get promoted to roles they may not be able to successfully interview for.

- their success encourages other engineers to be sloppy.

Real engineers:

- see programming as part of their job and try to be competent at it.

- have a passion for what they do and how they do it.

- can have an interesting conversation about technology.

- care about sustainable productivity and managing tech debt to achieve that.

- recognize that without uptime, the product doesn't exist.

- get passed on promotions by task-oriented managers.

- their success encourage other engineers to pursue excellence.

There are frontend engineers and product-oriented engineers that care about their craft and are knowledgeable engineers, but it's not a requirement. For infrastructure roles, a desire to understand things deeply is required.

> “Product-first” engineers are obsessed with using code to solve a user problem and they see code as just a means to an end.

> “Code-first” engineers are obsessed with the abstractions, architecture, tools and libraries in the code. Elegant code is the end.

I work on infrastructure products. You'd be hard pressed to convince me that my SDKs don't "solve user problems", because they do. Sure, frontend and backend aren't great descriptors. I often lambast "backend engineering" when a company has a unified hiring process and requires me to recruit the people who do the kind of work I do with the way they recruit web-only backend engineers, but these descriptors are far more amalgamous and tell me much less than what Frontend and Backend do.

> there are 2 types of engineers

False dichotomy. "Problems" are difficult to put in meaningful frames, and the engineering value is proportional to how "meaningful" the problem definitions are.

Users experience things they identify as problems, but can't possibly articulate in meaningful frames.

Users only experience symptoms, whereas engineers are responsible for systems. The shortest path to treating the symptoms is almost never a good solution, for either the user experience or the system.

In so far as there are different types of engineers, it might be possible to segment them based on their accountability. Some are accountable only to user demands, some are accountable for long term system stability, and so on. They are not "born" with different mentalities.

I’ve definitely had similar thoughts, though obviously no one dimension can capture all the nuance we’d really want for the discussion.

Personally, I find myself split between liking both (and being frustrated by both). The frontend/product stuff is the kind of stuff that’s easily explainable to grandma (“hey look at this button! I made that!”) but at the same time, “pixel twiddling” (spending hours just to combat weird issues in CSS leaves a spire taste. The backend/infra stuff is often much more “challenging” in many ways (not to say frontend is “easier”), but there have definitely been times at the end of a long day of work where I’m not really sure what I had to show for it.

Dichotomy between product first and code first is non sense to me I'm a nerd and love to share about complex and technicals subjects about coding but I never forget that my job is to deliver a value for people (B2C, B2B... doesn't matter), there's no point coding for code unless you want to show off that your solution is best than your fellows'. So to me, elegant code is just an ego trip

I'm very happy to not be working on web stuff for a day job, there is no "frontend" or "backend" to discuss.

A better distinction in my experience is whether the developer thinks to serve 100 concurrent users or 100k. Whether frontend, backend, or fullstack, different considerations and choices are made. Frontend less so, but still has impact, e.g. understanding of caching details, can't use sticky sessions or persistent notification connections etc.

Describing yourself as a backend or frontend engineer is all about having the power to say 'no'.

I describe myself as a backend engineer, and I refuse to touch your legacy frontend code or own any frontend code.

If you are unable to understand it, companies that do are a dime a dozen in the current market.

> The “Frontend/Backend” axis doesn’t map well to engineers’ motivations

True, but it’s useful to describe skill sets. They are truly quite distinct and equally challenging. Full stack is also useful because it means “I can muddle though most of it” — written as a muddler myself.

I can do frontend development.

You don't want me doing frontend development.

I don't want me doing frontend development.

I struggled doing frontend development back when it was 80x24, with green, bold, reverse, underline and blink. On a good day I got the fields lined up.

I can do frontend development, but, you won't like it.

Dev Centipede - they shall be as one.

Does anyone remember the days when we used to call the entire web application frontned? :)

There is no such thing as backend. It is interfaces all the way down

When people say they don't like frontend, they just mean they don't like implementing GUI designs as opposed to CLIs, APIs, and all the other kinds of non-visual interfaces. And why would anyone enjoy translating existing designs into code. It's rote and finicky; there's little scope for creative decision making and few hard logical reasoning problems to chew on (note that I'm not talking about architecting complex async business logic, but just the translating design specs into HTML&CSS part of the job). Also, CSS is an unholy abomination that is absolutely disgusting to work with

Implementing the designs should be part of the designer's job. That should be the price they are required to pay for getting to do the fun creative part. It's also more their speed as coding goes

i dont think any frontend dev would think they are product first engineer

My job title is frontend dev and I definitely don't think of the stuff I do as product first. Maybe just the nature of the job I am currently doing, or the fact that I manage a full stack website? Depends on the context, I suppose. There are a lot of gray areas for me.

I probably would.

Why not? ”Frontend” is what the customer sees first and bad UI is guaranteed to turn away customers in a competitive market.

I would.

I like doing client-side logic, e.g. calculators, stuff like that. I think that falls in the middle of UX/no-UX.

It would be better to use UI/no-UI instead. Because the while stack from DB to the JS and CSS we write can labeled as UX since each layer affects latency and how smooth the UX can be, but especially if you're writing client-side logic.

That's fair. I really enjoy writing code that users will interact with, but I don't like writing CSS. I think no-UI frontend is the best descriptor.

I can get behind the product infra nomenclature over backend and front end.

What if you enjoy working on everything in equal measure?

if it runs on the client’s machine it’s front end

if it runs on the server it’s backend

if it’s about actually running the server it’s infrastructure.

i dont see what’s that hard to understand…

I like the middle end

Reply on news.ycombinator.com