Comment by kmavm | Hacker News Reader

Comment by kmavm | Hacker News Reader

Since I don't see this specifically addressed in the text: I suspect this is a classic case of survivorship bias. The same way the stock market looks better and better the further back you go, because you aren't tracking the stocks of companies that are no longer in business, developers probably look better and better the further they are into their careers, since all the ones who've fallen by the wayside probably were the weaker developers who found something better to do with their time.

As a somewhat older developer, I find this a surprisingly difficult question to answer honestly. Comparing myself to myself from 10 years ago, I sincerely think I'm more effective, but self-delusion may play a part in that. I've probably lost some of my "step", in terms of raw capacity to memorize and compute mentally, and I have more commitments outside of the world of software, which dilutes my efforts further. Then again, the strategic ideas I have are more dependably correct, and I spend less time chasing down dead ends, either because I've been down them before or had the good luck of witnessing them second- or third-hand.

I've gotten a chance to see a world-class developer very closely between the ages of 36 and 45. He started this period as, very easily, the greatest engineer I'd ever even heard stories of, and I'm pretty sure he got better over that decade. It can be done.

I don't feel any smarter than I were on my 20's. OTOH, software has gotten much more complex. Mastering the Apple II ROM routines is one thing, but understanding how every piece in a complex web application (app server, rdbms, non-relational storage, cache) interact is much harder. After wrapping my brain around some concepts, it feels very thin. We rely on Google and the web to supplement our memories for things that 25 years ago depended on books and synaptic pathways.

I'm quite sure I am much more effective today than I were 25 years ago, but a lot has to do with cognitive prosthetics.

I find web development less enjoyable than 5 or 10 years ago because of the increasing size and complexity of the stack.

At least us old fogies have had the last 15 years to learn web development. How the hell do young programmers learn such a big stack in a few years? I'm guessing half using youthful energy and the other half skipped in blissful ignorance?! :)

How the hell do young programmers learn such a big stack in a few years?

They don't. Witness the never-ending repetition of basic mistakes leading to SQL injection vulnerabilities, script injection, etc.

I would bet more SQL injections occur due to lazyness than inexperience.

Plus, many database libraries make it significantly easier to write vulnerable code than it is to write secure code.

I think one would need data to confirm that.

I mean I am lazy, but not so much that I would knowingly write insecure code for my customers; I'm can't imagine that many developers are different in that respect?

I find web development less enjoyable than 5 or 10 years ago because of the increasing size and complexity of the stack.

Part of this is that stacks that start off all light and fresh "we're not Struts!" before long acquire a few too many "must-have" features until, Lo! they are Struts.

Then it's time to drop that framework and find something more fresh, light, and lean, and enjoy it while it lasts.

The past weekend (during a RHoK event) I was introduced to TipFy by a young dude who's far faster than me in grokking new tools. It was easy, fresh and led to a fun weekend of web development.

Tipfy runs on the Google App Engine Python stack. It's a bit rough on the edges, but that's part of the fun.

How the hell do young programmers learn such a big stack in a few years?

Welcome to the museum of modern wheels -- we have every shape but round.

Specialization.

When I was starting out, I did design, frontend dev, backend dev, and ops work. Over the last 15 years these positions have all split into specializations: design was the first to go, then ops. The split between frontend and backend opened up in the middle of the last decade, and continues to split even further into controller and model devs on the back end and Javascript and CSS people on the frontend.

The increasingly popularity of frameworks stems from this specialization. It's more important than ever to have separation of concerns, because as apps get larger, individual devs are doing smaller and smaller sections of the work.

Young programmers don't know less than us -- they know way more than we do, but on a much narrower range.

I really don't agree with this, design/dev have always been different specializations, serious javascript has only appeared in the last few years and I've only seen people actually describing themselves exclusively as a 'frontend dev' in the last 6 months.

And 'frontend dev' at the moment seems to be as malleable as a SEO was, sometimes it means a designer who can add jQuery and a couple of modules to a page, sometimes it means a talented javascript programmer with an in depth knowledge of HTML/CSS.

And young programmers can't know way more than older programmers, if you keep learning.

That's the point - you don't learn the whole stack, you let your framework manage it.

It's not about being able to add code to every piece of your stack, but understanding what all of its external interfaces do. How many programmers you know can do that with their stacks?

This is one of my problems with younger developers. They slap framework code together rather than actually figuring out what's going on underneath.

It's one of the reasons I still use PHP. It's the perfect balance between framework and coding.

I started programming in web development about 4 years ago: first HTML and CSS, then adding Javascript and AJAX, then PHP, then Ruby and Rails. In the process I learned a fair amount about MySQL and I can do the most basic Unix server administration.

I'm on my third full-time web development job and I now feel decently confident in my abilities. But yes: it's a big stack, and overwhelming. Everywhere I turn I see more things I don't know. I'm always reading and trying to improve.

Were there ever simpler times? It's an interesting thought to me. I find the constant challenge to be interesting, but admittedly, sometimes tiring.

I tend to think inherent in your reply is an idea that I only see with older developers: that we should actually understand the whole stack. Newer developers are content to let more and more of the development ecosystem be someone else's problem.

So, I empathize strongly, but I think the issue isn't that we need to use prothetics as much as the conventional wisdom is that "that's devops problem."

People have always been content to let parts of the development ecosystem be someone else's problem. It's only the boundaries that have shifted over time.

