3 ms·

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 p

by 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.
- jghn 12y ago
  I struggled with how to phrase that and eventually gave up hoping the ridiculous number I supplied would suffice. I agree w/ everything you said, but I'd argue that oodles of software jobs out there are solving solved problems and doing it over and over and over again and these were the sorts of jobs I was trying to evoke.
  - vinceguidry 12y ago
    The argument I'm trying to make is that it's not the job that's boring, it's the programmer that refuses to find something interesting about the job out of the mistaken belief that it's tedious or that it's a solved problem. It's not a solved problem. If it were solved, there would be a software package out there with a huge community, loads of extensions, that you could just use and be done with it. You wouldn't need any programming talent, just a guy smart enough to run an installer. Blogging is a specific case of CRUD that has just such a software package, Wordpress. Even so, Wordpress isn't the perfect solution to all instances of the blogging problem. Maybe you want a static one, maybe you want one in Haskell. Each combination is quite interesting in its own right. Hell, there's lots of things that Wordpress could be doing better. There's lots of things out there that are half-solved, like the more general case of CRUD. Here there are frameworks that allow you to solve specific CRUD problems, but each specific instance of CRUD, for it to really be solved, needs its own software package just like Wordpress with a huge community and easy installer. The vast majority of them don't, so you can't call them solved. That means there's still interesting things to learn about them. Remember 2048? I remember a lot of people saying it wasn't a terribly interesting game. Bullshit it's not! I'm building a Ruby library to run the game, (didn't like any of the ones I found) then I'm going to start building an AI engine to solve it using heuristics. When I play 2048, I've gotten up to 8192 a few times, and would love to be able to program an AI to play like I play. To build tooling to help me visualize my AI programming and watch it operate. 2048 is plenty interesting, if you don't think so, it's you that's the problem, not 2048.

by jghn 12y ago

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.

jghn 12y ago
I struggled with how to phrase that and eventually gave up hoping the ridiculous number I supplied would suffice. I agree w/ everything you said, but I'd argue that oodles of software jobs out there are solving solved problems and doing it over and over and over again and these were the sorts of jobs I was trying to evoke.
- vinceguidry 12y ago
  The argument I'm trying to make is that it's not the job that's boring, it's the programmer that refuses to find something interesting about the job out of the mistaken belief that it's tedious or that it's a solved problem. It's not a solved problem. If it were solved, there would be a software package out there with a huge community, loads of extensions, that you could just use and be done with it. You wouldn't need any programming talent, just a guy smart enough to run an installer. Blogging is a specific case of CRUD that has just such a software package, Wordpress. Even so, Wordpress isn't the perfect solution to all instances of the blogging problem. Maybe you want a static one, maybe you want one in Haskell. Each combination is quite interesting in its own right. Hell, there's lots of things that Wordpress could be doing better. There's lots of things out there that are half-solved, like the more general case of CRUD. Here there are frameworks that allow you to solve specific CRUD problems, but each specific instance of CRUD, for it to really be solved, needs its own software package just like Wordpress with a huge community and easy installer. The vast majority of them don't, so you can't call them solved. That means there's still interesting things to learn about them. Remember 2048? I remember a lot of people saying it wasn't a terribly interesting game. Bullshit it's not! I'm building a Ruby library to run the game, (didn't like any of the ones I found) then I'm going to start building an AI engine to solve it using heuristics. When I play 2048, I've gotten up to 8192 a few times, and would love to be able to program an AI to play like I play. To build tooling to help me visualize my AI programming and watch it operate. 2048 is plenty interesting, if you don't think so, it's you that's the problem, not 2048.