Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why You Should Hire an Old Programmer

joshondesign.com

Post reply on HN
Print view View original

161–170 of 192 posts

Re: Why You Should Hire an Old Programmer

#161

Post by CodeWriter23 »

js8 wrote: post #50

I think programmers should reframe the problem. If cognitive decline is real, why would anyone hire anybody over 40? Yet there are plenty managers, politicians, doctors, lawyers, salespeople, engineers, etc. who are over 40. If you want a culture where people retire at 40, go for it. But please don't pretend that programmers are "special" in that the decline in their skills is worse than decline in skills of anybody…

Cognitive decline? What a load of ageist malarkey. At 51, I can still hold complex thoughts in my head and make solutions. And when I slow down, it's because I'm wisely taking time to contemplate the implications of how the thing I'm working on affects the entire stack.

I wish the author would have tried to dispel this and another myth associated with age, inflexibility. I'm still learning new things. And sometimes, choosing what I know and am strong and familiar with is a choice to expedite. It has little to do with a lack of willingness to change or learn new stuff. In fact, I'm much more flexible than I was in my 20's. Mostly because time has tempered my arrogant self-righteous self with a healthy dose of humility.

Re: Why You Should Hire an Old Programmer

#162

Post by CodeWriter23 »

lliamander wrote: post #153
js8 wrote: post #50

I think programmers should reframe the problem. If cognitive decline is real, why would anyone hire anybody over 40? Yet there are plenty managers, politicians, doctors, lawyers, salespeople, engineers, etc. who are over 40. If you want a culture where people retire at 40, go for it. But please don't pretend that programmers are "special" in that the decline in their skills is worse than decline in skills of anybody…

It's not just about cognitive decline, but about how quickly our knowledge becomes obsolete. Tech is a very fashion-driven industry right now, and deep knowledge is sometimes (often?) valued less than ability to pick up the latest trend. There are skill sets that have a longer shelf-life, but developing those skills (and finding jobs that actually need those skills) is a challenge.

I had to abandon the "keep knowledge in my head" paradigm in 1990 or so and shift to the "problem solver" model. This is the skill set with an indeterminate shelf life.

Sure it takes time to become fluent in new systems. That's no different than the first system that I learned. I think if one lacks the willingness to stretch and learn the new, whether one is 25 or one is 70, that is when one becomes unsuitable for this line of work.

Re: Why You Should Hire an Old Programmer

#164

Post by gozur88 »

The most frustrating thing about being an older programmer is watching organizations make the same mistakes over and over again. Yeah, sure, you might want to hire an older guy because he has experience with the intangible project stuff. But only if you're planning to listen to him. I feel like Bill Murray's character in Groundhog Day:

Me: We need to create our security architecture in the beginning. It's always harder to add when we have a bunch of functionality to work around.

Management: But we don't have time. We promised these features by January 1st. Don't worry about security yet - the initial version won't have critical business or customer data.

Me: We'll never have time. Once the users get ahold of this we'll be buried under requests for new features and critical bug fixes. Particularly since the only way we have to test it is to have people poke at it in a browser.

Management: Adding automated testing would take too much time.

Me: ...

Re: Why You Should Hire an Old Programmer

#165

Post by imhoguy »

zephyrfalcon wrote: post #145
Mouse47 wrote: post #74

Earlier quoted context omitted.

Yup. I've seen 55+ year old programmers write what was essentially a message queue persisted in a database table, processed by a cron job. We frequently had problems with duplicate processing of messages, due to multiple cron jobs running at once. I've personally argued against a key-value store schema in SQL Server and was in favor of a flat-table design. In our case, there were records of different 'types', and eac…

"""All of the business logic was in stored procedures. I've seen a stored procedure with triple nested cursors spanning 2000 lines. Our 'senior' developer would take weeks to make changes to this thing.""" I remember when this was the thing to do; to store as much as possible in stored procs. Fat server (the server here being the database server), thin client. That has changed, and changed again, and no doubt it will…

Nowadays stored procedures hype equivalent is AWS Lambda.

Re: Why You Should Hire an Old Programmer

#167

Post by imhoguy »

sotojuan wrote: post #112
js8 wrote: post #50