Today's webdevs consider the webserver and database to be black boxes that are just "there" to be used. The people writing those webservers and databases in the 90s and 00s usually considered the OS and compiler to be black boxes that were somebody else's problem. The people writing those OSes and compilers in the 70s and 80s considered the hardware to be a black box to be trusted (at least at a high level; they knew processor architecture, but I doubt very many thought hard about how to build a flip-flop, NAND gate, or multiplexer). The people designing those chips in the 50s and 60s considered the vacuum tubes and silicon wafers to be black boxes; you don't think very much about how your silicon gets out of the ground, but that's a pretty huge project on its own.

It goes past even that-- how many devs today do you figure see Rails as a black box?

Ho!

At my age of 39 I solve tasks that in my 20's I can't even dream approaching. I attribute it to much higher-level languages I use today (mostly Haskell) and, of course, to experience in various fields.

cognitive prosthetics

I like that term.

I think Clarke's first law applies to programmers as well:

"When a distinguished but elderly scientist states that something is possible, he is almost certainly right. When he states that something is impossible, he is very probably wrong."

When you are older you maybe really spend less time chasing dead ends, I agree with that, but to be fully sincere with oneself, some of those ends might end up not being that dead anymore 10 or 20 years after you've last bothered to visit them.

Oh man, I agree with this. Stuff I intended to get around to someday back in the 90's is just a CPAN download away now.

That's a great point. I try to actively fight conservatism, but it's probably a neurologically losing battle; as I get more experienced, I necessarily get more scarred, and will instinctively avoid the areas that have caused me professional pain. When this helps, we call it "learning," but in the limit it tends towards rigidity.

"...and will instinctively avoid the areas that have caused me professional pain."

This is not good. You learned that your chosen solution did not work back then. This time, you know you have to try from the other side. This is learning too.

I appreciate a lot if there is a chance to try again what did not work a while ago. As long as you don't run out of new ideas. So far I don't (46).

That quote sounds deep, but it reduces almost exactly to:

"Almost everything is possible."

More precisely: "If a distinguished but elderly scientist passes judgement on in idea, it is probably possible. Only ideas whose possibility are not judged might be impossible."

If I recall correctly, Clarke's Law originally applied to fiction.

There it makes perfect sense.

is it fair to call it a bias in this case? it doesn't alter the conclusion that older developers are both better and scarcer, on average.

[disclaimer: 44 yo ;o] [ps. google has mitigated memory loss, i suspect.]

You are 100% right, a developer is a developer, so it's not bias. It could even be argued that the reason there are less older developers is because the better ones went into management and are no longer active developers.

Now, this all assumes that developer activity on Stack Overflow is correlated roughly equivalently over most ages. If it is, then these plainly state that for any random developer you would interview, they are more likely to be more knowledgable (according to the definition extracted by Stack Overflow activity) the older they are. The fact that there may be fewer developers at an older age is irrelevant.

Disclaimer: I'm 25

"It could even be argued that the reason there are less older developers is because the better ones went into management and are no longer active developers."

On the contrary in my experience, engineers who are fed up with coding or find maintaining their skillset too tedious or time consuming to fit in with other responsibilities generally move into management (have kids? : move to an exec role). I've been offered several CTO positions, but still building systems while many collegues have chosen the ladder (33 yrs old here) - if anything a subset of older programmers is healthy for the ecosystem.

"have kids? : move to an exec role"

Exactly - My point was that it is presumptuous (and irrelevant) to assume people leave development as they get older because they aren't very good at it. It's irrelevant because those people are, by definition, no longer developers.

A bias could come into play if you could prove:

Older developers who are (more/less) knowledgable are (more/less) likely to participate in Stack Overflow.

or

Younger developers who are (more/less) knowledgable are (less/more) likely to participate in Stack Overflow.

The latter proposition of bias is probably less likely since the sample size of younger developers is much larger.

I still think the conclusion is correct assuming the provided definitions: For any random developer you would interview from Stack Overflow, they are more likely to be more knowledgable the older they are. If the population on Stack Overflow is representative of the general developer population, than that assumption also holds true to the general population.

Also, you highlight another interesting thing: The average age a man in the US gets married is close to 28, right smack in the middle of that distribution. http://factfinder.census.gov/servlet/GRTTable?_bm=y&-geo...

I think "bias" is technically applicable. I.e., the population of older developers is not comparable to the population of younger developers because of survival (or if you prefer, self-selection) effects. Any non-trivial conclusions (e.g., that individual programmers should expect to get better with age, that your company should make an effort to recruit/retain older programmers, ...) from this data are confounded by these effects.

Well, survivorship bias can still be a reason to recruit older programmers - you want the survivors. As for retention, you would hope that a company will know which of their older programmers are valuable.

The question wasn't about finding out if older programmers are better, but if programmers get better as they grow older.

Measuring the latter in terms of the former is highly prone to the survivor bias. The OP's data is evidence in favour of progress over time, but it's weak. Now, progress over time doesn't sound like such a silly idea, so even weak evidence counts for me.

> Since I don't see this specifically addressed in the text: I suspect this is a classic case of survivorship bias.

The text didn't seem to do much besides present the stats. But he say this:

    I knew that with age coders tend to switch careers, but I
    was surprised to see the size of the drop. After the peak
    age of 27, number of developers halves every 6 to 7 years.

I figured that "survivorship bias" was sort of the exact point he was trying to make. Beyond that, there's really no discussion of causation (getting older makes one more "mature" or whatever), so I think it's implied that weeding out less committed devs is exactly what's going on.

I think you are over thinking it since everyone knows: Old Guys Rule

Reply on news.ycombinator.com