10 ms·

> Front-end and back-end are pretty arbitrary labels. I disagree. These are somewhat loose business standards that people have a general idea what they mean. T

> Front-end and back-end are pretty arbitrary labels. I disagree. These are somewhat loose business standards that people have a general idea what they mean. The confusion mostly comes with the middle tier ( aka the interface between front-end and back-end ). > By nonetheless making that distinction chances are you're creating a culture where developers neither take responsibility for the end result nor have any agency in it. No. The front-end and back-end usually denote responsibility and security. Sure you can know HTML and SQL as a front-end developer but generally, the back-end servers itself ( especially in production ) are taken care of by DBAs, sysadmins, network admins, etc. For toy projects that you do for school, you can wear all the hats. But in larger projects, nobody has the time or domain expertise to wear all the hats. Front-end usually deals with getting data from the back-end and showing it to the client. Back-end deals with clustering, replication, network availability, disaster recovery, etc ( i.e. making the data available 24/7 ) or whatever the SLA dictates. The difference between front-end and back-end isn't HTML or SQL or even where the code runs. It's about responsibility and security.

BjoernKW 8y ago
> I disagree. These are somewhat loose business standards that people have a general idea what they mean. The problem with these standards is that they aren't conducive to creating value. They mostly help with pigeonholing developers into neat categories so they can be treated as fungible resources. > the back-end servers itself ( especially in production ) are taken care of by DBAs, sysadmins, network admins, etc. The main idea of the DevOps movement was to break down these walls in order to establish a culture of shared responsibility. What's the point in that if we even have walls within the Dev part of that equation? People thinking "I've done my part. Not my problem anymore." once they've thrown their stuff over the wall can be hugely detrimental to an organization. > For toy projects that you do for school, you can wear all the hats. But in larger projects, nobody has the time or domain expertise to wear all the hats. You don't have to be an expert at everything. Asking and relying on the expertise of others is perfectly fine. A developer in my opinion should however be able to take responsibility for creating an increment of business value without having to resort to managers or similar interfaces for coordinating the efforts required to do so. Dividing developers into "front-end" and "back-end" lends itself to silo creation and the notion that someone higher up in the hierarchy is responsible for the business value your code contributes to.

BjoernKW 8y ago

> I disagree. These are somewhat loose business standards that people have a general idea what they mean. The problem with these standards is that they aren't conducive to creating value. They mostly help with pigeonholing developers into neat categories so they can be treated as fungible resources. > the back-end servers itself ( especially in production ) are taken care of by DBAs, sysadmins, network admins, etc. The main idea of the DevOps movement was to break down these walls in order to establish a culture of shared responsibility. What's the point in that if we even have walls within the Dev part of that equation? People thinking "I've done my part. Not my problem anymore." once they've thrown their stuff over the wall can be hugely detrimental to an organization. > For toy projects that you do for school, you can wear all the hats. But in larger projects, nobody has the time or domain expertise to wear all the hats. You don't have to be an expert at everything. Asking and relying on the expertise of others is perfectly fine. A developer in my opinion should however be able to take responsibility for creating an increment of business value without having to resort to managers or similar interfaces for coordinating the efforts required to do so. Dividing developers into "front-end" and "back-end" lends itself to silo creation and the notion that someone higher up in the hierarchy is responsible for the business value your code contributes to.