6 ms·

No, it's not the division that's the problem, it's having one driving the other. The thing is front end dev is actually very different from back end dev. Havin

by d--b 6y ago

No, it's not the division that's the problem, it's having one driving the other. The thing is front end dev is actually very different from back end dev. Having done a lot of both, I can say that they require very different skillsets and different knowledge, so it is quite normal that they're not done by the same people. Now, if your team is frontend first, you'll likely screw up your backend design in the sense that you won't be able to define a nice API for it. Similarly, if your team is backend first, you'll have a nice API, but probably won't think about all the frontend needs, and will have to patch things nastily down the road. Truth is, coordinating people with different skills is hard. Now this kind of articles take aim at teams that don't manage to make it work. So yeah, not being great at managing teams is an antipattern...

Silhouette 6y ago
The thing is front end dev is actually very different from back end dev. Having done a lot of both, I can say that they require very different skillsets and different knowledge, so it is quite normal that they're not done by the same people. I've seen this argument many times, but as someone else who has done a lot of both, I've never really understood it. It's just programming, like any other software project. Sure, you might use different languages and each might have its own tool chain, but unless you're using radically different languages or tools in the two cases, those are probably superficial differences. Most experienced professional developers can probably work in several languages, and you pick up a new tool chain in days if you need to. But the fundamentals of programming are still much the same whatever you're building. Certainly different applications also have different knowledge and skills -- writing a business automation tool is likely to be quite a different experience to writing a control system for ABS in a car, say -- but for a typical web app, the front and back ends are usually going to overlap a lot in this respect. As I mentioned in another comment, the huge exception to this is junior roles, because at that stage in someone's career they probably haven't gained much diversity of experience yet and you probably should start by focussing on one particular aspect. So if your project team consists of many relatively junior people and not so many seniors with broader experience, sure, you're going to put most people specifically on front-end or back-end, at least to start with.
- beefbroccoli 6y ago
  i've worked with way too many programmers who were great at math but couldn't match their shirt and pants.
- Myrmornis 6y ago
  I think the issue that the article skirts around is that front-end work involves UI design and styling. So sure, both involve using sophisticated modern programming languages etc, but the presence of visual styling work is unique to the front end and specifically what a lot of back end programmers feel they are unable to contribute to. I know that many javascript engineers feel similarly about their design and styling skills, but still, in my opinion the presence of UI design and styling in frontend work is the main contributor to the cultural/team separation.
  - Silhouette 6y ago
    We have been rendering HTML and adding styling from the back end since long before JS was cool... I think the real distinction here is between programming and interface design, which are also separate skills that any given person might or might not have, but that is true whether they happen be coding for the front or the back end at the time.
    - d--b 6y ago
      Well depends what you call "backend", I tend to think of it as the business code that the interface operates with. Namely the API. I work in finance, so there the backend consists of gathering data and applying statistics on it. The frontend is a presentation of the data and a way to interact with it. The webserver code that renders web pages definitely belongs to frontend dev.
      - Silhouette 6y ago
        Personally I would call code running on the user's device the front end and code running on some server or other remote device the back end. YMMV. Maybe this explains the difference in our perspectives. To me, other than perhaps the very first data collection where maybe the source is only accessible from the back end, whether things like statistical analysis or rendering of the results happen on the front or the back end is something you will decide on its merits for each project, not something that is necessarily tied to the mechanical programming skills or libraries on one suffer or the other.
blablabla123 6y ago
Having started with frontend as well because of necessity, I've realized people actually appreciate people with backend background working in frontend. Especially on complex UIs it makes sense to have people who are comfortable building complex features even if all details aren't clear yet. On the other hand, backends profit also from people with frontend-only experience.
- SergeAx 6y ago
  In complex UIs it makes much more sense to have product and design people who are able to simplify it without losing value for customer. Actually, ability to have the same outcome with less hussle is added value. It is manyfold more important with mobile-first experience.
Aeolun 6y ago
> Similarly, if your team is backend first, you'll have a nice API Or you have a horrid kludge, and regardless of how great your frontend team is, you are now stuck with a terrible mess.
nostrapollo 6y ago
I agree, my summary of the post: "Frontend is engineering too" which I 100% agree with, however the notion of not splitting up systems into functional goals is a mistake. User-facing applications just have different goals from an application consumed via API. Practically when you split up a system into a client facing application and an API application, from my experience and reasoning, it's always been because it results in a far easier to manage development process. The simpler you can make your system the less likely it will be to fail by any measure. So breaking systems up into smaller systems is just easier and simpler. One such division that is really easy is the backend and frontend. Model View Controller type frameworks are a great practical example of why breaking systems up makes them much easier to construct.

