4 ms·

No, I lived the C-explosion of 30 years ago and it was absolutely nothing like what I see these days. It utterly nuts how we are expected a learn a full-stack

by cubano 11y ago

No, I lived the C-explosion of 30 years ago and it was absolutely nothing like what I see these days. It utterly nuts how we are expected a learn a full-stack like Mongo/Angular/Backbone and then 6 months later is like NO we need AWS/React/Redux now! It's my oldman opinion that IT has become too much like fashion and not enough like engineering, but that's what oldmen think so who cares.

wonnage 11y ago
You can either shut yourself off from it and cement yourself into "oldman" oblivion, or actually try to understand why these tools exist.
- LoSboccacc 11y ago
  We old coot understand well why such inane tools exists and it's because there are too many people worrking in a hurry and can't be bothered to look back at sound engineering solution that already exists.
- manyxcxi 11y ago
  > You can either shut yourself off from it and cement yourself into "oldman" oblivion, or actually try to understand why these tools exist. For other languages/ecosystems I would agree. However, in the JS world there is a lot of stuff that exists simply to exist. There are typically multiple libraries to do the same thing (in general) but with someone else's opinionated take on it. Sometimes I feel like the developer of framework B was having a hard time grokking framework A and just decided to roll their own, like framework A, except for the parts they didn't like or understand. Then someone came along and realized that framework B had gaping security issues and was horrifically slow- so they created framework C which is the more secure and performant opiniated take on framework B that was an opinionated take on framework A. But then after four long months the devs behind C no longer maintain it because they've moved on to WebAssembly so a team spins off a fork of C in Coffeescript. In a lot of other communities they would've just evolved framework A, or C would've pushed some patches back to B. Or D would've taken over for C and there would've been a handoff. It's effing ridiculous that if I go back to a 5 month old project I will spend all damn day getting a build from source to work. It's not just the libraries and packages. It's the toolchain, the build pipeline (heaven forbid you look like a grandpa and still use Grunt!), the transpilers. I love that people are creating cool shit all the time, but it really seems like if the code didn't come from their team, they're going to iterate the idea and put out a competing package instead of contributing back to the original. And then we wind up with two unmaintained projects 6 months later... It really feels like there aren't many people (at least making headlines) that have had to maintain an actual live production system for more than a year or two. It'll be interesting to see what these people are doing 5 years down the road...
- pjmlp 11y ago
  We old dogs have seen this movie too many times, hence we learned to wait for the dust to settle, pick up the bodies and get on with our life. Not worth spending energy in worthless battles using tech that might be dead tomorrow.
BWStearns 11y ago
I wasn't around for the C-explosion but it seems like something that is exacerbated by the current ease and normalization of sharing code. Make a framework? Post it on github, go to a conference, write some blog posts, get your framework its own conference, ?, profit! (now I'm thinking of that Southpark guitar hero episode but with famo.us as Stan) There's incentive to put out new tools for the producers of those tools. On the user side it's easier than ever to learn new tech and framework. I'm learning Clojure and in a few weeks I've asked at least five questions about libraries and frameworks on stackoverflow and slack that have been answered by the authors of those tools. It's 3am on a Tuesday/Wednesday and there are still people helping each other out all over the internet, writing how-to blogs, answering Stack questions. As an aside, for all the weird pathologies of this profession and our community I think that's pretty awesome. My point is that even though the continuing learning burden might be volumetrically much larger, I'm not sure it's significantly more difficult.
z3t4 11y ago
Don't worry, it's mainly in the HN bubble, reading HN every day will after some years make you think this is how the world looks like. Most developers haven't even heard about Mongo/Angular/Backbone yet, heck, I even have to explain tree times that JavaScript is NOT Java.
- S4M 11y ago
  > Most developers haven't even heard about Mongo/Angular/Backbone yet, heck, I even have to explain tree times that JavaScript is NOT Java. Yes, but those developers are not doing front end web development for a living.
