Live data from Hacker News

The Programming Steamroller Waits For No One (2013)

thecodist.com

41–48 of 48 posts

Re: The Programming Steamroller Waits For No One (2013)

#41
post #40

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.

I'd also like to point out that most software projects are in maintenance mode right now. Startups focus on creating new products but what do you think every company on earth is running right now? There's infinite amount of work for a good programmer in the world, getting bogged down by trying to keep up with the latest cosmetic changes isn't the best long term plan.

Re: The Programming Steamroller Waits For No One (2013)

#42
post #36
post #3

I 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…

"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...

Re: The Programming Steamroller Waits For No One (2013)

#43
post #36

Earlier 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...

Yup, Lisp will definitely be around long after most of the technologies we read about today :)

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)

#44
Computer science concepts build on each other, but technology and frameworks don't necessarily get more and more complex. If you fall behind, you could always skip a generation of technology, and pick up the one after just as easily. In fact, it may be even easier. I've noticed the trend of new frameworks and APIs getting simpler and easier to use over time.

Yes. 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)

#45

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…

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…

New frameworks are getting simpler and easier all the time. They try to avoid the pitfalls that old ones fell into and thus become easier to learn than the last generation.

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)

#46

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…

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.

As it happens, I'm 43, and I've also been coding for 30 years. I even have a beard :)

Re: The Programming Steamroller Waits For No One (2013)

#47

In 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…

It could be worse, you could have been one of those companies that tied themselves to IE6.

Re: The Programming Steamroller Waits For No One (2013)

#48
post #26

Earlier 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…

They go to work for companies with the opposite philosophy. Some companies do no or very limited entry-level hiring, because they choose to hire programmers who made their mistakes on someone else's dime.

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.

Post reply on HN