Live data from Hacker News

Why You Should Hire an Old Programmer

joshondesign.com

141–150 of 192 posts

Re: Why You Should Hire an Old Programmer

#141
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'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…

>That's not an old/young argument.

Oh I wasn't saying it was -- just providing examples for when the hand-waving/dismissive attitude by senior developers isn't really backed by anything. I'm pretty skeptical of 'because I said so' answers nowadays (by both young and old devs).

>then have the key/value schema for anything oddball

Agreed, as long as 'oddball' means 'dynamic/customer-specific' and not 'we're too lazy to design a schema for this' ;)

Re: Why You Should Hire an Old Programmer

#142
post #16

Earlier quoted context omitted.

Experience takes time. More or less, depending on several factors (willingness to learn and improve, complexity of the subject, ...). But by definition, if you gain experience, you just got older than before. You cannot magically learn everything out of sheer willpower. Additionally, a few things are impossible to learn without time: the "Judgement" section in the article. You can certainly theoretically understand t…

Ok, let me be more explicit. You are absolutely correct that experience takes time and that the type of experience that the author speaks of comes from writing something and supporting it. What I am saying, is that you can choose to write different types of things and support them, without having to become 40+ years old. Not out of "sheer willpower" either; you just have to choose to write different types of things a…

I think you're still missing the point. No, just time isn't a magic ingredient. That time has to be well spent. But it still takes time.

And it's not just about having several projects under your belt. This is making the fundamental mistake that software development is a pretty intellectual pursuit, when in reality the social aspect is far more important.

There is living through the cyclical zeitgeist. There is the experience that only comes from having been through things when there were new, and having done this several times. There is no way for a young person to know what it was like to start writing JavaScript when it was first invented, or to have made one of the earliest AJAX apps when XmlHTTPRequest was first invented. That's not an argument that the old ways are better than the new, it's an argument that we know deep down why the new ways are better than the old (and what lessons the new ones could learn, too).

There is the super powers that come from having spent a long time in two or more completely different fields. There is domain knowledge that does not come cheaply, and to gain such expensive knowledge in more than one field is so rare.

I don't think the author is at all arguing that all 40+ developers are great. He's arguing to stop universally dismissing older programmers.

Re: Why You Should Hire an Old Programmer

#143

Earlier quoted context omitted.

I did not say you gain gain experience without time; I said you can gain experience without becoming old. That is, you can gain the kind of experience the author discusses before reaching age 40.

How do you think age happens if not by way of time? :)

It does not take 20 years to gain the experience the author is discussing. It can be done in significantly less time than that. That is my point.

Re: Why You Should Hire an Old Programmer

#144

Earlier quoted context omitted.

it is a historical fact that most of the best mathematicians make their famous discoveries when they are younger than 30. if you have studied the subject, you'd know this, so i assume you just dislike these facts and argue for the sake of it.

I would question whether this is actually true. Stats on Field medalists have to be taken with a grain of salt, given that it is awarded at 40 years top in the first place

That is pretty limited information. Talk to a good professor. he will gladly admit that his mind is not as nimble as it was once. maybe he will say things like hes glad he can still keep up and do research. mine told me this in front of an entire class just to drive the point home that 'the time is now'.

Re: Why You Should Hire an Old Programmer

#145
post #74
post #35

Earlier quoted context omitted.

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…

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 be different in the future again. The problem with our profession is that it isn't always easy to determine which changes are actual progress, and which are a fad or fashion.

(Anecdotally: I also remember having to replace ~100 lines of Python with ~60 stored procs and views in Access. This was code that was very unsuitable to be done in a database. The Python code did the job fast, and was readable and understandable; the Access queries were NOT, and it took them minutes to do the same thing. But, management considered Python "unmaintainable" because it was "an obscure language"... so they preferred the Access "solution".)

Re: Why You Should Hire an Old Programmer

#146

Earlier quoted context omitted.

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

>That's not an old/young argument. Oh I wasn't saying it was -- just providing examples for when the hand-waving/dismissive attitude by senior developers isn't really backed by anything. I'm pretty skeptical of 'because I said so' answers nowadays (by both young and old devs). >then have the key/value schema for anything oddball Agreed, as long as 'oddball' means 'dynamic/customer-specific' and not 'we're too lazy to…