by d--b 6y ago

Silhouette 6y ago

The thing is front end dev is actually very different from back end dev. Having done a lot of both, I can say that they require very different skillsets and different knowledge, so it is quite normal that they're not done by the same people. I've seen this argument many times, but as someone else who has done a lot of both, I've never really understood it. It's just programming, like any other software project. Sure, you might use different languages and each might have its own tool chain, but unless you're using radically different languages or tools in the two cases, those are probably superficial differences. Most experienced professional developers can probably work in several languages, and you pick up a new tool chain in days if you need to. But the fundamentals of programming are still much the same whatever you're building. Certainly different applications also have different knowledge and skills -- writing a business automation tool is likely to be quite a different experience to writing a control system for ABS in a car, say -- but for a typical web app, the front and back ends are usually going to overlap a lot in this respect. As I mentioned in another comment, the huge exception to this is junior roles, because at that stage in someone's career they probably haven't gained much diversity of experience yet and you probably should start by focussing on one particular aspect. So if your project team consists of many relatively junior people and not so many seniors with broader experience, sure, you're going to put most people specifically on front-end or back-end, at least to start with.

beefbroccoli 6y ago
i've worked with way too many programmers who were great at math but couldn't match their shirt and pants.
Myrmornis 6y ago
I think the issue that the article skirts around is that front-end work involves UI design and styling. So sure, both involve using sophisticated modern programming languages etc, but the presence of visual styling work is unique to the front end and specifically what a lot of back end programmers feel they are unable to contribute to. I know that many javascript engineers feel similarly about their design and styling skills, but still, in my opinion the presence of UI design and styling in frontend work is the main contributor to the cultural/team separation.
- Silhouette 6y ago
  We have been rendering HTML and adding styling from the back end since long before JS was cool... I think the real distinction here is between programming and interface design, which are also separate skills that any given person might or might not have, but that is true whether they happen be coding for the front or the back end at the time.
  - d--b 6y ago
    Well depends what you call "backend", I tend to think of it as the business code that the interface operates with. Namely the API. I work in finance, so there the backend consists of gathering data and applying statistics on it. The frontend is a presentation of the data and a way to interact with it. The webserver code that renders web pages definitely belongs to frontend dev.
    - Silhouette 6y ago
      Personally I would call code running on the user's device the front end and code running on some server or other remote device the back end. YMMV. Maybe this explains the difference in our perspectives. To me, other than perhaps the very first data collection where maybe the source is only accessible from the back end, whether things like statistical analysis or rendering of the results happen on the front or the back end is something you will decide on its merits for each project, not something that is necessarily tied to the mechanical programming skills or libraries on one suffer or the other.

blablabla123 6y ago

Having started with frontend as well because of necessity, I've realized people actually appreciate people with backend background working in frontend. Especially on complex UIs it makes sense to have people who are comfortable building complex features even if all details aren't clear yet. On the other hand, backends profit also from people with frontend-only experience.

SergeAx 6y ago
In complex UIs it makes much more sense to have product and design people who are able to simplify it without losing value for customer. Actually, ability to have the same outcome with less hussle is added value. It is manyfold more important with mobile-first experience.

Aeolun 6y ago

> Similarly, if your team is backend first, you'll have a nice API Or you have a horrid kludge, and regardless of how great your frontend team is, you are now stuck with a terrible mess.

nostrapollo 6y ago

I agree, my summary of the post: "Frontend is engineering too" which I 100% agree with, however the notion of not splitting up systems into functional goals is a mistake. User-facing applications just have different goals from an application consumed via API. Practically when you split up a system into a client facing application and an API application, from my experience and reasoning, it's always been because it results in a far easier to manage development process. The simpler you can make your system the less likely it will be to fail by any measure. So breaking systems up into smaller systems is just easier and simpler. One such division that is really easy is the backend and frontend. Model View Controller type frameworks are a great practical example of why breaking systems up makes them much easier to construct.