4 ms·

Data / API / DB design will take 10%-20% of your time at most (unless you’re a DBA), maybe as low as 1% on a large company where almost everything you touch was

Data / API / DB design will take 10%-20% of your time at most (unless you’re a DBA), maybe as low as 1% on a large company where almost everything you touch was made by someone else. In my experience (10+ years) backend is almost always faster when it comes to building apps. Not running your code on 300 different devices and OSs, or having to deal with 20 years of backwards compatibility is a big advantage. Plus the library churn as mentioned, I don’t know any ecosystem that comes close to JS (cue the Remix announcement from yesterday…) At $currentJob, backend features (go + pgsql) are usually done in hours while the FE/app development (React) goes on for days / weeks. It’s a bit unnerving. So, is backend easier? It depends, but it can certainly be a lot less stressful.

valenterry 5y ago
I have the impression that your experience is mostly limited to creating new applications, from scratch up. But in reality, most backend-work is maintaining and extending existing backends and then things become much more difficult. And that's also why backend is different from frontend: it's easy to throw a frontend away and replace it with a new one - try to do that with a backend - usually much much harder.
- bluedino 5y ago
  Even new stuff has challenges. Integrating API's for other devices and services that your app uses. Working with analytics and reporting.
- spoiler 5y ago
  > it's easy to throw a frontend away and replace it with a new one - try to do that with a backend - usually much much harder. Untrue. I work at a company that's swapped out the frontend and then later the backend. I had to work on both of the projects because, and I can tell you without a any doubt in my mind that they were both equally challenging (for different reasons, but that's beyond the point). In my experience frontend-only (or frontend-focues) devs tend to underestimate backend work, and the the backend devs are equally guilty of doing the same about frontend work. Everyone thinks they've got it the harderst. ¯\_(ツ)_/¯
  - valenterry 5y ago
    I'm sure that this also happens sometimes and that there are products where the frontend is the main part and requires more work than the backend. But I still believe that it's usually easier and more valuable to recreate the frontend, and the reason is that Backend is (on average) more stable, grows over a longer time. The reason is also that the risk of replacing the backend is higher, since for a frontend, you can usually use two of them in parallel (think AB testing) without much problems. But if you do the same with the backend and the new backend writes incorrect data into the db, then the old backend also starts to behave incorrect. Hence harder to change.
albertopv 5y ago
It can, but only on new projects. I had to deal with codebases old up to 15 years, once on a project developed in java 3 and run on jvm 8.
Jensson 5y ago
Building an MVP backend is a lot easier, but there is no limit to how much work you can put into a backend to a typical app. Frontend is a pretty much solved problem, getting to that state takes longer than the backend MVP but after that there isn't that much more to do. Or do you think that reddit, twitter, facebook or google put more work into their frontends than everything that goes on in their backends? Recreating their frontends isn't that much work, recreating their backends however...
- names_are_hard 5y ago
  Found the backend dev. Really, this is very dependent on the kind of software you work in and what the focus of that software is. There's a wide world of software out there, with all different kinds of priorities and challenges.
  - Jensson 5y ago
    > Really, this is very dependent on the kind of software you work in and what the focus of that software is. There's a wide world of software out there, with all different kinds of priorities and challenges. That is included in what I said, many projects are fine with an MVP, that is why it is called MVP. If your frontend is a game or some creator tool like photoshop then they will be complicated, but usually you don't call those frontends, and most frontend developers doesn't have the skills to make such products. > Found the backend dev. I've spent roughly equal time in both domains. Creating a frontend with the same quality as Google or Facebook isn't particularly hard (if you assume another guy did the UX design), it is tedious though. And that is basically all you have to be able to do to work as a frontend dev.
    - ricardobeat 5y ago
      This might sound shocking, but there is a lot going on behind the scenes at Facebook, Google, and any big player really, on the frontend. Like, a lot. Think a thousand A/B tests at once. Hundreds of independent products and internal tools. Each one with dozens of minor, but necessary pages that most users will never see. Facebook’s frontend passed 10 million lines of code back in 2013. Someone wrote all of that. Yes, we did that to ourselves… Most product teams for these companies have more frontend than backend devs. They’re building new features, sometimes multiple versions in parallel, fixing bugs and creating more of them, running experiments, and with modern frameworks, a whole lot of plumbing. You can basically generate infinite amounts of product work, and that’s what companies do.
dmichulke 5y ago
It depends. If the backend is done well, yes. But how often is it the case that you're called to work on a well-designed back end?

valenterry 5y ago

I have the impression that your experience is mostly limited to creating new applications, from scratch up. But in reality, most backend-work is maintaining and extending existing backends and then things become much more difficult. And that's also why backend is different from frontend: it's easy to throw a frontend away and replace it with a new one - try to do that with a backend - usually much much harder.

bluedino 5y ago
Even new stuff has challenges. Integrating API's for other devices and services that your app uses. Working with analytics and reporting.
spoiler 5y ago
> it's easy to throw a frontend away and replace it with a new one - try to do that with a backend - usually much much harder. Untrue. I work at a company that's swapped out the frontend and then later the backend. I had to work on both of the projects because, and I can tell you without a any doubt in my mind that they were both equally challenging (for different reasons, but that's beyond the point). In my experience frontend-only (or frontend-focues) devs tend to underestimate backend work, and the the backend devs are equally guilty of doing the same about frontend work. Everyone thinks they've got it the harderst. ¯\_(ツ)_/¯
- valenterry 5y ago
  I'm sure that this also happens sometimes and that there are products where the frontend is the main part and requires more work than the backend. But I still believe that it's usually easier and more valuable to recreate the frontend, and the reason is that Backend is (on average) more stable, grows over a longer time. The reason is also that the risk of replacing the backend is higher, since for a frontend, you can usually use two of them in parallel (think AB testing) without much problems. But if you do the same with the backend and the new backend writes incorrect data into the db, then the old backend also starts to behave incorrect. Hence harder to change.

albertopv 5y ago

It can, but only on new projects. I had to deal with codebases old up to 15 years, once on a project developed in java 3 and run on jvm 8.

Jensson 5y ago

Building an MVP backend is a lot easier, but there is no limit to how much work you can put into a backend to a typical app. Frontend is a pretty much solved problem, getting to that state takes longer than the backend MVP but after that there isn't that much more to do. Or do you think that reddit, twitter, facebook or google put more work into their frontends than everything that goes on in their backends? Recreating their frontends isn't that much work, recreating their backends however...

names_are_hard 5y ago
Found the backend dev. Really, this is very dependent on the kind of software you work in and what the focus of that software is. There's a wide world of software out there, with all different kinds of priorities and challenges.
- Jensson 5y ago
  > Really, this is very dependent on the kind of software you work in and what the focus of that software is. There's a wide world of software out there, with all different kinds of priorities and challenges. That is included in what I said, many projects are fine with an MVP, that is why it is called MVP. If your frontend is a game or some creator tool like photoshop then they will be complicated, but usually you don't call those frontends, and most frontend developers doesn't have the skills to make such products. > Found the backend dev. I've spent roughly equal time in both domains. Creating a frontend with the same quality as Google or Facebook isn't particularly hard (if you assume another guy did the UX design), it is tedious though. And that is basically all you have to be able to do to work as a frontend dev.
  - ricardobeat 5y ago
    This might sound shocking, but there is a lot going on behind the scenes at Facebook, Google, and any big player really, on the frontend. Like, a lot. Think a thousand A/B tests at once. Hundreds of independent products and internal tools. Each one with dozens of minor, but necessary pages that most users will never see. Facebook’s frontend passed 10 million lines of code back in 2013. Someone wrote all of that. Yes, we did that to ourselves… Most product teams for these companies have more frontend than backend devs. They’re building new features, sometimes multiple versions in parallel, fixing bugs and creating more of them, running experiments, and with modern frameworks, a whole lot of plumbing. You can basically generate infinite amounts of product work, and that’s what companies do.

dmichulke 5y ago

It depends. If the backend is done well, yes. But how often is it the case that you're called to work on a well-designed back end?