Yes, I'm prepared to defend any design decision I have all day if I have to. I like discussing / arguing things because someone else might have thought of something I didn't consider. It's about making a good product, not about who wins. I use the pro/con model. That's probably lost on most people, especially defensive ones. I get aggravated by "because I said so," too. When you're older, you don't get dismissed as much if at all.

My mentor was a huge arguer, that's probably where I got it from. He'd start talking louder and spittle would come out at me and everything. It was ugly, but I got used to it. We'd go at it for hours, but we both knew when we came up with the right decision and were receptive to it. I like to think I'm quite a bit more tactful than he is though.

>Agreed, as long as 'oddball' means 'dynamic/customer-specific' and not 'we're too lazy to design a schema for this' ;)

Oh god, I suffer over schema design decisions more than I should, but sometimes, relational just doesn't fit what I'm doing. What's really helped is I got stuck doing reports for a huge schema my 2nd two years and I really saw what crappy design could do to performance. My favorite is when a schema has missing foreign keys on 80% of the tables. It's like they discovered foreign keys 3/4 of the way through the project and didn't bother to retrofit them.

Re: Why You Should Hire an Old Programmer

#147

I don't disagree with anything stated here, but how much of this actually is a function of age? I feel like a young programmer could aquire all of these traits also, because they're less about age and more about being able to learn from experiences. You can choose to have more experiences to become the kind of person the article talks about. Or is this a survivorship bias thing? The old programmers are more likely to…

I think the article is arguing that while age may not be necessary for quality, it is sufficient. A young(er) programmer may or may not have these qualities, but in order to survive in the programming industry beyond a certain point, you have to develop these qualities. (Not sure whether I agree, but I think it's a point worth considering.)

Re: Why You Should Hire an Old Programmer

#148

Earlier quoted context omitted.

programmers actually need to think sometimes. the jobs mentioned are more routine and rely on soft skills and experience a lot. I do not mean any disrespect by that. mathematicians are also best when they are young, but unlike programmers work in academia and get to teach until retirement, whereas programmers get replaced.

Are you sure the jobs that rely on soft skills and experience are more routine than other jobs? What experience do you have to support that? I've found that once you throw humans into the mix, nothing is routine. I think CS schools do their grads a huge disservice by creating the expectation that the coding is the hard part. There are a lot of people who can reverse a linked list who can't coordinate a huge project,…

For me not everything needs to be labelled thinking to be valuable. I do not know how much money beyonce makes but i know its a lot. I never implied that soft skills are easy to pick up. in fact for some people they are nearly impossible to learn.

Re: Why You Should Hire an Old Programmer

#149

Earlier quoted context omitted.

I would question whether this is actually true. Stats on Field medalists have to be taken with a grain of salt, given that it is awarded at 40 years top in the first place

That is pretty limited information. Talk to a good professor. he will gladly admit that his mind is not as nimble as it was once. maybe he will say things like hes glad he can still keep up and do research. mine told me this in front of an entire class just to drive the point home that 'the time is now'.

I have been doing mathematics up until a couple of postdocs - and based on first hand experience I think that the story of young mathematicians is mostly a myth.

Maybe people in their 60s were not at the center of research, but I would say that the field was dominated by people in their 40s (certainly not by 20-something).

I cited the Fields medal, because their artificial limitation on age is one of the first things that comes to mind when talking about the subject

Re: Why You Should Hire an Old Programmer

#150

Earlier quoted context omitted.

I would question whether this is actually true. Stats on Field medalists have to be taken with a grain of salt, given that it is awarded at 40 years top in the first place

That is pretty limited information. Talk to a good professor. he will gladly admit that his mind is not as nimble as it was once. maybe he will say things like hes glad he can still keep up and do research. mine told me this in front of an entire class just to drive the point home that 'the time is now'.

That has to do with the Ponzi scheme that academic life is. Your professor is running a group of ~10 woefully underpaid grad students and he needs fresh blood to keep it running. Your time is now, before you discover that there are way better paying options available.
Post reply on HN