> 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

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