5 ms·

As a full-stack-but-primarily-back-end web developer, I somewhat resent the OP's implication that web developers are lesser than other developers. Why are we di

As a full-stack-but-primarily-back-end web developer, I somewhat resent the OP's implication that web developers are lesser than other developers. Why are we distinct from "algorithm developers" and "application/db developers" when what we develop are applications that interact with databases and often require fairly sophisticated algorithms? Can't we just agree that different types of developers work with different technologies and skillsets and one isn't inherently better or worse than another based solely on which technologies they work with? All that aside… the "rockstar" attitude rankles, though really, it's something you'll mostly see in job listings and such than from web developers themselves. I can't recall meeting any developers in this industry who would refer to themselves as a rockstar with a straight face, but I've met a couple bosses who said things like "we only hire rockstars" and such. So to the extent that a skilled web developer seriously says they're a rockstar, they probably only do so to angle for a job, I'd imagine.

BrainInAJar 11y ago
Mostly people get these notions when web developers call themselves "full stack" when their stack starts after the DB delivers them data and stops when they deliver data to a browser. There's a whole lot of stack under & including the database and a whole lot in the browser & js engine.
- Albright 11y ago
  That's an interesting argument, but in the field of web development, "full stack" has a particular meaning, so you're kind of arguing that a widely-used and -understood term in this field should have a different definition than what's currently agreed upon, and, well, I don't think many people are going to be too receptive to that.
bonobo3000 11y ago
Call me an ahole, but I really think that web dev does not require nearly as much deep knowledge of computers as an engineer working on lower levels of the stack. Each web app usually solves the same tired problems again: interface with a db, present data, cache stuff, handle user accounts etc.. There is some meaty stuff - perhaps caching and serious performance optimization, but most of a web app is either front-end CSS stuff, or interfacing with a DB to fetch data. Yes, there is definitely work to be done in making a web-app, and i don't think its easy at all to get a website to be really fast or get the styling right across 100s of devices, but its not always technically challenging work IMO. I am NOT saying that web devs are worse, but yes, I am saying that the job generally requires less deep technical knowledge, and perhaps more of other skills i know nothing about :p This is the rationale for why I choose not to go into webdev, because i love solving meaty problems. I would love to hear your perspective and be proven wrong though.
- matthewmacleod 11y ago
  This entire comment is just nonsense. Web development is equivalent to any other level of the computing stack. That is, there are good developers working on solving complex problems, and bad developers churning out mediocre software that doesn't really do anything "meaty". I see absolutely no evidence that web development is any less technically challenging than any other field – the fact that there are loads of developers churning out cookie-cutter CRUD apps doesn't mean that's the whole field.
- Albright 11y ago
  I will not call you an ahole because you're at least conceding that you may be wrong about web development not being "meaty." Let's see if I can argue that there is indeed meat in web development. Let's look at your "tired problems." "Interface with a database." Yep. Hey, which database? Do you use the tired and true MySQL? Do you trade up to Postgres's improved features in exchange for possibly reduced compatibility? Do you do NoSQL like all the cool kids? Great, now which NoSQL database? Will your app really benefit from it? Okay, you picked a database; do you write SQL directly, or use a pre-built database layer/ORM of some sort? If the former, do you know how to escape your arguments and make sure you're not inviting injection exploits? Do you know how to write efficient queries that will touch as few database rows as possible? If the latter, will it hide needed capability from you or behave much slower than using straight SQL? What are the trade-offs? Do you perhaps use specialty databases like Solr for search or Redis for key-value storage in addition to your main one? Is the increased complexity worth the potential speed or flexibility increases? Can you make sure queries to those databases are secure too? Or "handling user accounts." Oh my God, okay. Do you let people sign up with usernames? Just email addresses? Do you allow multiple accounts with the same email address? If someone has signed up with the username "Helen" (with an ell), do you let someone else sign up as "He1en" (with a one) or "He|en" (with a pipe) and possibly impersonate them? How do you store the password? No, that's wrong. No, that's also wrong. How do you let people reset their password if they forget it? Oh, wow, that's very wrong! Are you storing credit card numbers or addresses or other personal information? How do you do user permissions, so some user accounts have administration permissions that others don't? How do you avoid XSS exploits that might allow an unprivileged user from taking over an administrator account? What if you want someone who's between a normal user and an administrator who has some edit privileges but can't take down the whole site? Okay, got all that worked out? Okay, now make it respond in 200ms or less from all points in the world. And compliant with these government regulations the client is just now telling you about two weeks before the scheduled launch. And also look and work the same in Spanish, Traditional Chinese, Simplified Chinese, five different strains of Arabic, and, most cruelly, German, whose long words bring many unprepared web designers to tears. And on mobile. Granted, many devs will work with a framework or CMS that helps solve some of these issues for us, but even then we need to understand the inner workings of that system and what the trade-offs are in order to truly exploit it.

