[jackmaney]

From the slides:

"Which technology that is relevant today was relevant 5 years ago? Which technology that was relevant 5 years ago is relevant today?"

Ruby, Python, Java, C, C++, Windows, Linux, OSX, relational databases, HTML, CSS, JavaScript, HTTP...and that's just a very short list off the top of my groggy, pre-coffee-in-the-morning head.

[cruise02]

Aren't those two questions asking the same thing? (I'm behind a firewall, so I can't access the slides.)

[ultramundane828]

The big difference there isn't necessarily in the questions, but in the sets of things the questions are applied to.

It's still asking the same thing, so I'd say yes. But you might be asking it for different reasons ("am I interested in this historically or practically" vs. "is this innovative or canon?").

[iktorn]

not really - there is a subtle difference

[cruise02]

Aren't they both asking "What technology has been relevant for the past 5 years?" Maybe I just need an example that answers one question but not the other?

[kenjackson]

The answer to both questions would be the same. Although the way the question is phrased may get one to the answer faster or slower.

[woogley]

think of it as "peaks" of relevance

[6d0debc071]

XML, SQL, Direct X, Apache....

Mmm, coffeeeee @_@

[randallsquared]

Not sure if intentional, but every member of this list is derided by a vocal segment in the community... :)

[coldcode]

Five years ago iOS appeared. I think it's still a relevant environment. Android as well is similar in age. Both still dominate the mobile world.

[jackmaney]

According to Wikipedia, both iOS and Android have been around longer than five years.

[Dewie]

I haven't even programmed for five years, but it seems like if I get into the industry, all the fabled "rapid change" in the industry seems to mostly be about learning new ways of doing conceptually old stuff, with most of the learning being new API's, slightly different syntax and all the gotchas and corner-cases that come with these new tools.

Maybe there will be some new (to the industry) programming paradigms, but from the reception that functional concepts have gotten from a lot of people, there seems to be a large amount of seasoned programmers that seem pretty displeased at the idea of having to learn stuff that is actually for the most part new to them.

[gav]

A large part of the "rapid change" is people re-inventing things or re-writing things in a hipper language.

I feel that a lot of this comes from unrealistic scaling expectations; stop worrying about serving Facebook-like traffic and use tried-and-tested tools.

[Shorel]

The idea is to use technologies that old bureaucrats can't understand, in order to avoid bureaucracy from creeping into the project.

If you have ever been in a project with some higher up dictating some technology because the corporate vendor is good at his job, but said technology is awful for the project, and you have no say about it, that's what the 'rapid change' tries to avoid.

For example: using Oracle for a small DB.

[robodale]

This. It's the old new thing.

[iktorn]

fair enough but I'm fairly sure that if you traveled in time from 5y ago with a decent developer from that time he would have hard time landing a job today

[nikster]

In my experience the opposite is true.

Some people have an easy time programming, and the specifics - libraries, languages, etc - don't matter at all. They'll pick up that new stuff in their sleep.

I recently hired a Java guy after talking to him - he had all the right hallmarks so I was pretty sure he would be good. I gave him a task with a piece of software I am intimately familiar with. A good developer would have had to get up to gear for a week (40 hours), then code, test, work around the little kinks (there are many).

All in all an optimistic assumption of mine would be that this task would take a brand new guy a month. The dev I hired did it in less than a week!

These people are rare. They are the rockstar programmers. And if you find one, you want to hold on to them no matter what.

Team players? What if the guy can do twice as much in a week than a "team" of 5 mediocre guys?

To get back to your assertion, he then proceeded to learn Android and put a functioning app in the Google play store in less than a week.

Granted that's still Java, but the libraries are all different and developing for mobile is also different.

If I had an iOS job right now, this guy would get it, despite never having done iOS. He'd learn this in his spare time and then proceed to run circles around people who've been at it for years.

That's a rockstar programmer for you.

[yogo]

