4 ms·

Web development's difficulty is a shallow complexity that doesn't require (deep) problem solving ability so much as it requires a willingness to tolerate tedium

Web development's difficulty is a shallow complexity that doesn't require (deep) problem solving ability so much as it requires a willingness to tolerate tedium. The kicker is that, in my opinion, almost all of the complexity in webdev is superficial and to a high degree artificially (by choosing an inappropriate application data transport protocol,HTTP) introduced precisely because of the perception that developer talent in the field is cheap (cheaper than alternatives at least). Edit: and from your other comment suggesting you can get a $60k offer to somebody implies there is not a real shortage of talent (good or otherwise) and that you consider webdev to be a commodity, and not actually "hard".

vinceguidry 12y ago
I do not find web dev tedious. Not at all. Not even a little bit. I solve problems once. Once solved, if I need the solution again, I refactor or extract the needed solution to a library and reuse it. If I find myself writing the same kind of code enough times to where if I continued it'd become tedious, I switch gears and start looking for an abstraction. Web applications 'grow'. Their growth needs to be managed. If you don't manage it well, your business needs suffer horribly. > and from your other comment suggesting you can get a $60k offer to somebody implies there is not a real shortage of talent (good or otherwise) and that you consider webdev to be a commodity, and not actually "hard". No it means that we've tried the corporate approach and found it a non-starter, so I have lots of leeway to drive the hiring process. There just aren't any good candidates willing to work for the money we're willing to pay. I have to lead up front with our salary because we've done it too many times where once salary comes up the whole process breaks down.
- totalrobe 12y ago
  > There just aren't any good candidates willing to work for the money we're willing to pay. ...so pay more money? Or take a chance on the not so good candidates and have a great training program? Or start an internship/co-op program at a local university and find cheaper talent. Get creative.
  - vinceguidry 12y ago
    You realize it's not just me making decisions, right? The company wants what it wants.
    - totalrobe 12y ago
      Unless "the company" is an AI from the future, "the company" is made of people that can possibly be influenced to try something new. Except nothing I said is revolutionary. If you want to hire experienced devs, you'll have to pay more than entry level.
ritchiea 12y ago
What areas of software development require deep problem solving?
jghn 12y ago
To be fair to vinceguidry I think a few things are at play here: - web development is a monstrous sub-field in the software engineering field. As others have pointed out, just about everything has some sort of web presence somewhere. There's a pretty big difference between someone doing something groundbreaking and novel and someone making the 920375235236th standard CRUD oriented java enterprise site. The latter camp will grossly outnumber the former camp by multiple orders of magnitude, but I think it's clear that what vinceguidry is referring to is the former (at least I hope he is) - People tend to think that their sub-field in the software world is some sort of special snowflake that makes it harder to deal with than the others. They're aware of the tricky bits of their sub-field due to having a ton of specialized knowledge, but then look at the other ones and mainly see the surface scratching bits and declare, "Oh, that's easy!". - Everyone has different strengths and weaknesses and will tend to gravitate towards the areas that they'll excel at. People also like to think that they're smart and that their coworkers are smart, so assumptions can be made that all of the smart people are gravitating where they're heading. To loop back to the OP a bit here, HN has a strong bias towards bay area startup culture which has a strong bias towards web development (generally of the former category I described above, at least they all would self-report themselves in that category) so everything is going to be seen through that bias. In my circle of software friends we span a pretty broad range of the industry. Over time the view we've taken when discussing each other's world is that we all could rapidly learn to do the jobs that the others do, however most of us wouldn't want to. Personally my point of pain is when I start hearing about UI oriented stuff, but when I start talking about reworking algorithms to scale from GB to PB that's when they start tuning out. Neither's harder, they're just different.
- vinceguidry 12y ago
  > someone making the 920375235236th standard CRUD oriented java enterprise site People always think this when they think CRUD. The reality is, even CRUD can get quite complex. Even just laying out an HTML page properly takes a lot of knowledge. Understanding the 'zen' of CSS. The zen of HTML5. The zen of jQuery. What looks simple on the surface can get very complicated quickly. If you don't respect that complexity, then you'll find it tedious, and won't apply your problem-solving mind to it, won't abstract that difficulty away, and will find it unbelievably painful to maintain and add features to later on down the line. I'm making what looks on the surface to be standard CRUD. A product info management app. Well, the product data itself are key-value pairs and the design calls for you to be able to edit which keys you're able to put in. So there's no set database schema, and I don't want to do anything like making a two-column table of values that has a zillion rows, so I'm using Postgres Hstore. Now I have to maintain an abstraction layer over that which has gone through a few iterations and might have to withstand a few more. It makes creating views difficult because you don't know just how big everything's going to be. So I might spend a whole day laying out the list page, diving into the minutiae of CSS rules, thinking carefully about all the different types of data it's supposed to display and deciding where to put certain types of logic so that I can reuse it later if needed. The thing about CRUD is that to really do it right, you have to also think carefully about the data domain. If you're not building flexibly, which takes up-front time, then when you have to move stuff it's going to feel really painful. I realized that I don't want the ability to add new SKUs to be accessible to normal users, so I moved it into the admin section. It took five minutes and was as straightforward as it sounds. But if you're not all that great at web dev and/or don't respect the power tools at your disposal, such a move could take all day and introduce subtle bugs in your UX that you won't catch until next week when you're working on something else. If you really are trying to re-solve a solved problem, like blogging, then don't do any programming at all, just fire up Wordpress. Absolutely solving solved problems again is going to be tedious. But if you're building a CRUD app, and you can't find something interesting about it, then you're not really applying your full mind to it. There's a reason you're being asked to build it, because the functionality they need isn't being offered elsewhere. I built a vehicle reservation system that was "standard CRUD" but they wanted this dashboard style view that took up half the dev time that I thought was really interesting and turned out great. The rest of the CRUD came out easy, we have lots of tools at our disposal for generating that sort of thing.