yoonay 11y ago
I would just like to say that Mongo/Angular/Backbone is not a really valid stack since Angular and Backbone are pretty much competing technologies. You can probably mix them up but I hope no one really does that. Your second example of AWS/React/Redux is also a little weird since AWS is a cloud platform and it offers around 50 or so products. You can run a CGI based web app programmed with Perl in EC2 if you wish, and you can do that as easily as 15 years ago if you learned it back then. As a younger web developer sort of a guy, I'd say that the current situation is not something where you have to be learning a whole new set of tools every 6 months. You can still easily find a job if you know for example Angular 1.x, some CSS, and understand how to create a stateless JSON API using whatever language you are comfortable with. Betting on the strongest horses of the front end side has had you learn two different technologies (both in the same language) in the past four years, I'd say that's not too much asked. In the back end cloud platforms have really taken over, but it's not really that different from 15 years ago when people ran their own hardware. Linux is still the king, now you can just choose whether you want to be in 100% control of the infrastructure or actually make your life easier by purchasing a PaaS (e.g. heroku, beanstalk).
- cubano 11y ago
  > I would just like to say that Mongo/Angular/Backbone is not a really valid stack since Angular and Backbone are pretty much competing technologies. You can probably mix them up but I hope no one really does that. Yes yes, I know :) I played a bit too fast and loose with that particular example but it was late and it was more to make a rather hurried point then to actually engineer a production stack. But facts are facts, so I appreciate the correction.
maze-le 11y ago
> how we are expected a learn a full-stack like Mongo/Angular/Backbone and then 6 months later is like NO we need AWS/React/Redux now! I live under the assumption that you don't have to. The thing you should figure out is: finding a stack that suits your needs (and the needs of your customers) best. If you find it, is is perfectly reasonable to beeing a bit more conservative and stick with it. On the backend for example I used rails for years, and with good reason. I am not planning to switch, but I am open enough to consider my options and experiment with other stuff. I know there are (maybe pretty good) alternatives: enterprisey Java-frameworks; good old django; nodejs; experimental stuff with erlang or haskell. I think the frontend/js-world is not so much different. You don't have to know every framework, because it is the latest hot shit... It is not wrong knowing the strenghts and weaknesses of new frameworks, but you don't have to use and adopt to everything thats new.
officialchicken 11y ago
I care ;) I agree it's too fashionable and not just plain old good engineering. And thanks for the clarity! Now we have to live with too many engineers whose mind have been demented by the 'move fast and break things' philosophy.

by cubano 11y ago

wonnage 11y ago

You can either shut yourself off from it and cement yourself into "oldman" oblivion, or actually try to understand why these tools exist.

LoSboccacc 11y ago
We old coot understand well why such inane tools exists and it's because there are too many people worrking in a hurry and can't be bothered to look back at sound engineering solution that already exists.
manyxcxi 11y ago
> You can either shut yourself off from it and cement yourself into "oldman" oblivion, or actually try to understand why these tools exist. For other languages/ecosystems I would agree. However, in the JS world there is a lot of stuff that exists simply to exist. There are typically multiple libraries to do the same thing (in general) but with someone else's opinionated take on it. Sometimes I feel like the developer of framework B was having a hard time grokking framework A and just decided to roll their own, like framework A, except for the parts they didn't like or understand. Then someone came along and realized that framework B had gaping security issues and was horrifically slow- so they created framework C which is the more secure and performant opiniated take on framework B that was an opinionated take on framework A. But then after four long months the devs behind C no longer maintain it because they've moved on to WebAssembly so a team spins off a fork of C in Coffeescript. In a lot of other communities they would've just evolved framework A, or C would've pushed some patches back to B. Or D would've taken over for C and there would've been a handoff. It's effing ridiculous that if I go back to a 5 month old project I will spend all damn day getting a build from source to work. It's not just the libraries and packages. It's the toolchain, the build pipeline (heaven forbid you look like a grandpa and still use Grunt!), the transpilers. I love that people are creating cool shit all the time, but it really seems like if the code didn't come from their team, they're going to iterate the idea and put out a competing package instead of contributing back to the original. And then we wind up with two unmaintained projects 6 months later... It really feels like there aren't many people (at least making headlines) that have had to maintain an actual live production system for more than a year or two. It'll be interesting to see what these people are doing 5 years down the road...
pjmlp 11y ago
We old dogs have seen this movie too many times, hence we learned to wait for the dust to settle, pick up the bodies and get on with our life. Not worth spending energy in worthless battles using tech that might be dead tomorrow.

