I'll confirm and reinforce everything you're saying here.

Six weeks after I decided to move companies, last year, I had three excellent job offers to choose between, and even more that were less great but still doable.

> you should be GOOD

I like to think that I'm pretty ok at this. Being able to compare and contrast Linux top half and bottom half interrupt handlers all the way through optimizing a y combinator implementation during an interview leads to some good results.

To the other replies about how to stay passionate after so many years of 'basically the same things over and over': I don't have a good answer to that.

I did some amazing stuff earlier in my career, and I long desired to find a place where I could go even further, but I've come to realize that it's unlikely to ever come about again.

Perhaps it's kind of like 'grinding' in your favorite video game. Same stuff, over and over, mildly challenging. Take pride and feel good about getting it done, well, again and again.

I don't know if my answer is good, but here it is...

If I find myself in a position where I'm actually bored and doing the same things over and over, then I move on to a new challenge, be it with my current employer or not. The most important thing for me in a job is that it's interesting to me. If it becomes boring, then it's time for a new job that is interesting -- partly for my own emotional health and partly because that's a strong sign that I've learned all I can learn from my current position.

And there's always a new job that is interesting!

Can you elaborate?

Starting in the 1990s, I was in the 'devops' team inside of Network Engineering in an enormous and enormously successful (to this day) retail chain. At the time, we were told by AT&T, our biggest WAN provider, that we were the largest centrally managed network they were aware of. Even larger than any one of their own various management regions. When I left there in the early 2000s, there were tens of millions of IP addressable devices on the network, and my team wrote the software that managed and monitored most of 200,000 Cisco and Nortel routers, switches, access points, and other kinds of devices.

At the time, this retail chain was, on average, opening or relocating a new store every day, and each store had a surprisingly large network. Also, we were pioneers in just in time delivery.

So, the network had to be extremely agile (we had people all over the world, all the time, being paid to mess around with our hardware in the form of upgrades, installations, rollouts, etc) and exceptionally stable.

Store shelves would start to go bare after an hour of network downtime at one of our hundreds of distribution centers, across 10 countries. (The 'bareness' would happen many hours later, of course.)

For most of that time, I was the technical leader of the automation team inside of Network Engineering. NE itself had on the order of 40 or 45 network engineers, plus the 5-7 people on my team.

At that scale, automating 99% is about as good as automating 0%. EVERYTHING needed to be automated. And, as things changed, rapidly, my team's automation had to be ahead of it, all the time.

For most of the years I was there, my team delivered spectacularly. We even hit 99.9999% global network availability one quarter. Note: this is absolutely not a bullshit number. The sense of urgency and focus demanded that all assumptions were tested all the time, and availability metrics were very accurately calculated.

The monitoring system I designed and we built was state of the art at the time, and in some ways, even compared to the offerings today.

True story: an NCR contractor (who we widely used to do the in-store hands on work) decided to start stealing our equipment in Southern California. He knew we had redundant store routers; the frame relay circuit plugged into one, and the dial backup circuit plugged into the other. He knew that when one router was to be taken for service and another wasn't immediately available, the procedure was to plug both network lines into the remaining router; our automation handled that and kept dial testing.

So he walked into a number of stores, did that, and walked out with an expensive router.

When he was caught, the data from our monitoring system was featured in the prosecutor's case against him.

We guaranteed within less than a minute of accuracy that any managed device that fell off of the network would be noted and reported. And so it was, and he did go to jail.

From a technical perspective, I'll just say that the entire system was built around the paradigm of message oriented programming. Neither I nor any of my team members knew about erlang at the time, but the system we made organically had many of the same features and strengths.

And, finally, just before I left, I was pushing forward into using machine learning techniques to do truly predictive network monitoring and management. The initial results were extremely promising.

Can't you pretty much directly apply those lessons learned to Highly Scalable system design and implementation?

Seems like your skill set would be in very high demand, after a couple of Udemy Docker and Kubernetes courses.

I've helped a couple of companies implement Kubernetes already (:

I can’t agree with this. Most businesses aren’t doing anything that require leetCode and deep algorithms knowledge. After a certain age, what’s important is to know how to drive business value and how to either save the company money or make the company money.

