If you expect to retire at 60 (likely 65 these days) and you start working at 20: 40 is smack dab in the middle of your career.

I think that notion gets lost when we talk about ageism in tech and then people talk about 40-somethings.

but those are still of small group, it's like a normal distribution, I read somewhere age wise there are only about 1.5% that are above 50s.

Of course you're not going to hire a woman if you could hire a man - they might get pregnant and be away from work for a long time.

Of course you're not going hire an older employee that knows their worth over a recent graduate that isn't familiar with the salary they should earn. You can rip them off much more easily.

People can be cunts but still act with some rational motivation. That's why we have protected categories, to make sure that that isn't a strategy worth pursuing.

that's the real problem, self and situational-awareness.

i like the points in this thread. perhaps aging is just a natural bad actor filter. options narrow as we wise up.

this is the one thing you said I disagree with, unless you mean dealing with it by eliminating it.

It didn't become like a job job until what, the mid 1960's? That's 60 years ago.

And the number of programmers is doubling every ~5 years. Of course it's front-loaded with young people! The people who have been doing this for the field's entire time of mass popularity (1980's onwards imo) haven't even had time to get proper old yet.

But also: The more experienced you are, the more your biggest value isn't in banging keys on the keyboard. A company would much rather leverage your thoughts and opinions and that may look a lot more like technical leadership than programming. Even though it's still engineering.

Only an asshole cares how old somebody is. Reminder also, ageism isn't just a bummer, it's illegal.

Most people aren't going to take legal action, but imo if you're discriminated against you have somewhat of an obligation to do so.

Another factor to consider is post-peak-comp. You may find yourself in roles when you are older that pay less than they used to. This may very well be fine because you no longer have a down payment or kids college to save for, and if you didn't keep upgrading homes.. your mortgage payments 10-20 years into owning should a smaller and smaller percent of your income. If you are no longer chasing comp, you have a broader selection of roles and can be more selective.

It's easy to blame ageism, and ageism is real. There are a lot of people who really resent older people and believe flat-out untrue myths about cognition, value of experience and work ethic. That said, every time a friend shares a beer with me and tells me the woes of trying to get a job when older, I hear this:

I can't get a job that pays me like I'm senior, but requires the skills of someone half my age.

The solution is to break out of that box, and either be ok with lower pay, or go for jobs that leverage the value of your experience.

> perhaps due to your own abilities and other special qualities

I'm sure if you looked at yourself, or maybe had someone look with you, that you'd find you have quite a bit to offer when it comes to ability, and especially special qualities. As you get older it's hard to understand what is special because you've seen a lot, and it all seems average.

Very few of them have been pushed out of the field. Yes many moved up, but the majority still code. The ones who had not moved into management are either retired (Over 65), retired early (Rich, big payday) or dead.

I am very much the “average programmer”, but I learned a long time ago how to focus on “adding business value”, talking to customers (internal and external), writing, presenting, explaining concepts to non-technical people and even once a decade ago talking to investors and potential acquirers when a startup I was working for when they wanted to talk to the “technical folks”

I focused on small companies before my current job where the director/CTO was looking for people who could demonstrate a history of being “smart and get things done”.

I avoided the leetCode grind by preparing for a couple of years to target the cloud consulting department of the two of the major cloud providers or if necessary one of their partners. I knew that a combination of software development, infrastructure, cloud, and soft skills would give me a competitive advantage.

Do you feel that they were beneficial in terms of making you a better developer, or did you simply learn a bunch of solutions to puzzles that have no bearing on real world development?

"offers for work" or "job offers"? "Traditional" w2 full time go-through-an-hr-dept organizations possibly have more of an ageist issue than other scenarios. Freelance/consulting seems to still offer more flexibility on the age front, but it's more of a gut sense from speaking with those in my network.

If the candidate says “I’m only taking this to avoid starving but will quit as soon as I find any other job”, then sure, don’t make the offer. If they don’t give any signs either way, assume they’ll stay for 18-48 months as is common and decide accordingly.

The older I get, the more I think it is not the company itself but middle-managers.

Managers with an authoritarian streak will have trouble handling experienced developers that objects to non-optimal designs and processes.

It is much easier for such a manager to handle young naïve developers that gladly accept to work 5 times as many hours as a good design needs.

Software don't work well with an "do as I say, no matter how stupid it is" approach. I think that is why Silicon Valley (and Europe) has much greater success writing software than asia/India.

An older, grizzled, battle-hardened engineer is one of a manager's best assets.

In hindsight, until the last two in 2016 and 2018 they were just journeyman CRUD jobs with the last two being hands on dev lead and de facto “cloud architect” respectively.

I just got my first job in $BigTech at 46 two years ago. It’s not officially a “software engineering job”. But for all intents and purposes I’m doing the same type of work I did at the last couple of jobs - gathering requirements, presentations, development, and a shit ton of yaml, HCL, PowerPoint slides, and diagrams.

I’m sure at 48, I could contact my network of former coworkers, managers, recruiters and someone would give me a job even if it were just a standard .Net journeyman developer again.

If you’re still randomly submitting your resume to an ATS trying to prove yourself to companies by reversing binary trees on whiteboards while juggling bowling balls and riding a unicycle on a tightrope, you’re doing it wrong at 40+ years old.

I did that at 45 and landed an interesting job at FAANG (and I'm not the only one). I think it's a bit contradictory to think old programmers are still as capable and sharp as 25 years old, and at the same time insisting to be judged on different standards.

Then it's your preference not to be a programmer. My point was that it's also possible to be a SWE for those who still dig programming at our age. But you have to play by the rules. That being said, I don't think I'll last in such a position until retirement.

I just knew I wouldn’t enjoy being a small part of a large team coming from small companies where I could work up and down the life cycle from pre-sales, to requirement gathering, to implementation, to DevOps [sic], UAT and training.

I’m still part of a huge organization in the grand scheme of things. But my projects range from me the sole tech person doing everything to my working with a team where I lead or implement one “work stream” depending on the size of the project.

With a string resume, a hiring manager might think "They probably know what a binary tree is because it they didn't, they would not have made it this far."

Both interviews were about half a day, I got offers from both the company that asked me to do a merge sort paid slightly more. I accepted the second job.

Real business folks have real world problems to solve. They don’t care whether you can reverse a binary tree.

As an aside, one of the more junior people that I would be leading asked me how I would parse addresses while the director was in the room. I said I wouldn’t. I would license third party CASS software and explained all of the corner cases and then went into my speech about a company shouldn’t concentrate “on anything that doesn’t make the beer taste better”

I suppose it's all about the role you're applying for. There are "real business" where engineers are hired to solve technical challenges. Being able to solve simple algorithmic problems is a legitimate prerequisite for this type of role.

And let’s not pretend that all developers at BigTech are solving “hard problems”. I do have access to code for one of the major cloud providers.

I’m not saying the jobs are simple just that the complexity is figuring out what to write, how to organize it, how to deploy it, etc.

And before the gatekeeping starts, I programmed in assembly on four processors as a hobby by the time I graduated in 1996 and my third job around 2007 was to maintain a complete proprietary tool chain (compiler, VM (language VM), IDE) for Windows mobile. I spent my first decade plus out of college bit twiddling in C.

You're obviously the kind of person I'd want to hire ;) Why would you mind writing some code in an interview? I don't ask anything that requires memorizing your data structures and algorithms textbook. All I'm looking for is people that can "think in code" which in the population of job seekers isn't as common as you'd think.

I’ve had one coding interview in 25 years between 8 jobs. That one was in 2012. They had a Visual Studio IDE with skeleton code abs failing unit test and I had to make the unit tests pass as a pair programming exercise. I thought that was a very practical type of coding interview that I copied when I had to filter a bunch of contractors when I was a dev lead.

But now, if I leave my job at BigTech as a “cloud architect specializing in application modernization” - basically enterprise app dev/DevOps [sic], training, etc., before I retire, it will be at some startup looking for a more strategic role, even though I would be hands on.

It’s automatically a red flag about the job that I prefer if I’m not being asked about strategy and given a coding interview.

I am early 40's and have had no issue finding work and am currently interviewing others to come work with my group in a solution architect / tech lead style role and they are all my age. I have never interviewed for a job and not gotten an offer, regardless of age; with that said I'm not interviewing at startups or places I feel really wouldn't allow me a family life. I get the offers not because I'm incredible, I'm not, but because I know my lane and skill set and stick to it.

It got to the point where my “interviews” were more just sitting down with directors/CTOs and talking like adults about how I would help them solve their real world business problems. I haven’t done a coding interview in over a decade even though I have been hands on all that time - across five jobs

After some frustrating experiences applying and interviewing for jobs at the kind of startup-sized companies where I’ve spent my entire career, and fearing that my age might be a factor (I’m about to turn 40), I applied on a job at a Fortune 500 and had an offer a few days later.

The pay, benefits, and work/life balance are excellent, to the point that I have some regret over not exploring this avenue sooner.

Oh, and now I’m younger than most of my coworkers again. I don’t think ageism is a thing here.

Several reasons for ageism sometimes missed. This from someone whose been discriminated against, who has hired, who now owns a company & who was also a recruiter.

__I don't agree with this__ just laying the reasons out for clarity sake:

- Hiring managers don't consider themselves ageist, but opt for younger employees whom they think make a better cultural fit. You can blame the 'work is my social life' culture that emerged in the 2000's and that persists today.

- Hiring managers don't want to be ageist, but they've had or heard of bad experiences where disgruntled or non-performing employees abuse the EEOC process for financial gain and retribution. Very well intentioned rules, designed to protect certain cohorts of employees, doing the exact opposite as is often the case with Gov regs.

- Hiring managers (usually fixated on 'new tech') who fear diminished learning, adoption or performance capacity in older employees.

- Money. The perception that older employees cost more in wages and benefits, without much thought to efficiency gains that accompanies gray hair.

I was age discriminated against by a well known SAAS provider, who used a 2014 interview process to extract a detailed roadmap and ideas for product growth from me, and then ghosted me. I've watched as they've (badly) implemented the specific of my roadmap the past few years, and I chuckle. 100% my fault for giving up too much value in the interview process, but it was tough time and I thought I really needed that job.

> Hiring managers don't want to be ageist, but

I classify this into the "I'm not a racist, but..." bucket.

> Hiring managers (usually fixated on 'new tech') who fear diminished learning, adoption or performance capacity in older employees

This is the textbook definition of what ageism is.

Conclusion? They are ageists, plain as that. They may not consider themselves to be, or want to be, but they still are, because ageist is as ageist does, and it matters jack what appearances they want to keep or what they think or who they perceive in a mirror.

[0] https://www.scientificamerican.com/article/at-what-age-does-....

I can't speak in either instance at this time, but I'd like to think ageism isn't nearly as widespread as it seems when discussed on here when it comes to technology-based work. E.g., Small town in Nebraska with one or two software houses versus SF.

I think with software jobs paying what they do, retiring at 50 would be pretty easy.

Not all software engineers are paid ludicrous money though, and even in places that they are paid well the cost of living can be atrocious.

I’ve gone the management route because I like making larger product decisions (or at least being involved in them). ICs at any level rarely get that level kind of input.

I low key blame the onslaught of product management for software as the problem. It’s pulled all the fun product stuff out of engineers hands. :(

It seems to me that it's an intellectual activity where one should go on for very long honing their skills and becoming better and better at it with age.

Maybe the industry sidelines the older more experienced technical folks at a cost, and that's why there seems to be a reinvention of the wheel several times in the software industry.

I'm curious if there are other technical fields that are similar to programming with regards to ageism.

Wishful thinking maybe, but open-source may help in this regard. As more and more of software is being added to the commons, those who've been there and done that can have a greater influence in driving progress.

> better capacity (and willingness) to adapt to the tower of babel du jour

this all sounds like you're describing people who can type and do what they are told.

and: we're all apes who can type.

edit: age is irrelevant. my point isn't that older people are better hires. hire for skill.

Obviously, outcoding everybody else is sometimes considered as a value and other times it is not. Shrug.

- cheaper

- less jaded

- easier to "manage"

- more willing to do the boring work that the older devs don't want to do

- more likely to be on call or work extra hours

- less likely to retire next year

No body wants to do the boring work. I think more experienced devs realize that a boring assignment isn't personal, its just business.

I think something that tech and chess may have in common as well is the ever-shifting grounds. Electrical engineering of today is not dramatically different than electrical engineering of yesterday. But programming (depending on the domain) is quite different today than yesterday. This is going to result in an age bias because at some point you start to simply become jaded learning 'Incremental, overhyped, and not strictly necessary new trendy framework/language [that nobody will be using in 10 years] #2,743.'

Chess is not a good analogy. It is a singular context. The real advantages that being over 35 and programming brings are:

- You are able to juggle much larger and different contexts at the same time - You have immense foresight that enables you to architect larger things

I think the peak age thing ends up being less due to actual aging and more due to the responsibilities of life taking time away from practice.

>“I feel I don’t have a lot to gain, I don’t particularly like [the championship matches], and although I’m sure a match would be interesting for historical reasons and all of that, I don’t have any inclination to play and I will simply not play the match,” he said on his sponsor’s podcast. [https://www.npr.org/2022/07/20/1112479750/magnus-carlsen-wor...]

Carlsen is very strong, but his title defenses have never really reflected that - ironically with the most recent exception. In the two defenses prior, he only managed to draw the classical section and relied on tiebreaks. His defeat is all but inevitable, and I think he wanted to go out undefeated. I think the one opponent he was hoping to be able to play against was Alireza Firouzja. Alireza is young and will probably become a world champion contender at some point. But Magnus would have been able to count on Alireza collapsing under the unique pressures of a world championship match and let Magnus then go out on top having undefeated having defeated champions from 3 generations. Instead Alireza collapsed at the candidates, scoring less than 50% in spite of being the (at the time) 2nd highest rated player in the world.

By the way, electric engineering of today is also quite different from electric engineering of the 80's. You have to learn new tools. Maybe if you work for an electric utility it's still the same though I tend to doubt that as well.

More for the role: full-stack has you doing multiple roles, but is not compensated as such. You're even removing the communication overhead if the role had been split in two. It seems to me as a business move to compress roles and pay you less for double the capability in exchange for varied work. I don't think people should just accept lower comp just because they prefer varied work.

But why do you think fullstack is paid less? Is this a generally accepted fact?

By relying on the idea that back/front is "just" a way of splitting a system, one could say that SRE/Front is a way of splitting a system, or Sales/Support, or Finance/HR, and so on. We're of course talking about ways of splitting the system(s) involved.

I think the spirit of the original idea is that roles are defined by boundaries. The boundaries are definitely "made up" but they aren't arbitrary. The degree of expertise and volume of knowledge needed to operate effectively (or expertly) within a role, and the ease or difficulty of obtaining those requirements, should be acknowledged when a company describes a role they are hiring for. If the bulk of your roadmap is back-end work but you want to hire full-stack devs because its nice to have everything, this seems like sloppy practice (though totally accepted).

On the other hand there are plenty of full-stack jobs that really just mean "back-end but not going to throw a contract in our face when you have to drop into the browser debugger to solve a problem". This is the kind of full stack I am. I wouldn't be okay with being asked to work on our frontend for the next year but I'm perfectly comfortable with debugging, making recommendations, doing some front-end work if it means filling a gap when resources are constrained.

Of course, they can't test their own code manually. That's two roles: developer and QA!

So a backend developer is at least 3 roles of work. Are you making 3x the salary you should be?

The biggest personal reason generalist roles should be priced higher is the time you spent to learn multiple things well enough to get a job doing them. If you accept a role as full stack that pays the same as a backend only role, you're essentially devaluing your own time. The other perks are reducing head count and giving the business that extra flexibility and convenience. If your salary doesn't reflect that, you're giving it away for free and we know how much businesses make us pay as consumers for convenience.

It might seems strange to consider a lot of factors, but you have to remember that generalists can bring quite a lot to the table.

Not at my day job, that is and has always been a series of mundane chores. I sadly think expecting to get paid for stimulating programming is fairly unrealistic. There is just not a lot of market for solving interesting problems or designing well-optimized code.

I find other avenues to build interesting things instead. At 35, I'm able to build things that I could never have when I was 15 or 20 or 25. I have so much more experience with what works, I'm much better at identifying which decisions matter, and which corners can be cut.

Works for me in ML.

When I would program for myself in the weekend I wanted to work on problems that would look good on my CV. Focus on techniques and languages that will be beneficial for my carrier. Soon also my hobby coding became a lot less enjoyable.

I then decided to seperate my hobby and carrier. In my spare time I started working on the things that fascinated me. Implementing operating systems, creating software rendered 3d engines, compilers etc. All from scratch. All in my favorite language (which is Common Lisp for me). Not caring if it would bring me money once, not worrying if anybody would use it or wanting to put it on my CV once. The only reason that is to enjoy it.

Straight away the magic I felt as a kid about computers came back in full strength. It hasn't faded since. And the funny thing... I started enjoying my enterprisy work also again. Already getting my coding passion fix in another way I could appreciate my work and the way of working for what it is.

During that time, I was a part time fitness instructor as a hobby, I trained for half marathons with friends, dabbled in real estate until around 2009 (guess how that worked out), got remarried, raised two (step) sons and now my wife and I are making plans to live a digital nomad life flying across the US. Our free time will be spent sightseeing and learning Spanish well enough to have a different experience when we stay in Mexico for a few weeks later this year.

That will bring me close enough to 40. I don't really see me stopping coding then.

At some point reading articles like this I was mildly worried about being employable as a programmer later in life. But not any longer. The amount of work seems to be ever increasing, and open positions get filled with middling talent at the face of persistent lack of skilled programmers. Seems like anyone with even a sprinkling of motivation and passion will not go without work for long.

I don't get it either but at the company I am in.. everyone moves into positions where they code very little. It causes a lot of problems but that is how it is structured

I had a brief stint as a manager, ended up doing more coding than my team. That was the moment I decided to step back into coding again.

For me, coding is puzzle solving or playing with Lego. It is therapeutic. If someone can continue to pay me to play, why not!

Yup.

For instance, at around the same age, I much prefer pair programming ; try to avoid remote work ; have little time for drawn-out technical discussions ; etc.

I wonder how much of these takeaways are career-path-dependent and how much are due to innate personality traits.

Note: I get contacted by recruiters constantly, at least a few times a week. Yes ageism is a thing, but you if you're really good at what you do you're much more valuable than young engineers.

- Nope, I don't want spend my week doing 1:1 with a team.

- 40 years old and I was never so sharp as developer as now. Focused. Precise. Fearless.

- Being the most senior developer in my team, doesn't put me in any special position other than I deliver a lot of good code, I do a lot of devops tasks, i review a lot of PR and people hear me.

- I can scale my work through my peers.

- I trust and respect the managers and architects, because I understand how hard their job is.

- They trust and respect me because they know that I could do their work (and they mine) and the roles are not ranks, but choices.

I don't fear for my job. I know that in the worst case scenario, even earning 50% of my salary would be more than the average of the population and I would still have fun with that. I can work in a niche market like Java.. or hell even Cobol :)

As a side note, get ready for the pitch forks, it started going up as we approached the then potential Trump era in 2016.

btw in Germany, people are already sharping their pitch forks too..

So large companies only?

Senior staff tend to get better at spotting the standard industry cons, but I find it amazing people often think they are somehow going to outsmart company contract/IP lawyers. Legal encumbrances are often a necessary evil, but some of the agreements fresh grads eagerly sign read like a Faustian bargain.

One finds many people tend to disbelieve anyone that contradicts their personal biases, and some get indignant when told how the churn-rate for large firms will affect them personally. It is like wishful thinking bypasses years of statistics training, and basic numeracy. Many industries simply rely or a steady stream of gullible STEM kids to keep their Youth Employment Tax credits, externalize training costs, and provide stock bumps from a symbolic layoff for year-end investor reports.

I wish the Tech industry treated people better, but "it is what it is". =)

I do want to add one more thing to the list:

* Find a well-managed team of really nice people that know more than you do.

Every part of this requirement is important, especially for generalists like me!

If you find this, life becomes lemonade.

As demonstrated by Adobe's Figma acquisition, there is plenty of opportunities in the authoring/graphic tools. So maybe you'll make the next Figma.

> I have no idea about how effective pair programming is. My desire to discover it is zero.

I used to think like that, but then, recently, I started doing pair programming with a colleague from time to time using vscode live sharing feature, and I find it amazing. Not really for the pure implementation work, but rather for the more architecture or design of things like API or data structures. I found that we are really productive spending about one hour or less together in the editor and brainstorming live the ideas.

I think of it in terms of leverage. If I knew for sure that my becoming a manager would let me be a force multiplier for my team, that they would all be enough better to more than compensate for losing me as an individual contributor, I would consider making the switch. Having been a developer myself, I would have insight into what gets in their way, and I could use my managerial powers For Good™ to get those things out of their way. At least that would be my intent. I've had excellent managers who had been good developers who chose this path.

Having said all that, one of my first managers early in my career was a high-functioning developer who was moved to a leadership role because that was the default expectation. He was a terrible manager; he played favorites and treated his responsibility as authority to be wielded against those he didn't like. I was fortunate that he liked me, but he stifled the early careers of some of my friends who were at least as good at the job as I was. So there is something to be said for not having developer-to-manager as a default expectation.

However, it is not a negatively thing. We may be able to setup IIS / Apache with Squid two decades ago to do similar things. The bar to do it now is much lower, and the tooling to help achieve that is much better overall (there are some not-so-great: Figma is a great design tool, but it doesn't translate to code directly unlike Dreamweaver / Borland VCL / Visual Basic, but I heard Framer is doing good on that front). That is part of the reason why there are so much more participation of labor in this industry: it is more graphical and easier to do (even terminal tools, largely do the similar things, are much more graphical nowadays!).

I feel it never really was about denying how effective plain web pages are but rather that faced with the choice of a wonderful DX with just JS, and a more difficult day to day with a mix of both, we picked the first. Sometimes at the expense of the end user, yaddi yaddi yadda, etc.

Good solutions for the "have your cake and eat it" scenario with exceptionally good DX are just now reaching some maturity.

Getting great reliable software delivered quickly, which is easy to maintain and change, should be the goal, I feel. But if that’s the case, why do people invent problems to find solutions to, why do people spend multiple days a week in Scrum meetings, etc.?

But looking at everyone involved and their actual incentives:

- For a consultant, the objective is to maximize the billable hours.

- For the employee, to get modern skills on their CV.

- For the junior programmer, there is a more level playing field with the seniors when tech is used that’s new and nobody knows, vs. tech the seniors know well and they don’t.

- For the manager or owner of a product company, they want less stress having to make decisions and as long as the product makes money who cares if the software could be delivered 50% or 70% faster?

Many of us are living this now. If it's not the chasing of new frameworks, it is old frameworks no longer being actively supported, or key features never being developed. Then it turns out something like vanilla HTML + JS can do the job just fine, but you need to update everything to vanilla to make it uniform.

Many developers nowadays seem to expect to be able to just wire things together without actual writing much algorithmic code. And the solutions have catered to that.

Those of us that are older lament the idea of using frameworks to increase our productivity, but still being more than glorified middle-men.

This attitude is common, that these frameworks are not, themselves, dependencies to be managed and protected from.

Is this not the typical mentality?

Putting together a decent web app today that is competitive with what’s out there and doing it in a reasonable amount of time is something that just requires frameworks and library mashing. Even though I can fully empathize with your comment, from experience, and even though my beard is almost as grey, piling stuff I don’t understand together from yarn or npm is exactly how I start a new web app. My job recently switched from web to hardware, and the workflow changed dramatically into writing and scrutinizing every line of code, and complied instruction even. But even still in the hardware company there is an overwhelming sea of choice and complexity and an army of young and old programmers all borrowing and reusing code at all times, with everyone just treading water and understanding only the tiniest sliver of it all.

I think we have no choice but to embrace the fact that it’s no longer possible to avoid swimming in 90% code you can’t control or understand, and figure out how to better manage it and encourage people to snorkel under the surface whenever they can. I don’t think we should blame it on the kids though, they’re just trying to get by the same way we did, but in a different world than we had. The good ones will still shine through and be amazing, and the rest can learn their mistakes the long way just like we did when we were young and obstinate.

I once had an experience where I asked a younger developer why they didn't use cookies for a solution they were using JWT's for. Their answer? They didn't know how to use cookies.

I was bemused, their solution worked just fine, it's just all the extra infra needed when compared to cookies, which would have solved the problem just fine.

I'm in my mid-40's and I would apply that observation to scrum (and software dev in general). What I tend to see are a lot of very earnest people who are legitimately trying and the behaviors often associated with scrum are what they've been taught works.

Truly understanding what goes into successful software dev takes years of work and is more craft than algorithm, so I can understand the challenges.

If you're talking about web applications then I tend to disagree. The SaaS paradigm and the UI living in a browser are relatively new ideas that are still maturing. I don't think there is a lot of good "what was already there" and we're just seeing the evolution of tooling for this ecosystem, not completely decoupled from the evolution of the large companies that rely on this tooling. Not sure it's worth getting frustrated about... I tend to just stay away from it because I prefer to work in areas that are less fluid. And sure, sometimes there's just Not Invented Here syndrome and let's reinvent the wheel instead of using existing wheels. Nothing new about that either, it's always been like that.

All that said, the principles of how everything works are unchanged. People that only learn to use a framework are just not good software developers. People that understand the principles can work in any framework. This has always been true and is still true. There's a shortage of people that really know their sh*t and there's always been as well. That's great... I'll never run out of work (I might run out of motivation ;) ).

It's not that difficult if you actually can make decisions quickly. It only gets difficult once you are in a bigger company where you have multiple more or less competent stakeholders and every decision get accompanied by multiple meetings.

I disagree with this. I think there are a lot of people who don't like being a leader for lots of reasons... but every time I've promoted a reluctant leader it's been magical for that person and for their team. A lot of times the people that self-promote and like to be in charge should never, ever be given athority.

> I am very skeptical of new technologies

I used to think that way until I realized that in a lot of cases, we've been re-inventing the same concepts in computing since the 1960s. I think a lot of the re-invention is really being driven by hardware capabilities, languages and fashion. We're seeing it with Rust right now - let's rewrite all the things in Rust! Underneath it all, though, the payoff for using new, less capable tech, is that eventually it will pass up the old in a very meaningful way - and when it does, systems build on the old are washed away.

> I disagree with this. I think there are a lot of people who don't like being a leader for lots of reasons...

Note that you are talking about different things from OP.

OP was talking about managing, you are talking about leading. These are two very distinct skills. Sometimes you can find both in the same person, but these people are few and far between, since each of these roles is already a full time job.

Everything I've experienced in my professional life has taught me this: managers who can't lead can't manage, and leaders who can't manage cannot lead. Never once have I worked for a manager who didn't see themselves as a leader, and never once have I met someone who called themselves a leader who wasn't management.

People who are stellar managers, have extremely high empathy and EQ, understand their engineers, prop them up, help their career, guide them toward both professional and personal growth. They also did not have a single ounce of leadership or charisma in them, very low technical chops, no vision, and not interested in providing team leadership.

I've also met stellar leaders, visionaries, who inspired, entranced teams with every single word that came out of their mouth. They provided short and long term directions, technical and product guidance, motivation. And they were absolutely terrible human managers. Could not place themselves in other people's shoes. Didn't really care about managing the career or growth of people on their teams. Were only focused on matters that did not involve any human feelings.

These kinds of people both have their places and they complement each other wonderfully.

And sometimes, you find these two very distinct, polar opposite qualities, in one single person. But like I said, this is much more the exception than the rule.

And of course, the reality is that most people lie on a spectrum between these two extremes.

A leader can lead initiatives just via building relationship and having expertise without role power or any reports.

I was hired at my last job by the then new CTO to lead the “cloud application modernization” effort as they were pivoting to providing access to micro services to large health care companies.

After being somewhat successful at it, he offered to make me a team lead (been there done that). I told him in no uncertain terms that I would quit first. We had a great working relationship.

I now do basically the same thing in the consulting department at BigTech as a middle level hands on consultant.

I asked a year end could my position be considered a “terminal position” or would I need to work toward a promotion. My manager asked me why. Again I was very honest. I needed to know because I would be looking for another job before seeking a promotion. He said it could be a terminal position,

I prefer leading projects over leading people.

I often hear the argument that there is nothing really new in programming and that everything was already done in some way or other back in the 1960s.

I completely disagree with this and find it harmful. There is genuine innovation and new research happening in computer science all the time. The example you gave, the Rust language, is based on linear type theory that was first developed in the 1990s. Nothing like it existed in the 1960s and that is why it offers real improvement to software development.

Today, software development is slow, buggy, expensive and late. We owe it to ourselves to continue to research and search out ways to improve our craft. And this is happening. Newer programming languages and tools DO incorporate innovations from recent computer science research and are better for it. We should celebrate this rather than cynically pretend that all computer science research halted in 1969.

That I have to become a manager. That I won’t always code until I retire. That I won’t be welcome in the workforce in my later years.

All of those things frighten me! I love programming, and I want to be doing it in my 60s, happily. Glad to see that people are.

However, idle you never can be. Because being of age and not being able to run with the pack is bad. Luckily, it is not the framework of the day but more the soft skills which make the difference.

FWIW pair programming is very hard to do well and usually pretty uncomfortable. It needs to be structured well and done in smaller doses with lots of breaks. But when it has worked right (which was a small minority of the time for me), it has been exhilarating for me, unquestionably much faster and more productive than coding by myself, and much more fun.

I do think pair programming is also a fabulous way to share workflow tips and tricks. Watching someone drive you will see things you didn’t know, and when people watch you they’ll discover your secrets. Even if pair programming is hard, I think it’s pretty good for the organization to have team members doing it on occasion to help propagate this kind of knowledge more quickly. But yeah YMMV and it does also require self control and letting people do things their way sometimes even if it seems slow.

Either you're both at the same level, and you can feed off each other, thinking through edge cases and bugs as you go. Or you could be at different levels, where one engineer is teaching, and the other is learning. It's really a win-win in my opinion.

the miserly "leave me alone and let me code by myself" people are siloing knowledge and probably not writing the best code or products than if their code could be critiqued in real time or on pull requests and so on.

a lot of adult software engineering is not in a vacuum but in a collaborative and fast-feedback based environment

Of course, if you're managing, and you know someone is not motivated, you probably don't turn to this as your solution, but I'm not management, so I could be wrong!

My the youngins have some pride. Not sure how to break it to you but, the web, phones, etc was created mostly by people 10 years older than you.

Looking at myself, I think my biggest strength is in knowing what not to do.

When I was younger, I'd work on whatever. Then everything started sounding like yet another get rich quick company, and is that what I was giving up my life for? Just to move little green pieces of paper around?

The most appealing thing I'd seen recently was a company that wrote software to help maximize farm yields. At least there was some real, effective benefit for a great many people.

It's like the goal of the company gradually became more important than the tech or money. And altruistic companies are very rare.

But I always really wanted to teach, so that's what I do now. Pays about 40% of what I'd make in industry, but I get to geek out all day and do work that benefits the world.

After my graduate work I am the opppsite. I realized that meaningfulness is not a sufficient condotion for enjoying my work. The tasks I work on and my coworkers make a much larger impact on my happiness. Whether I work on something "stupid" or "vapid" matters much less.

I kinda fell into it. I wrote some guides that were popular, and the head of the program at this boot camp was copying my examples for content (I had placed the code examples in the public domain, so he was acting ethically, don't worry), and he stopped and thought, "I should call this guy." They were a startup and needed folks to teach. I had just left the company I cofounded and was drifting for a bit, so it was good timing.

The university is in the small town I live in (about 100k population) and I organized a tech meetup here, and met the head of the CS department that way. That ultimately led to me being hired recently.

For casual teaching, be a part timer. There are lots of night courses that need teaching.

Private boot camps should pay around $90/hr. Adjunct positions at universities probably pay about $1000/class/month. It's really not good money, but it's good experience. I taught a couple quarters as an adjunct at the university and the positive student reviews I gathered contributed to me getting the job, for sure.

Lol I just noticed the user name. I've used what you've written in the past.

That's cool though, 90/hr a works out to a little more then my base rate at my last job so not bad. I don't have a bs let alone a master so I'd guess a university wouldn't want me to teach hah. Thanks!

I always saw myself as an individual contributor, and rebel against the path that leads to what's effectively project management with zero daily coding. But being the lead of a smallish team, making sure everyone's working towards goals and helping more junior devs when they get stuck, is a surprisingly interesting challenge.

Even to this day, I have never been hired after being interviewed by a youngster. I suspect karma might be a thing, so I just endure them all knowing little shits for 30-60 minutes and move on.

For most of my career, I've been told (and I believed) that I would probably get forced out of a hands-on individual contributor role as I aged. During the late-2000's, I even had an early midlife crisis and earned a law degree, expecting that I would need to make a career change into IP or something. That hasn't been the case.

What I think people missed is the compounding effect. The supply and demand for computer programmers seems to double every decade (maybe the interval is even shorter). With each doubling, the older cohorts become a smaller and smaller share of the whole. People look around and think, "There aren't many older programmers here", and base predictions off that observation. However, the more accurate observation would be, "There have been A LOT of younger programmers added here!". I don't believe that it's actually a zero-sum game, though.

I don't know if this human resources cousin to Moore's Law will continue indefinitely, but it's certainly held up through my career. Even when it inevitably slows down, I think that just means you'll see the age cohorts balance out more over time.

https://blog.cleancoder.com/uncle-bob/2014/06/20/MyLawn.html

There is also a massive increase in the number of 25-35 programmers in the same time period.

My interpretation is there are definitely forces that push against older programmers staying in or re-entering the profession, but they aren’t as severe as they appear to be just looking at the raw numbers. Generally, programmers who want to remain the profession are going to be about to, but it is harder to be a programmer over 40.

[1]: https://whoisnnamdi.com/never-enough-developers/

This is especially tempting if someone’s skills start to diverge from what’s in demand.

In my own case, when I have enough money to retire it’s going to be hard to convince me to keep working.

A programmer is told what to do, and half way thru development they have the boss show up and say 'I just read of this brilliant idea in BusinessWeek, lets add/change the code to do .....".

My basic philosophy is that I'd probably be sitting in front of the silly thing anyway. Might as well be paid for it.

Programmers are in a bubble. Head over to the local grocery store. The person bagging your groceries is 63. There is no retirement plan for him - as well as most Americans. These "old" people will end up working until 70, on their feet. If I can find someone to pay me to write CRUD apps all day in whatever hipster framework, I am fine with that, no complaints here. Beats working at HomeDepot.

While brutal, there is something to working later from a health perspectice. When I was young, retirees played tennis and golf but I dont see as much of that in my cohort.