Why You Should Hire an Old Programmer
joshondesign.com
joshondesign.com
There is nothing wrong with being a young one with no experience. There is so much wrong when a company has only a bunch of young programmers and no experienced one who lead them.
But obviously that's a generalisation. Just like your comment is.
To be fair - I'm not sure how that is age related. e.g. I've had very strong reactions from some inexperienced developers who literally only had knowledge of one way of doing things to the possibility that another option might be possible and better.
It's irritating in programmers because we can write prototypes to prove out our theories. It is really irritating in the fuzzy areas (like government and organization grant readers).
I'm interested in why it happens to some people, but not others. You'll see people who are set in their ways by their mid to late 20s, and others who seem to keep an open mind perpetually.
I remember when I started out that I'd scour every line of code for memory leaks and optimize the hell out of it. Today we've got more memory, faster machines, and the code doesn't need to be quite as tight.
Mentorship goes both ways. I help newer devs about processes and patterns. They help me with new technology and trends. I think it works well but it requires patience on everyone's parts.
They may think the old programmer are leak of passion, just there to do their part of job, not creating things and "Change the world" like they do.
For example when you tell them to parse HTTP header with a 256 buffer, they may argue why not give me 4K buffer so they can done it more easily, "It's fine to use 4K for that, just install more memory".
I've had discussions with "industry veterans" that didn't get the fundamentals about their machines straight (a couple of them, for example, seemed to be ignorant of the fact that caching is a thing and influences your memory access delays).
Usually, that wouldn't be much of a problem, except when they claimed authority on performance and how hot-path algorithms should be implemented. The upside to those discussions is that they're usually easily settled with a couple of benchmarks and unit tests.
Similarly, I'm often puzzled whenever I encounter someone who works on a ("official") C++ project and e.g. refuses to use RAII and/or const properly. I get that you might dislike to depend on too many "external" tools, but just throwing the upsides of the language you're using away because "that's not how we did it back in the day" really bugs me. I can't avoid the impression that those people are being willingly ignorant...
A part of his summer project was to make some api calls to a soap endpoint. We were all very busy so he tried to be as self sufficient as possible and not ask questions. After about a week, he comes to me with questions about soap xml schema and implementation details.
He did not understand it's already built into the tooling. You literally drag-n-drop a url endpoint into your project and get a proxy class for calling the soap endpoint. He was way off into the weeds trying to finish his project. A little guidance helps.
Still, I don't consider it a big failure. A lot of people go through life using technologies without really knowing how they work. He could have very well drag-n-dropped the soap endpoint and never learned a thing about soap. Now that he knows a bit about it he may alter his decisions in the future knowing the guts e.g. 'don't do that because it won't work through soap' etc.
I've had scenarios where I spent an afternoon building a little one-off application I needed for some specific debugging task only to be told a month or so later that someone already built a proper tool for that - but only one developer knew about it, and it was stored in a different repository I had no access to.
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 each type may have a number of fields always be null. Looking back, I'd probably do something like this:
Entity
common attribute 1
common attribute 2
etc
Entity_Type1
entity_id fk references Entity,
type1_attribute 1,
etc
Each of these developers refused to use git, in favor of visual source safe. I know.
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've lost count of the times I've been steamrolled in discussions. I'm not sure if it's my age or if I'm just lacking that much socially. When you lose an argument over key-value schemas of all things it makes you really question if you know what you're doing...
We tend to be fairly agile with regard to new technologies, and much of that is driven by the architects. A few of the young folks will recommend bleeding edge platforms/libraries/techniques. Some of this stuff has been accepted, some of it hasn't. It is almost always filtered through the lens of experience ("what happened when we tried to introduce x? ").
Experience counts, primarily because one group has been burned in the past by accepting recommendations from just-out-of-college engineers. That's not to say the younger devs don't know anything, but they have precious little experience shipping actual product.
(We work in the medical domain, so "move fast and break things" doesn't work so well in a highly-regulated industry).
On the other hand, our senior build engineer is more, uh, established in his ways, and we are currently stuck on an antiquated version control system. This particular engineer also wields quite a bit of influence to the larger company, so his way tends to be the way we go (unfortunately).
At the end of the day, I think you find stuck-in-their-old-way folks in an industry. This is not at all unique to software engineering.
And I have been steamrolled in discussions with 20-somethings as well. "Don't worry, I'll always give you enough time to refactor the tree shaking caused by this design," from a first-time manager is probably my favorite, followed by "this must be re-written, there's no way to salvage it in-place."
They went from consistent if slow progress in defusing the landmines in the old backend to eight months of re-writing everything (frontend included since the data model was also changed) and trying to claw their way back to parity.
Bad programmers will be bad programmers, regardless of age. At least age will put a polish on average developers, letting them work above their raw potential simply because of "I've seen this before; here's how it was solved".
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. I use the database for what it was made for, and only what it was made for: to persist and retrieve data. Anything else should be in the code.
Also, key/value schemas are terrible and slow, but sometimes they're the only way to get the dynamic nature of what you are doing. The best compromise I've seen of that is to have the values you know are going to be used a lot by groups/customers flat, then have the key/value schema for anything oddball.
I guess the moral of the story is old/young doesn't really matter. It's know / don't know what you are doing. I guess it boils down to thinking about what you are doing. Key value is very dynamic but I'll bet it's slow. Do we need fast more than dynamic? Is there a compromise that will satisfy both requirements? Many people don't think that deeply and just want to get it finished.
When I was young, the dot bomb was the "great filter." After that, there were a lot more people who knew what they were doing because they survived. It sucked though, I don't recommend it.
> 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 implementing a reasonably performing web application.
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.
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' ;)
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.
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".)
If they like git and know it well, they're probably old, full of the experience and benefits you're looking for, _and_ energetic, growing and open-minded.
(I said "probably" because it's not perfect. But it's a pretty good heuristic).
However: I strongly suspect the reason for both generalizations to exist is the fact that we as humans tend to remember the extreme encounters the most - the obvious observation being that the Dunning-Kruger effect applies to all ages.
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.)
Hire older programmers because they don't make sweeping generalizations.
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 else.
No one would complain about a 63yo brain surgeon, who according to some IT HR people would have cognitive decline, but has somehow picked up skills to be a master surgeon.
For example, I couldn't learn other languages so well as a teenager (I wasn't such a great grammarist with English either). As an adult I've picked up French rather quickly and grown fascinated by linguistics; hard to understate the positive effects this has had on my career and even social life. Take all of that and the real-world job experience, add it to the calc and CS coursework from university and I'm 100x the developer I was 5 years ago.
Perhaps English is not your first language because you sound like me at 19 explaining to my dad why I haven't finished his website lol
Same goes, ideally, for politicians and lawyers and engineers.
This guy springs to mind: https://en.wikipedia.org/wiki/Laszlo_Babai
Because, yeah, programmers and mathematicians don't actually need any experience, they can just think everything up on the spot!
I also wonder how you imagine that other professions gain their experience, if they don't need to think.
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
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, or build a product from the ground up that people care about. If those are soft skills (implying they're less challenging to pick up), why do most engineers only develop them after they're pretty skilled technically?
In my experience, it's not because they're forced to in order to make up for declining mental horsepower. It's because what you're calling the "hard skills" have become routine to them, and they want to do harder things than they can accomplish as an individual contributor. They want to do work that's less routine.
Why label soft skills as "not thinking"? Humans are way more complex than computers.
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?
^ (all the arguments that don't boil down to "you have to pay them more")
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 kind of expected that argument to come up. It's funny that the reaction of the industry itself to that is to give up on the experience and ride with the fashion, rather than fight those trends.
It's almost as if immaturity is a self-fulfilling prophecy.
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.
That is what I aspire to. I think I'm doing well in this regard for how far I am into my career, but any advice you have in this regard would be appreciated by me (and others presumably).
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.
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: ...
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.
But by doing the things that people can see and skipping the things they can't see you're effectively just lying when you produce a schedule. You don't do automated tests because it's a fun way to kill a Friday afternoon - you do them because they free you up to work on new functionality. So you're not really saving yourself time by not doing them.
These kinds of projects are almost always disasters. Invariably the problem is someone in middle management undersold the cost to the people above him. There's not enough time to write the app properly, so they borrow time off the end (with interest) to make it look like things are progressing to the deadline.
So you finish the first 90% on schedule and then flail around on the next 90%.
What I've been waking up to is that projects that estimate realistic budgets and time scales don't get funded. Everyone underbids knowing that the company/customer will continue to fund and extend deadlines for project after sinking so much effort into a buggy prototype, until the realistic estimate is reached and the product actually reflects all the "hidden"/"discovered" requirements (i.e. foreseen but not in the bid) including security, integration and test efforts.
What's weird is that everyone, customers included, seems to be in on this.
I think only debt slave or masochist stay in such places for longer. Age doesn't matter.
I would rather look for more focused software product companies with stable teams.
Only consistently useful features require bug-fixing. It is better to spend more time fixing bugs on few useful features after they implemented and tested by users, than spend time polishing all features (including useless features) up-front.
Not that any of this is surprising, since the lessons of the semiconductor boom and bust weren't put to adequate use during the dot-com boom and bust, so whatever new lessons we learned then still aren't being put to use.
Since being in what is, fundamentally, a support profession, the most I can do is play along. That means, sadly, as another commenter admitted of himself, I'm in on it.
Also after a few years in the game you tend to get targetted by recruiters as you may have specialised into certain areas. i.e. finance.
So for example, I don't normally look for work, it normally finds me.
Also, a lot of the sites that feature contract work ask for way too many details, and are basically a race to the bottom on price, sometimes at the expense of quality, and I don't feel panicked enough yet to join that race.
It's at best a 'neutral' because when you inevitably leave again you'll take all those people with you potentially leaving the company floundering.
And unlike a lot of people it seems, I don't really enjoy moving to another company or taking people if they enjoy what they do; it would be that they would ask me first if I have something.
Badly. The unfortunate truth is that if you've hit 40+ without having built up enough expertise and contacts to bypass those types of interviews then finding a programming job is going to be really hard.
This I think is true in most professional fields and doesn't answer the question posed.
The interview-fail of the software industry is all about knowledge gaps:
- the knowledge gap of most practitioners in this field of the most basic fundamental findings, constructs, etc. of their field;
- the knowledge gap of discerning actual skills based on presented CV credentials;
- the knowledge gap of the interviewers themselves -- who are of course paid members of the same under-educated industry -- resorting to popular trends as substitute for the ability to distinguish between capable and incapable candidates;
When an arts and crafts "industry" [has] pretensions to being "engineering" or "science", this is what you get. Throw in a healthy dose of age discrimination, and voila.
Can you elaborate a bit? I hear this all the time (get the job through contacts and networking not by applying and interviewing) but nobody will go into step-by-step detail about how one actually can manage to "bypass" a company's interview process.
Company: "Thanks for your interest in working here. Your resume and application are impressive, and you have great references! Obviously you are skilled, so forget about having to interview. How's $180K plus benefits sound, and can you start in a week?"
I've been in tech for close to 20 years and that scenario just sounds absurd to me.
Networks and reputation. Get a former boss/colleague that knows you (and who has ideally ended up in a position some of trust/responsibility) to recommend you to his boss. If someone the boss trust tells him that you have the exact combination of expertise they're looking for and that you're the person they need then everything goes a lot smoother.
That's how I got my current job. A former colleague (who'd ended up in a management position) called me out of the blue, invited me out to lunch and straight up asked me if I'd be interested in a new job. I still had to interview, but it felt like much more of a formality.
You can also just ask people. Keep a list of people you've work with that you trust/respect and that you believe trust and respect your skills and just keep in touch with them once every 6 month or so. Let them know that you are open to switching jobs if something interesting comes along and ask them to keep you mind.
Another way is to become a 'name' in your field. If yours is one of a handful of names that always comes up when people are talking about who in town is really good at X then chances are people will start seeking you out.
However, I've seen people claim, here on HN and in other forums, that they have received offers (not just opportunities to interview), sight otherwise unseen, from companies based purely on their own reputation and/or references. That's what seems unbelievable to me.
(1) I've always been a bit of an algorithms guy. I've met many people who were better at debugging, a few who were better at systems design or straight-out coding, but if you need someone to pick the exact right algorithm and tweak it a bit to suit a particular situation then I'm all over it.
(2) The interviewers were obviously well trained. The problems were well chosen and presented, and I was allowed to think through things my own way at my own pace. The followup questions clearly indicated that the interviewers were looking at more than just whether I could solve this particular problem - how I broke it down and handled edge cases, how I handled changing requirements, testability, communication, and so on. Having written before about how such interviews are usually an exercise in ego and a total waste of time (or worse), I was pleasantly surprised.
I think a lot of older programmers do avoid such interviews. They'd never admit fear is a factor, but it is. I'll admit I hesitated before going through it myself, but then I realized that even if I "failed" it didn't diminish me. It just meant there was a difference of opinion about what mattered or made someone a good fit for a job. I can live with that.
1. Because I've had many interviews where people ask one of perhaps 200 questions over and over (reverse a double linked list, serialize a tree).
2. I do complicated stuff, daily. Multithreaded communications patterns. Cross platform code. Memory / performance optimizations. Etc. All syntax from plain C to C++14 plus extensions. When I have to do a basic data structure operation, on a single thread, it's actually relaxing.
3. If anything, to tackle your question more directly. The advantage is on my side. Heck, out of university, I was very green. Now, I feel sorry for all the youngling in the interviews with me or anybody older. Experience matters heavily. The mastery of the data structures domain (language independent), is very real.
Then again, I actually really love what I'm doing. So that helps.
What about those who don't? Plenty of programming jobs don't require this kind of stuff, at least not everyday. These kind of jobs that keep your mind fresh are the most desirable as you get older, but they're limited.
I had a 9 months hole early in my career (personal reasons). I started coding a game from scratch. I never finished it, but learned a ton and it's actually a great talking point in interviews.
I had a government job at one point. Turned out to be different than advertised. No brains required ( except people being nasty to each other it seemed). Most poisonous place I've seen. I left that.
It helps that I'm in Toronto and there are job offers around, but it still takes me a week and 400-500 resumes sent when I hunt for a new job.
Bottom line: one has to keep pushing to get where he wants to be.
Worse in that we're 25 years removed from Algorithms classes.
Better in that we're used to explaining ideas to colleagues and management, and generally much better at expressing ourselves than we were when we first graduated from college.
That's the entire point. These sorts of interviews are an easy, legal way to filter out the "olds." And you're old in this industry by the time you amass 10 years of experience.
If there were really a shortage of programmers, ageism would not be an issue. As it is, there is an extreme glut of talented programmers and it's definitely a buyer's market.
Unfortunately the small / medium companies I work for tend to get acquired by large companies and I'm forced to work for a large company for a couple of years due to inertia. It doesn't take me long to yearn for a smaller company.
Many older developers of my acquaintance are happy where they are, they just don't move very often.
With newcomers to the industry we see a reasonable cross section, but with more experience, the sample becomes confounded by many other factors.
All that is just nonsense !
So - the author says that he has "developed some good communication skills". Great! Moving on, let's look at his linkedin page. Quotes from past jobs: "even after our idiot (now ex) CEO canceled the platform.", "wonky JavaEE stuff.".
So, as a hiring manager, from this post + linkedin, I now know that this guy: 1) can reach large audiences, 2) trashes past jobs and colleagues publicly. And thus, I would be terrified of hiring the author, as there seems a 50% chance that this will end with my employers being trashed in the same way. That's just not worth it.
OP: Come on, give yourself the chance to be hired by removing that from linkedin.
> I don't think it's so bad. Sometimes, you work with idiots.
Just because a person thinks coworkers are idiots doesn't mean the person should pipe up about it. It's one of those communication skills that a person with a ton of experience is expected to learn.
"Anyone who is still a programmer in their 40s has to have developed some good communication skills." "Old programmers are dabblers." "Old programmers have judgement." "We can pick up any new language because we’ve used so many over the years."
I've met old programmers who are counter examples to all these points.
A steelmanned version of the article would argue why older coders are more likely to have these skills than young coders. It also needs to talk about the average difference in ability relative to the variance in each group. If old coders are on average 0.1 standard deviations better than young coders you should focus on hiring the good old or young coders. If old coders are on average 1.5 standard deviations better than young coders you should just focus on hiring the good old coders and exceptional young coders.
Growing older doesn't make you a 10x dev, just as it won't make an average musician a superstar.
I will know more next year than I do today.
This will never stop.
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 be this way because the people who would be old programmers who are not this way aren't programmers anymore?
So, yeah, a talented young programmer could have accumulated enough experience to acquire these traits. But it's more likely to be found in us old farts.
Agree with your survivorship idea too. There's been a few that have changed course along the way.
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 the meaning of it, but to experience it and have a deep, intimate understanding of it you have to go through the process of writing something and supporting it.
So it's not a matter of correlation / causation, it's a matter of the two concepts being two sides of the same coin.
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 and support them. Yes, you will be older than you were before you started. But... to get that experience you do not need to reach age 40.
If anything, simply getting older is not a guarantee that you will get that experience. Suppose you only program CRUD apps for 20 years with the exact same stack every time. There's only so many times you can write the same sort of app over and over again before you get diminishing returns on that kind of experience. The author knows this implicitly, but assumes from his own experience that other 40+ year old programmers will have as wide a range of experience as he does.
That's really the specific premise of his that I'm questioning: that being an old programmer automatically means you have a wide range of useful experience that makes you better.
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.
In the last 20 years I've gone from writing desktop applications using RAD tools, to websites using no tools, to web apps using frameworks, to mobile apps using IDE's, to mobile apps using web app tools.
In the same period we've seen the rise and fall of Object Orientation, the fall and rise of Imperative/Structured Programming, and the burgeoning new age of Functional and Reactive/Declarative Programming.
Also Agile came and devolved back to Scrum Only, and waterfall never stopped being the default.
All version control systems got converted to Git.
SQL fell out of fashion for being too complex and then everyone worked out why all that complexity was needed.
You can't be in this industry for 20 years and work on one stack writing the same sort of applications ;) Maybe five years, tops.
Typically after you learn from experiences and gain knowledge you age. I'd question someone that is young and thinks they know the world.
If being able to acquire all he knowledge/experience while young were true, everyone would peak at 25 and not get any better.
There is a certain point some people get where they _refuse_ to learn more and are "set in their ways" and that becomes detrimental to a younger/fresh idea.
I doubt anyone would advocate age quotas for hiring but having a mix of experience/knowledge with fresh ideas is probably ideal. At least, it feels ideal in our team which has ranged from high 40s to low 20s.
The whole knowledge * intellect idea that someone else here mentioned is far too reductive. You can be a ridiculously smart person who has read white papers and coding books, learned all about discrete math and project management, worked on as many projects as you could, and still not touch the maturity of an older software developer. Why?
Experience doesn't begin and end with topics directly surrounding your vocation; your whole life contributes to it.
As you age, you get to know yourself better. Old people have made far more decisions in their life than a young person has: lots of good ones, and lots of bad ones. You know your decision making process and its flaws. You remember what it feels like to reap the rewards of a good decision, and even more intensely, you remember the sting of a bad decision. You know, from experience, what decisions you should make, what ones you shouldn't make, and any confounding variables.
You also start to understand those same patterns in the human and organizational behavior of people you live and work with. You start to get an intuitive understanding of the kinds of mistakes various kinds of people make in various kinds of situations. There's a reason that older people– often ones without a ton of domain knowledge– are generally the ones making big decisions in a mature company, while the younger people are working out the details.
For example, the couple decades that I spent as a bouncer in clubs might not help me see if I'm making a bad coding choice per se, but it vastly increased my understanding of group dynamics, ego, negotiation, how to mitigate the damage of having to make snap decisions with a whole lot of consequences, how to respond when someone tries to intimidate me or make me feel uncomfortable, deescalating pointless arguments, and even starting a fight when one really needs to be started. (the worn-smooth restraint and fighting techniques have much less utility in the office... so far) Before I gained that experience, I'd have no way to have known it would proved useful in a software development career. I'm sure many parents, people who have coached sports teams, people who have experienced the death of an industry, or even people that have gone through messy divorces can all point to things they've taken away from those experiences which have vastly improved their judgement and maturity.
And it's not just the soft skills which are improved by this understanding. Being more mature means you write more mature code. I look at code I wrote 15 years ago and shudder. It's not that I have a better understanding of the mechanics of Perl or C now than I did then, but my sense of logic has been refined, I'm more patient, and I have a better sense of where to put in extra effort and where to cut corners.
When you're young, you're still mostly figuring out what you're capable of, but you don't have a very good sense of what your limitations are. When you get older, you've got a pretty good sense of what you can do, and a much better sense of how to keep yourself and everybody else out of trouble by avoiding what you can't do. The problem is, lack of experience is generally pretty opaque to the people who lack it.
¯\_(ツ)_/¯
Agree! this is a succinct description of a eng management problem. However, it can be mitigated by hiring coachable, trainable (and mature) people. Interestingly, we've had great luck hiring from programming bootcamps; programmers who lack programming experience but have other work experience & who are eager and able to learn quickly, & usually come with some level of intellectual curiosity (as opposed to entitlement).
Is this true? I had a manager tell me once "when you're thirty, everything just starts to make sense" which I now know is total bullshit because I hit that milestone and there was no epiphany.
I think the old have been bullshitting the young since the beginning of time. It's their right, but it's still bullshit. Having a lot to say doesn't make it worth hearing.
- Your starting maturity makes a big difference. Not everybody is the same, and there's no shame in that.
- Not everybody is equally introspective. This is not a controversial statement. Not everybody is equally intelligent either, and the two things don't always correlate.
- Setting arbitrary, absolute chronological milestones on emotional maturity is dumb. I probably didn't learn to consistently have clean laundry on hand until I was in my early 30s. I also had a job where I regularly had to insert myself into life-or-death situations when I was just barely out of my teens, and I was damn good at it.
- The assertion that you wouldn't get better a better understanding of your vocation, workplaces, and how people work in general as you deal with them for decade-upon-decade seems a whole lot more outlandish than the counter-claim.
- People who claim to have it all figured out ARE full of shit. Life is a mountain, not a mesa.
- Things you've dealt with look deceptively easy to deal with when they're in the rear-view mirror.
To stand out from other candidates I prepared a 7 minute screen cast (using Camtasia which I bought a couple of years back) showing off programs I'd written and briefly mentioning programming aspects that made each program different. I uploaded it to Dropbox, emailed the link to the recruitment agent who forwarded it on. I got the job after two interviews and have just completed my first week. I was lucky, round here there aren't that many programmers and most jobs are for C#/ASP.NET MVC websites. It's just a 30 minute drive away.
The job interviews included an online IQ test (not a problem), a logic test which was not my finest hour (4PM on a Friday is the worst time for me!) and a 10 minute stand up presentation on the subject of my choice. "A trip to an Arctic Isle."
“Experience: that most brutal of teachers. But you learn, my God do you learn.”
And that's another reason to consider: yes, there are young people that has these traits, but mostly it comes from experience (or as we say here, 'colmillo').
The other big factor is the old saying that old dogs don't learn new tricks, so it's difficult to guide them towards the company vision, and it's worse when they have a boss that could be their son.
Those are my experiences based on Mexico, I know there are better places in the world with different mindsets, I just wanted to include my thoughts on this topic.
On the other hand, I worked with old devs too, and they did a lot of spaghetti code, they didn't make a module and a lot of things are weird for them. Like async/await/yield.
I think that it's not an old programmer, it's about the attitude that they had during his professional career and the attitude that they have now. With a lot of experience and the right attitude, I agree, it's a perk in the team!
1- "programmer" is the entry level in a software/hardware company. Rising stars move up in the ranks over the years and take more responsibilities. Manager, sr. manager, director, VP, etc. still a programmer at 40?
2- If you're still programmer at 40, you might really like it! We're looking for programmers and need age/exp diversity in our group. You are rare my friend and valuable.
So yes, you can absolutely have a professionally rewarding, lucrative career as a 40-50 year old programmer, but you'll earn more money by moving over to the business side, simply because you can more easily show a direct line between your actions and business revenue.
Architecting a class or small single-use library is a subset of the skill required to architect a distributed system, a large multi-tenant application, or some other non-closed system.
Whether you want them to have the same job title or not is I think orthogonal to the fact that they are very different jobs.
I think we are arguing the same thing, we're just stuck on the semantics of titles. I guess let me put it this way, do you know people who have the title of programmer who are way better at building systems than a guy with the title of architect? Of course. Some companies don't even use the title of architect. That certainly doesn't mean no one in the shop can design a large system. It's not the title, it's the ability, and titles are a horrible way to discern ability.
>A programmer with 20 years of experience is definitely worth more than a programmer with 2 years of experience. But not that much more.
This is what I took issue with. A (good) programmer with 20 years experience is capable of designing large scale systems, which is much more valuable than a programmer with 2 years experience. Maybe it's just my bias.
When I first heard the term "architect," I asked, "what is that?" and the reply was, "someone who designs large systems but doesn't code." I thought to myself "well that's dumb." FWIW, I've had the title of "architect" at various companies since 2008 and I've always coded at least the skeleton of my designs. I mean how else do you know if you're right? When I switched companies in 2010, the new company didn't have the title "architect," so I was just a "senior engineer," until we got acquired. I regained the title "architect" because I made X amount of money. Like I said, meaningless. As a side note, I think coders calling themselves engineers is also incorrect. Engineering is a specific discipline that actually has meaning. It's like Dr. Dre. It sounds good, but I sure ain't going to see him for a rash.
Able to make good choices = Intellect * Experience
In the context of older developers, I don't think you can really assume wisdom has been an outcome of all of those years of experience. Wisdom grows with a certain affinity for introspection and self-correction, and not everyone has those traits.
I hesitate to try and prescribe an answer for the "how employers should find good employees" question, because it's so difficult, but I imagine the ideal hiring process would:
- Allow candidates a choice on how they want to be tested (take home thing, online code test, whiteboard, whatever else)
- Ask better questions at the abstraction level that would show experience. For example, if you want to know whether someone has experience, give them an architectural diagram (or process diagram) of your current project/workflow/whatever, and ask them how they would improve it (and if they've ever been through the steps they suggest themselves/how they would roll it out).
There was an excellent post on HN a while back detailing what a specific company (whose job is doing interviews, I can't for the life of me remember what company it was), learned from doing thousands and thousands of interviews.
Also I'm not super good at math, but in the equation you posted wouldn't the intellect variable be pretty much equal to experience, and you could make up for one with the other? Or maybe you're implying that the scales for each multiplier are different (like intelligence might only go 1 to 10 but experience might go 1-100?)? I agree with what you're getting at, basically that someone who has seen lot but isn't as clever will often make better choices than someone that's very clever, but completely green.
Is it common for programmers that have been on a job to not realize the ways in which their software sucks? Knowing what to avoid and the consequences of doing things wrong is an important factor of experience; additionally, maintaining a bad system gives insight into mitigating problems.
That said, I do agree that experience isn't just a passive function of time (as in "interest earned"). Instead, it's more like a landscape that needs to be explored (and to your point, some companies will allow a programmer to explore more productive areas).
> ...the equation you posted wouldn't the intellect variable be pretty much equal to experience, and you could make up for one with the other?
I suppose the answer to your question would depend on just how much variance you place on intellect. Is it:
- 0.0 (rock) to 1.0 (cleverest human on earth)
- 0.0 (rock) to 1.0 (cleverest intelligence across time and space)
Either way, I wouldn't take the equation too seriously--it was just a model to show a trend :/
I agree with the point- I'm getting older, too- but the reasoning is not strong.
Ah well, lesson learned. Don't do it, youngsters!
Isn't age discrimination illegal?
Why would discriminating against younger people be any more fair or legal than against against older?
I expect discriminating by amount of relevant experience is fair, but that's not the same as age.
https://en.wikipedia.org/wiki/Employment_discrimination_law_...
As someone who started coding at age 9, I agree. :-)
It's not about hiring someone in their 40s per se, but rather about recognizing the value of 20 years' experience. Age alone doesn't impart wisdom.
To attract the candidates they optimized non-salary benefits they thought college kids would like such sports tickets, beer nights etc.
The bottom line is companies know exactly what they are doing and just officially claim some culture fit thing.
Same with hiring women, minorities,etc.
Even with open space offices. They say it's because they want people to collaborate but more often than not they want to save money and monitor people to see if the are "working".
I have been self-employed for the past ~7 years and it has been great as I have been able to balance work with the first few years of my sons life. Time I will never get back so being able to be there every day has been wonderful. But now I need some consistency so will be looking to find a normal job very soon. I don't care about free coffee/sofa, gym memberships, sports tickets, etc. I just want flexibility so when my son has some school event I can go without having to use up a whole days holiday for a 45 minute show, etc.
I am not looking forward to it though. I know I am going to find it hard to adjust!
So there are companies that will let you do that just have to find them.
In my experience, they try not to see the connection. If you try to show it, they'll listen for a bit and then rationalize. If you keep at it you'll begin to see irritation and even aggression.
That a fair number of CTOs have a decent technical background doesn't seem to help much, somehow. I've had this confirmed personally when I got together with a coworker from almost 20 ago who had moved into management. He struggled to keep experienced people because they moved for more money, because they were paying below market value. If I suggest something like paying more, he considers it and then some weeks later I find he's still struggling to figure out a way to keep people, having changed nothing of consequence.
It's my pet theory that (almost all) management wants programming/IT to be a commodity and are willing to pretend that it is, to their detriment. They demand that it be a commodity.
Its a management cultural issue, not an older programmer issue really.
I think this goes to the mindset that it is always important to try to prove your skills by example.
If someone were to be making hiring decisions, posts like this discovered during the course of casual googling would oblige the person with a robust basis not to hire. Heck, at least one firm on my CV has instructed me to regard discriminatory language involving suspect classification, age included, as grounds to reject.
(2) If you are making hiring decisions the appearance of random blog posts should not and will not give you any legal basis not to hire. Legality is encoded in the law, not in blogposts, especially not in blogposts by random passers by. If you were using this as a reason not to hire the person writing the blog post then you might get some mileage out of it but it could also easily backfire.
Entirely true. In my defense, I'm not a lawyer. Technically also in my defense: the United States has a bad habit of calling corporations people.
> (2) If you are making hiring decisions the appearance of random blog posts should not and will not give you any legal basis not to hire. Legality is encoded in the law, not in blogposts, especially not in blogposts by random passers by. If you were using this as a reason not to hire the person writing the blog post then you might get some mileage out of it but it could also easily backfire.
This may be true in the Netherlands, but in many states in the US, quite a number of things can be used as grounds to not hire, with the notable exception of anything involving suspect classification (https://en.wikipedia.org/wiki/Suspect_classification). My understanding is that if someone is likely to cause the firm to be responsible for illegal conduct e.g. age discrimination, for many firms, that's a sufficient basis not to hire.
I'd love to be corrected, though.
HR policies are what takes care of that, if an individual is able to make the company engage in illegal behavior you have bigger problems in the oversight department. Hiring comes with a bunch of rules, this person should not be able to transcend those rules by their lonesome.
Policies don't physically prohibit certain conduct; they merely provide a framework of consequences to discourage it. That's also why policies exist on when not to hire someone: to minimize the risk of the new hire acting in violation of policies.