There is no steamroller. I know many programmers feel this way, but in my humble opinion it is a fallacy, and not a very healthy one. No-one can deny that our industry is evolving at breakneck speed, and it is an exhilarating place to be. But just because there's a new technology every week on HN doesn't mean that we are losing old ones at a similar rate. It is perfectly possible to have done nothing but C or Java fo…
My advice to people feverishly trying to keep up with the latest JavaScript frameworks is to take a step back, and learn a new language that's been around - like Java or C++. The only knowledge that's throw-away is too domain specific, too library specific etc.
The Programming Steamroller Waits For No One (2013)
41–48 of 48 posts
Re: The Programming Steamroller Waits For No One (2013)
#42I enjoyed this article. However, haven't many of the core fundamental concepts and abstractions found in computing technologies stayed relatively the same over the past 40 years? Minus the occasional paradigm shift, of course.
It really amazes me that Unix has not only lasted so long, but actually increased in its relevance (being the foundation behind Android, iPhone, OS X, AWS, etc.) How many computing technologies from 1969 are we still in daily contact with? Nassim Taleb has this nice heuristic that says that the expected future life of something is proportional to how long it's been around. So ASCII text will outlast HTML, because it…
Lisp? We're all reading HN which is written in some Lisp dialect. There are also quite a few Clojure devs in here (including me) and a few using other Lisp dialects (and participating in flamewars about what a true Lisp is or is not). Don't know if it counts ^ ^
And then not 1969 but 1976: daily Emacs user here...
Re: The Programming Steamroller Waits For No One (2013)
#43Earlier quoted context omitted.
It really amazes me that Unix has not only lasted so long, but actually increased in its relevance (being the foundation behind Android, iPhone, OS X, AWS, etc.) How many computing technologies from 1969 are we still in daily contact with? Nassim Taleb has this nice heuristic that says that the expected future life of something is proportional to how long it's been around. So ASCII text will outlast HTML, because it…
"How many computing technologies from 1969 are we still in daily contact with?" Lisp? We're all reading HN which is written in some Lisp dialect. There are also quite a few Clojure devs in here (including me) and a few using other Lisp dialects (and participating in flamewars about what a true Lisp is or is not). Don't know if it counts ^ ^ And then not 1969 but 1976: daily Emacs user here...
I have yet to do much with Clojure, mainly because I'm not really in the JVM ecosystem. But I think its focus on immutability is a great contribution to Lisp and will last a long time. It's an idea that transcends a particular implementation.
Re: The Programming Steamroller Waits For No One (2013)
#44Yes. In the world of programming you have to always be learning, but you can take a break from learning, and jump in later if you stay in the same place technologically for too long. It's not like if you fall behind, you need to learn everything in the time period between then and now. You just need to learn now.
Re: The Programming Steamroller Waits For No One (2013)
#45There is no steamroller. I know many programmers feel this way, but in my humble opinion it is a fallacy, and not a very healthy one. No-one can deny that our industry is evolving at breakneck speed, and it is an exhilarating place to be. But just because there's a new technology every week on HN doesn't mean that we are losing old ones at a similar rate. It is perfectly possible to have done nothing but C or Java fo…
I'm in agreement here. The engineers that will lose out are the ones that think that by learning the latest and greatest frameworks and libraries, they are somehow improving in their mastery. This is, in fact, stamp collecting. Fewer and fewer engineers feel comfortable doing the basics. Implementing a raw custom data structure, writing a new parser, twiddling bits on a wire, debugging segmentation faults. The new-ag…
It's far far easier than learning a new language, and it's now common knowledge that you shouldn't make hiring decisions based on what specific languages a candidate knows. I haven't seen a trend in the real world forcing people to know new frameworks as a requirement for a job. In fact, I'd say it's less so than needing to know the language.
Many that put that they "know" a framework that I've seen "know" it just by doing a project in it over a weekend.
Re: The Programming Steamroller Waits For No One (2013)
#46There is no steamroller. I know many programmers feel this way, but in my humble opinion it is a fallacy, and not a very healthy one. No-one can deny that our industry is evolving at breakneck speed, and it is an exhilarating place to be. But just because there's a new technology every week on HN doesn't mean that we are losing old ones at a similar rate. It is perfectly possible to have done nothing but C or Java fo…
There definitely IS a steamroller. However you have to be in your 40s to be able to look back and see it fully. The article was about the grand scheme of things over decades. If you're under 25 you've only really experienced a single decade of the evolution of software. I'm 46 and started coding at age 13, so everything in the article made perfect sense to me.
Re: The Programming Steamroller Waits For No One (2013)
#47In my opinion, this is less of a problem for a programmer than for a product-company. Depending on the size of the change, a reasonably competent programmer can pick up enough of a new programming language or framework in something between a weekend and a month of playing around with it. However, if a company has invested years of work into a product, they can't simply switch the programming language or framework. Wo…
Re: The Programming Steamroller Waits For No One (2013)
#48Earlier quoted context omitted.
I'm in agreement here. The engineers that will lose out are the ones that think that by learning the latest and greatest frameworks and libraries, they are somehow improving in their mastery. This is, in fact, stamp collecting. Fewer and fewer engineers feel comfortable doing the basics. Implementing a raw custom data structure, writing a new parser, twiddling bits on a wire, debugging segmentation faults. The new-ag…
Maybe there are lots of types of programmer now. I tend to do the sort of things you mentioned, and look in awe at the amount of api / domain knowledge good Java or web developers have. Actually, I wonder if the steamroller is age. I can remember talking to a HR at a company I used to work for. I asked why they spent so much more effort on recruiting graduates and juniors than seniors. 'Seniors cost twice as much as…
Yes, some also go into technical management or project management roles, but in my base of anecdata, that was either out of a genuine preference or because they realized they weren't all that good at coding. And of course, some leave the field, but this is by no means an industry where only 1 in 3 entrants has a spot 10 years later if they want one. If you're even halfway decent as a coder, you'll have a chair and the music will keep playing for you as long as you reasonably elect.