4 ms·

It is becoming clear to me that much of the perceived difference of opinion here is just because of terminology. I was thinking of "development" as meaning spec

It is becoming clear to me that much of the perceived difference of opinion here is just because of terminology. I was thinking of "development" as meaning specifically the programming side of things. This is quite distinct from the other skills you mentioned like responsive design or database design. Of course someone might have both front-end programming and user interface design responsibilities on the same project, but I would no more assume that than I would assume the same person would have both front- and back-end programming roles, and the skills for the latter combination are much more closely related. My point here is just that everyone has a different mix of skills and trying to pigeonhole people or restrict anything to only certain combinations is not necessarily either realistic or helpful.

jasode 6y ago
>, I've never really understood it. It's just programming, like any other software project. [...] But the fundamentals of programming are still much the same whatever you're building. It doesn't matter if the underlying programming fundamentals are the same because the human brain still has preferences on what it wants to work on. The mistake is applying some "umbrella term" (i.e. "programming") for an activity and thinking that will automatically make all sub categories attract the same interest level. It doesn't work that way. This same phenomenon happens in other intellectual activities such as mathematics, writing, painting, etc: One mathematician might prefer to study algebraic topology while another mathematician prefers to work on number theory. Thus, saying, "I don't get it -- it's all _math_ so why should one person have more interest in one branch vs another?!?" ... does not remove the preference. One writer may prefer to write political analysis essays and never writes fiction -- but another writer prefers to write fiction and never opinion pieces on current events. Therefore, saying, "I don't get the fiction/non-fiction dichotomy because both activities are just the same task of manipulating _words_?!?" ... doesn't make a preferred interest disappear. Yes, some authors write both fiction and non-fiction but the existence of them still doesn't remove the preference of other authors who specialize in just one. Even within sub-category of fiction, you get sub-specialization of "mystery novels" instead of "romance novels". Likewise, saying "painting is painting" does not change the fact that an artist might prefer to always paint landscapes and never horses or people. >It is becoming clear to me that much of the perceived difference of opinion here is just because of terminology. I was thinking of "development" as meaning specifically the programming side of things. [...] and trying to pigeonhole people or restrict anything to only certain combinations is not necessarily either realistic or helpful. Some people naturally just want to pigeonhole themselves. I've done frontend work on old DOS machines (text-based UI), raw Win32 API, VB/C# GUI forms, Javascript/HTML -- and I don't like any of it. I prefer to program the backend algorithms. Yes, coding a loop to "iterate through all window controls to enlarge them by 10% in the GUI" has something in common with "iterate through all nodes of a graph to optimize a path" ... because they're both "loops" ... but they have very different levels of intellectual satisfaction. I won't argue with you if you feel that they should feel exactly the same because they're both "programming" but I can't help it that I don't derive the same enjoyment. If I was employed by Google, I'd enjoy working on the backend ranking algorithms. To a lesser degree, I'd be ok with working on the spider crawlers. But I'd quit if they assigned me to work on the web frontend where users type in queries. But I'm also glad there are developers who prefer to work on the frontend instead of the backend because it allows people like me to stay with my preference.
- Silhouette 6y ago
  FWIW, I'm not trying to suggest that front-end and back-end dev are the same and that no-one will have any preference for one or the other. Of course they feel different and some people will enjoy one thing or another more. My objection is to the common arguments that front-end and back-end dev are fundamentally different on a technical level and/or that they should be done by different people or that the same person can't be good at both. Compared to other programming fields, such as traditional desktop applications or embedded real time systems, front- and back-end on the web are quite similar in the skills and technologies they use, and I don't think drawing a clear line between them is very helpful (that is, I agree with the original article that started this discussion on this point).
  - mercer 6y ago
    front-end: webpack/parcel/etc. configs, plugins, css-, js- and asset-'transpilation'. arcane CSS knowledge, keeping up with HTML developments, learning about promises, no async, no web-workers, react hooks, etc. back-end: perhaps less, uh, dynamic, but: db architecture, SQL, much more CLI/linuxy stuff, server security, API design, version control, deployment, containers, ansible, load-balancing, nginx config... The difference not primarily being a sort of 'core' skillset, but rather purely learning and remembering the intricacies of all these things. That's too much for most people. EDIT: I find that there's a definite sense of 'progress' or 'leveling-up' in all these areas put together. I get better at finding the right documentation, finding the best places to go for help, figuring out what the foot-guns are as well as distinguishing fads from truly worthwhile developments. I get better at 'intuiting' where I might need to take a deep dive to truly understand things, or where I might need to consult an expert. It gets easier to take lessons from one area and apply them to another. But ultimately there's still so much 'domain knowledge', much of it shifting and changing, even if just because the client cares about it, that it's hard to keep up in both the front- and back-end world. And even if that shouldn't have to be necessary, in practice it often is. For example, I've been doing more back-end stuff for the past few years. I keep an eye on what's happing in the js/React world as that is what I mostly did before. I struggle with setting up a new project because apparently Webpack changed, apparently we do CSS in js now, and apparently hooks are the hot new thing. I have a /lot/ of time to study all of this, but unless I actually work on a project that uses all this fancy new stuff, it doesn't really properly become part of my skillset. The same goes for backend stuff. I can set up proper Linux servers 'in anger', but apparently now it's pretty useful to know how to use Amazon/Moft serverless stuff and I just never got to that. And I'm single and almost permanently reading up on all this fancy new stuff!
