Career planning: Where do old devs go to?
ayende.com
ayende.com
I've always been very busy (one of the main reasons I don't post on HN as much any more). I don't have a resume. I'm not on LinkedIn. If I ever ran low on work, it would probably take me a day or two and a few phone calls to find something.
I don't work on anything unless I find it incredibly compelling. I write applications. I've seen tons of different technologies, many old ones I still use. But I also get very jazzed learning new stuff and incorporating it into my toolbox.
I know tons of programmers in my age group. I'd classify them into 2 groups:
25% - just like me. You don't see our resumes because we're very happy building cool stuff and rarely look for work. We've also seen it all and can smell something we're not interested in a mile away. You don't see us at many events because we're so busy with work and life, we only pick the ones with the most promise of bang for the buck. Most of the programmers I know in this group would make phenomenal additions to many startups, but don't recognize this as a compelling alternative to what they're already doing. The best way to engage us is to seek us out, make friends, and share some stories about something cool you're working on.
75% - one year's experience 30 times, not 30 years experience. Unaware of modern technology. Couldn't write Hello World in anything other than BASIC, FORTRAN, or COBOL (and would probably misspell 50% of the words). No imagination. Limited ability to visualize the possibilities. Hiding under the radar in some enterprise. You don't want these people.
You might be wrong, and you should factor that in. Perhaps you're not helping people towards a bright new future of self-realization, just condemning them out-of-hand based on your own limited experience or misconceptions? (Not using "you" to imply you do this, btw.)
> Perhaps one isn't helping people towards a bright new future...
Never the less it's important to think carefully before criticising others. You are absolutely right and I'll try to keep that in mind next time I want to tell someone how bad they are.
The worst part is that most people don't recognize this, they live in the bubble, being proud of themselves they know it all. Unless they lose this job and suddenly realize they are basically unqualified for anything outside of their narrow field of expertize.
Either get lucky, never lose that job, so you don't get your feelings hurt when looking for new job. Or get out of the bubble before it's too late and start challenging yourself with new opportunities.
I went Googling for its origin and the first link just took me back to HN: https://news.ycombinator.com/item?id=4627373
That's the problem with the generalization: it's too general, can be applied to almost any normal career, and isn't really a good heuristic to use when analyzing somebody's work experience in most contexts.
I find it quite amusing, but in my observation, this 25%/75% split can be found in each age group you'd look at...
You are basically saying 75% of the developers after certain age are useless. I don't agree or disagree with your statement . Just startled. What does it say about software development as a career ? Would you say the same thing for lawyers or doctors with 30 years experience? This is depressing.
Example: The top 20% of a population owns 80% of the wealth.
And yes, this applies to other occupations as well.
If you don't have passion for something you'll never be truly good at it.
Sure they may not have the "passion" but it also doesn't mean they're grinding away through their days. As I said in another comment, your priorities change and your perception/measure of job satisfaction changes as you get older. Mine certainly has despite being a techy and developer to my core.
You also could uncharitably argue that 75% of developers of any age are useless. Furthermore programming has a much lower barrier to entry than being a doctor or lawyer and it's much easier for a terrible programmer to hide their terribleness for 30 years than it is for a doctor or lawyer.
I don't have a reference for this, but I remember reading that other than surgeons, doctors' skills decline the further out they get from medical school... of course that's doesn't take into account a lot of the other important parts of being a doctor like how you interact with patients, etc.
Sure they maybe repeat the same one year's experience year after year perhaps with some technology transitioning years from COBOL to VB to VB.NET or C# or maybe Java, that kinda thing. They'll know Oracle or MS SQL or DB2 well enough to make stuff work, or maybe they call into a message switch (with a pre-wrapped library for their language/framework) to read/write their LOB data.
They work there for years and years collecting their salary and annual (if there are any) bonuses and many will be the last lucky few to hang on to a decent occupational pension, in return to knocking out code to meet business requirements. But they do it well, they know their line of business apps for their organisation's market sector and "how things are done". These are conservative people working in conservative business environments.
The thing is who cares? Many of these folks have interesting lives outside their corporate bunkers which involve travelling the world, renovating houses, flying small aircraft, model trains and enjoying friends and family...and much, much more.
It's just a job and I'm sure these folks will have their own measure of job satisfaction which will be different from ours. It might not be as exciting as the seat of your pants local startup but it pays the mortgage and provides reasonable financial security.
Sure there are no absolute guarantees about job security, but I live in the UK and we're at a lot less risk of being fired for no reason other than "at will". It takes quite a bit of legal effort and cost to make employees redundant, especially in finance where you're fairly likely to be a member of a union (mass redundancies have to be negotiated and consulted on and redundancy payments agreed etc).
It's not depressing, it's just that these folks have different priorities in life.
Scott Hanselman described some of these folks as "Dark Matter Developers"[0].
[0]: http://www.hanselman.com/blog/DarkMatterDevelopersTheUnseen9...
* To address the Ayende's question, being 47 I'm probably an "older dev" I've worked for the same company since 2003 (ISP/Web Hoster), I like the work, I'm happy there, they treat me well, I work from home, it's (fingers crossed) reasonably secure. It'd take a really seriously good offer to make me change employers. This is not to say that I don't keep abreast of the latest tech and frameworks, the fact that I follow HN should make that abundantly clear; for example we're looking at how we could monetize Docker for our clients - first heard about here.
I can understand this mentality, but cannot sympathize with it. Personally, I refuse to treat my job as "just a job." I want it to mean something. I want to look forward to coming to work everyday. I want to feel like the work I do makes a difference, as opposed to fizzle out and die in the massive corporate bureaucracy. I hate the idea that I'm just spinning my wheels, looking busy, collecting a paycheck. Doing so is just... soul crushing. That's the best way I can describe it.
I'm actually literally 15 minutes away from giving my two-weeks notice. Just waiting for my boss to come in. I'm glad I had the chance to put my feelings in writing somewhere other than my resignation letter because I wanted to get them off my chest but not burn bridges. Thank you teh_klev. :)
Well, some people don't build model airplanes after work. They raise families, work at food banks, take care of their elderly parents, sponsor people in AA, and so on. Ideally, every waking minute of your life will make the world a better place, but it's a luxury to expect a career that really means something.
Good luck on your career decision. It sounds like you've already made up your mind, but in general it's a good idea to talk to your boss about the soulcrushingness of work well before you want to quit. It's possible that she would be willing to give you more variety, responsibility, or freedom to keep you around.
I remember when I was early in my career I talked with an older engineer who had done lots of time in the insurance business and I said something like "I don't know if I could ever work in something so boring".
He replied "making sure that claims are paid out correctly can be the different between somebody having a home or going homeless, or somebody being able to feed their family or not having transportation at all. Keeping in mind the lives of the people you're ultimately serving keeps me motivated even if the day-to-day is boring"
It's advice I've always kept at heart and it's been helpful.
That's fine for you, and quite a laudable position to take.
But the reality is, in a great many environments, across the board -- in blue chips as well as in startups (often quite insidiously so) -- as soon as you start personally investing in your work, you start taking on considerable risks. It means, almost by definition, you're going to start butting heads with people -- or at least take on a heavy risk of appearing to others like you're butting heads with them, even though you're not. Because they'll have to start justifying their own decisions, and exposing their own lack of depth and experience. And that's really, really threatening to a lot of people.
The safest route, by far? Keep your head down, and don't become "personally invested" in your work. Otherwise you risk becoming (per the Japanese proverb) "the stake that sticks up."
The present role, where I've been for the past 11 years, is very enjoyable and gets me out of bed in the morning...but paradoxically I do treat it somewhat as "just a job". I have to do that because otherwise I'd just burn out, and that happened once before and it nearly killed my development career.
But anyway, I wish you all the best and hope the future's bright for you.
I'm skeptical of the "financial security" claim. Obviously this is not true in the U.S., where there is zero hesitancy to lay people off and very rare to have legal recourse as an employee when laid off.
But even working in the U.K. or other nations with stronger worker protections, you are still vulnerable to your employer hitting hard times. Companies can very quickly go from profitable to out of business or close to it, especially where technology is involved. Not having skills applicable outside of your current job does not seem like a secure strategy.
I guess it depends on how you define 'reasonable financial security'. As someone in the US, I define financial security as having a couple month's pay in the bank, and a retirement plan of some sort, while making enough money every month to pay the mortgage and the bills and have some left over to spend on entertainment, then it is doable, even in the US.
A mediocre developer who has a bit of experience, making $75k/yr anywhere but San Francisco or New York, could afford to be in the situation I describe.
What does 'reasonable financial security' look like elsewhere?
Sure, but types of companies I'm talking about where these folks work are big blue chip FTSE 100 companies. It's a very rare event where a company the size of Lloyds or Barclays or BAE snuffs itself out of existence.
Ok sometimes you get a perfect storm such as the 2008 banking crisis but even then the UK government and others stepped in to prop up the likes of RBS, Bank of Scotland and Northern Rock. No-one turned up to discover the doors locked in the IT department and life very quickly went back to business as usual.
It doesn't really have anything to do with after a certain age, either. Some percentage %x of your 5 year experience programmers haven't really moved much past their first year at all.
To be fair, I think of it really as a series of plateaus, not a hard and fast rule. People get stuck at a level of professional development for all sorts of reasons, internal and external.
The thing is, it gets more noticeable the longer time period you are talking about. Comparing two people with 3 years experience where one of them hasn't really progressed past the first year or so, and the other has 3 solid years is a lot different than comparing two people with 30 years experience where one of them hasn't really passed the 10 year mark of development and the other has a solid 30.
And "useless" is the wrong way of looking at it. There is a lot of use for a developer with 5-10 years of experience, so long as you don't expect them to perform like a developer with 20-30 years experience. This is true even if they have 30 years on paper, which can be a bit of sticky point w.r.t compensation, but that's a different issue.
This absolutely happens with lawyers and doctors, by the way. A real difference is that a doctor has been forced into a good 10 years of professional development before they take the training wheels off, so the base level of competence is much higher. Some of them don't progress significantly beyond that for the rest of their careers, but that doesn't mean they aren't productive for that whole time.
As an industry, I do believe that software development is pretty weak on developing talent internally, particularly beyond the entry level.
But I've always thought a team of generalists beats a team of specialists, which is swimming against the current tide.
Considering nearly any situation your team encounters, junior people, experienced people, and very senior people are likely to take different lessons for it, because they have different perspectives on what happened and what could have/should have happened.
To me, a "same year of experience, 30 times" person is someone who runs into similar situations over and over, but fails to grow in how they understand and react to them. This is true of architectural issues, interpersonal issues, schedule management issues, ... everything really.
Technology stack isn't so important here. If anything I expect the experienced people to pick up a new stack faster, if they've done this before, all else being equal.
I'd expect insight and ideas from a 20+ year developer I'd never dream of asking a junior (< 5 years), and if you don't get them - you're probably looking at someone who has repeated many of those 20 years.
Ed why can't you have your own company? Why can't you be the one who is hiring or at least teach others how to hire. I bet you can smell a talent from 1000 miles away - even if someone did not finish a good school; the world of software engineering would make so much more sense.
[EDIT:] I imagine a job interview; an interviewee says: "I didn't program this but I did program something more difficult"; interviewer makes a frowny face; Ed comes round the corner, puts his hand on the interviewer shoulder and says: "He did not call you stupid; he just said he is ready for the challenge - he has the experience".
1. He doesn't take a job unless it's challenging. They don't post on HN or go to conferences because they are busy with so much work and life (hence no wisdom sharing).
2. If he is a freelancer (which his post makes him sound like), than he does own his own company. It's just not a software startup looking for VC or articles in big magazines.
3. He's not hiring because he wants to program, not do HR. Also, Michael Jordan can't pick players for shit and he's the best BB player in history. Skill in a job doesn't mean you can find talent, and the level that he would jump and say a person has talent is probably the level where said person doesn't need recognition to know their skill.
4. If a team does a good job outlining job requirements and interviewing, they too can smell talent from 1000 miles away. But interviewing every applicant with a 2.0GPA from a bottom tier school takes a lot of time and most often does not reveal a hidden gem. Regardless of what their potential is.
Or they simply aren't interested. They are happy with what they do.
On the other hand, seasoned programmers do make great interviewers. And a good interview often include them in the process. Their insights are very valuable.
Also as a sidenote, if there is no senior/lead developer during your interview process. Or the people do not appear to have a clue. Run. Unless they are going to hire your as the senior/lead, and they admit they lack the knowledge.
I've owned a company but its lonely, so now I earn less but work as a peer in somebody else's company.
That seems highly unrealistic.
- What are the odds HN would attract and recognize a one-in-seven-billion individual? HN is not THAT special.
- You believe Ed holds great wisdom, and it is Ed himself telling you he is not the only one.
This exactly and it happens at all ages. I interviewed someone not long ago who had 5 years experience. It turned out they learned their job in 3-6 mos. and just repeated that same job for 5 years. I was amazed how little else they knew.
Most programmers don't take this path by choice. They just don't see it as its happening. You have to pro-actively manage your developer career if you want it to grow over the long haul.
Let's remember that in those 42 years the number of BASIC, FORTRAN, or COBOL jobs has diminished through to almost nothing. The last person I met who described themselves as a COBOL programmer was about 10 years ago, and even they said they did it for the money as there were so few of them left.
So the programmers edw519's knows have in all probability probably managed to switch from COBOL to to VB6, then Java or PHP and then maybe even C# or Ruby and are probably nowhere near as stagnant or unambitious as he's portraying them.
It's that or he hangs round at COBOL programmer's meetups.
Something about programmers makes them think they are all the destined one true hero, and as a result, programmers tend to disparage and disrespect their own peers, at great cost to themselves.
My favorite is this guy [1], who was literally adding billions of dollars of revenue for Goldman Sachs, but was getting paid peanuts. When he left to pursue more interesting work (not for salary!), they brought the FBI down on him.
I don't call myself a programmer, computer scientist, or any such low class term anymore. I'm a consultant, and I don't associate with self-deprecating professionals who denigrate their own fields.
Humans are primates, and we form status hierarchies. Proudly exclaiming that your tribe is at the very bottom is the definition of stupidity. Good luck to those that do, I sincerely wish you the best. But when your salary stagnates, you're asked to work 80hr weeks without overtime, and you get no respect from management, maybe its time for a little self-reflection.
There is a reason software dev is such a low status profession, and it's not because we're "nerds". It's because we self-denigrate and self-deprecate like no other profession on earth.
1. http://en.wikipedia.org/wiki/Sergey_Aleynikov
EDIT: It is worth reading this article if you'd like some more details on this problem, from a fellow HN member who has dedicated a lot of time to thinking about it [2].
2. http://michaelochurch.wordpress.com/2014/07/13/how-the-other...
As a combination or individually? Medicine is about the only one in the list that's strong in all of the listed characteristics. "Heavy engineering", to my knowledge, doesn't pay much more, finance doesn't seem that much more stable, and law certainly has good work conditions for those at the very top, but not for the newbies.
The programmer types were different from the trader types. The trader types were far more alive to the bigger picture, to their context. They knew their worth in the marketplace down to the last penny. They understood the connection between what they did and how much money was made , and they were good at exaggerating the importance of the link. Serge wasn’t like that. He was a little-picture person, a narrow problem solver. “I think he didn’t know his own value,” says the recruiter. [2]
Last time I checked, banks are the most powerful industry, and GS is the most powerful bank[1]. Aleynikov was single handedly building, deploying, maintaining and updating Goldman-Sach's HFT framework.
If you believe that key people like Aleynikov don't make the HFT industry profitable, a certain Medallion Fund and a Dr. James Simons would beg to differ.
[1] https://www.youtube.com/watch?v=FzrBurlJUNk
I don't know of any big software companies getting government bailouts after gambling with money they scammed from average citizen . Once you can get away with that, and not have a single executive do jail time, come back to me. Every industry is subservient to the whims of banks. They'll tell you otherwise, but actions speak louder than words.
I call shenanigans on the claim that Aleynikov was single handedly running the trading infrastructure for even a single one of their desks. That's complete nonsense.
As for Jim Simons: It's generally believed that the main cause of Renaissance's success is that they have a couple hundred of the world's smartest people all working together. It's not a 'key man' shop at all. (Also: You seem to be suggesting that Simons himself did all the work. The fact is that he spends most of his time smoking cigarettes and handing out wads of cash.)
That's true, but it's a hockey stick / logarithmic thing. When I started coding, the BASIC and COBOL technologies were waning-- still bringing in paychecks, but it was clear that their peak was a few years in the past.
There are lots of people right here on these forums using technologies today that are in the exact same situation. Citing these examples by name usually erupts into a flame war, but for sake of illustration, a good example might be PHP.
Perl, on the other hand, is.
They haven't really diminished to almost nothing, they have just been outsourced to Indian shops. You'll have a really hard time finding Westerners who still write those languages, but Indian firms are happy to step in and fill that void, maintaining the hundreds of millions of lines of COBOL code still in production at Fortune 500 companies, on a contract basis.
My skill is not marketing my skills on a freelance basis. My skill is in engineering.. and a variety of others (like startups, people management, etc.)
I hate 80/20 like splits that are so binary.
Part of the problem here is that it's very difficult for many people under 30 to imagine someone over 40 is not falling into your %75 category. They already think that most people can't do fizz buzz.
I once had an interview with a 20 year old with 2 years of experience. HE was the head of development at one of those startups that raised millions on kickstarter.
He asked me the question: "How would you do feature X in language Y?". I pointed out that you couldn't do it in language Y but that you could do these other things that were similar. He then said " In language Z you do this and that's the answer I was looking for". But language Z is not the same as language Y.
Flubbing a question? No problem. Everyone can get nervous. Giving a BS question and then using the "wrong" answer as a reason to not hire me? Suspicious. So, why would he try to do that? Well, it turns out we were on a video call.
Who wants to hire someone old enough to be their dad? I understand that sentiment.
But the Software Industry hasn't developed a pyramid of job titles you can climb.
Am I missing something?
Leavnig that aside, sometimes people move or switch focus or have to take jobs at crappy "body shop" companies to make ends meet during a bust, etc. Hence the quality of the network isn't necessarily good enough to have the kind of "I need a job, whatcha got" connections you mention.
I don't have a network. I have friends and I have colleagues, but I don't really have anyone that could get me job leads (maybe a couple of my friends)
Keep in mind that most companies offer referral bonuses and programmers like to work with people they know and trust. I used to avoid doing this like the plague because I thought I was being a burden to people I consider friends. In reality, asking for a referral is mutually beneficial for both parties.
Every single one of my former coworkers, managers, and other people I dealt with on a regular basis is still at my former employer or retired. How do those contacts help me?
If it turns out none of them can help you, you're out an hour or two and the cost of coffee.
A longer term alternative is to make cool things and tell people about them. Write some open source or a side project and post it to HN. Lather, rinse, repeat until you get people emailing you asking you if you have time to talk.
Whatever strategy you use, the goal is to make a personal connection with a hiring manager directly.
[1] http://www.iwillteachyoutoberich.com/blog/ramits-definitive-... [2] http://www.iwillteachyoutoberich.com/blog/video-how-to-use-n...
Something you notice immediately is that they never feel like they're being used when someone wants to "meet for coffee" as transparent cover for getting something out of them.
They realize that someday they'll need their back scratched, and there's always the possibility that they'll get something (a tip, a lead, etc.) out of an unexpected meeting.
The entire reason LinkedIn exists is because most people, even many very highly skilled people in professional career roles, find it difficult to make effective use of such networks, for example. And if you're an engineer who has experienced a rough patch of employment or worked at a company or in a role or under a boss they hated or experienced a period of burnout or underperformed somewhere due to any of those circumstances the whole thing gets that much more difficult.
There you go. I spent (really too many) years at one small company after moving from a top-5 city to a top-20 city. And some of my contacts have left town.
Also, even if I've got people who can vouch for me, how do I tell them I'm looking for work? (This might sound trivial but I haven't figured it out.)
Given the alternative is being stuck in a boring job, or low pay, or unemployment, what is so difficult in shooting an email asking if they know anyone hiring? What would your reaction be if you got such an email from an ex-colleague?
But then, I spent 8 years at one job and in grad school. Anyone I knew before that would be really hard to find even if they could be a useful network.
And I was really bad at connecting with my committee--I graduated, but without a good network there.
Then I moved across the country.
I've never had any problem finding work, if I shop my resume around to local contractors and "body shops". In fact, I've made a pretty good career out of that. But "exciting" work? Not so much.
At this point, I'm considering getting out of the field. And I love what I do. I just hate what I'm doing, if you can see the difference.
For two companies.
I think I'm probably the last generation that looks at long-term employment as a good thing, and the older I get the less risk I want to take in being "the new kid" who would be the first to go if anything went wrong with the company.
I also don't talk to former co-workers much because I've moved on to different problems.
So, yeah, I'm bad at networking.
I do. They almost certainly know more than I do about anything of any substance. Maybe they don't know node.js and mongodb as well as some young person, but they can figure that stuff much faster than I can learn any of the stuff they've learned throughout their life. I worry more about the opposite: who wants to work for someone young enough to be their child?
Exactly, there is nothing magical about implementing the Reactor pattern in a 25-year old language.
I was just reading a response to this article with someone who was much older, like 50 or 60 or something, also said he was a Node.js programmer.
I've actually been really paying close attention to trends, new programming languages, etc.
Node.js is kind of old news. The coolest new programming language I know of is Nim.
Stuff that I think that matters for the future is higher-level semantic metalanguages for information exchange and information systems factorization, fully distributed computing, connected devices, and custom circuits/electronics.
I didn't mean to imply that no "older" developers are interested in newer things, just that it really doesn't matter if they aren't.
While I enjoy the current situation, it's unlikely to last. Sometimes we forget that there's plenty of people who have simply built up a clientele and a repuation through plain old networking. These jobs tend to be more lucrative and probably don't require you to learn the flavor-of-the-month js framework. It's no surprise that we don't see many experienced professionals competing for what are essentially entry-level jobs (despite the use of the word senior in the job title and despite the high salaries inexperienced developers command). Obviously not all experienced professionals have built up that network. Those are the people you see applying for jobs.
Source: I spent a couple years getting to know a network of CTO's and architects who have been doing ecommerce since it's inception. They are in demand, they don't apply for jobs, and they are paid handsomely, and yes some of them are grandfathers or grandmothers.
Interview offers, and they only come to the people who have the right combination of keywords and location. Miss on one or both of those counts, and you are invisible. The second seems to be much more important than the first, too.
Hi, I see you're doing [JOB] at [COMPANY]. How would you like to do [JOB minus 4] at [COMPANY minus 2]? We have Beer Thursdays and your fellow employees will all be young enough to be your sons (and yes, they're all male).
And at best it's:
Hi, I see you're doing [JOB] at [COMPANY]. How would you like to do the same job, but at a different, but very similar company, with the same lack of a future career path?
What you never see is:
Hi, I see you're doing [JOB] at [COMPANY]. You probably feel like you're in a rut there, and are ready to advance to [JOB + 1] at [COMPANY + 1].
All you have to do is sift through that firehose for jobs that match your expertise, at companies you wouldn't hate to work for, at rates and hours you'll accept, and that don't seem like they're just jerking you around. Then after you've expended that effort you can begin the actual process, which may fall through for any one of a billion reasons, not the least of which are that most recruiters are jackasses with little understanding of the actual field of work.
For anyone with a slightly complex set of skills just getting to square 1 of having a recruiter or HR person be able to understand your skillset is damned near impossible. And there's no way they'll actually be able to have a proper appreciation of your competency except in the crudest, most oblique manner possible (e.g. years of experience, "big" projects completed, expected wages, etc.) It's hard enough to have a conversation between talented, highly knowledgeable software devs which actually parses the differentiation between various job roles (like, say, systems engineering and web dev), which can span enormous ranges of differences. Trying to get the human resume regex parsers we know as recruiters and HR personnel to understand such things, good fucking luck. And yet today those people often stand between you and a job.
I could only imagine the state of the industry without word of mouth referrals.
If you need the recruiter in order to get the interview in the first place, it doesn't matter how well you shine in the interview.
I once had a recruiter (he had my resume) contact me for a Novell admin position. And there was nothing related to Novell on my resume. Then I knew not to waste time with 'recruiters'.
The experience I've had with outside recruiters in the past 10 years is atrocious, though. All they're looking for is warm bodies to toss at a company, and hope one of them sticks. No or limited experience--they still want to present you...after modifying the resume you've sent them in Word.
Today's outside recruiters are inexperienced in and ignorant of the field ("Your last job was a fitness trainer??"), and borderline unethical.
I'm still surprised so many of them are in business.
I've observed that Group 2 (your 75%) frequently winds up in "Director of IT" positions where they can productively re-use that year over and over again keeping the ship running. Some of it is a lack of imagination, some just a simple desire for stability. Either way, they get very stuck. Their firms can't afford for them to do anything else, and they have to take a pay cut if anything bad happens.
Now my question.... By keeping a low profile, do you feel you are artificially lower your wages or opportunities? You're in the same boat as the top 3 or 4 developers I know - very talented, well paid, jobs find them, and employable in any market. But sometimes I wonder if they could get paid more if they were more visible, simply from supply/demand. (They have a scarce skill, increasing the demand for it should increase the wages) Or is it that anyone who would properly employ them is by definition outside mainstream hiring and would know them already?
Engineering has almost always been an entry level job; computers or not. You start as an engineer; and as you get better, the number of engineering management jobs is pretty limited, so there's nowhere to go for the vast majority of people. But you get pulled into enough internal projects you start to develop a bit of business sense, so many people will often go from engineering up into the business (it doesn't hurt that many engineers are smart with a solid foundation in applied mathematics).
This isn't just the case with development. My father in law started out as a structural engineer. By the time he was 10-15 years into his career, he was managing large construction projects. 30 years in he was running a big portion of the company.
I saw the game for what it was early and got out of engineering before I hit 30. It's a treadmill of skill development where having over 10 years of experience doesn't benefit you, since the technology du jour changes every decade anyway. I still enjoy hacking and coding - but I do it as a hobby.
An MBA and a CS degree are a powerful combination. In fact, if there were more engineers with MBAs, I doubt the MBA would have a reputation for being somewhat clueless about practical matters.
Some days I'll sit down and work with other devs on code even write them some examples to illustrate what I want, and then the next I might be talking to senior business people from our customers.
I didn't do my MBA until I was in my 30s and had already been a CTO, biggest thing I got from it was the ability to think differently - literally turn an argument around to see it from the other side, and a lot of friends who done various masters degrees say similar things
But again, there's only so much market demand for that; and I would have trouble believing that more than 10% of his peer group at age 30 went that way.
This is more typical to what I've seen: someone started out as a developer writing back-end code, but noticed that it was more difficult to deploy the code consistently than it was to write. So they started helping out the tech ops team with that, until it became most of their job. Then the tech ops manager quits, and the company needs a replacement. The back-end developer was doing the job anyway; and it's a pay raise, so why not. Now they notice that the real reason it's so hard to deploy back-end code is because the servers are never patched, so they work on a process solution to make sure everything is consistent. The work is still technical in nature, but it's becoming much more process-oriented.
Maintaining a technical skillset is hard. Not many people have the energy to keep it up throughout their 30s when they're having children, taking care of sick parents, etc. So you'll see a lot of people gradually move to the business side - which isn't hard to do when you have an engineering mindset that helps you solve hard problems. It's also often a pay raise anyway.
But in general it makes sense for experienced people to move into managerial roles where they can leverage their knowledge on a meta level, rather than purely object level work.
The other is to become a specialist (as in, an expert in something). It's not as common, and most companies don't offer a dual track (and when they do, it can be a trap)
The one thing you don't want to take is to get stuck (the "one year's experience 30 times" edw talks about), and I see lots of people getting stuck. I'm kind of stuck myself but I think I'll be able to transition into business soon.
What did you jump into afterward?
Net result is I took on a bunch of debt to go back to school but my salary is much higher now and I have a lot more control over my destiny. I don't regret it for a second.
In this context, what would you define as 'product'? I'm curious as I hear it mentioned and it sounds fun, but conjours up mental images of inventing the next Gilette razor.
IMO, product in tech companies is a much more exciting role because you get your hands dirty with creating the product. Let's say I'm the product manager for Facebook's News Feed. I would work with designers, developers and marketing folks to determine the features of the product. For example, I could say "Hmm, let's show more ads to people between the ages of 18 and 29 than we show to people between 13 and 18". We would test the hypothesis either through focus groups or A/B testing and determine if users are like/hate/neutral on it, and if they're like/neutral and it provides more money, it's now a feature in the mainline product. The role is slightly different at different companies (product managers at Google are expected to write a little code and lead engineering teams, for example) but the core tenet of the job is answering the question of "What should the product be?"
Product management is the central role at any startup for the first few years. A good product manager is worth their weight in gold. A great product manager can make you billions. For me, it's the perfect mix of creative, technical and business disciplines. You have to have the vision to see what the product can be, the technical chops to know how to get it done, and the business sense to know what levers you should be pulling at any given time.
The truth is actually far more extreme. Some developers are orders of magnitude more productive than others. The work they do is simply that much better and more valuable. This should be unquestionably true as there are several examples of very, very small development teams (sub 5 person sized) who have churned out incredibly valuable products. You can chalk some of that up to luck, especially in the case of games, but not all of it. The fact is, building software well, building software that works, that does something valuable for users, that is free of major defects, that is designed in a way so that it can be maintained and extended easily, and so on, those things are not just about how many lines or function points a developer creates. But those things can add millions or even billions to the value of the end-product, and they can be done just by one person.
Software is not factory work, nor is it strictly just engineering. The most important part of software development is a creative, artistic endeavor. And like all works of creativity the end result has an enormously wide variation in quality and value.
If you're doing very "shallow" software development (e.g. pumping out CRUD apps or CMS backed sites or what-have-you) then years of experience may not do a whole lot for you. If you have the opportunity to take on meatier dev work then experience is more than just learning some tricks and being knowledgeable in the frameworks and toolsets of the day, it's about deep skills. About how build things well, and right. How to communicate effectively. How to write truly self-documenting code. How to wrangle the complexity of the problem space and the implementation space while mediating for the user in a way that makes sense to them. And so on. Some devs in some jobs just keep adding to their skilsets as time goes on.
Some unexperienced developer might be stuck with a small issue for days just to complete some bigger task. Here the experienced developer can answer the question in 15 minutes and the unexperienced one can continue with the simpler tasks.
I compare programming to writing, more than engineering. There is no engineering in programming. No matter how many "methodologies" are created, writing good programs and good systems is akin to writing a good story or a good book. It takes practice, it takes courage to remove instead of adding, to make it as simple as possible. The best programmers are Hemingways to me. Terse, to the point. It just works. It looks beautiful.
In the same vein, a writer doesn't usually become a manager. He keeps on writing, until old age, until forever. That's what we do, what we like to do. Sometimes one becomes a manager due to money pressures - after all who's going to pay a programmer the same as a GM or VP. But people like myself secretly or not see themselves programming until the bitter end.
It is also (always?) storytelling, I agree.
Think of when you are working on a large project and you all of a sudden need to refactor some module which then has a huge impact all over the application. This is similar to a novel where late into the book the author figures out they want to change some part of a main character (like their origin, name, just some kind of detail), which will require fixing it all over the book. Writers refactor similarly to programmers.
Writers have outlines. Programmers have design documents.
There are more parallels between the two, but I forget many of them right now.
It really depends on the industry and context. Part of me really envies you if you can say that much and that reflects your experience.
I spent most of today making sure that my SPMP, SQAP, SCMP, SRS, etc... documents conform to the relevant IEEE standard.
If none of these acronyms means anything to you, again, I envy you.
Yet, the parent is talking about "programming", that is still the most important part (although still a part) of a Software Engineering project.
Software Engineering is a recognized discipline, and although I do work in an EE environment, I believe most software projects (which have a contractual obligation with a definite scope and a deadline) use it in a form or the other.
SQAP - Software Quality Assurance Plan?
SCMP - Software Configuration Management Plan?
SRS - Software Requirements Specification?
I've seen "engineering" defined as "statics, dynamics, and thermodynamics", but what you've listed sounds much more like engineering to me.
I might be wrong, but I believe "Software Engineering" is a more common concept in Europe than US, since many "Computer Science" degrees are actually part of Engineering Universities curricula.
That is to say, many universities are more likely to offer a "Software Engineering" degree rather than a "Computer Science" one. But it might be only my experience.
Consider spending some of your day to automate these tasks. It sounds easily automatable.
I wrote a script that checks that Python scripts conform to standards and it worked well and saved a lot of time. Perhaps something like that would save you a lot of time and allow you to spend your working day doing something more fullfilling.
I wish the best of luck to you sir!
So learning programming is like learning language, and should be taught similarly -- lots of feedback (REPL, throwaway projects/conversations) to develop fluency, and once you can carry on conversations, start specializing into specific, valuable subjects you may want to talk about and do business in.
But programming is definitely writing.
All of the most fundamental hard-science engineering advances end up, not just being encapsulated into libraries, but woven into the languages themselves (garbage collection, lexical closures, laziness, STM, generics, ownership and borrowing...), and programmers express their (executable) ideas more clearly using language appropriate to the topic.
I read about, for instance, PG Wodehouse pinning every single page of his book up on a vast wall in a grid, so he could take it all in and then take a step forward and consider what was being accomplished over the course of these two or three pages, and see at a high level what was working or not.
Or Raymond Chandler exploiting the existence of pulps to throw away heavyweight notions of story in favor of a medium where you can just choose to have a man burst through a door with a gun in his hand, so he could throw readers right into the meat of a story. And then burnishing his little hacks to gemstone luminousness by writing them to, according to him, the same level of quality as the "slick magazine stories" of his day.
And Chandler's insistence on the importance of actually playing with, and loving, the words themselves, at the sentence level ...
I think all of the things that make programming unique have to do with its connections to, 1) our basic human language capabilities, and 2) writing for two audiences at once.
Imagine if software was physically manifested and somehow translated into familiar aspects of life. Going to buy a car you wouldn't see a lineup of several incrementally different models from different companies, instead you'd see: a bicycle; a tank; a bamboo framed solar powered moped held together by duct tape; a rocketship; a jet pack; a houseboat on top of an enormous tracked crawler; and a pair of rollerskates (both for the left foot). Also, half of them are free, a quarter of them can be bought for cash, and the remaining quarter cost tens of thousands of dollars per unit and can only be purchased through very elaborate contract negotiations (and there's no rhyme nor reason which is which, because the rocketship is actually free, and the rollerskates is one of the crazy expensive ones).
That's software, and that's just a tiny pocket of it. The entire software industry is basically fractally weird in the same fashion, but on a much larger scale. It's commonplace for some metrics to differ between direct competitors by not just percentage points but by orders of magnitude. It's also commonplace for competing products to offer entirely different paradigms of use. Imagine considering buying one of two different hammers, one of which is an ordinary hammer, while the other somehow submerges and infuses your surroundings in a bubble of liquid glue 1 light year in radius, then rapidly cures just the portion of glue you want to cause two things to stick together, then instantly vacuums up the uncured glue remaining in the bubble. That's the scale and weirdness of differences between SQL and NoSQL, or between systems built on node.js and java, for example. But we accept that as if it's normal, and the end user never really sees it. HN is a perfect example. As a user you can't really tell what HN was written in, and you can't discern a difference between its underlying structure and, say, how facebook works (except at a functional and UX level). But underneath HN is written in Arc by a tiny team and facebook is written by an army of devs on PHP and makes use of custom PHP compilers.
I myself have done web, mobile apps, mobile games, console and PC games, systems programming, database programming and even incorporated my own business. I've done these with open source stacks and Microsoft stacks.
It's all fun in the end, if you have something challenging for me to work on, a new tool and or a new medium I'm all ears, please contact me....I'm 39.
Older devs will just rely on previous connections to find new work or stay in positions that pay well and come with lots of vacation (as/more important than pay to me).
I think it was a talk by Uncle Bob where he talked about how many devs there were worldwide when he started programming, how many there were in the early nineties and how many there are today.
The question "Where do old devs go to?" can still be asked (and Ed answered that question) but I think the answer doesn't matter much with regards to the average age of devs during interviews.
A company is going to be interviewing way more younger devs than older ones simply because of the age distribution of devs.
Even if every single (old) dev was still developing software, there would still be very few old devs compared to younger ones. That's why the graph in TFA is shaped like that.
I may be totally mistaken here but that's how I understood that part of the talk and I think it makes sense.
I look at it this way. I've been programming for 10 years and, in a typical "do what I'm told" job, I'm not going to learn anything new. Sure, managers only get 10-15 hours of coding time, but that's more than you'll get in useful coding time as a managed employee anyway.
As a manager, you can have your underlings explore new technologies and report back, keeping you current on the field, and while you'll only get 10-15 hours of coding time (unless you work 40+) you have a lot more freedom in deciding what you code, and power to get your work noticed. I'd rather have 10 hours per week of quality coding experience than 40 hours in the Java mines maintaining someone's VibratorFactoryVisitorSingleton.
Managers are good at complain-bragging and making their track sound more painful than it actually is. The fact is that a manager who keeps his coding skill current is highly valued. Being a manager means you have organizational credibility, and if you want to use that credibility to code because you think it's the right thing for you, then you can.
If I were to take a cynical view of dual-track organizations, I'd say that the real purpose is to convince the programmers that the management-ladder people are better than they actually are. A Director-equivalent programmer at Google (Principal Engineer) is an objectively strong engineer, and it's competitive as hell to get to that rank. The Director-level managers at Google aren't any better than middle-management at other companies.
I would be quite surprised if the real product direction power wasn't held by the principal engineers at Google. I mean, ya, the managers get to manage, and they provide some leadership, but they have those pesky management tasks and politics (all necessary) getting in the way of that. In that situation, there are also probably plenty of managers who have to manage peers (i.e. people who have equal or even more influence in the company), and the concept of "underling who reports back" is a bit of a stretch!
The individual contributor path is exponentially more difficult to climb. I argue that you both have to win the lottery with the right projects and get in early at a company, and have all of the necessary skills.
I believe it is a story that is told to individual contributors by people with real power to keep them motivated.
The only theory that I've heard of where a flat org could be actually beneficial to individual contributors is the parents theory on open allocation. Otherwise it's just management kicking out the ladder once they've climbed it.
"...but i want more pay - how about CEO level pay?"
"nope."
Even as a mid-level developer, my salary matched that of experienced project managers in my wife's previous line of work (large insurance company).
And CEOs generally lead a very different lifestyle than a good developer. On call 24/7, lots of travel, etc. And it's a different set of skills that many developers lack (schmoozing, sales, dealing with other giant egos). Compare that to my 40-45/hour work week, true vacation (with no work interruptions), and limited exposure to clients/sales/etc (which I find the most stressful part of my job - minimizing that is a good thing for me).
There's lots you can learn on your own. Just do some web searches. Pick a language, and start learning. Python is great for a beginners. (I like Haskell, but I'm weird.)
There are a bunch of auxiliary skills that help. Learn how to use irc (freenode is great), get familiar with github.
Drop me a line, if you need more help. My email address is in my profile.
- I was formally educated in FORTRAN up 'til the 95 spec. Many engineering codes still exist in it, so I've since rounded out OO Fortran. It helps me read legacy code, talk to the older engineers, and maintain it if need be.
- I built a computer with a nVidia GPU chip: It helped me appreciate the hardware side of things and enabled me to write and run CUDA (CPU/GPU) programs, which offers a window into high performance computing (HPC).
- I learned as much about the OSI stack as possible (I had the fortunate opportunity to take a week-long CCNA bootcamp training class) so I could have a rough mental model how networking works, which helps in distributed computing or HPC scenarios.
- I already knew C, so I spent time spinning up on C++ and its ecosystem, as it can be popular in engineering contexts.
If you are wanting to go the pure developer route then there are plenty of others who can provide better advice. I have come to enjoy the inter-discipline of CS and engineering.
I took some of my class notes on equations and implemented them in a variety of ways as an exercise to get used to the language while keeping the engineering knowledge relevant. For instance, when I was blazing past a variance calculation, I was surprised to learn that catastrophic cancellation could occur in a naive implementation. Not because I "got the answer wrong" per se, but because a computer has limits (in this case: precision), and there's no way (in my mode of learning) for that kind of information to stick unless I have my hands dirty in the code.
To go back to the languages though, I stuck to major ones and played with Python, C/C++, and Fortran. Python and Fortran I used online references to play with and learn, while with C++ I bit the bullet and read C++ Primer which is really hefty but I found to be very thorough (and a great reference).
Junior developers: $75k-100k + $2-3k equity/bonus
Senior developers: $90k-140k + $4-8k equity/bonus
Engineering manager: $120-160k + $10-15k equity/bonus
Director or Super-smart architect: $140k-$180k + $15k-20k equity/bonus
VP (senior manager): $250k-350k + $200k-1MM equity/bonus
CxO: $300k-$1MM + $5MM-50MM equity/bonus
So when you say "Mary in the cubicle next to me makes more than me," you're probably talking about at most a $50k difference, which is a rounding error for the senior execs. You'll be hard pressed to find a non-senior exec in any line of work (engineering, QA, project management, mid-level management) whose compensation even comes close to what the big shots are making.
Is there where we get to discuss the gross over-compensation granted to CEOs in the US?
[I'm joking, I don't want to discuss that here]
At most companies the coding required is easy and doesn't require much thought, low-skill = low-pay. The job of allocating capital and people to the highest ROI areas is much more significant to most companies' success than having the best programmers.
Personally I would have said a big part of it is that they control payroll.
Think steven jobs - he is credited with apple's success. May be that's true - he could have ruthless quality requirements. But it couldn't have happened without the engineers that _actually_ created the product. Why is it that the CEO gets exponentially more returns than the soldiers that fight in the trenches, doing the _actual_ work?
We have a large number of developers with 20+ years experience. You aren't seeing their resumes because they're here and don't have a reason to leave.
I've been here 12 years now, and if you can't match the 25 days vacation, 10 sick, 12 holidays, plus bump my salary 10% or more, I won't even call you back.
Edit - I'll also note that I'm a project manager by title. I don't have personnel responsibility, so I still get to spend a lot of time on technical issues (and even some coding).
Not saying you're mediocre; but a job like that leads to mediocrity and complacency because the work is often unchallenging. Again, nothing wrong with that since your life priorities shift at some point -- taking care of your family with a stable, high-paying job is often far more important in your late 30s than having a kickass fun job. But developers in their late 30s tend to have jobs that aren't so glamorous to us on HN.
HOWEVER, I can give you a little bit of advice on what skills might be a little bit useful. You want to learn to create reports/data portals for something like Oracle Business Intelligence Suite, SAP's Business Objects, or IBM's Cognos.
Bank of America used to use Oracle's solutions, but as I understand it they're moving over to Business Objects. For the rest, I can't say, but there are a lot of companies that want these skills.
Any suggestions for books on it? They're training me, but the more I can learn on my own, the better.
Sorry, no suggestions for books.
Do you know if you'll be working with Crystal Reports? Or directly with the Business Objects API? Either way they're both very, very poorly designed and implemented. Good luck I hope you're getting paid well.
Want to set up a testing instance and just play around or build something? They're either not available or horribly crippled. If you can get into a company that is doing it already and you can get access, you will have an easy time learning it (but it's not exactly fun).
He worked in networking. I guess it was one of the largest private networks in the world, and they had a big budget and got to use tons of interesting gear (make it fast! make it secure!). I don't think his department was mediocre in any way and was probably a rewarding job (providing you can get over the working for an evil corporate kinda thing).
I'm speaking more of the peripheral IT functions - the one-off business apps and reporting solutions that departments within banks will often use because no commercial product exists to serve a specialized need. I can think of one example at a major international bank that was executing over a trillion dollars in currency trades a day. They had a pretty basic tool that basically amounted to a spreadsheet with some custom logic that pulled data from a bunch of systems and aggregated it so the traders could book a bunch of smaller trades together and get better rates. This tool was super-niche and quite simple from a programming standpoint, but it made the company probably a million dollars a day. So they paid a guy a full salary to maintain it. He had been in the job for 15 years and was pretty well settled in. They probably didn't need someone full time dedicated to this, but it's not hard to justify $100-150k in salary for someone to maintain a system that generates $200 million a year in pure profit.
It's a different challenge. At a bank, you manage a system based on boring, mature technology, that processes billions worth of transactions every day. Or a server park of 20,000 machines. It's not mobile game development, but on the other hand at least it's not mobile game development.
It can also be work with too many grotty doesn't-teach-you-anything-technical challenges. For example, a bank that has acquired multiple companies with incompatible, archaic, poorly maintained systems, and struggles to keep them interoperating while stitching them together under some ill-considered technical policies and bizarre regulatory side constraints. Struggling with medium-scale technical challenges that only exist because larger-scale technical best practices aren't followed isn't as productive as it could be. You do learn things but it's akin to learning how to develop code in a dysfunctional language in the absence of specifications and source code control systems and testing: too many of the things you learn tend to be kinda messed up. And by the Anna Karenina principle they may not generalize well to your next job, even if that job also has more than its share of screwed-up challenges.
All businesses tend to have some proportion of work that is too idiosyncratic and ill-conceived to be satisfying or to be a good long-term career choice, and it's dangerous to overgeneralize from anecdotes. But I don't know any way to sharpen up a claim about the proportion of idiosyncratic ill-conceived work so that we could test the claim with proper statistical sampling. Falling back to anecdotal evidence then because it's all I have, there might really be a tendency for some parts of banking have more than their share of this.
Some banks can be so weirdly huge, that one department may be developing a simple website with last decade's technology, while another has computer scientists working on algorithms for a high frequency trading system with microsecond accuracy, which may never at any point have an unscheduled hiccup of a fraction of a second. As far as challenges are concerned, it's hit or miss, just like in any other sector.
America is the only country in the developed world where people tolerate and expect restaurants to pressure workers into preparing food while they're sick and can barely feed their own families. Don't eat fast food if you visit.
And maternity/paternity leave is almost non-existent.
All of which leads to people coming to work sick, spreading disease, being miserable, burning out, and spending a fortune paying strangers to watch their babies.
* Horrifying by Western European standards.
"new" programmers, the ruby devs, the python aficionados and the PHP gods are becoming increasingly common.. we're at a golden age where it seems a large percentage of our generation is doing some kind of dev work- larger than any proportion of people in history.
it shouldn't be surprising that people with 20 years experience aren't common because not many people comparatively were vested in the industry 20 years ago.
If your company has an actual interest in employee retention, you have found a real gem. But the rest of us are getting screwed over too often to ever sit back and pretend to have job security.
What I am finding now is that every place I might want to work has no software developer employees my age (which I find to be very suspicious) and every place that does have developers my age or older is a career dead end, SNAFU, or both.
And having my ear to the ground for so long, I have noticed a steady progression in HR recruiting practices from barely tolerable to downright rude. And the time between first contact and offer (if any) is stretching out longer and longer. (I don't live anywhere near California, if it wasn't obvious.)
So if you want to be an old developer, it appears as though you'll first have to solve the problem of how to find steady work without using a resume. There seems to be an element of chance involved, such that each skill and contact you acquire at your current job gives you another roll or two of the dice for the next. I really crapped out with my last gig, which yielded zero new skills and zero new contacts, for entirely related reasons, but a contact at the previous job helped me land my current job, where I am working with someone I knew from three jobs ago.
I am not a particularly big fan of the good old boy network method of hiring, but if you are both good and old, you still may find it difficult to get hired via the HR process. That process is fundamentally broken, and it is quite unlikely that any company that interviews you will ever give you more than a single bit of feedback, that being OFFER=false. Many won't even explicitly say it, letting their extended silence do all the talking.
So I would venture a guess that older people STAY because the effort of trying to GO has become so excruciating for many of them that it wouldn't even be worth it if it resulted in a 50% pay raise. And for some of them, they know that will never happen.
Can you explain this one? I don't even come close to using my sick time up. I'd much rather have them give it as one giant PTO bucket (unless you're implying PTO is less in total than vacation + sick).
Think about how salary works. If you work as an exempt salaried employee even one minute during any given week, you are supposed to be paid for the whole week. That is why vacation time used to be granted as an integral number of weeks. Converting weeks of vacation into hours of paid time off is simply another step on the slippery slope to treating some salaried workers like wage workers, without any of the additional rights or protections.
Also, anecdotally speaking, every time I have experienced the conversion (3 times), new PTO total has been less than old vacation + sick, and it has always resulted in fewer actual days spent on vacation. The PTO conversion is always the company trying to cut benefit costs quietly without triggering a mass exodus.
As a corollary, if you have PTO and intend to leave a company, use it up before giving notice.
And we haven't even touched on other issues. People with PTO may be less likely to stay home when they are sick, because it reduces the amount of planned leave they can take. This results in more contagion in the workforce.
There are very good reasons for paid vacation and paid sick leave to be different classes of benefit. But in this case, it is simply a coal miner's canary. A company transitioning to PTO is reducing their labor costs by reducing the benefits of their productive employees. Look carefully to determine whether any effort has been made to reduce overhead. PTO by itself is not an unambiguous signal. If execs are still giving themselves bonuses while your earned leave becomes PTO, they probably just reassigned the value of your benefit to themselves, and it's time to look for a new employer before they come up with another bright idea, like stack ranking.
This criticism also applies to some extent to "we don't worry about leave" companies. I haven't ever worked for one, so I can't say for certain.
I have noticed a lot of age discrimination the "bay area startup scene". Not so much outside the bay area.
I do wonder how long it is until someone gets sued for age discrimination when the way they knew the person's age was a video call.
I see a lot of startups (including some YC ones) wanting to do a video call with a recruiter before even sending your resume to a hiring manager.
I'm used to recruiters wasting my time, they need to feel important. I'm used to being excluded for stupid reasons, like: [I describe how I wrote code that generated SQL that was used to query an Oracle backend] "which version of oracle" [some minor release] "oh, I'm sorry, they're looking for oracle [next minor release] experience".
My impression is that front line HR people look for an excuse to screen people out... makes them feel important.
And now age is a way they can do that. How are video calls an acceptable requirement?
"He just wasn't a cultural fit. I mean, like I totally saw grey in his hair".
I'm under this same impression. I've referred people to be checked out for a department who have great works in frontend professional services teams. Even have a significant blog, examples that our current employees could be trained by...
Sure enough, while a 3.0 a couple years ago would be good at one college, we don't respect the college that they attended enough.
I've actually been programming since I was six. When I graduated, I was programming in Perl. Today, I'm an Android engineer because I jumped ship to a startup and built up experience then left for a place that pays their workers.
I believe a lot of older developers struggle with redefining themselves as they get older. It's not so much "you can't teach an old dog new tricks," but rather complacency about the job market and dumb attitudes. If you've been doing well in one area for a long time, it can be difficult to make the transition to a current technology. HR doesn't usually think developers can learn new programming languages even if we do it every day. For example, I had to strip Fortran from my resume just so recruiters would stop assuming stupid things.
Then there are many who leave the profession, become consultants, or shift to management.
The engineering track at AmaGooBookSoft. You'll earn +/- $200k a year mid-career and have roughly zero market or execution risk.
There exist many options if you're willing to take more than a W-2 employee level of risk. (e.g. Found a boutique consultancy. Redirect the conversation when your W-2 friends ask what your weekly rate is.)
Finally, the 0th option: if your local economy doesn't have the job you want, make it for yourself.
Why is it this way? Because there are more programmers who can do your job than there are managers who can manage you. You can argue that's unfair, but it's the way it is. The managers have skills that are in demand, and despite what the general HN attitude towards managers/executives is they are important to the success of most businesses.
I do agree that there is a lack of a long term non-management career arc. I worked at a large mechanical engineering company and the titles were Engineer, Senior Engineer, Engineering Specialist, Principal Engineer, Staff Engineer. Once you made it to Senior engineer you could split off in a management track that went Supervisor, Manager, VP. It worked out fairly well, because the higher level engineers (Principal, and certainly Staff), made well more than the early management track. Going into management was not the only way to get a raise. Obviously this made the engineers better, but it also made management better, because it seems there are a lot of reluctant managers out there that just want to get paid more.
edit: I found a blog post by Bob Martin that describes this in writing: http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html
1. There is just a smaller pool of 20+ year devs because 20 years ago there were less developers, smaller pool of jobs etc. it should be possible to work out the max size of that pool from ONS / job data and get a ratio for today.
2. What is your job criteria? Permanent position? Wage is low compared to say contract or freelance rates? Advertised in the public job forums?
3. Lack of interesting work or autonomy.
I am a Dev with 15+ years - (I dropped out of CTO position to go back to full time Dev work). And I cannot imagine taking a permanent position unless it comes really close to a contractor wage. And I would prefer remote working.
I will be surprised if I ever find a 150k+ remote permanent position. But if I did I would expect to see only 40 year olds on the short list.
And I am pretty unusual in that I still job hunt in the open - actually applying for jobs. This is not an issue for the large majority of people I know who use their "networks" better than I do.
So in short a good Dev (and having lasted 10-20 years they cannot be idiots) is not goin to be looking for a job, if they are, they will not be looking where you advertise, and if they do look there, your rates will be too low, your job conditions off putting and finally you probably tell people what and where and how to work.
If you want old devs, pay more, micro-manage less, and fish in places that are recruiter unfriendly.
There's only about 18 hours in the day where I can write software and some of those are consumed by lunch and dinner.
1) Developers are treated without much respect. Seriously, even with the scarcity, and even when we do get paid well (which is relatively rare) and have nice perks, developers still don't get the kind of respect other similarly highly skilled professionals get. At some point, when you get in your mid-30's and compare yourself with other professionals in the same age group, this really starts to grate.
2) The vast majority of companies still doesn't know how to make developers function properly. Those of us who discuss stuff like Agile, "manager / maker schedule", remote working, the pros and cons of open office plans, etcetera form a tiny minority, and we live in an echo chamber. 90% of all devs are still code monkeys in the basement. As a developer with a bit of experience and authority I decided to put my effort in changing that (i.e., get into management) to make life better for other developers.
3) I felt I was just repeating myself, basically doing the same thing on different platforms in different languages. I found it harder to learn new stuff not because I got "too old to learn", but because I didn't see anything particularly "new" in it, just same shit, different platform, which wasn't particularly motivating. (The only exception is the "cloud", because approaching the infrastructure as a dynamic, programmable resource is actually something new and challenging.)
Salary is still very much an issue. All this talk about developers getting paid so much is total bullshit, with the possible exception of a small minority of SV companies. Developers are seriously underpaid compared to their economic value and scarcity, and it's mostly just a matter of a lack of respect for "techies".
Personally, I don't care about the money (as a manager I currently choose to not get paid more than my best developers, which is making my bosses kinda nervous), but the feeling of getting screwed just pisses me off.
Most of you that are reading this: you are most likely not getting paid what you are worth. Not even close. Yes, even those who think they're doing fine. I've seen the numbers, and as a profession we are collectively getting screwed, with very few exceptions.
There are many professions in which people are less scarce, require less skill, knowledge and experience and add less economic value and still get paid considerably more simply because they are not "techies".
The base salary for a LU tube driver is more than the average it salary in London.
You are probably a lot harder to replace and a lot more skilled than many of those several hundred "core" employees. You probably are a "core" employee, it's just really convenient for them to not think of you as such.
As long as you don't complain or jump ship, they'll just keep doing that. Of course it's not all that tempting to jump ship, since even businesses that are "inherently software business" underpay developers, so if you're comfortable where you it's hardly worth it to move on for a few extra bucks. Despite the fact that all of those businesses are definitely whining loudly about the scarcity of developers.
Hell, even if you are "peripheral", if the same company needs to invest huge sums of money in office space, equipment or other "peripheral" stuff to "support" those "core employees", they will simply do the math and pull their wallets. It has nothing to do with "peripheral", it should be about scarcity and economic value. Paying you twice as much won't make a dent in their spreadsheets, nor will it make you insanely overpaid compared to many other employees.
But unfortunately in reality nobody bothers to do the math, it's all about "perceived" value, and as long as both you and your employer live inside the reality distortion field that totally undervalues developers, you'll continue to get underpaid.
The few companies that forget about prejudices towards techies and simply do the same cold hard math they apply to every other investment have absolutely no problem paying way above "market rate".
1) One explanation is that, often unexperienced people start doing programming, start looking for a job, but after 1 or 2 years, they just know its not their cup of thee.
Lots of people try learning programming themselves. And while it may work out ofr a lot of them. I think there is also a huge dropoff.
During my computerscience study at university there was almost 50% dropoff after 2 years. Only the die-hards survive.
2) A lot more people are learning to program these days. 10 years ago, there were a lot less people doing programming. That's why you are seeing the curve.
3) People with 10+ years experience generally don't go out looking for work and applying for interviews. By then you have enough connections that if you want to change job, you'll find it through old colleagues. Not by shopping around like younger devs. This applies to most all professional occupations, not just Software Engineering. If you look at people applying for positions in economics / law you'll see a similar graph.
Here's something you can try: what do you wish you did 5 years ago (that you could have done with your knowledge at the time)? Now, imagine what you in 5 years will want the you of today to do. Go attend some local conferences or meetups. If you have trouble making connections quickly, prefer repeated events.
I'm actually surprised that I have found so many jobs that way, compared to how easy it was just knowing some people who already work at the company who is hiring. I still had to interview, though--one interview with the hiring manager and her boss that took less than an hour.
The only problem is that very few of my old colleagues have connections to any of the jobs that I might actually want.
So now the standard response I get is "we decided to hire someone that was a better fit for us" or "we decided not to fill the position at this time". If you can't read the subtext, that means "you're too old (and therefore expensive)" or "we were trying to import someone cheaply, and your application screwed that up."
At 40+ you probably have a couple kids, a mortgage, a spouse, education loans, car payments, family vacations, pets, children's activities, children's pets, your own personal activities, cocktail parties, maybe saving up for your kids' college educations, whatever. Unless you've found yourself without these kinds of obligations, your job will end up being defined as something that can fit a work to live scenario. This is very hard to do in the previously described scenario.
So what's left? Some startups will let you do the 9-5/5 40 hour work week, but the reality is that big boring mega corps, building boring B2B insurance/inventory/timecard processing/bleh software is where you're likely to find the kinds of jobs that fit your new "adult" lifestyle. And you know what? You won't really care all that much.
If you do care, and you're tired of figuring out the access permissions for this role as part of that use-case for the umpteenth million time, you can career shift into management and start learning about the business you were supporting as a developer. You might want to end up managing other developers, being a "nerd herder", which presents an whole new set of fantastically non-deterministic challenges. You might move into product or program management, and be responsible for overseeing execution of contracts or high-level delivery of vague CEO initiatives, an entirely different challenge.
You may even want to take the plunge and shift into sales, starting as a sales engineer, but developing your own clients and moving into a full-service sales and solutions provider role...which you might later turn into a business consulting company later. Your hours might be more flexible and your pay can be unlimited in this kind of role.
Lots of startups make a big deal about the "full-stack" developer, you can do front and back-end systems with equal finesse. But a "full-business" developer, who understands the entire business from sales-cycle to post-delivery product-support can be extraordinarily powerful and I guarantee that job can be very interesting. The tech can be boring, but the kind of critical thinking and task breakdown skills you might bring with you from development can be really useful elsewhere in the business world.
You might even learn enough about some segment of the "business stack" that you realize you can launch your own startup targeting software to solve some problem you saw when you were operating in that portion of the business.
I´m still unsure if it's a path I want to follow indefinitely, but I agree with the parent that going out of your comfort zone presents you with a whole new set of challenges, which are not necessarily easier or more boring than purely technical ones.
Bingo! Only megacorps and people who hire noobs recruit that way. Beyond a couple years its all ... "That guy I worked with who was an expert with statistics (by their standards)" or "That guy with the awesome github repos" or "That guy I contracted with once..."
And looking at his graph, I'm guessing his job description is skewed toward noobs. Something about the company, or the job descript, or working conditions or ...
Once or twice I have met programmers in their 60s who remember the days of punched cards etc. That's really exciting. Generally there's not many of those guys and now they are tucked away in major corps or government systems.
Who would we manage, if per the article their average future employee only has 2 yrs experience and I have about half a century of working life. So the average bottom layer of the pyramid programmer will end up reporting to roughly twenty five ex-programmer managers simultaneously.
Or rephrased, 24 out of 25 programmers "must" find work elsewhere every two years or so, to keep the numbers reasonable.
"tucked away in major corps"
That's where I am. Work to live, not live to work, great benefits, nice working environment, nice coworkers, but if I want a promotion pretty much ten people would have to quit or die of old age first. This "being pushed into management" stuff from coasties sounds really weird to non-coastie ears. Or having a "career" sounds weird, since I've had the same job for decades and have no realistic hope of title advancement, and I'm perfectly OK with that.
That seems like it explains the OP's experience right there. Why would honestly senior devs even consider jobs well below their salary range? My shop is almost entirely very senior people with 10-20 years experience, but we pay accordingly.
Anyway, my dad has always resisted any push towards management. He did occasionally get the lead of a project thrust upon him, but he was still programming until he retired. However, he comes from an age where people stayed with a single employer for their entire life. You don't get to see his CV because he was never looking for a new job. You see my CV a lot because I'm constantly looking for something new.
Although in that graph, I guess I'm actually in the 10+ segment now... I'm still a young dev, though.
Anyway, move away from LA, and up to SF or NYC?
We hired one former consultant recently who basically told us, that at his age, nobody wanted to hire him for consulting jobs anymore. He took a (presumably) big pay cut to work for us, but at least it's a steady job as he approaches retirement.
There's good and bad, of course, we have an exceptionally experienced staff but eventually we'll all retire. There may be a problem where we don't get fresh perspectives on our work but I'm not really convinced that's true. Maybe more of a problem in social/mobile/web but in product development it's probably not as much of an issue.
I think the older devs that are still relevant probably don't show up in the job seeking type of data, they are probably already booked with paying work and startups!
:)
When I emerged from a deep stint with a company (2000-06), the age distribution had shifted dramatically to people in their 20s. Not only were many of the old timers gone, I was finding myself to be the old timer.
What had happened to all my old timers? Many didn't survive the dot-com bust or recession of 01-02. They either outright retired or moved to different careers; some survived, but moved on anyway. Some had died.
Those that remained in technology went three different routes. Management, consulting, found a place in a company they like and haven't budged.
Personally, I started my own consulting business which I enjoy. Although nearing 50, I do feel some envy for the guys who've found a nice small/mid-sized company to settle down in. They may not be as well compensated, but they are often "IT Director/VP" (where IT is 3-8 guys), are still hands-on, get to have fun, and not have as much stress.
His company is unusual in that way: Average age of the devs is around 55. He currently writes test software and technical manuals for advanced control systems. They're hiring, if anyone is interested.
1.) Developers get comfortable with a given technology, and eventually stop learning. And the longer this goes on, the more exceedingly difficult it is to leave that comfort zone, because it makes you feel dumb and slow. When I first got into the industry, there were lots of folks doing things like IBM mainframe assembly and RPG/3 and COBOL. They'd tell me that that was where the real money was, and there was no need to learn new skills. After all, those systems weren't going anywhere, and they were bringing in fat checks. In fact, the more obscure the technology, the more money they make.
This particular trap of sticking with a technology is an insidious one that I almost fell into myself. In my early 30's, after working at the same place for about 10 years, I started coming to the conclusion that I was the best developer that I knew. I could do stuff in a weekend that other teams of people would fumble over for months. I was unstoppable. Then I changed jobs a couple times, and started doing game development, and started getting worried that I was actually not nearly as smart as I thought, and that I was losing my edge. But the real truth is simply that when you do the same kinds of jobs with the same technologies for many years, you get real good at doing those things. You find a comfort zone. And leaving that comfort zone feels wrong, stupid, and even counter-productive.
2.) It becomes tempting to switch to management. Over my career I've worked for innumerable managers who used to be developers in whatever technology was used 5 or 10 years ago, but now they do management. Often, they don't even realize how out of date their grasp on technology is. It's easy to fall into the trap of moving into management, because it's typically the only path to any kind of career development or upward mobility. I've gone into management myself for a few years, but then realized that if I want to be a good developer as my top priority, then I need to spend my time focusing on being the best at that, which can mean making some sacrifices. Once you move into management, you're done unless you keep your skills current.
3.) Developers need to continuously retrain themselves. This one kills most developers dead. You have to train yourself. The means not expecting your employer to do it for you or pay you to do it. Every 5-7 years over the last few decades I've totally changed my technology platform many times, and every time it was because I had spent the last year or so getting ready. I'm talking about spending a significant amount of time working with and understanding technologies other than the one you're using right now, say about 200 hours per year at least. I haven't read the responses on this forum yet, but I guarantee you will see a pattern of developers feeling like they don't need to work hard to retrain themselves. Saying things like, "programming is my job, it doesn't have to be my hobby as well." This is a fine attitude, as long as you aren't planning to be a developer for more than 5-10 years.
If you're in software development for the long haul, more than 5-10 years, then you have to be continuously training. If you're not absolutely serious about staying on top of new technology, then your skills will be obsolete and niche within 5-10 years.
I know how to start with a vague notion of a system, interview 15 domain experts in the field, and turn that huge mass of random information into an organized document. I know how to collaborate with others to make a design, and manage the project through to completion. For certain areas of domain knowledge, I have knowledge and skills on par with top industry experts. And the 23 year old kid may actually meet or exceed any of those things, but probably has never successfully worked trade shows, sold products, or given presentations or training programs. I also run my own business that's profitable that I started from nothing, and has been going for a few years.
That doesn't really matter too much in a lot of situations though, so in a lot of cases, maybe I can't differentiate myself. I, too, was once a 23-year old badass who had been programming for 13 years since before getting out of grade school, and knew everything, and was the most amazing programmer around. The most important advantage I have over the me back then is now I know I'm not as smart as I thought, and I understand much better the importance of teamwork and giving everybody on the team a chance to shine.
Living with code written by someone half my age is no problem at all. A far more difficult thing is dealing with code that's badly written. But all professional developers eventually learn to deal with that; it's like how sailors learn to deal with rough weather.
"I was born in the mid-sixties and got in touch with software programming at an early age. It became my hobby, along with the field of electronics. I was very keen to get to know exactly how things worked and what was happening, even up to the level of the silicon. In those days I spent more time reading datasheets and computer manuals than I did reading comics. "
I find great joy in exploring new technologies. At the moment, I'm learning Docker.
It seems like the article is written from the perspective of assuming that the age distribution of the job seekers that they interview is equivalent to a random sampling of all software developers worldwide, but it could also just be a function of how resumes make their way their way to this particular company in this particular part of the world via the particular channels through they receive resumes.
I would still expect a random sampling of people looking for programming jobs worldwide to be heavily weighted towards recent grads however, for lots of reasons:
(1) Just in terms of numbers, there are a lot more people with recent CS degrees than degrees from 20+ years ago.
(2) People in the first few years of their career are much, much more likely to send resumes to a gazillion different places. They are also much more likely to start looking for a new job after 1-2 years.
(3) People with less experience are much more likely to apply for an entry-level position.
(4) If you have a company mostly or entirely staffed by people in their 20s, that by itself is going to scare off older developers and encourage younger developers to apply.
(5) If most of the company is composed of people in their 20s, then most of the resumes you receive from acquaintances of your existing employees are going to be from people in the same age group. So, there can also be an element of it being a self-perpetuating thing.
Etc. etc. etc. Basically, why there are fewer older developers is an interesting question with multiple answers, and why this particular company doesn't get resumes from them is also probably an interesting question with multiple answers. The questions raised by the article are so general, however, that there are no simple answers.
But of course it isn't purely a meritocracy, because social factors matter, too.
And of course careers and office politics matter, too.
And of course there are biological considerations, like family and energy and health.
And of course it is exhausting to frantically keep up with the bleeding edge of the technology du jour.
And of course deep, long-lived knowledge matters just as much as coding ability sometimes.
And on and on and on....
A generalization, to be sure, but it fits with edw519's view of 75% of middle-aged programmers in https://news.ycombinator.com/item?id=8481761.
Who is older: a) programming commercially since age 20, currently 35 (15 yrs full-time experience) b) programming commercially since age 35, currently 40 (5 yrs full-time experience...)
Once your arms and fingers start giving out (or eyestrain), people start feeling old really fast. Doesn't matter how old you are. Take care of your health (including keeping your brain active on interesting projects...) and you'll stay "young".
I would like either one of those jobs but I would rather take the seat on the management board to be honest for the influence it would give me.
Writing good software starts with a business decision and the Suits people are notoriously bad at making good calls in that department.
More than likely, the answer to the question, "where are the developers with 20 years experience?" The answer is, "the same place they were 10 years ago."
1 - Writing code is a young man's game. Older devs get one too many platform/language iterations behind the curve so can't apply for as many jobs - obviously not true for everyone, but could account for something
2 - Older devs are tempted into management, and so write emails for a living instead of code
3 - Older devs may have more commitments outside of work, so can't take on jobs that demand long hours in the office and long hours at home keeping up with tools and trends
4 - Huge numbers of people are starting to realise you can make good money sitting on your arse all day and writing code, so there are lots of them applying for jobs with low experience - that's not to say many of them will still be trying a few years from now
5 - All the best experienced older devs don't apply to job ads, they just move easily between contracts using their network
But, he always, without exception exuded confidence and delivered new features quickly. He was hired as a senior architect at several startups before he turned 25.
In reality, there are plenty of excellent older developers around who are still building stuff. They just aren't building it at the kind of company where you reach the most senior recognised development position after as little as five years, you've run out of interesting problems to solve in half that time anyway, the management think productive developers are the ones who work so many hours that they can't have a family and/or social life at the same time, and the junior developers think grandpa can't program with anything invented since COBOL.
Meanwhile, look at the guru everyone turns to in a small-to-medium sized shop, the top-billing freelance/contractor/consultant crowd, the disproportionately successful founder demographics, and the guys who are lecturing everyone else with "Fellow" in their title at the bigger technical firms, and you'll find plenty of places where the very experienced and capable hackers are still plying their trade quite happily.
How come no one asks where do old chefs go to? What about old artists? What about old musicians? What about old plumbers? What about old construction people?
"So asking where we are is the wrong question.
"You should be asking what it would take for us to become fired up about your company?
"For one thing, you'd have to be within commuting distance, because we're not going to uproot our family and ditch our real-estate investments for some random job anymore, in particular not now that the lawn and roses are finally starting to look nice.
"Telecommuting is fine, but it wouldn't be the same for your company, would it ? You wouldn't have a genuine graybeard to berate and lecture all the young ones around the office.
"And I doubt you can muster at set of 'benefits' which can motivate us, what we'd probably like most of all would be to work fewer hours not more."
(Agreeing with Poul-Henning Kemp? God help me!)
Another commenter pointed to a post by Robert Martin[1], with the following quote:
"...what caught my attention was the shape of the age distribution in the first graph. If this graph is correct, then most programmers are under 28. Most programmers have less than 6 years experience!"
Which seems entirely true to me. Unfortunately, I'm significantly less optimistic than Uncle Bob:
"One seasoned programmer in their 40s can have a profound effect on a team of a dozen or so twenty-somethings. As a leader, that programmer can teach the team about principles, patterns, practices, and ethics...."
Mostly because it seems impossible to lead those 20-something programmers. Most of them seem to have a project or two behind them (mostly unsuccessful, but that hardly matters) and they know everything. As a result, it's not so much a question of leadership than one of beating them into submission every time a new question comes up.
To quote me:
"Ok, X works, we've done X successfully for a while, several people around here are familiar with X. Let's use X."
"Sure, we'll look at X'," quoth they.
Then, "X' is too hard; we can't get it to work," when they come back.
"So, X?"
"No, Y is the new hotness, let's use Y."
[1] http://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html
www.ProjectAmericanDream.com
Full disclosure: I am an investor and know dozens of people doing the program, friends and family members. Most successfully.
Older programmers have lots of challenges. Being good has nothing to do with it. If you didn't build a network as you went through your career you are going to have a hard time at 50+. Age discrimintion is very real in certain circles. An then there's the ridiculous process through which some choose to evaluate or filter people.
I have never been a freelance programmer, always an entrepreneur so I never experienced this first hand. That said, I've always had good relationships with recruiters because of my need to hire engineers for my businesses. I often get to hear war stories over a cup of coffee.
If I had to summarize what seems to bother me the most and strike me as most unfair is what I call the search for the instant language x and framework y programmer. It seems there are companies who only care about an instant and immediate fit with the language and tools they are using rather than to search for unique experienced talent and new thinking. A software engineer with decades of experience and a solid foundation in Computer Science has gone through several language/tools/frameworks transitions. Their value goes far beyond being able to write fizzbuzz in a certain language in 15 minutes. That's myopic and really juvenile in my opinion. No, these people can offer strategy, structure, safety, planning, ideas, process and a whole host of other valuable contibutions to an organization and yet they might fail a language x and framework y interview test. Once hired they can learn the desired language/framework very quickly yet there seem to be lots of examples of people not getting past that firewall due to, again, in my opinion, misplaced priorities in the hiring process.
Some of the best people I have hired knew absolutely nothing about the tools and frameworks we were using. Because I never look to fit people into a little box that has never been an issue with the way I hire at all. If someone is really good and can bring solid value to the organization I gladly spend several thousand dollars sending them to courses to get them up to speed. Inside of a month you have someone with amazing value who can now jump in and rock with the tools you happen to be using.
One example I can offer that isn't direcly related to CS is when I hired a machinist to help run our CNC shop stocked with the latest Haas CNC machines. He had NEVER run a CNC machine. Didn't even know the first thing about G-code. He had 40 years of machining experience. He blew me away when he showed me a whole bunch of little machinist utilities he wrote for his HP-41 calculator. I hired him on the spot. I probably invested about $10K in various classes getting him up to speed on CNC. This guy was AMAZING we learned a ton from him, for some of us lessons that will stay with us the rest of our lives. A mentor in the true sense of the word.
So, yeah, at some level I think hiring, in certain segments of the industry, is broken.
I have been going around doing interviews because I did not network enough and my contracting/freelancing work dried up. What they are looking for in a senior developer is the ability to lead teams, improve collaboration, code quality. I'm in my 40s and I can absolutely believe that 50+ people can have serious difficulties securing the right position.
Of course, there are people so set in their ways that they simply refuse to keep up with technology. We are not talking about that group here, least I don't think so.
BIG caveat: my family and I look a lot younger than we are, with no effort at all besides clothing and wearing a backpack I could pass as a 20 something college student through my early '50s. I also had to be careful in talking about my background, in one memorable 2003 interview I let slip that I'd worked on PDP-11s and the technical interviewer who was probably around my age exclaimed "Just how old are you??!?!??!!!"
Which wasn't intentionally an illegal question, just that the mental model he'd been building of me suddenly went TILT. I did get that job, software archaeology where experience made a difference.
Note this will depend on such things as having enough experience to show you're a generically good employee. If you were a new graduate I'd look favorably on e.g. in high school starting out at entry level in a fast food restaurant and working your way up to, say, shift manager (if you could make it that far, very favorably).
But I went more by the oldest jobs that looked really good on my resume, like being the VP of tech or being directly or indirectly responsible for most of my company's revenue, and including figures. Even better than developing software that you claim works is having people buying it and proving it works.
But I've also noticed the people who love talking with me about that are not hiring me. It seems they bring me in to reminisce about the old days, and then go hire someone else. As nice as it feels for my ego, I might drop it.
I've done that.
> I'd already been trimming older jobs due to length and lack of relevance)
And will probably try that as well. I agree that removing any indicators of age helped a lot with getting interviews. This would also help with clueless agents contacting me about PHP or Perl jobs when it's been a very long time since I did either of those things.
Or not cluttering it with no longer particularly relevant technologies. E.g. programming Windows at the Petzold level (although some discussions on HN have given the impression that right now that might be the way to go :-( ).
In other words, if you're good enough at interpersonal politics to keep improving as a developer past the 5-year mark (which requires working people well enough to get on the best projects) then you're also good enough to move into management.
Moving into management is also just plain easier than protecting a specialty against the anti-intellectualism of business-driven engineering. You're a top-flight developer making $140k with a well-formed specialty (let's say that it's machine learning in Haskell). Your options are: (a) compete for the two jobs that exist in the world, (b) give up your specialty and move to a hedge fund, or (c) move into management, which tends to be specialty-agnostic, and lucrative. If you've decided that you're a manager from here on out, all those damn Java shops become options again.
Startups were supposed to provide an alternative, but these days the VCs act like bosses and being a funded CEO is a middle management position.
For what it's worth, the genuinely interesting fields of programming tend not to have the same age-related attrition. Machine learning researchers, and even serious engineers like Jeff Dean, are just starting up when they're 40. However, the business-driven engineering that 95% of us have to contend with is mind-rotting. Spending a week debugging someone else's VibratorVisitorFactory method, or figuring out what the fuck some ORM is doing, just causes atrophy.
We have age-related attrition (of both kinds; our most talented leave, and our less talented or just less lucky are punted) because we're a badly organized industry. We have a talent for which there's nearly unlimited demand, and yet we refuse to organize around protecting its interests with a union or a professional guild.
Also, organizations that use a "dual track" only underline the problem. Take Google. It's 100 times harder to become a Principal Engineer (Director-equivalent) than to hop on to the management ladder and make Director. It's 10,000 times harder to become a Google Fellow (VP-equivalent) than to make VP. There may be a noble intention behind dual track organizations, but their actual effect is to show how stacked the deck is against lifelong individual contributors in a world that is still "manage or be managed".
I think it is obvious given total headcount that there aren't 10,000 times as many VPs as Fellows. And given I know of way more people going from IC to Management positions than the other way around, it seems many ICs effectively compete with folks on the Management ladder for Management jobs. Meaning even if equal effort was required to get to Director as to PE, I'd expect many would-be PEs end up as Directors because they decided to switch to the management track for whatever reason (e.g. because they realized they were already informally managing). Sure, one of those reasons /might/ be they thought career advancement was easier on the management track, but what proof of that do you have?
To assert it's 2 orders of magnitude harder to become a PE than a director, and 5 orders of magnitude harder to become a Fellow than a VP, I think you're gonna need more proof than that.
Quite literally. If I want to be a manager of a sizeable bunch of programmers, then that's a popular job that every company (from small tech companies to multinationals selling soap or loans) will have a bunch of and most of them probably have a vacancy right here and now. If I want a Fellow-type role, then my options can be counted on my fingers.
Over time, they advance a lot faster than we do. We have to take on above-level responsibilities (which is politically dangerous, because people start to wonder if you're neglecting your at- and below-level job duties) to advance. They don't.
concern for other peoples' careers, ability to delegate, humility, emotional stability, ability to see multiple perspectives, commitment to Google and its values
You don't really see these among the people in power. Stack ranking? Secret "calibration scores"? Closed allocation? Blind allocation? People getting PIP'd for having 20% Time projects?
Stack ranking is there to smooth out mistakes in your manager's judgment. One of the big problems I saw in the promo process is that people who quietly help out a lot of other people but don't work on their manager's pet projects will get overlooked by their manager at promo & calibration time. Stack ranking is there to counteract this: if you have helped out lots of teams, you will appear high on many other peoples' stack ranks, sometimes even higher than your manager, and promo committees take this into account when considering promotions of people who don't have their managers' blessing. And it generally works, too: I was promoted on the strength of peer recommendations (I had quite low calibration scores, largely because I've never really cared what my manager thought of me), and I know several other friends who were as well.
Calibration scores are there to prevent the problem where a manager games the promo system by giving super-awesome assessments to all of his reports. He has every incentive to do this: it raises his own prestige within the organization to have a "super high performing" team (even if it's only high-performing because he set the goalposts low), and engenders loyalty from his reports. Calibration forces him to justify his scores to his peers, all of whom have an incentive to inflate their own reports' scores relative to him.
Closed allocation does suck, but in my experience Google didn't actually have closed allocation. If you had a solid track record and a team willing to accept you it was remarkably easy to transfer to a different department.
Blind allocation is a consequence of Google's "hire for the company, not for the team" practice, which is a way to prevent empire-building and keep the hiring bar high. When teams do their own hiring, every manager has an incentive to take a marginal candidate, because his team is probably overworked, and one mediocre employee is better than zero employees. Over time, this would make the whole company mediocre, which is why Google has instituted a uniform hiring bar across the company. Blind allocation is an unfortunate side-effect of this; most people would rather know which team they're going to (actually, if you're in demand by multiple teams, you can get this - I spoke on the phone with my eventual manager before accepting my offer letter), but that's hard when you're not interviewing with one particular team.
I have never seen anyone get PIP'd for having a 20% time project, and I had like a dozen 20% projects during my time at Google, one of which became a major open-source project (and ultimately consumed like 50% of my time). I have seen people get PIP'd for not doing any useful work on their main project, but that's because you're hired to do a job and you better do it.
There may be some jokers who are Principal Engineer at Google, but I never met any. In fact, I met plenty of great engineers who were "only" Staff. So my impression is that you have to be a really good engineer to make Principal.
However, Google's management is below-average by the standard of large tech companies (how else do you explain its use of stack ranking?) and its product team isn't especially good either. I never met a Principal Engineer or higher of whom I knew I could do his job better than he could, whereas I met plenty of high-ranking managers and product people for whom that was obviously the case, and not just to me.
The management ladder, at a tech company, is where you go when you get tired of competing against the best in a field, and prioritize high salary and title. And there's absolutely nothing wrong with that. People grow up, have families to feed, and take the big-fish/small-pond route. (At Google, that's product or management-- clearly not engineering, where there are plenty of very big fish.) Good for them. It's probably the right decision. It's hard as hell to justify, say, a $200k salary as an AI researcher when absolute badasses are content with $150k. It's much easier to go into the business mainstream where absolute jokers take $500k, by age 40, for granted.
This is the dirty little secret of corporate IT departments, that 95% of the workload is cleaning up other people's messes. The "engineers" promote themselves into the work "designing" and "creating" new systems, then use that "experience" to get a job doing the same somewhere else. Then the "programmers" come along and actually make those new systems work, spending 3 months debugging, then 3 years on after-hours standby support.