vinceguidry 12y ago

I do not find web dev tedious. Not at all. Not even a little bit. I solve problems once. Once solved, if I need the solution again, I refactor or extract the needed solution to a library and reuse it. If I find myself writing the same kind of code enough times to where if I continued it'd become tedious, I switch gears and start looking for an abstraction. Web applications 'grow'. Their growth needs to be managed. If you don't manage it well, your business needs suffer horribly. > and from your other comment suggesting you can get a $60k offer to somebody implies there is not a real shortage of talent (good or otherwise) and that you consider webdev to be a commodity, and not actually "hard". No it means that we've tried the corporate approach and found it a non-starter, so I have lots of leeway to drive the hiring process. There just aren't any good candidates willing to work for the money we're willing to pay. I have to lead up front with our salary because we've done it too many times where once salary comes up the whole process breaks down.

totalrobe 12y ago
> There just aren't any good candidates willing to work for the money we're willing to pay. ...so pay more money? Or take a chance on the not so good candidates and have a great training program? Or start an internship/co-op program at a local university and find cheaper talent. Get creative.
- vinceguidry 12y ago
  You realize it's not just me making decisions, right? The company wants what it wants.
  - totalrobe 12y ago
    Unless "the company" is an AI from the future, "the company" is made of people that can possibly be influenced to try something new. Except nothing I said is revolutionary. If you want to hire experienced devs, you'll have to pay more than entry level.

ritchiea 12y ago

What areas of software development require deep problem solving?

jghn 12y ago

To be fair to vinceguidry I think a few things are at play here: - web development is a monstrous sub-field in the software engineering field. As others have pointed out, just about everything has some sort of web presence somewhere. There's a pretty big difference between someone doing something groundbreaking and novel and someone making the 920375235236th standard CRUD oriented java enterprise site. The latter camp will grossly outnumber the former camp by multiple orders of magnitude, but I think it's clear that what vinceguidry is referring to is the former (at least I hope he is) - People tend to think that their sub-field in the software world is some sort of special snowflake that makes it harder to deal with than the others. They're aware of the tricky bits of their sub-field due to having a ton of specialized knowledge, but then look at the other ones and mainly see the surface scratching bits and declare, "Oh, that's easy!". - Everyone has different strengths and weaknesses and will tend to gravitate towards the areas that they'll excel at. People also like to think that they're smart and that their coworkers are smart, so assumptions can be made that all of the smart people are gravitating where they're heading. To loop back to the OP a bit here, HN has a strong bias towards bay area startup culture which has a strong bias towards web development (generally of the former category I described above, at least they all would self-report themselves in that category) so everything is going to be seen through that bias. In my circle of software friends we span a pretty broad range of the industry. Over time the view we've taken when discussing each other's world is that we all could rapidly learn to do the jobs that the others do, however most of us wouldn't want to. Personally my point of pain is when I start hearing about UI oriented stuff, but when I start talking about reworking algorithms to scale from GB to PB that's when they start tuning out. Neither's harder, they're just different.

vinceguidry 12y ago
> someone making the 920375235236th standard CRUD oriented java enterprise site People always think this when they think CRUD. The reality is, even CRUD can get quite complex. Even just laying out an HTML page properly takes a lot of knowledge. Understanding the 'zen' of CSS. The zen of HTML5. The zen of jQuery. What looks simple on the surface can get very complicated quickly. If you don't respect that complexity, then you'll find it tedious, and won't apply your problem-solving mind to it, won't abstract that difficulty away, and will find it unbelievably painful to maintain and add features to later on down the line. I'm making what looks on the surface to be standard CRUD. A product info management app. Well, the product data itself are key-value pairs and the design calls for you to be able to edit which keys you're able to put in. So there's no set database schema, and I don't want to do anything like making a two-column table of values that has a zillion rows, so I'm using Postgres Hstore. Now I have to maintain an abstraction layer over that which has gone through a few iterations and might have to withstand a few more. It makes creating views difficult because you don't know just how big everything's going to be. So I might spend a whole day laying out the list page, diving into the minutiae of CSS rules, thinking carefully about all the different types of data it's supposed to display and deciding where to put certain types of logic so that I can reuse it later if needed. The thing about CRUD is that to really do it right, you have to also think carefully about the data domain. If you're not building flexibly, which takes up-front time, then when you have to move stuff it's going to feel really painful. I realized that I don't want the ability to add new SKUs to be accessible to normal users, so I moved it into the admin section. It took five minutes and was as straightforward as it sounds. But if you're not all that great at web dev and/or don't respect the power tools at your disposal, such a move could take all day and introduce subtle bugs in your UX that you won't catch until next week when you're working on something else. If you really are trying to re-solve a solved problem, like blogging, then don't do any programming at all, just fire up Wordpress. Absolutely solving solved problems again is going to be tedious. But if you're building a CRUD app, and you can't find something interesting about it, then you're not really applying your full mind to it. There's a reason you're being asked to build it, because the functionality they need isn't being offered elsewhere. I built a vehicle reservation system that was "standard CRUD" but they wanted this dashboard style view that took up half the dev time that I thought was really interesting and turned out great. The rest of the CRUD came out easy, we have lots of tools at our disposal for generating that sort of thing.