murgindrag 6y ago
> It is becoming clear to me that much of the perceived difference of opinion here is just because of terminology. I was thinking of "development" as meaning specifically the programming side of things. This is quite distinct from the other skills you mentioned like responsive design or database design. I don't think you can break things up like this. Good developers can work one, sometimes two layers in each direction. A back-end developer who can't design a database is a lousy back-end developer. A front-end developer who implements user interfaces handed over from a designer is a lousy front-end developer. Pigeonholing people isn't helpful, but it is helpful to (1) Recognize that there are distinct, deep skill sets (2) Known when and how to organize teams and software. Some benefit from vertical splits, and some from horizontal. There aren't universals here.
- Silhouette 6y ago
  I agree entirely that there are many different skill sets involved in building a web application, and I also very much agree that there are no universal rules for how to organise the team building a web application. I'm just arguing, following the spirit of the article we're discussing here, that there is no inherent reason the same person can't have both front-end and back-end programming skills, and can't perform both of those functions proficiently. Of course there are many non-programming skills involved as well, but I don't accept your premise that a back-end developer should necessarily know how to design a database or that a front-end developer should necessarily know how to do all the design work for a UI. Plenty of web applications aren't backed by a database at all, so the first claim is clearly not universally true. Plenty of organisations have people dedicated to their design and branding, and that might be shared across all media, so again it's clearly not always the case that someone doing front-end programming must also be able to handle those aspects in order to be competent or useful. Given that front- and back-end programming are much closer in the skills required than either is to user interface design, graphic design, creating digital art, understanding accessibility and usability issues, designing and maintaining an efficient database or system administration, among other relevant skill sets, it seems entirely reasonable to me that a project might want to have the same team responsible for all programming, and have different people doing things like the UI design and the database and system administration. Another team might have people with different mixes of skills and might use them more along the lines you described. All projects and all project teams are different.

jasode 6y ago

>, I've never really understood it. It's just programming, like any other software project. [...] But the fundamentals of programming are still much the same whatever you're building. It doesn't matter if the underlying programming fundamentals are the same because the human brain still has preferences on what it wants to work on. The mistake is applying some "umbrella term" (i.e. "programming") for an activity and thinking that will automatically make all sub categories attract the same interest level. It doesn't work that way. This same phenomenon happens in other intellectual activities such as mathematics, writing, painting, etc: One mathematician might prefer to study algebraic topology while another mathematician prefers to work on number theory. Thus, saying, "I don't get it -- it's all _math_ so why should one person have more interest in one branch vs another?!?" ... does not remove the preference. One writer may prefer to write political analysis essays and never writes fiction -- but another writer prefers to write fiction and never opinion pieces on current events. Therefore, saying, "I don't get the fiction/non-fiction dichotomy because both activities are just the same task of manipulating _words_?!?" ... doesn't make a preferred interest disappear. Yes, some authors write both fiction and non-fiction but the existence of them still doesn't remove the preference of other authors who specialize in just one. Even within sub-category of fiction, you get sub-specialization of "mystery novels" instead of "romance novels". Likewise, saying "painting is painting" does not change the fact that an artist might prefer to always paint landscapes and never horses or people. >It is becoming clear to me that much of the perceived difference of opinion here is just because of terminology. I was thinking of "development" as meaning specifically the programming side of things. [...] and trying to pigeonhole people or restrict anything to only certain combinations is not necessarily either realistic or helpful. Some people naturally just want to pigeonhole themselves. I've done frontend work on old DOS machines (text-based UI), raw Win32 API, VB/C# GUI forms, Javascript/HTML -- and I don't like any of it. I prefer to program the backend algorithms. Yes, coding a loop to "iterate through all window controls to enlarge them by 10% in the GUI" has something in common with "iterate through all nodes of a graph to optimize a path" ... because they're both "loops" ... but they have very different levels of intellectual satisfaction. I won't argue with you if you feel that they should feel exactly the same because they're both "programming" but I can't help it that I don't derive the same enjoyment. If I was employed by Google, I'd enjoy working on the backend ranking algorithms. To a lesser degree, I'd be ok with working on the spider crawlers. But I'd quit if they assigned me to work on the web frontend where users type in queries. But I'm also glad there are developers who prefer to work on the frontend instead of the backend because it allows people like me to stay with my preference.