BrainInAJar 11y ago

Mostly people get these notions when web developers call themselves "full stack" when their stack starts after the DB delivers them data and stops when they deliver data to a browser. There's a whole lot of stack under & including the database and a whole lot in the browser & js engine.

Albright 11y ago
That's an interesting argument, but in the field of web development, "full stack" has a particular meaning, so you're kind of arguing that a widely-used and -understood term in this field should have a different definition than what's currently agreed upon, and, well, I don't think many people are going to be too receptive to that.

bonobo3000 11y ago

Call me an ahole, but I really think that web dev does not require nearly as much deep knowledge of computers as an engineer working on lower levels of the stack. Each web app usually solves the same tired problems again: interface with a db, present data, cache stuff, handle user accounts etc.. There is some meaty stuff - perhaps caching and serious performance optimization, but most of a web app is either front-end CSS stuff, or interfacing with a DB to fetch data. Yes, there is definitely work to be done in making a web-app, and i don't think its easy at all to get a website to be really fast or get the styling right across 100s of devices, but its not always technically challenging work IMO. I am NOT saying that web devs are worse, but yes, I am saying that the job generally requires less deep technical knowledge, and perhaps more of other skills i know nothing about :p This is the rationale for why I choose not to go into webdev, because i love solving meaty problems. I would love to hear your perspective and be proven wrong though.

matthewmacleod 11y ago
This entire comment is just nonsense. Web development is equivalent to any other level of the computing stack. That is, there are good developers working on solving complex problems, and bad developers churning out mediocre software that doesn't really do anything "meaty". I see absolutely no evidence that web development is any less technically challenging than any other field – the fact that there are loads of developers churning out cookie-cutter CRUD apps doesn't mean that's the whole field.
Albright 11y ago
I will not call you an ahole because you're at least conceding that you may be wrong about web development not being "meaty." Let's see if I can argue that there is indeed meat in web development. Let's look at your "tired problems." "Interface with a database." Yep. Hey, which database? Do you use the tired and true MySQL? Do you trade up to Postgres's improved features in exchange for possibly reduced compatibility? Do you do NoSQL like all the cool kids? Great, now which NoSQL database? Will your app really benefit from it? Okay, you picked a database; do you write SQL directly, or use a pre-built database layer/ORM of some sort? If the former, do you know how to escape your arguments and make sure you're not inviting injection exploits? Do you know how to write efficient queries that will touch as few database rows as possible? If the latter, will it hide needed capability from you or behave much slower than using straight SQL? What are the trade-offs? Do you perhaps use specialty databases like Solr for search or Redis for key-value storage in addition to your main one? Is the increased complexity worth the potential speed or flexibility increases? Can you make sure queries to those databases are secure too? Or "handling user accounts." Oh my God, okay. Do you let people sign up with usernames? Just email addresses? Do you allow multiple accounts with the same email address? If someone has signed up with the username "Helen" (with an ell), do you let someone else sign up as "He1en" (with a one) or "He|en" (with a pipe) and possibly impersonate them? How do you store the password? No, that's wrong. No, that's also wrong. How do you let people reset their password if they forget it? Oh, wow, that's very wrong! Are you storing credit card numbers or addresses or other personal information? How do you do user permissions, so some user accounts have administration permissions that others don't? How do you avoid XSS exploits that might allow an unprivileged user from taking over an administrator account? What if you want someone who's between a normal user and an administrator who has some edit privileges but can't take down the whole site? Okay, got all that worked out? Okay, now make it respond in 200ms or less from all points in the world. And compliant with these government regulations the client is just now telling you about two weeks before the scheduled launch. And also look and work the same in Spanish, Traditional Chinese, Simplified Chinese, five different strains of Arabic, and, most cruelly, German, whose long words bring many unprepared web designers to tears. And on mobile. Granted, many devs will work with a framework or CMS that helps solve some of these issues for us, but even then we need to understand the inner workings of that system and what the trade-offs are in order to truly exploit it.