Also, be well aware of where a technology falls on the hype cycle and keep your skills current with it. Whether you are looking for a job or not, see what other companies are looking for and make sure your skills are in sync.

Also, knowing how to speak the language of business is just as important as knowing how to talk tech - if not more so.

Finally, networking. Network with former coworkers and get to know local recruiters.

I’m 45 and I am not seeing any signs of ageism. My former manager is in his late 50s, self demoted to an individual contributor after his kids graduated and is now a full stack React/C# developer on top of Azure. All of the people he hired at our former company were 38+ and we are still developing, switching jobs, and are very much in demand. None of us are in management.

And yet, those are still the most popular interview questions :/

Even though they made an offer, it told me a lot about the company that they never asked me any architectural questions. I declined the offer. The job I did take, the manager asked me what would my 6 month plan be to create a modern software development department and to migrate their system from one based on PowerBuilder written in 2000 to use modern technologies.

For my current job - still as just as individual contributor at a small company, we discussed the technical challenges and the goals he had and we started diagramming.

I would have to try my best not to laugh at a company who was building yet another software as a service CRUD system who asked me to do algorithms.

I just posted a comment in another thread about burnout. It's very common in our industry. I believe it's due to the Coolidge Effect. Aka, the brains inherent search for novelty. It's a struggle to not look at almost all programming tasks as just some variation of the same problem, if you've been doing this long enough. How do you keep it interesting enough, to stay passionate?

And the marketing bods/management and so on more or less dragged the project off track, up to the point I didn't want to work on it at all, I quit, I left my 'baby' and had a hard 6 months where I didn't really want to do anything... Good thing is that I became a pretty competent landscape photographer along the way...

Nowadays, I work a LOT more like a mercenary. I don't mind working on projects that leads straight to the wall -- NOBODY will listen to you, or trust you've seen that 12 times before.

So as far as I'm concerned, I enjoy the work, the architecture, the TECH challenges, and everything which gives me a quick, and I completely ignore the outcome in the end. Sure, if it's a success, whoohoo whoohoo but I no longer put the same amount of 'care' and 'ownership' in what I do. I just let it go, and do something else just as efficiently.

It might sound cruel, but for the like of us who REALLY get a kick from designing/building/implementing stuff, it's actually quite liberating.

I just smile benignly on at the idiots in the room sometimes, it's quite relaxing :-)

The form I am referring to, builds steadily over time. It's not the result of some bad interaction with management, rather, it's the result of doing the "same" thing for 30 years.

I recognize that the problem is in seeing it as the "same" thing. Yet, given our job as programmers is often to see the forest through the trees, to identify patterns, it becomes hard not to see yourself as solving the same set of problems over, and over, and over, and over.

That's the type of burnout I'm referring to. I'm guessing you don't struggle with that at all ;)

There's LOADS of fields that you haven't done. I remember my first time trying to get my head around some VHDL code and I felt I was 12 years all over again looking at 6502 assembly code.

Make your horizon wider!

I'd love to be able to do 6502 for a living...

Most programming tasks are a variation of the same problem, you realise it, accept it and then realise that the way to write good software is to get decent at the building bit and then work on getting decent at all the other bits around it.

