13 ms·

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

134 points by loa_in_ 5y ago

jimmaswell 5y ago
Frontend/backend is a perfetly fine division of primary skillset
- robmccoll 5y ago
  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.
  - kayman 5y ago
    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.
    - zarzavat 5y ago
      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.
      - isoskeles 5y ago
        Can you expound on this idea a bit? I don't get what you mean, but it sounds possibly interesting.
        zarzavat 5y ago
        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.
        dalu 5y ago
        1995-2013 would like to disagree
    - danjac 5y ago
      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.
    - deleted 5y ago
      [deleted]
  - steve_adams_86 5y ago
    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.
    - morvita 5y ago
      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.
  - azophy_2 5y ago
    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
  - scottlamb 5y ago
    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...
  - 3np 5y ago
    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.
- deleted 5y ago
  [deleted]
- arvindamirtaa 5y ago
  Of web development skillset, maybe. Of software engineering, not even close!
tuananh 5y ago
i dont think any frontend dev would think they are product first engineer
- lghh 5y ago
  I probably would.
- cheeaun 5y ago
  I would.
- reidjs 5y ago
  Why not? ”Frontend” is what the customer sees first and bad UI is guaranteed to turn away customers in a competitive market.
- chilldsgn 5y ago
  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.
seanwilson 5y ago
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.
- __MatrixMan__ 5y ago
  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 ;)"
labster 5y ago
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.
- Bilal_io 5y ago
  When I read "product engineer" and "production engineering" I do not think they're the same.
- xmprt 5y ago
  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.
robbedpeter 5y ago
Dev Centipede - they shall be as one.
travisd 5y ago
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.
- ttty2 5y ago
  Most of the weird issues in css are because of cascading styles. Try css in js, and everything it's much more predictable.
userbinator 5y ago
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.
- toastal 5y ago
  Why ‘unfortunately’? I figure most of us are grateful the internet exists and powers much of our lives (and livelihoods).
  - userbinator 5y ago
    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".
- deleted 5y ago
  [deleted]
- pseudalopex 5y ago
  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.
- tempodox 5y ago
  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.
mLuby 5y ago
> “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.)
- reidjs 5y ago
  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.
  - mLuby 5y ago
    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.
    - geoduck14 5y ago
      This pretty much sums up the challenges I've been facing the past week
  - strken 5y ago
rpmisms 5y ago
I like doing client-side logic, e.g. calculators, stuff like that. I think that falls in the middle of UX/no-UX.
- Bilal_io 5y ago
  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.
  - rpmisms 5y ago
    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.
bschwindHN 5y ago
I'm very happy to not be working on web stuff for a day job, there is no "frontend" or "backend" to discuss.
sbretz3 5y ago
What is considered a viral tweet? It seems like the signal to authority/knowledge/value ratio in this case is overblown
- ozim 5y ago
  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.
  - sbretz3 5y ago
    I hadn't thought of it from this angle, thanks for sharing your perspective!
    - ozim 5y ago
      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.
hardwaregeek 5y ago
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.
- jraph 5y ago
  It's funny because backend and frontend also have meanings in compilers. You could answer "No, frontend, obviously" and be accurate.
  - heisenbit 5y ago
    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.
- verrp 5y ago
  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).
  - jhgb 5y ago
    > "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".
- nradclif 5y ago
  Came here to say this. It drives me nuts when people unconsciously identify all software engineering with web application design.
kiawe_fire 5y ago
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.
- ozim 5y ago
  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...
seandoe 5y ago
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.
highwind 5y ago
Does anyone remember the days when we used to call the entire web application frontned? :)
encoderer 5y ago
> 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.
- whartung 5y ago
  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.
jobu 5y ago
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.
rawrfml 5y ago
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.
thinkingkong 5y ago
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.
pxi 5y ago
What if you enjoy working on everything in equal measure?
ramoz 5y ago
> “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.
- lhorie 5y ago
  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.
Razengan 5y ago
I like the middle end
bigpeopleareold 5y ago
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.
29athrowaway 5y ago
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.
kodah 5y ago
> “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.
gigatexal 5y ago
I can get behind the product infra nomenclature over backend and front end.
blub 5y ago
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.
- tempodox 5y ago
  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.
mkl95 5y ago
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.
wly_cdgr 5y ago
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
dalu 5y ago
Well sorry but I prefer backend because no one has an opinion about how something looks or presumes to know about that area. To managers backend is voodoo stuff and frontend is where they have an opinion, because they are directly exposed to the result of the frontend, the presentation. However working purely frontend or purely backend gets equally boring. I don't agree with the article. Btw I'd like to know if I'm passively banned. My karma remains 20 and I can post 2 comments per day at most.
yobbo 5y ago
> 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.
deleted 5y ago
[deleted]
jcq3 5y ago
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
karmakaze 5y ago
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.
StefanKiss 5y ago
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…