I think programmers should reframe the problem. If cognitive decline is real, why would anyone hire anybody over 40? Yet there are plenty managers, politicians, doctors, lawyers, salespeople, engineers, etc. who are over 40. If you want a culture where people retire at 40, go for it. But please don't pretend that programmers are "special" in that the decline in their skills is worse than decline in skills of anybody…

> Yet there are plenty managers, politicians, doctors, lawyers, salespeople, engineers, etc. who are over 40. If anything, these careers (aside from doctor maybe) hit their peak in their 40s or early 50s. I would say our culture thinks programmers peak in their late 20s/early 30s. For HN users in their 30s - what are you doing to not get ageism'd?

Launching side-projects for fun and profit when the family sleeps. But it is rather escape cave from daily boring corporate stuff.

Re: Why You Should Hire an Old Programmer

#168

Post by vpeters25 »

Clubber wrote: post #133
vpeters25 wrote: post #129

Earlier quoted context omitted.

> I'm and old programmer and I've been arguing against business logic in SPs since SQL Server 6.5 and have been losing ever since. That's not an old/young argument. > It's because vendors (in this case MS) recommend putting code in SPs. I suspect it has to do with lock-in. If i recall correctly, back in the dark ages of Classic ASP and SQL Server 6.5, database stored procedures was the only feasible way of implementi…

No, we had middleware back then. It was ugly text over sockets, or worse, DCOM, but it worked. That was more ISAPI than classic ASP. If nothing else, we could create a queue table in a database and have a Windows Service pick it up.

Ah DCOM, fun times.

Back in SQL 6.5 days (and all the MS SQL versions up to, i believe, 2005), "precompiling" queries in stored procedures was recommended for performance reasons. It was even asked on hiring interviews, at least to me.

Re: Why You Should Hire an Old Programmer

#169

Post by wwweston »

ruffel wrote: post #35
pleasecalllater wrote: post #24

When talking with young programmers I too often think "well, you are doing that wrong, been there, done that". They don't want to listen. A couple of months later they notice that the gray beard ones were right. From a company perspective, that's just too late, as the money loss is not recoverable. There is nothing wrong with being a young one with no experience. There is so much wrong when a company has only a bunch…

Conversely I find that a number of the old(er) programmers I've worked with are incredibly stubborn and bigoted. They refuse to see anything from another persons perspective especially if that person is young. As well refusing to keep up with 'modern' technologies and paradigms because "that's not how I'm used to doing it". It's a lot of the "I've been round the block a few times I know what I'm doing" bullshit attit…

> As well refusing to keep up with 'modern' technologies and paradigms

I don't know if in the situations you've observed or participated in the primary argument was about the "modern" nature of the technology choices in question, but as far as I've been able to tell, often when someone employs it as a descriptor, it's a sign that you need to probe carefully to figure out if there's any "there" there. Often enough the person doesn't know how to assign it any other merit than it was recently created. Which can be another way of saying "fashionable."

That might not be the only merit a technology that makes that claim has, but I tend to find it's more likely that there are other merits the less visibility the term modern has in the discussion surrounding it.

> because "that's not how I'm used to doing it".

Here's a question: if you already know a way of doing something that will meet project requirements... why spend time investing in another way of doing the same thing?

One of my guidelines is to prefer learning things that expand my capabilities over learning things that retread existing ones.

That's a more finely articulated proposition than "that's not how I'm used to doing it", but I wouldn't be surprised if they had a large degree of overlap.

(Also, my observation has been "that's not how I'm used to doing it" is an argument employed across age ranges without discrimination.)

Re: Why You Should Hire an Old Programmer

#170

Post by ralusek »

gozur88 wrote: post #164

The most frustrating thing about being an older programmer is watching organizations make the same mistakes over and over again. Yeah, sure, you might want to hire an older guy because he has experience with the intangible project stuff. But only if you're planning to listen to him. I feel like Bill Murray's character in Groundhog Day : Me: We need to create our security architecture in the beginning. It's always har…

I mean the problem is that you're both probably right. You SHOULD add in tests and security, but you also very likely DON'T have time.

Good code can be structured in a way that it's not going to be a nightmare to add in considerations of this nature further down the line, but with this sort of environment of "speed > everything" else, they're not likely to let you implement code well either.

Post reply on HN