Requirements gathering (aka talking to people and writing down/recoding what they say), testing (hitting things until bits fall off), reliability (making sure things don't break the same way twice), documentation (making sure the poor sod in after you has more to go on than you inherited).

There is a tonne of variation in what the average dev has to do day to day (unless you are a "Here are the requirements, you can change nothing, implement this spec, never question it" dev - in which case I pity you) so the trick is to keep learning in multiple domains when one gets stale rotate to another, variety is as they say the spice of life.

Every day is the same. If you want to search for novelty, it's the fact that it is the same problem and it's been broken from the beginning of time. So do something else! But what? That's what drives me.

You can't dally, either. It would be easy to just spend a year logging (and probably get nowhere). But you can't do it in a job. They won't stand for it. So what can you do in your few minutes of leeway? What difference can you make? You aren't going to fix it, so how can you extract just a tiny bit more information so that maybe someday it will all click?

I think most people don't care about this stuff. Programming is inherently boring. You need to care about insignificant details to really get deep into programming, I think. I mean, it doesn't really matter. Global variable, passed parameters. It sucks one way or it sucks the other way. Who cares? Only crazy people, probably. But in my opinion, that's where the fun is.

His solution: he became a long-haul truck driver (he asserts that the skill overlap between software engineering and long-haul truck driving is far larger than you'd think). After a couple of years doing that, he reentered the software engineering world, completely revitalized.

But I can't think of a better industry than software development to satisfy the search for novelty. There's always something new and interesting to learn.

(BTW I am programmer, a little bored out now)

I think you'll see some survivorship bias in this thread — we may end up answering a different question:

"How can you tell who is likely to still be programming 20 years after they start their career?"

Instead of listening to you and I (age 50) there are some young people who would rather claim that basic/low-level/first principles knowledge is irrelevant.

I've never been 'age discriminated' before

I have. These coder-bros I was interviewing with accused me of Googling the answers and started in on the complete condescension. (I was doing the classic dynamic languages programmer thing and writing a quick script to answer their question programmatically.) Nothing fundamentally age-discrimination about that. It was how they spoke to me and treated me after that. Sometimes I still get mad or sick thinking about it. One thing I've learned, when people are projecting things on you which contradict the facts, that's a big symptom of bias.

Some older people I worked with (I'm 40 now) were well respected by the others, because they prove time and time again that their experience is really valuable on all kinds of stuff, both low level details and high level strategies. To show this in an hour is difficult.

Although I was once able to do it, and was hired. They asked me a typical OO inheritance questions with a base class Animal, and derived classes Dog and Cat, and then let them "bark" and "meow". I knew were it was going, so I said "There will probably come more animals after this, so what I would do is drop the inheritance and move into a data-driven approach, where the specific animal behaviors can be defined in a config file, without needing to go through programmers have to compile a new exe every time". They liked that response, although that was probably not the standard answer that they were looking for when interviewing juniors.

And basically such things are your job as a senior anyway, to look into the future and steer the short sighted solutions that juniors come up with.

I'm really sorry about that man... I guess young people tend to feel like they own the world. I'm 27 and I believe I have been raised outside this toxic bubble (I got a lot of shit from my parents, I never thought I was somewhat special just for the sake of it, I only felt special after achieving goals, I always felt necessary to them though, regardless of achievements). I believe younger people are raised like they are too special, the promise of a better world, the ultimate legacy of their parents and that tend to go over their heads, specially after a historical period of unprecedented growth in which my parents and I believe their parents lived (60s through 80s) in which they prospered.

Young people tend therefore to believe they inherited their parents achievement and they can only go forward. I feel lucky I don't share that and I would love to be your coworker and learn from you.

Yes, that sounds like the normal "folly of inexperience" -- it comes from people who don't yet have enough experience to know that they don't know as much as they think.

There's a reason that people (in any field) with less experience tend to be more certain of the correctness of their judgement than people with more experience. The more I learn, the more I realize how little I know.

> Sometimes I still get mad or sick thinking about it.

I think back on instances like that as dodging a bullet. Can you imagine the hell that actually working with those people would have been?

It is irrelevant to most jobs and no I am neither young nor inexperienced. I first started programming in the 80s in 6th grade doing a combination of 65C02 and x86 assembly language and I spent my first 12 years professionally bit twiddling in C - first on DEC VAX and Stratus VOS mainframes and then on x86 PCs. Later I maintained a proprietary compiler/VM used to write apps for Windows Mobile.

I think I have my low level chops....

Just as one example, the basic level of algorithms, where one could realize when they're creating a O(n^2) routine, is relevant to just about every shop I interacted with working for a language/VM vendor. I found it disturbing, the number of times I could play the hero just by knowing that much.

I've worked in shops using C, where I kept bumping into workers who hadn't the foggiest idea how a C compiler might work, and it not only showed in their code, it even showed in management decisions. (Long story short: The application literally had 100's of re-implementations of linked list.)

I've interviewed recent grads from top-tier schools with near 4.0 GPAs, who try and tell me things, like adding a pointer to a struct incurs zero memory use. Then I ask them how much memory a pointer would take up, and they can't give me any kind of answer. (Or ask me a relevant question for more info, so they can answer.)

All this stuff could be avoided if there was just a certain level of basic background knowledge. They're like car mechanics who don't know the first thing about electricity. There's a certain level of background that can keep you from inconveniencing and hurting yourself. You don't need it most of the time, but when you do, it can save you a lot.

I think I’ve had to implement one complicated algorithm that was low level and not a complex business requirement in years and that was the “shunting yard” algorithm to convert a string algebraic expression to a number as part of the parser for the compiler I was maintaining.

Most developers could go there entire successful career without ever knowing how a compiler works.

Only a smattering. I could cover just about all of it in 2 nights of instruction. However, that doesn't mean the students would have mastered and internalized the concepts to the point where they'd make the right realizations when they need to.

I think I’ve had to implement one complicated algorithm that was low level and not a complex business requirement in years and that was the “shunting yard” algorithm to convert a string algebraic expression to a number as part of the parser for the compiler I was maintaining.

Right. Most of the time, one implements simple algorithms, using hashmaps and "vectors" as building blocks. But first principles knowledge can also make one better at that.

Most developers could go there entire successful career without ever knowing how a compiler works.

(Their.) Right. Most people can manage. Just like most mechanics can manage to muddle through learning as they go. But why not have mechanics learn basic knowledge about electricity? They do, because that kind of 1st principles knowledge can save people from pain. The same applies to CS/programming. Also, the knowledge itself is pretty neat. A lot of people get pleasure from learning it and being able to understand their world in a deeper and more nuanced way.

People going to top-tier 4 year universities, getting a 3.75 GPA, but coming out with no more than a glue-crud-apps-to-cookbooked-machine-learning/buzzword-of-the-day-library level of knowledge just strikes me as a colossal waste and colossal rip-off. It's also people becoming the victims of low expectations. I know that kid who tried to tell me that a pointer doesn't take up space could well have learned that stuff, if his program had just had slightly higher expectations. I'm reminded of schools who track certain kids into learning nothing more than what's necessary to balance a checkbook. That's killing young minds with the bigotry of low expectations. We're probably already at the point where some say asking kids to learn enough math to balance a checkbook is asking too much. Something about that strikes me as selling people short.

That's very true, but it has changed my attitude for the worse about interviews. The particular situation where someone can take facts and reality itself away from me (not really in reality, but in terms of the outcomes of the immediate proceedings) is like hell itself. The possibility of that lurking, because I am indelibly "marked" by my age is awful.

I remember a while back on a guy who was raving about my code setting a (as boolean) flag with "done++;" -- he thought it was such an awesome idea. OH YEAH.

I think I definitely was. The attitude of one guy changed when he was looking through my resume and realized how old I was. There's this condition and particular set of reactions that accompany people getting strangely willing to believe you did something bad, even when they have scant or incomplete evidence. I grew up someplace where we literally had to drive 50 miles to visit friends of our approximate ethnic group. It's something that's familiar to me.

In my current job, I'm working with C++/MFC.

If I need a job now, I want to be able to call my list of recruiters and within the next week have dozens to choose from and 3 or 4 offers which has been easy to do between 2008-2016. When I was looking in 2017, there were more companies looking for Node and full stack developers paying what I was looking for than C#. I happened to find a job that needed my combination of C# and architectural experience, but the pickings were getting slimmer.

So now, as much as I hate it, I’m going down the full stack JavaScript road because that’s where the opportunities are, and filling in a few gaps that will let me be an overpriced “digital transformation consultant”/“cloud consultant”, etc. (Yes I die a little every time I say those words).

One skillset is about getting a job fast if needed the other is by getting one that pays more. It’s about optionality.

When you are still trying to be a software developer in your 40s you can't afford to not keep up. Companies are far more willing to let younger people learn on the job than older, presumably better paid old developers. They already stereotype us as not being up to date, no need to reinforce it.

I'd love to read your list. :)

Finding these experienced people isn't easy. Many don't want to move. You can't just drop by a college and grab them in bulk. We'd hire more (see https://news.ycombinator.com/item?id=19055183 for "Who is hiring?" post) if we could just find them.

When I first learned to program (I was about 12), I was using paper tape and those old Bell teletypes, in a facility that still used punched cards.

Here's my punched card story -- I bumped a box with a card deck and it sent the cards flying, mixing them all up. The systems operator made me sort the cards by hand. It took me hours. It was a few months before I learned that they had a machine that would have done that for me automatically -- but the sysop had decided that I needed to learn a lesson (which I did, in fact, learn!)

I wrote a lot of "Apple Telecom 3.0" that ran on most "powerbooks" back in 1995+ or so, you know, modems, faxes, voice mails and all these very high tech stuff :-)

https://www.reddit.com/r/apple/comments/3faz2u/steve_jobs_in...

This is the Steve Jobs more young entrepreneurs need to know about and emulate. Not the "Jobs was an asshole and successful, therefor if I am an asshole I will also be successful" vision of Jobs. Or the "Jobs made pretty things and suckered people into paying too much for them" vision of Jobs.

I wonder if you can expand on this. As I get older, I find myself and my peers confronted with having to answer to younger, often less experienced, stakeholders. What kind of challenges have these presented for you and how have you adapted? What philosophy or attitude should us aging techies adopt as the gap between our peers widens?

Don't feel underused or misunderstood etc etc even if you blatantly are. You won't be able to change it anyway, just work with what you have, and use your remaining brain cells to do stuff they CAN'T do: for example learning the next big thing quicker than they will...

Ultimately, it's just tech. it comes, it goes... You've likely seem most of it before anyway...

Also, when you DO find the basket case of someone who is interacting with you like an ass and has no clue about your real value, remember that it's THESE GUYS failings that will ultimately keep you employed to make stuff work in the end :-)

-- but people who don't will always struggle --

-- MORE so as they get older! --

So I know it sounds silly, but acting classes, talking in front of the mirror or whatever else might help a lot more than staring at a screen for a few days...

What are the things you would suggest to learn and what resources do you recommend?

Thanks, again!

My guess is that I'd be pretty average or less, given my patience threshold -- I've worked with fantastic managers before, I'm not them. I don't think there's much of a problem of age discrimination in managements, unless it's for places like startups and so on where "people" NEEDS to "look cool and startupy".

I'm a pretty effective mentor tho, and I seriously enjoy that -- I think it's a lot more "my place" than trying to manage/herd cats :-)

I have a personal request... Please don't say "And, if you're ${SOME_DEMOGRAPHIC}, you should be ${SOME_LABEL}"

I understand what you are saying, but it doesn't leave room for someone like me. I got mu first dev job at 40, about 5 years ago. No matter how good I am, it's not possible for me to have more than 5 years of experience. And my age has nothing to do with how good I am.

Young devs are surprised when I say Git is only okay, look forward to the next SCM tool, they tend to think git will be the tool fir eternity, and surprised when I list if the 6 other tools I’ve gone through in my career ... so far!

what would you consider a solid, time-proof set of fundamentals ?

Oh and be fluent in C -- you might not like it, you might despise it, you might think whatever you might think of it, but you will find 10 examples of anything in C for any programming problem you have.

Basically it's like being able to read/write Ancient Egyptian when finding a stone with wierd symbols on in the desert.

Then do a small run on how compiler works (you know some assembly, and you know some C now to match) from then you can infer how an interpreter works, and even infer how a JIT works. You'll get to understand how the Javascript in your browser actually /works/ -- that's more than what 99.9999999999% of the population will ever know :-)

Then feel free to play with other languages, quite frankly, I'd suggest not getting enamoured with one in particular. Ultimately, they are all the same. Make sure you understand how a garbage collector works, how dynamic loading of libraries works, and more generally, how the operating systems works -- no need to get in details.

Just ^^^ THAT makes you more knowledgeable than many people throwing O-n's problems around the place.

For training, i think you should try some easy "security challenge" that exist on the web, especially those based on shell, network and assembly with no stack-protection. They are not usable in the "real world" (well, some shell exploit might still work tbh), but you will learn how to use debugging tools efficiently, as well as reading assembly. If you want to be a devops, those skills are very important imho.

Every large institution has an old COBOL mainframe running some mission-critical software that they can't upgrade away from.