134 points by loa_in_ 5y ago

jimmaswell 5y ago

Frontend/backend is a perfetly fine division of primary skillset

robmccoll 5y ago
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.
- kayman 5y ago
  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.
  - zarzavat 5y ago
    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.
    - isoskeles 5y ago
      Can you expound on this idea a bit? I don't get what you mean, but it sounds possibly interesting.
      - zarzavat 5y ago
        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.
        dalu 5y ago
        1995-2013 would like to disagree
  - danjac 5y ago
    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.
  - deleted 5y ago
    [deleted]
- steve_adams_86 5y ago
  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.
  - morvita 5y ago
    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.
- azophy_2 5y ago
  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
- scottlamb 5y ago
  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...
- 3np 5y ago
  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.
deleted 5y ago
[deleted]
arvindamirtaa 5y ago
Of web development skillset, maybe. Of software engineering, not even close!

tuananh 5y ago

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

lghh 5y ago
I probably would.
cheeaun 5y ago
I would.
reidjs 5y ago
Why not? ”Frontend” is what the customer sees first and bad UI is guaranteed to turn away customers in a competitive market.
chilldsgn 5y ago
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.

seanwilson 5y ago

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.

__MatrixMan__ 5y ago
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 ;)"

labster 5y ago

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.

Bilal_io 5y ago
When I read "product engineer" and "production engineering" I do not think they're the same.
xmprt 5y ago
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.

robbedpeter 5y ago

Dev Centipede - they shall be as one.

travisd 5y ago

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.

ttty2 5y ago
Most of the weird issues in css are because of cascading styles. Try css in js, and everything it's much more predictable.

userbinator 5y ago

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.

toastal 5y ago
Why ‘unfortunately’? I figure most of us are grateful the internet exists and powers much of our lives (and livelihoods).
- userbinator 5y ago
  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".
deleted 5y ago
[deleted]
pseudalopex 5y ago
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.
tempodox 5y ago
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.

mLuby 5y ago

> “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.)

reidjs 5y ago
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.
- mLuby 5y ago
  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.
  - geoduck14 5y ago
    This pretty much sums up the challenges I've been facing the past week
- strken 5y ago

rpmisms 5y ago

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

Bilal_io 5y ago
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.
- rpmisms 5y ago
  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.

bschwindHN 5y ago

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

sbretz3 5y ago

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

ozim 5y ago
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.
- sbretz3 5y ago
  I hadn't thought of it from this angle, thanks for sharing your perspective!
  - ozim 5y ago
    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.

hardwaregeek 5y ago

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.

jraph 5y ago
It's funny because backend and frontend also have meanings in compilers. You could answer "No, frontend, obviously" and be accurate.
- heisenbit 5y ago
  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.
verrp 5y ago
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).
- jhgb 5y ago
  > "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".
nradclif 5y ago
Came here to say this. It drives me nuts when people unconsciously identify all software engineering with web application design.

kiawe_fire 5y ago

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.

ozim 5y ago
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...

seandoe 5y ago

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.

highwind 5y ago

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

encoderer 5y ago

> 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.

whartung 5y ago
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.

jobu 5y ago

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.

rawrfml 5y ago

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.

thinkingkong 5y ago

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.

pxi 5y ago

What if you enjoy working on everything in equal measure?

ramoz 5y ago

lhorie 5y ago
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.

Razengan 5y ago

I like the middle end

bigpeopleareold 5y ago

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.

29athrowaway 5y ago

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.

kodah 5y ago

> “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.

gigatexal 5y ago

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

blub 5y ago

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.

tempodox 5y ago
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.

mkl95 5y ago

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.

wly_cdgr 5y ago

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

dalu 5y ago

Well sorry but I prefer backend because no one has an opinion about how something looks or presumes to know about that area. To managers backend is voodoo stuff and frontend is where they have an opinion, because they are directly exposed to the result of the frontend, the presentation. However working purely frontend or purely backend gets equally boring. I don't agree with the article. Btw I'd like to know if I'm passively banned. My karma remains 20 and I can post 2 comments per day at most.

yobbo 5y ago

> 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.

deleted 5y ago

[deleted]

jcq3 5y ago

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

karmakaze 5y ago

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.

StefanKiss 5y ago

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…