BWStearns 11y ago

I wasn't around for the C-explosion but it seems like something that is exacerbated by the current ease and normalization of sharing code. Make a framework? Post it on github, go to a conference, write some blog posts, get your framework its own conference, ?, profit! (now I'm thinking of that Southpark guitar hero episode but with famo.us as Stan) There's incentive to put out new tools for the producers of those tools. On the user side it's easier than ever to learn new tech and framework. I'm learning Clojure and in a few weeks I've asked at least five questions about libraries and frameworks on stackoverflow and slack that have been answered by the authors of those tools. It's 3am on a Tuesday/Wednesday and there are still people helping each other out all over the internet, writing how-to blogs, answering Stack questions. As an aside, for all the weird pathologies of this profession and our community I think that's pretty awesome. My point is that even though the continuing learning burden might be volumetrically much larger, I'm not sure it's significantly more difficult.

z3t4 11y ago

Don't worry, it's mainly in the HN bubble, reading HN every day will after some years make you think this is how the world looks like. Most developers haven't even heard about Mongo/Angular/Backbone yet, heck, I even have to explain tree times that JavaScript is NOT Java.

S4M 11y ago
> Most developers haven't even heard about Mongo/Angular/Backbone yet, heck, I even have to explain tree times that JavaScript is NOT Java. Yes, but those developers are not doing front end web development for a living.

yoonay 11y ago

I would just like to say that Mongo/Angular/Backbone is not a really valid stack since Angular and Backbone are pretty much competing technologies. You can probably mix them up but I hope no one really does that. Your second example of AWS/React/Redux is also a little weird since AWS is a cloud platform and it offers around 50 or so products. You can run a CGI based web app programmed with Perl in EC2 if you wish, and you can do that as easily as 15 years ago if you learned it back then. As a younger web developer sort of a guy, I'd say that the current situation is not something where you have to be learning a whole new set of tools every 6 months. You can still easily find a job if you know for example Angular 1.x, some CSS, and understand how to create a stateless JSON API using whatever language you are comfortable with. Betting on the strongest horses of the front end side has had you learn two different technologies (both in the same language) in the past four years, I'd say that's not too much asked. In the back end cloud platforms have really taken over, but it's not really that different from 15 years ago when people ran their own hardware. Linux is still the king, now you can just choose whether you want to be in 100% control of the infrastructure or actually make your life easier by purchasing a PaaS (e.g. heroku, beanstalk).

cubano 11y ago
> I would just like to say that Mongo/Angular/Backbone is not a really valid stack since Angular and Backbone are pretty much competing technologies. You can probably mix them up but I hope no one really does that. Yes yes, I know :) I played a bit too fast and loose with that particular example but it was late and it was more to make a rather hurried point then to actually engineer a production stack. But facts are facts, so I appreciate the correction.

maze-le 11y ago

> how we are expected a learn a full-stack like Mongo/Angular/Backbone and then 6 months later is like NO we need AWS/React/Redux now! I live under the assumption that you don't have to. The thing you should figure out is: finding a stack that suits your needs (and the needs of your customers) best. If you find it, is is perfectly reasonable to beeing a bit more conservative and stick with it. On the backend for example I used rails for years, and with good reason. I am not planning to switch, but I am open enough to consider my options and experiment with other stuff. I know there are (maybe pretty good) alternatives: enterprisey Java-frameworks; good old django; nodejs; experimental stuff with erlang or haskell. I think the frontend/js-world is not so much different. You don't have to know every framework, because it is the latest hot shit... It is not wrong knowing the strenghts and weaknesses of new frameworks, but you don't have to use and adopt to everything thats new.

officialchicken 11y ago

I care ;) I agree it's too fashionable and not just plain old good engineering. And thanks for the clarity! Now we have to live with too many engineers whose mind have been demented by the 'move fast and break things' philosophy.