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 of young programmers and no experienced one who lead them.
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 attitude.
But obviously that's a generalisation. Just like your comment is.
In my experience, growing older, I've found both of these generalizations to be true in myself. There are plenty of times that I've watched junior developers make literally the exact same mistakes I made 10 years ago. At the same time, I've learned that technology has continued to move on and things that were wrong 10 years ago may not be wrong today.
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.
This reminds me of an intern that recently went through our company.
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.
Hopefully you lot took it as your own failure and not the poor intern dropped into the field with one of the most over complicated technologies and 'magical thinking' tooling.
Sure, we shouldn't have been so busy to not support our teammates.
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.
Not saying that is necessarily the case, but situations like this can also develop if you have a lot of basic knowlege (especially regarding tooling) that is neither documented properly nor spread amongst most of the team.
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.
Problem is a lots of young people may not seeing old people and old knowledge the same way like old people do.
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".
Well, it often isn't that simple, really. "Old" knowledge can also be simply not true anymore.
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...
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 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
He was certain that the flat-table design would take up more space since it would 'have to store every attribute every time'. Most of these were varchars, so (looking back) that was straight up false. Not only that, but in a key-value schema you have to store the name of the 'column' (key)... every time. I was unable to articulate the harms of key-value schemas when it comes to queryability...even though our existing system was filled to the brim with 'unions' due to a key-value schema. I lost this argument.
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...
>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 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.
> 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 implementing a reasonably performing web application.
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.
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' ;)
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.
Eh, I've seen some fresh college grads advocate the same stored procedures and silly k/v stores in relational DBs; someone told them that "model code must be isolated; stored procedures are the best way to do that" and they took that as gospel.
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 work in an organization that is relatively balanced as far as age goes (I'm 45). The most senior-level engineers tend to be older than me, though there are a few younger guys (still over 30). Perhaps I'm just fortunate, but here's what I've observed:
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.
In some cases, the Old Ways and the Old Software is better, and it takes wisdom and experience to identify these cases. "Because it's old" is almost never a good reason not to use some software or technique (code does not rot). "Because it's new" is sometimes a good reason to try something, though.
"""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".)
git is a good litmus test. If they're old and refuse to use it, they're probably a close-minded dinosaur.
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).
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.
Yep, pattern bias happens to a lot of people in a lot of age groups in a lot of professions. One of the consequences of having a massive pattern matching machine for the human CPU.
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 hear this much more often from the less-experienced programmers than I do from the seasoned, experienced ones. Once in a while, and usually in a very large shop, I hear it from an experienced veteran. However, usually (not always, but usually) from one who's had 1 year of experience 20 times rather than 20 years of experience.
> 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.)
I've also had my share of encounters with such people, so I can relate to what you're saying here.
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.
It definitely happens in lots of other types of jobs, too. It's not just programming.
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 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 else.
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.
The more I think about it, the more I believe this is indeed the fatal flaw in nearly all^ of the arguments against hiring experienced programmers. For any service I can think of where skill is needed, whether it be patching my roof, fixing my car, doing surgery on me, representing me in court, flying the airplane I'm on, I would rather pay more to have a greybeard doing it than have someone fresh out of training/college doing it. I'd guess most people are not even remotely concerned about "cognitive decline" in any of these scenarios. What makes programming different?
^ (all the arguments that don't boil down to "you have to pay them more")
Yea, I feel the cognitive decline is a kind of an excuse, to mask the expense of experienced programmers. Only in the tech industry is this an issue.
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.
Hey great career idea for extreme over-achievers: write software until you're 35 but in the meantime study full-time as a thoracic surgeon. By the time you're "done" or "washed up" (according to some recruiter who does...??), you're the right age to start your career as a doctor that I'd probably not want cutting into me for a few more years.
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.
> I had to abandon the "keep knowledge in my head" paradigm in 1990 or so and shift to the "problem solver" model.
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).
> but about how quickly our knowledge becomes obsolete
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.
> 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?
No chance I can do math in my head nearly as well at 30 as I could at even 25, but I can't count the other areas I have improved in that seem to mean so much more as an adult and as a professional.
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.
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.
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'.
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
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.
I'd hope that my doctor "need[s] to think sometimes". Anything less while holding a scalpel in anticipation of cutting me open is downright terrifying.
Same goes, ideally, for politicians and lawyers and engineers.
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, 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.
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.
they do but it is not the same thing at all. we need to think for hours, finding the right algorithm to compute something. doctors need to make the right decision in very little time based on their experience and knowledge.
Yes but aren't probably a good 2/3 of "developer" jobs the relentless pursuit of arranging the chaos into routine? Funnily, is not a "routine" a building block of a programming language??
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.
I'm in my early 30s, so frequently called an older programmer and I've heard a lot of, "we don't have time".
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.
What you describe is often the scenario of do-everything consulting sweat shop building tailored or customized solution from scratch based on a single customer requirements. Management often lacks business vision and technological path. Front sales and techical people are randomly assigned and switched between ad-hoc projects with varying industry domains and poor communication chanels.
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.
Most of new features are useless, so it does not matter that they are buggy.
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.
I think that's true, pretty much. But the downside is they force an inefficient development methodology on you as you try to make the imaginary deadline.
It's even worse as an old sysadmin, since my Groundhog Day permeates almost every part of the organization.. and I've learned to avert my eyes from the code itself and leave that nightmare to the Old Programmers.
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.
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.
>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.
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%.
How do older programmers deal with coding interviews from companies like facebook / google? i feel like those advantage people who just finished their algorithms class, or have time to practice specifically for it.
Well enough, apparently. I had to go through this at Facebook pretty recently. I was 51 at the time, and there were a half dozen guys of similar age in my subsequent bootcamp class. (It's interesting that my age cohort was all guys even though the class overall seemed pretty balanced, but that's another topic.) Two things definitely helped with this.
(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.
How do older programmers deal with coding interviews from companies like facebook / google?
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.
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.
step-by-step detail about how one actually can manage to "bypass" a company's interview process.
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.
Not sure that counts as "bypassing the interview" but thank you for your thoughts! This seems like normal networking 101, get your foot in the door by knowing someone there.
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.
It's not bypassing the whole interview, but it is bypassing the "coding interview" gauntlet which is what seems causes the most anguish. If you're there on a strong recommendation from a trusted colleague then the interview becomes as much the company trying to convince you to work there as it is you trying to convince them to hire you.
What you're missing is, it's not "Thank your for your interest in working here" it's more like "Joe Smith said you might be interested in working here", and there is still sort of a phone interview, even if you're almost sure to be getting an offer during it.
> 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.
Don't want to generalize but as far as I have seen; they don't. As a 6th point in his list could be; connections. I (42 y/o) know people; I can get programmers to follow me if I move company which is a plus. But I also know investors, potential clients, C*O's and hiring managers. People recommend you or know you via their network.
You could read it that way indeed; I meant it like; I know a lot of coders who will join me if they are looking for something new.
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.
> i feel like those advantage people who just finished their algorithms class, or have time to practice specifically for it.
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.
Could you give some examples of where you first got your contracts (outside of personal connections)? The contract market seems great (I'm in it right now), but finding decent positions seems pretty difficult without a pre-existing large network.
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.
Yep, same here too. Worked as a freelancer for 15 years with one company and now trying to find a new contract (with only a small network) is pretty hard (can only do remote jobs due to a handicap).
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.
> 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.
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.
I have no desire to work for either Facebook or google. I like small / medium companies where I can cover a lot of ground and make my own design decisions.
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.
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.
Counterpoint: Because these companies place so much emphasis on your actual performance at coding during interviews, they can be better for older programmers because they are not hiring based on how you look but on what you can do.
Lots of people think that the answer is "badly", but we don't really know. My personal experience (I'm 44) is that I've been offered every job I've interviewed for, passed every phone screen etc.
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.
This. At 47 I'm 13-2 in interviewing, where one of the rejections was mutual (a recruiter added bullshit to my resume and sent me for an obviously bad fit) and the other was Palantir years ago (coding didn't go badly, I think it was culture fit). I've never practiced for interviewing and I'm pretty suspicious that you only need to if you've spent your career gluing together code you don't understand. I've been worried about ageism but it hasn't kicked in yet.
Older programmers can do just fine in those algorithm tests, if they have been programming recently at their day jobs, and not PM/managerial work. Years of 8 hours of programming per day is actually good practice. They might have to brush up on Big O notation. :)
This guy assumes that old programmers are not super enthusiast and hard worker but they have experience, while young ones are enthusiast, hard worker and motivated but they know nothing, that's not a very rigorous way to prove something ...
I would _never_ hire this candidate, based on seeing this.
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.
Quoting a previous reply to this thread which was deleted (so I'll omit the commenter's name):
> 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.
OP here. I specifically left that part of my CV in because it represents a war story about webOS. Anyone who was a webOS fan knew what I was talking about and agreed with me. It has been a conversation starter with recruiters several times.
I've worked with old programmers who are great and old programmers who suck. Most of the points in the article are obviously wrong.
"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.
What a ridiculous assumption. It is not about age! I've seen both young and old horrible coders. Of course you can have a slight advantage from experience if your'e older, but the quality of that experience remains relative to the person in question. You might have 10 years of experience doing things the wrong way!
Growing older doesn't make you a 10x dev, just as it won't make an average musician a superstar.
To be honest, as a middle aged folk I find it impossible to relate with ping pong culture and open space offices. On the other hand, cubicles here are too often signal of brick & mortar ways to intend business, which ultimately means losing value. That's why I think older folks like me should really get into contracting or external consulting. As an alternative, do with finding a job at utilities or other non-cyclic ventures, they always seem eager to listen to juvenile-but-not-disruptive folks to innovate just a bit, not too much, not too fast.
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 be this way because the people who would be old programmers who are not this way aren't programmers anymore?
> because they're less about age and more about being able to learn from experiences
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.
For most programmers in their 40's, at least in my experience, we've been working in the industry since at least our mid-20's, if not earlier. Very few older programmers I know started learning to code in their 30's. Most started in their teens.
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.
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 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.
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.
You think there's any stack that will last for 20 years?
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.
I enjoy your attempt to use "it's not the years it's the mileage" but your assertion that there is some way to gain "experience" without "time" doesn't make a lot of sense.
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.
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.)
Well I'm not sure if you're young or just playing devil's advocate, but a young person often feels that way.
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.
"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).
Totally. I've also had good luck with people coming out of programming boot camps. In my current line of dev work, I'll take someone who's really eager to learn new things and jump on tasks over someone who can confidently invert a binary tree on a whiteboard.
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.
I'm 58, live in the country (UK) and found a programming job almost exactly suited to my skill set (Pascal mainly-i.e. Delphi along with C# plus a few years of C, C++). Add in 5 years of 6502/Z80 assembly (games in the 80s), two years of Ada. The last three years was creating a mobile app in C#/Xamarin. Plus lots of php, html, SQL.
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."
Hiring is more than the job tasks: there's work culture, politics and external factors. At least here in Mexico, the people usually are very political (we call them 'grillos'): they tend to form groups, brain wash other employees and use the law to their advantage, because in Mexico, the employer has to prove almost everything in case there's a work dispute.
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.
If you're trying to get hired please always include your location in your communications so that you don't get rejected out of hand for not appearing to be 'close' and/or waste peoples time.
Be old dev doesn't mean that you know how to write code. I worked with devs with twenty years of experience, and I love it, and I learnt A LOT from them.
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!
2 reasons why you will OR won't be hired as an old programmer:
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.
A programmer with 20 years of experience is definitely worth more than a programmer with 2 years of experience. But not that much more. A skilled architect with 8-10 years of experience will beat a programmer with 25 or 30 years experience every day in terms of ongoing business value, and will command a much higher salary (15-20% or more).
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.
Job titles are meaningless. When I say 20 year programmer, it's what you would call an architect, senior engineer, whatever. The programmer being someone who doesn't do any design is a foreign concept to me and should find another career. Any architect that doesn't write at least the skeleton code is the same. All levels of that career needs to involve design and implementation of that design.
Every company I've worked at with 2 or more developers has acknowledged a difference between a developer responsible for high level architecture and technical ownership of a system(s) who happens to program some of that system as well, and a developer responsible for programming parts of that system who happens to architect smaller self-contained pieces of it.
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 you are trying to differentiate between a programmer with 20 years experience and what you call an architect by using titles. Like I said titles are meaningless. A programmer with 20 years experience who can't design a large system isn't a very good programmer. An architect who can't design a large system isn't a very good programmer either.
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.
Consider smartness as "what you can do with what you know," while experience is "what you know"--then, what follows is that having more experience makes up for not being as clever.
Able to make good choices = Intellect * Experience
Moreover, employers can _try_ to assess intelligence with whiteboard interviews...but the easier factor to evaluate is experience. It's right there on the resume!
Yeah, except 10 years at certain companies could teach you less than 6months to 1 year at one company that's actually doing it right.
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.
> Yeah, except 10 years at certain companies could teach you less than 6months to 1 year at one company that's actually doing it right.
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 :/
This is usually delineated by wisdom vs intelligence. Intelligence is raw horsepower, and wisdom is the ability to make good decisions.
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.
Agreed. I remember being in my early 20s, watching my more experienced colleagues, and realizing this. I had had a different (incorrect) mental model: I had thought intellect was as good as experience, so Ability = Intellect + Experience. I was wrong.
Time does not translate directly to experience, not all experience is equal, and one thing old programmers should know about more than anything else is their personal biases.
I agree with the point- I'm getting older, too- but the reasoning is not strong.
In Polish the title "senior developer" is usually translated into "starszy programista"; the adjective "starszy" means literally "older". So, I ask everybody to call me "old programmer". :)
Thank you. 56 years old, still writing code. I enjoy working with young programmers, they bring energy and ideas to my projects and keep me from getting stale and stuck.
As others have stated, "age discrimination" is a bit of a misnomer. It's completely legal to say that you're not hiring someone (under 40) because they're too young. A more accurate description would be "discrimination based on age of a candidate over the age of 40" but that doesn't roll off the tongue quite as well.
Are employers so dumb that they would hire on the basis you're suggesting without considering the arguments put forward in the piece? Young and old have, perhaps, on average, different characteristics worthy of note if you're hiring someone. Is all!
Reason to hire a young programmer based on the confession from CTO: we like college grads because we can drive them hard and pay them minimal salaries. The only thing is they burn out pretty quickly. And yes they also lamented the quality of their software and how releases were buggy and delayed. Not sure they saw a connection there...
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".
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.
I also have that theory, and it's not a stretch since the act of business is to commoditize everything. I especially saw it in the IT consulting business.
I am 33 and have a 4 year old son who will be starting school this September. The biggest benefit for me that any company could offer would be true flexibility with regards to my working hours and location.
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!
I work from home for example and nobody watches over my shoulder how much I type, just that work gets done and releases ship out and such. I can go to my kids school to see a performance and then make up the work if need be later. If it is a nice day I might start work earlier then to have time to go to the pool in the evening with them.
So there are companies that will let you do that just have to find them.
Being sweet-talked into raping the world for other peoples awesome profits comes easier when you're 20. The real problem is the messed up priorities of most companies these days; older coders are more likely to call bullshit and demand a fair share of the cake.
The problem with Old Programmers, is not their work. Thats solid. Its the fact that they have mortgages, pensions, health issues, etc. This costs employers money. And employers HATE giving money because they feel like since you are getting a meager salary they are already doing you a giant favor.
Its a management cultural issue, not an older programmer issue really.
To add a dissenting view, ideally I want more seasoned developers, so older is better. However, I still want to hire the right developers. I have worked with some older/experienced developers who were deficient in various ways, including one who had no concept of separation of concerns or testing code.
I think this goes to the mindset that it is always important to try to prove your skills by example.
If an attorney were building an age discrimination case against a person (or entity, per jacquesm below) involved in the rejection of a younger candidate, posts like this are among the evidence I suspect would be used to point to a discriminatory mindset. That said, I'm not a lawyer.
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.
(1) You don't make legal cases against people involved in a hiring rejection, you make a case against a company.
(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.
> (1) You don't make legal cases against people involved in a hiring rejection, you make a case against a company.
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.
> if someone is likely to cause the firm to be responsible for illegal conduct
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.
We're not at all in disagreement, but even after an enforcement action is taken within the firm, if the illegal act has already taken place, you'll still find lawyers willing to go after the firm.
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.
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.