Silhouette 6y ago
FWIW, I'm not trying to suggest that front-end and back-end dev are the same and that no-one will have any preference for one or the other. Of course they feel different and some people will enjoy one thing or another more. My objection is to the common arguments that front-end and back-end dev are fundamentally different on a technical level and/or that they should be done by different people or that the same person can't be good at both. Compared to other programming fields, such as traditional desktop applications or embedded real time systems, front- and back-end on the web are quite similar in the skills and technologies they use, and I don't think drawing a clear line between them is very helpful (that is, I agree with the original article that started this discussion on this point).
- mercer 6y ago
  front-end: webpack/parcel/etc. configs, plugins, css-, js- and asset-'transpilation'. arcane CSS knowledge, keeping up with HTML developments, learning about promises, no async, no web-workers, react hooks, etc. back-end: perhaps less, uh, dynamic, but: db architecture, SQL, much more CLI/linuxy stuff, server security, API design, version control, deployment, containers, ansible, load-balancing, nginx config... The difference not primarily being a sort of 'core' skillset, but rather purely learning and remembering the intricacies of all these things. That's too much for most people. EDIT: I find that there's a definite sense of 'progress' or 'leveling-up' in all these areas put together. I get better at finding the right documentation, finding the best places to go for help, figuring out what the foot-guns are as well as distinguishing fads from truly worthwhile developments. I get better at 'intuiting' where I might need to take a deep dive to truly understand things, or where I might need to consult an expert. It gets easier to take lessons from one area and apply them to another. But ultimately there's still so much 'domain knowledge', much of it shifting and changing, even if just because the client cares about it, that it's hard to keep up in both the front- and back-end world. And even if that shouldn't have to be necessary, in practice it often is. For example, I've been doing more back-end stuff for the past few years. I keep an eye on what's happing in the js/React world as that is what I mostly did before. I struggle with setting up a new project because apparently Webpack changed, apparently we do CSS in js now, and apparently hooks are the hot new thing. I have a /lot/ of time to study all of this, but unless I actually work on a project that uses all this fancy new stuff, it doesn't really properly become part of my skillset. The same goes for backend stuff. I can set up proper Linux servers 'in anger', but apparently now it's pretty useful to know how to use Amazon/Moft serverless stuff and I just never got to that. And I'm single and almost permanently reading up on all this fancy new stuff!

murgindrag 6y ago

> It is becoming clear to me that much of the perceived difference of opinion here is just because of terminology. I was thinking of "development" as meaning specifically the programming side of things. This is quite distinct from the other skills you mentioned like responsive design or database design. I don't think you can break things up like this. Good developers can work one, sometimes two layers in each direction. A back-end developer who can't design a database is a lousy back-end developer. A front-end developer who implements user interfaces handed over from a designer is a lousy front-end developer. Pigeonholing people isn't helpful, but it is helpful to (1) Recognize that there are distinct, deep skill sets (2) Known when and how to organize teams and software. Some benefit from vertical splits, and some from horizontal. There aren't universals here.

Silhouette 6y ago
I agree entirely that there are many different skill sets involved in building a web application, and I also very much agree that there are no universal rules for how to organise the team building a web application. I'm just arguing, following the spirit of the article we're discussing here, that there is no inherent reason the same person can't have both front-end and back-end programming skills, and can't perform both of those functions proficiently. Of course there are many non-programming skills involved as well, but I don't accept your premise that a back-end developer should necessarily know how to design a database or that a front-end developer should necessarily know how to do all the design work for a UI. Plenty of web applications aren't backed by a database at all, so the first claim is clearly not universally true. Plenty of organisations have people dedicated to their design and branding, and that might be shared across all media, so again it's clearly not always the case that someone doing front-end programming must also be able to handle those aspects in order to be competent or useful. Given that front- and back-end programming are much closer in the skills required than either is to user interface design, graphic design, creating digital art, understanding accessibility and usability issues, designing and maintaining an efficient database or system administration, among other relevant skill sets, it seems entirely reasonable to me that a project might want to have the same team responsible for all programming, and have different people doing things like the UI design and the database and system administration. Another team might have people with different mixes of skills and might use them more along the lines you described. All projects and all project teams are different.