The notion of a rockstar is silly. I think it's somewhat common to find developers that can pickup languages in a short space of time. Once you understand the concepts of OO/procedural and functional paradigms something would be wrong if you couldn't pick up a new language in a day (plus some more time for best practices, patterns, etc.).

Greenfield development is always easier than having to work with 200K LOC codebase that is crappy for all intents and purposes. Let's see how quickly a developer can jump on, wrap his/her around everything, then make significant changes and maybe I'll believe in that nonsense.

Personally I think if a job ad includes the word rockstar, I would expect hot groupies and coke on the job (2 or 3 times a week to allow some time for actual work :)).

[peacemaker]

In my experience you couldn't be more wrong. I've been programming for over 12 years and started out with C and C++. I have successfully walked into jobs using other 'modern' technologies with only a few days worth of learning them. Sure, things change but it doesn't take much to keep up with those changes and a lot of what's considered new by all the cool kids is actually the same old stuff in a shinier package.

[dbecker]

The changes in programming are pretty superficial. If a good C/C++ programmer from 1995 were transported to 2013, they could pick up Python quickly.

[klibertp]

> The changes in programming are pretty superficial.

In mainstream programming. You don't need to time-travel to experience huge cultural and technological shifts - you can go from Prolog to Forth to Racket to Smalltalk to OCaml to Haskell and experience more of a change than a C++ programmer from 1985 would if transported to 2013.

Inside one paradigm the changes are necessarily iterative and slow. Differences across the paradigms are huge. At a given time only one or two paradigms are mainstream, and they change rarely. The same goes for hardware architectures. This makes it look like programming is stagnant, and for the most part it is. However, when the change comes - like from unstructured to structured programming or from 16 to 32 bits architectures - people who lived happily inside the main paradigm have a hard time adjusting.

I don't know when the next major shift in paradigms will come, but it will, and then the belief that the only changes in programming are superficial will prove dangerous.

[dbecker]

This was in response to a comment stating that someone who programmed 5 years ago couldn't get a job today.

The fact that Prolog isn't the same as Forth is a complete tangent.

[klibertp]

What I'm saying is that there were moments in a short history of programming when it was "hard for someone who programmed 5 years ago get a job today", and not because of economical reasons.

I personally remember one and it was around the transition from 16 to 32 bit architecture (for me it was in context of WinAPI vs. MSDOS programming). That seemed like everything has changed completely and people had to put a big effort to stay relevant. The same happened - from what I hear - when OO became mainstream. The same when we largely abandoned asm for higher level languages. Basically, I'm saying that there are such 5 years periods in which the above statement holds true.

Such turning points have, I think, one thing in common - new technologies, methodologies and paradigms are not created overnight, in each case the "new" was around for quite a few years before it "suddenly" replaced the "old". It was just outside of day to day work of most programmers. That's why I think it's important to be on a constant lookout for new things in programming - or even old, but different things. One day, in a matter of months, they may become dominant and make your skills largely obsolete which will make you maintain some legacy stuff for the rest of your career. It's a hyperbole of course.

Anyway, while today and 5 years back are not that different, maybe today and five years in the future will be. And then you'll have a problem getting a job until you catch on. I'm not saying how probable it is, but it happened and may happen again. Or didn't it? What is your perception of this issue?

[moron4hire]

I'm actually finding that I am using older techniques to get performance gains that my peers on other projects are not able to realize because they're blinded by the idea that the "latest and greatest compile-to-javascript language" is "the best", so therefore must be "for all cases."

[afandian]

I don't think so. Technology wasn't so different, especially web development. Most of the software we use today was in place. It would be behind a few releases and there were fewer libraries. But otherwise broadly similar. Any decent developer learns on the job anyway.

[Jimmy]

Bullshit. You can still get a job writing COBOL. C, C++, and Java are also older than 5 years.

[vladimirralev]

That's very hard to believe. Why do you think so?