An old hacker's tips on staying employed
madned.substack.com
madned.substack.com
The article strikes me as good advice. I didn’t find anything to disagree with in it.
Ageism is a thing. People have all kinds of biases of which they may or may not be aware. You have them too, and so do I.
A line from another source that I keep in mind is this: “If you’re always getting angry, you’ll turn your nature against the Way.” [1] It doesn’t pay to be the angry, unapproachable person in life.
What this leads to is a lot of dumb decisions. One example in this case is that, to someone who's never written a line of code, a 25 year-old developer is the same as a 50 year-old developer, but at half the cost and without the hassles of things like kids to take care of. You need to have a decent understanding of the work developers do, in order to understand the value the 50 year-old developer brings and why paying him or her 2 or 3x the 25 year-old is actually a bargain.
Most company’s best 5% 25 year-old developers are probably creating more value than their median 50 year-old developer, even though that median senior dev is creating more value than the median 25 year-old.
I kind of disagree with this, although I don't think it's age that separates developers. But developers who can work independently are a lot more valuable than those that require close supervision, and those developers are considerably more value than those who are actively destroying value.
Y axis is a histogram of “number of engineers producing that value”, increasing with Y.
This, but for value instead of IQ: https://en.m.wikipedia.org/wiki/File:IQ_curve.svg
What I have found though is a lack of willingness to put up with bullshit. Stuff I accepted as normal in my twenties I'd just walk away from now. This is probably good for the employer but maybe not for your immediate manager.
True. But most people reach that point after a few years or never.
Is this the 'classic' expectation for a dev? Where I work the least technical person is the PM and everyone else comes together to determine what gets done and how it gets done.
Everyone knows the tech side and decisions gets filtered down to the rank and file. Taking initiatives are expected - I know this is likely the exception not the norm, but I hope future workplaces are more like this and less like that.
This can also be said of managers. Then why aren´t they discriminated by age too?
Absolutely. I will be using this one.
This is a widely held position, which sort of makes it a self-fulfilling prophecy. But I'd argue that it's not true. Most of what I know now that is really valuable isn't related to the technology of today or 1986. It's related to how to work, how to design systems, how to decompose problems, how to scale, etc. etc.
The thing is most people quit the field long before putting in 20+ years. So, I suspect it’s less about the experience than the filtering process.
Since finding a "best 5%" is almost impossible, because who knows until you hire them and they work there for a while, the best bet is to hire people who are older. Also, for a bone fide best 5%, they are going to work at the cool companies, and never will work at a sewer processing government utility company in their IT department, or work at for a local chain of tire stores with 50 locations and an IT staff of 3 people.
So, one might as well not even worry about the top 5%.
It isn't like there is a shortage of technical managers right now.
I've never had a non-technical manager, even when I worked in sales, and I've been doing this for over 20 years.
That's not accurate. At 35 there are young kids, maybe even 45. At 50 they're pretty much independent, at least aged 10-12. So actually, if you hire a 32 year old dev you should be more concerned about kids than if you hire a 50 year old. So if that's the concern, only hire 18 year olds I guess, or maybe even 15.
source: 25+ years experience in this industry.
The flip side is that I have never been so focused during working hours as now. I’m getting quite much more done in six hours than I used to get done in eight or nine.
After seeing this time and time again, and because I was getting older, I made a conscious decision to move into management. Be the change you want to see in the world, right? Now my output is mostly spreadsheets and powerpoint, but I enable my team to do good work as I insulate them from the bullshit. I can always get down into the trenches or work on a side project if I need to scratch that creative itch.
Cause nobody every changes, loses their edge or falls out of touch with their tech roots, right?
We just need to get these clueless dinosaurs out of power before the current woke kids take over!
I happen to be doing a security assessment on some products (PuTTY etc) at the firm (Fortune Global 100) where I am interning.
It baffled me to read a directive from management that said that we should shy away from open-source projects - I must confess that I was somewhat frustrated at the sheer ignorance in the memo but your comment allows me to see a silver-lining. I hope that one day I can rise up to management and make decisions based on greater nuance than simply saying "OSS bad and insecure".
Note that large amounts of OSS is used in companies, but it's generally code that developers are expected to know well enough to dive into if need be. And code that is popular enough to be well tested for bugs and known that breaking errors in the framework will get fixes. Examples would be things like Python or Node.js.
As a manager a potential problem you can have is a major bug your team is responsible for that no one is qualified to fix and thus your only reasonable time estimate is unknown. Avoiding certain parts of OSS is often a precaution against this situation.
I have filed many bug reports for paid software over the years. The bugs were fixed exactly 0% of the time. If they ever gave a reason, it was along the lines of "you are a special snowflake, nobody else has had that problem, so it isn't worth fixing".
Eventually, I just stopped filing bug reports.
Things aren't better with OSS, either, though I resent went bugs get closed because they're old.
Our policy with D is we never close bugs, no matter how old they are, unless we fix them or no longer have users for it (like D version 1).
I'm picturing the guy who came up with this idea sitting at his desk surrounded by unopened bills.
Besides, I once got Oracle to fix a bug. It took months and I basically had to spell the fix out to them, but it actually is possible.
A few months ago, one of our young devs got a PR accepted to fix a tiny little Spark bug that had been bothering us for a while. The big boss meeting was happy, plenty of virtual pats on the backs and congratulations.
And then someone had to go and ask when we'd see the fix in our DataBricks cluster.
In my experience, the big difference is buying software (good luck with getting Microsoft fixing a bug in office or windows; no one even tries) vs buying a service. If we bought specialized custom software support for some expensive hardware, those companies jump when there is a question.
I know that’s what management believes but in reality it’s a complete illusion. I can’t recall a simple time where we got a bug fix within reasonable time from any of our 6, 7, or 8 figure software vendors. You get fixes only if you have paid for custom code but tickets against the actual product disappear into the void.
Reading between the lines of your questions: I'm not throwing spears at the lib maintainers; I'm pointing out that relying on 3rd party code may cause complications. In my case, I made a decision on each individual lib.
hahaha, you so funny
Unless the OSS in question has an enterprise support subscription that is useful, the best responsible actor for OSS projects is all (or a subset of) your employees. They know your workload best and know the issues that affect you most and can learn the skills needed to improve the OSS that you use. Having a diverse set of companies contributing to an OSS project makes it suitable for a more diverse set of use cases and circumstances.
We all see ourselves as the rare exception, the one bucking the status quo and doing things differently.
Quite often your efforts aren't visible to everyone, but it's visible to some and they're thankful for it!
Its really, really easy. If you think weekend courses are going to be too much because you remember Engineering in college, I can tell you from experience that they won't be.
Ford is facing huge challenges as the entire industry has to pivot to battery powered vehicles and they want to get rid of their best and most experienced people?
This will not end well for them. I'd be just the opposite and try to convince these folks to work until 75!
They wanted to fire the most expensive people. In union shops seniority tends to go in hand with higher pay.
And I'm guessing their thinking was that the closer someone is to retirement, the more likely they are to accept a payout offer.
I was a fairly good programmer when I was 25. I'm a MASSIVELY better programmer at 57 than I was back then. My memory is a bit worse, and for certain kinds of problems, I may be a bit slower than I was at peak (maybe around 42-47). But hire me now, and you'll get a better programmer than you would ever have gotten from this body in the past.
And, guess what: no kids to take care of because they've already grown into fully fledged adults and lead their own lives.
I think it's on the downward trend though.
Where I work, more managers than not used to be an engineer, and the younger they are, the more likely they're going to used to be engineers (or straight up converted).
If everybody went to the same handful of colleges, is roughly the same age, and lives in the same trendy suburb, it doesn't matter what color they are. That "diversity" is literally skin-deep.
‘I have a family, how do you guys adjust cadence for people with outside commitments - eg let’s say I need to leave every day at 5’.
Gah, there’s no way to ask without setting off the alarm bells with these bastards.
I can't say for certain whether that's cost me a job before, but I'm also probably not missing much if that's the case.
This is actually the problematic mindset I'm trying to avoid. I don't want to work at a place where leaving at 5 is "adjusting cadence." I want to work at a place where management sets appropriate timelines, and we work hard to meet those timelines -- during the work day. The company I work for right now has a culture of work hard 9-5 then disappear. It's great.
The key thing is really BATNA because that gives you the confidence to say what you've gotta say.
That strikes me as a good indicator that you probably don't want to work there. Why is it unreasonable to ask if you are regularly expected to work more than 40 hours per week?
This is also a form of ageism. Ask questions to find out how people act rather than relying on their age as a signal.
Don't dismiss a younger person's ideas as naive without consideration, just like you shouldn't dismiss an older person's ideas as outdated without consideration.
Being older doesn't automatically make you correct, but neither does being young.
Thankfully, there are companies out there which do value older workers and will make the effort to encourage a more diverse/inclusive working atmosphere.
And when a woman joined the team, well, there wasn't any sexual harassment or sexism. But don't turn your back on her when she's got a nerf gun...
automate whenever possible.
“They” want very cookie cutter people. The more you try to control things, the fewer pleasant surprises you get.
It's also a lot easier to get hired by people who are older than you as they don't have the same biases against older devs... but at my age there are getting to be fewer and fewer folks older than me as they're retiring at a good clip.
Indeed. I’ve been in the too while executives at a large, publicly-traded company denied specific hiring requests because their LinkedIn profile pictures “looked too old”.
On the other hand, that company was terrible to work for many reasons. They weren’t excluding older developers because they thought they were less knowledgeable. They were excluding older workers because the company knew they couldn’t trick them into working 12-hour days and putting up with abusive management practices. Young people could be convinced the bad things were normal. Older devs knew better and wouldn’t stick around anyway.
Being only in a senior role that late in life itself is a red flag.
More seriously I think something that can happen with older folks is they might fall into working in a single place with a single set of tools for a very long time so when they transition to something different it may be hard to adjust. Not necessarily because “they are old” but because if they did one thing and only that thing for 15 years it’s hard to change.
Thus at BigCo, hiring senior devs of advanced age should make sense to do.
s/a staff engineer/architect.
sometimes it's just junior, regular and senior programmer
I had an older employee in his 60s work as a dev even as he was slowly dying of cancer and receiving treatment. He showed up every day, doing his work, proudly contributing code even at deaths door, until his last day. He had worked 30 years in IT and was a senior dev and there was nothing wrong with his productivity, attitude, etc.
I was blessed to know him. I hope you find strength to open your mind and realize there are wonderful people of all sorts and ages all around you.
I’ve worked with amazing devs and hardware engineers from every age, including 50 and up. I’m guessing your experience with older devs “having a complex” was part of their response once they realized that you are just an asshole. As competent and experienced professionals who have dealt with many assholes before you, they adjusted their dedication to your project to reflect how little they cared about it once you became part of their job. They did enough not to feel guilty, but not so much that they risked working with you for longer than it took to find a better job.
I also like your story about me, because there isn't a single person who works for me or with me that would describe me as an asshole. I'm just an asshole to morons in denial on this flaming turd of a "tech forum". If you don't plan for your expiration date in the programming trenches, then you won't see it coming when it hits you hard.
There's a reason the average age of a programmer is 39 just like there a reason why the average age of a construction worker is 38.
> I also like your story about me, because there isn't a single person who works for me or with me that would describe me as an asshole
If that's true, it's because you play a different character in person. Tell them about how you are "an asshole to morons" on a "flaming turd" of a tech forum, and how amused you were at the example of a terminally ill cancer patient continuing to work as evidence that old people can develop software.
Taking the industry as a whole is representative of a typical career path. If your narrow point is that people who have entry level positions are young, well, of course.
If you've got a better dataset than the BLS, I'm sure there are many people who'd be interested, and you should share it.
...to your face. But you have no idea what they privately think, or say to each other when you're not there.
(I'm with GP, I too guess what they think isn't what you think they think.)
Even if you are really good, you will not get promoted if you came for a non-wealthy background.
Why pay twice as much for an experienced developer when you can get a fresh new grad that is "just as productive"? Companies often ignore the fact that there is an experienced Senior Developer sitting in the corner telling that productive Junior Developer what pitfalls to avoid and how to get things done.
So the average manager doesn't actually know how to judge productivity. I don't think they think they know, and just are mistaken. I think they know they don't know. So what do they have to go on? Pay, and conformity with their own set of best-loved personality traits (called "cultural fit").
Besides the ageism thing (because I'm still relatively young so it doesn't, admittedly, affect me) I've noticed the same exact thing about cynicism. If you're always angry you will eventually only see reasons to be angry because no one else will keep interacting with you. Similarly, if you're a cynic about everything you will soon find yourself in an environment that only reinforces your believes because everyone else gets tired of it
For me it was helpful to get therapy for a few years from a “No More Mr. Nice Guy” therapist. You can search for information on Nice Guy syndrome & Dr. Robert Glover.
I’m definitely not saying that this is your issue. I’m only saying you might want to check it out.
Joining men’s groups helped me, too.
I've been saving aggressively for retirement for just that reason.
Learn the people patterns. Every where I have worked has at least a few, if not all, members of Typical IT Cast Of Characters. There is the "know-it-all-but-does-not", "wise old sage", "management climber", "new guy", "one-job-and-doesn't-want-to-change", "hockey-jersey-guy-who-smells-but-knows-too-much", etc. Pick your own. Most of these people will avoid, tolerate, get along with, or maybe love the others. Or some combination thereof. I have found being the impartial mediator to be advantageous. Be the "Ferris Bueller".
Know the business as well as the tech. Technologists that can dive into the business language and work with both groups are invaluable.
Diagrams. Work hard on developing the capability to express ideas/concepts/flows in a diagram that fits on one sheet of paper. Do this all the time...even for one-offs. As the author states, it helps build your brand. It's advertising. When I see a one-pager I did 6 months ago on a desk covered with coffee stains, or pinned to the wall above monitor...I know I have made an impression. I worked with a few masters of this craft, and honestly, they are all magic on any team.
Share credit constantly. Don't ever appear that you need validation. Give good ideas away for team members to catch and grow. You will build a community around you that seek you out for guidance. Time passes quickly... that junior dev you credited for a schema re-jig 5 years ago is now a VP at BigCo. She didn't forget. Keep in touch, right?
I don't follow. Which characteristics of Ferris Bueller are you suggesting to emulate?
Any advice you'd like to share regarding this?
These people are hard to find...but you can (as I have) try to emulate them. I can suggest some books...I started with Edward Tufte's. Beautiful diagrams...and why they are beautiful. You can also look into the various "Napkin Books" from Dan Roam.
When I find a particularly amazing diagram, I keep a copy of it for reference. It helps me structure ideas and how I will communicate them to my leadership or my team. You can, with care, put an awful lot of data on a single page.
Again, make a lot of diagrams. If a concept, workflow, procedure, etc moves from unknown to known (mechanism by which this happens is not important) , draw the picture and send it out. If it never gets used again, at least you practiced the drawing and people know you can do it. Develop a style. A color palette. Certain styles of arrows. The list goes on.
Tooling: I love Visio. Damn, it's a fun tool. There are a few web-based tools... Omnigraffle, Lucidchart... not as good. At least for me. You can bang stuff out fast in Powerpoint, too. I keep a big pile of templates that I have massed over the years. Never used photoshop...not even once. Although, I keep inkscape and gimp around if I have to muck with actual images...but I really try to avoid that.
I've had two employers where this skill was highly valued. (I even had a boss at one, who did his diagrams in effing MS EXCEL - not pretty, but often simple and effective). Most people wouldn't think of using Powerpoint, but in fact, as you say, it's a particularly effective tool. At least for relatively simple ideas.
Then I've had a couple of employers where absolutely NOBODY gave a crap about diagrams AT ALL. (as in, nobody ever did them, and everybody was constantly confused about what we were even doing). Any diagrams I encountered were halfhearted attempts and incomplete, and almost always out of date by at least a year. I tried to fill that gap but it just wasn't in the culture there.
I'm at a new place now that seems to have a better culture and I'm hopeful.
Did you mean _Beautiful Evidence_?
I also think diagram skills are impressive but almost every time I try to get my understanding into a single page diagram I just gets lost along the way and the resulting diagram lacks just One Thing to make it really illustrative but I can't pin it down.
I know exactly what you are feeling trying to get that One Thing. It's what separates the good stuff from the great. I don't try to show everything on one diagram... even if it fits contextually. If you force people to have to think too much when they try to unpack your diagram, they lose interest. Draw, edit, adjust. After many years, I have a few "general starting points" in my head, and go from there. I still need to edit a lot...but I get there faster these days.
This is huge. I am the most senior dev in an organization of about 40 and one of my favorite things to do is to take an idea and hand it over to a junior dev to run with, then completely give them all credit. It is a huge boost to their confidence, they appreciate the gesture and public praise, and your bosses are well aware of what happened even if you never say anything. Amplify your impact by lifting others up.
I'm 59, and have been out of the "market" for the last 4 years. I have no intentions of ever working for anyone else again. I'm fortunate, in being able to do that.
What did it for me, was the atrocious way that I was treated, when I went looking for work, after leaving my previous employer; just shy of 27 years. I stayed that long, not because I'm a "clinger," but because I was damn good at my job, and they valued me.
It seems that us "olds" are not popular. It appears to be personal and emotional; not based on any empirical data (Did I mention that I'm actually fairly good at what I do?). Quite strange, in an industry known for its data-driven approach.
It didn't take me long to figure out that the current environment does not want me around. I won't go, where I'm not wanted, and I'm incredibly grateful to have the means to do this. I am quite aware that most of my peers do not have this choice, and it hurts my heart to know that they will spend their final years of employment, being treated in such a shoddy manner.
But that won't stop me from working. I just had to set my own agenda. It's coming along nicely. I tend to develop rather ambitious stuff, and the last few years have been fun. I would not have done it, if I hadn't been pushed; so I guess it's all good.
What I really enjoy doing, is writing code for free. The kind of code that I write, on my own, is precisely the kind of code that most modern corporations don't want.
I take Quality very seriously, and that's actually an impediment, in today's coding culture.
Seriously, what the fuck is everyone’s plan?
Mine is to achieve financial independence by living well within my means, saving a lot of my take home pay, and investing that savings into index funds.
Having that basis of financial security will, at some point, allow me some freedom to consult at my leisure. In the meantime, it gives me the freedom to leave a job if it turns out to go south.
Bingo.
If it all goes down the drain, I am quite capable of doing a whole lot of stuff.
The classics are always a good bet.
Capitalism has a way of doing that, in spite of its momentary lapses and corrections. (Wish the same was true for health care.)
Index funds are a good way to make sure that someone else is getting paid to do the hard work of investing for me.
I'm cautiously optimistic.
If the typical person works for 50 years, and you saved/invested 50% of your income for 25 years, then you’ve effectively matched both the means and the cost of living of someone making half your salary.
As a software developer, it isn’t unrealistic to plan to retire around 45, for example.
For myself, I love developing software. The design, problem-solving, coding, testing, but, most importantly, seeing folks use it, and knowing that my software is A Good Thing.
For most of my career, I was a manager in my "day job," which meant that my tech chops were barely exercised.
My company didn't have a "shower clause" in their employment contract, so I could work my own gig. I deliberately avoided making money, and I also deliberately avoided writing anything that could compete with my company, or make them look bad (Which I easily could have). It was a matter of Respect (for me).
So I did open-source stuff, for over twenty years. I developed a fairly robust system that has become the de facto world standard for a particular demographic, and a few apps and whatnot, around it.
I have also developed a whole slew of SPM modules, which are really high-Quality. I use most of them, myself (eat my own dog food), so their Quality needs to be "top shelf."
I wrote and released over 20 iOS (and Watch, Mac, and TV) apps, since 2012, but I'm down to just a couple, nowadays.
I'm writing a fairly ambitious native iOS app, right now. It's the frontend for a fairly intense set of servers. I've been working on it for a year (and an additional seven months, writing one of the servers, and the other server is the one I mentioned previously -I've worked on that for over ten years). I feel that it is just getting to the point where we can start refining the UX. I have been establishing the infrastructure, to this point.
That's where my heart lies. I'm actually a very good manager, but I don't love it, and don't miss it.
There are a lot of IT jobs in non-FAANG companies that place more value on experience and domain knowledge, but they're not as glamorous or high-paying. Midwest companies, or places like banks/insurance companies. Stable companies that tend to change at a slower pace.
This can be good or bad depending on your personality and professional drives. I've always had a bit of paranoia about job security, but looking back, that's usually been a result of imposter syndrome.
The one thing that has helped my career tremendously is being generally agreeable. No one likes to work with the asshole rockstar, but someone who is easy going, shares credit and helps keep everyone as positive as realistically possible is valuable. Just make sure your boss sees this in you.
I hope that they were able to get help, because early back injuries have a habit of coming back to haunt you, later in life. I have a bad back from a tweak I did, when I was 18. Nowadays, it is an entire new universe of pain. Back then, it was just a little twinge.
Don't ignore back pain, get that taken care of.
I don't know any US tech people that get a company car.
The base pay tables: https://www.igmetall.de/download/docs_MuE_ERA_Entgelte_Juni2...
(Edited to add) and at least the rates for Bavaria are for a 35 hr/week contract. Multiply by 1.14 to find the rate for a 40 hour contract.
Health insurance is not the single-payer utopia some in the US make it out to be, but the public option being default puts a check on the private insurers and even full retail medical costs are usually much lower than in the US: my c-section plus 3 day hospital stay would have been about 5k EUR.
Having my “happy surprise” baby at 40 in the US would have killed my “retire at 55” dreams from fear of college costs. Here, it merely delays it a bit, because we’ll need to pay his living costs for a few more years, but not monstrous US-style tuition costs.
There’s a correction in the offing, but of course, I have no idea when it will be.
I won't wake up tomorrow and suddenly be black or latino. I probably won't turn gay (I've had my chances, and ignored them, so I'm stuck in boring old Heteropolis). I probably won't wake up a woman (although it is -technically- possible).
I will, however, wake up tomorrow, one day older than I am today.
We all will (God willing).
I'm not sure that folks are realizing that they are setting up a system, that will, sure as the swallows return to Capistrano (until climate change alters that), end up being the petard, upon which they, themselves, will be hoist.
It's like Robespierre, and his fun toy.
I'd be interested in hearing what you think these personal and emotional factors are.
So much of career advancement is shared social & cultural values and norms, and we're out of sync with a workforce that skews significantly younger.
But I won't get into it. Anger breeds anger. I am not stereotypical anything. Most folks, here, seem to develop an entire personal narrative of others that post here, based on one or two posts. I have the habit of doing that, as well, but I deliberately ignore it, and explore the HN profiles of folks that interest me (or attack me). I generally find out that we actually have a lot in common. Sometimes, I have even made friends with people that started off, hating my guts.
I'm a weirdo. I don't really fit any templates out there -even good ones. If people get past the age thing, then they generally seem to think that I'm "hiding" something, or being an overbearing ass.
Might have a point. My ass has become more overbearing, as I have gotten older, and I believe that most folks prefer that I keep it hidden. It's not pretty, when I show my ass.
Other leaders love having experienced talent around. But if a leader doesn't want me, I honestly see it more as someone who has their own issues to work through, not a negative statement on my talents.
I don't think that's true. I think you're conflating ageism with bias against someone who worked at one place for a really long time.
As a hiring manager, I'd be excited about talking to someone 50+ and the experience they can bring to the table, as well as their unique ability to mentor me as a manager because they have so much experience being managed.
But I'd be wary of someone who worked so long at one place, because I've worked with people like that, and it usually doesn't go well. They tend to believe that the way things were done at their last company is the only way things can be done. They were so senior at their previous company that they always got their way simply because of their seniority, and do not have a lot of experience being the new person.
Someone who worked that long at one place would have a high bar to clear, because I'd need some pretty solid proof that you worked on projects that required you to learn new skills, that you had experience working with different groups of people and different managers with different styles. All of these things I can assume are true with someone who has had multiple jobs.
And lastly, while you have a lot of experience, it's not a diversity of experience, at least not like someone who has worked at more places.
So all told, I'd rather have someone with 30 years of work experience at four or more companies than someone with 30 years of experience at one company.
>> , I'd rather have someone with 30 years of work experience at four or more companies than someone with 30 years of experience at one company.
Experience means depth and/or breadth, so what you're really saying is "I want someone with 30 years experience, not 30x 1 year of experience. Multiple companies increases the odds that they'll at least have breadth".
This is a valid strategy but still a bias. There was a time when many people worked at the same company for their entire career as the desired path, not some form of settling or indicator of limited skills. It's only a generation or two that has not experienced this.
No one ever seems to follow any of the many links in my HN profile (except, every now and then, I get spammy LinkedIn connection requests).
As it turns out, I happen to have a wide variety of experience, but one common factor, is that all of it has been focused on shipping software (even my side work).
So, yeah, I guess I am a "one trick pony," but that one trick, is a lifetime of ship. I've heard that can be useful.
I'm almost always 'the new person', and have rarely been on projects more than 2-3 years. I operate as an independent - sometimes solo, sometimes with a team. Most team projects have not gone more than 2-3 years, some solo projects have gone longer - 4 or 5 was about the longest. The pace changes over time - initially a lot of work, then some transition to maintenance, slower feature rollout, etc. Then... another project comes along, and ... you're "the new person" again, with more experience about what's worked and what hasn't.
I can not imagine working one place for 27 years. It boggles my mind. I've had to learn to accept that I will never get one of those '20 years of service' plaques I saw on TV shows as a symbol of "the company man" sort of thing. It's just not possible. I have had 20+ years of self-employment, in spurts, although the last round has been going on 13 years now.
I also agree with the personal brand section. It's part of the reason I was so argumentative. I worked on internal tools that people were forced to use and some of the stuff that was done was hated by many. I was really worried that my association with the project would ruin my brand/reputation. So I would always argue to try and fix things that people hated.
Eventually I gave up and started writing greasemonkey scripts to make things more usable.
You can be put in a situation where you've got an approach that works but you have been overruled to use an approach that doesn't (assuming of course genuine best efforts to make it work, otherwise you're the problem). If you are the person on the spot in a critical business situation, you've got a choice, do you risk your job for doing what works despite being explicitly told not to, or do you risk your job anyway and the security of your team and company by executing a destructive sequence because you've been told. I keep reading lots of examples of these situations, especially in military non-fiction, where people go either way. In these rare situations, if it's your finger pulling the trigger so to speak, I think you have to do the only thing you know is right. And maybe dust off your resume when you get back home.
Relatedly, I use a very similar analysis when giving tasks to junior engineers. They almost always want to do something that isn't exactly what I would do, for a whole bunch of obvious reasons. Sometimes I need to override them, but it's a complicated analysis that sums up to what you wrote above. I will even sometimes let them do something that I think will lead to some negative, but recoverable consequences, because the best learning is from your own mistakes, but to learn from those mistakes you must first be allowed to make them. I just have to make sure the positives of learning outweigh the possible issues the mistakes could lead to. And sometimes, I'm wrong about whether it was a mistake or not, of course. :)
An example of something I'll generally override regardless is a security issue, because the consequences of that can get pretty negative. But merely layout out the code with the IO & business logic more tightly coupled than I'd like is something I may let slide, especially if they're going to end up having to write automated testing for it anyhow.
When I do let something go, I generally give a heads up about what negative consequences I expect may transpire, and then let them do their thing. I think that in general, "wisdom" can't be taught in the conventional sense of the term, but I do think you can sensitize people to the existence of certain patterns and accelerate the process of acquiring such wisdom as a result.
But, to take it a step further: If someone wants to do something a certain way that I don't agree with, I give them my professional opinion, and then I tell them that it's their task, and overall I trust their hands-on opinion more than my hands-off opinion.
Saying: "I understand that you disagree with my plan but for this one I am asking you to disagree and commit so we can move forward" is surprisingly effective when used from time to time.
I have been burnt by two people padding their resumes before jumping out of the company. This caused me to rethink the "Two and Done" rule at higher management levels.
So always follow up after a "two-and-done" experience to see if the people who argued against you are suddenly disinterested in the entire project once they've won the argument, and do it your way anyway.
I've watched far too many people over the years get sucked in by the monthly payments on a huge house, luxury car, etc, and while they can pay it, there's no slack in their budget and very little in the way of a buffer. I've also watched a few people go from $hugenums to $reasonablenums for income, and if they've lifestyle inflated their way to consume the $hugenums salary, welp. Doesn't go down well - the BMW dealership doesn't particularly care about your salary problems, they care about your loan/lease payments.
If you can keep your spending down, and build a buffer, you've got plenty more options than just "not missing a paycheck."
I don't think anyone here is saying "Don't have a car." Unless you're in a situation where that makes sense.
I'm certainly saying, "Don't go lease a luxury car when you need a car," though. Get reliable transportation, if you need it, but there's a large gap between "reliable transportation" and "luxury cars." Spending $10k on a car out of college that will last you another 10-15 years is entirely sane. Spending $100k on a car because, hey, you got your tech job and now you can have the fancy car, is stupid.
The health that needs to be coupled with wealth to be free is also decaying over time. The things you'd enjoy at your 30s, 40s, 50s, and 60s are also going to be different.
You can't optimize for only what you'll enjoy in your 60s and you can't really store up freedom.
It's not too hard to beat inflation. Yeah, you do have to expose yourself to some risk, but it's really not hard to know enough about investing to make your wealth grow over time.
That 20% risk needs to be properly accounted for somehow.
> General inflation
Average market growth is higher than the average inflation per year. I trust that investing in the market and holding a percent of your portfolio in Treasury bonds will give you a very good chance of growing or maintaining your savings against inflation and market variance.
There are several problems with this analysis;
1) You're making a 50+ year forecast (depending on your age) based on a 100 year data, a prediction ultimately not based on first principles.
2) Ultimately average inflation doesn't matter; the specific things you'll need to buy matter. You can enjoy the lowest CPIs in the world and still get shortchanged if you need to buy a house in the Bay Area at the end of a boom.
3) Lifetime averages might look good, but not all years of your life has the same wealth sensitivity; e.g you can postpone getting into a mortgage in your 30s but can't really postpone unexpected healthcare costs after 50s without lifespan altering consequences. The aim is not maximizing your returns until the day you die, it is to have enough when you need it throughout your life.
I'm not saying you're going to be necessarily wrong, but there is a risk of overemphasizing the predictive power of past performance and understating outlier events.
By the way, economies can fail in more than one way, e.g. markets can't really beat hyperinflation, which is a salient risk today depending on how covid shapes supply/demand curves, and in stagflation markets would suffer in addition to inflation, which is an outlier risk but a risk nonetheless. Sure, any of these would resolve in a decade, but during that decade you're going to be faced with purchasing decisions that you can't wait out, hence the melting of your ice cube.
Keep your lifestyle small, kids - perhaps take a look at what other lines of work with similar education requirements pay as a guideline; say, a mechanical engineer with a bachelor’s degree. Buy that car with cash, or at least one you could pay off with cash on-hand/in a non-retirement brokerage account.
Instead:
- it's okay for getting laid off to suck in the hours and days afterwards
- it's also okay to be totally fine and get another job right away
- be loyal to people and missions, never to companies
- do not tie your identity to your employer
- you're allowed to do things differently next time: you don't have to find someone who's identical to your ex, you don't have to choose to ride a bull instead of a bicycle, and you're not limited to working for companies with a similar culture or business model as the last one
- at the end of the day, an engineer who gets laid off is probably going to get a bunch of severance and go back into another job pretty soon, so it's unlikely things are as bad as you think they are
[0] of course, many people don't ever have bad breakups or get laid off, but expecting the best case can mean getting blindsided by the worst case
I am correct, A LOT, when it comes to technical decisions, strategies and the Right Thing To Do™ but that does not mean that my decision is Right For The Business™.
I do not have the full view into what my others see.
- I do not see the CEO getting pressure from investors, board members or customers.
- I do not see the Head of Development dealing with not having enough people to get work done, budget issues or other critical issues that I am not involved in.
- I do not see the Development Manager dealing with people that are having struggles and thus not getting enough work done.
And in those situations this rule doesn't apply.
I excel at and enjoy programming. I always have since I first learned on a PcJr. I have been a Team Lead, Software Architect and other roles but I would like to stay employed as an IC as long as I still enjoy it.
Ageism is a thing. I believe this "personal brand" strategy is the way forward.
While it may be possible to pull off a jaded, "I've seen some shit", "get off my lawn" attitude, it will probably make everything more difficult. I try to keep a positive attitude and avoid being the guy nobody wants to work with. This, combined with a mountain of experience, will hopefully keep me gainfully employed so long as I still want to be.
I think I'd just rather make less money. It's not just that I dislike selling myself. I actively cannot respect people who are taken in by such an approach.
I look at each new JavaScript framework, "SQL sucks, no wait, SQL is actually great!" passing trend in the industry now and on some level it can make me miserable. But I try to not let it bog me down and take my whole attitude with it.
To be honest, this is an advice for everyday life, nobody likes a drama queen or a energy vampire around them.
When a new opportunity or problem comes up, do you want to be the engineer that many people dread talking it over with? Or do you want to be the engineer that makes people (at least slightly) excited to discuss something with?
Do you want to be known as the engineer who sucks energy out of the room in brainstorming sessions, or the one who can help the group "see around corners" either from your personal insight or from fostering a sense of directed curiosity within the group?
You're right that it's not necessarily the best programmers who create the most value/make the most money for themselves, but I don't think the counter position is "you have to become a giant phony and sell yourself".
My boss/CEO once told me "You can't have this shitty attitude if your stuff doesn't work" (or something similar)... I made sure my stuff worked after that. Although, my attitude was really only bad with him, IMHO; everyone else seemed to think I was nice to work with.
It's a hard to picture a situation where that's the right thing to say though. Unless you were exceptionally insufferable.
Certainly some back and forth earlier there, I wouldn't argue that I didn't have a shitty attitude with him. Being charitable, he had an aggressive management style that I didn't apprechiate, and as a mostly autonomous worker, I chose not to do a fair number of the tasks he wanted me to do. Otherwise, my stuff tended to be at least as reliable as the rest of the system, except my stuff relied on external services / user input.
However, ageism, aka Age Discrimination(tm) is real in technology as I'm sure it is in other disciplines. I'm sure many will say, "don't suck" and you'll get hired. Remember your words/thoughts after you reach the final "culture/fit" check after jumping through every flaming hoop put in front of you during the interview process, and then suddenly, after all the glowing feedback the 30-something VP of Engineering or Paper Clips makes your candidacy flatline.
I was hired by Travelocity 1 OCT 2007 as a designer. After a couple of months of doing no work I was involuntarily reassigned to a developer position. I had to learn to program. I had to figure it out from nothing. It turns out designers and Java developers were a dime a dozen, but the business couldn't hire competent front-end developers to save their lives.
I finished 2008 with a negative annual review. My manager had to intervene to raise from review to a higher level than catastrophic failure. Keep in mind I was learning to program from nothing on the front-end of a billion dollar website. Some areas of that website had limited or no safety controls to prevent you from blowing things up at the click of a button.
In 2009 there were massive layoffs. Despite my abysmal annual review my job was safe. I mean super guaranteed safe in a special HR bucket labeled CRITICAL, DO NOT TOUCH. There were people with tremendous tenure and even directors and vice presidents that were being laid off. Some of these people walking out the door were rising stars in the company but every team was impacted, for fairness, using quotas.
At the end of the day it was clear performance was only a minor factor in whether you kept your job. More important was critical need. The didn't layoff the very few database people that worked there. They didn't layoff the front-end developers. They didn't layoff the people who monitored critical infrastructure. In each of those critical roles there were only a tiny hand full of people (count them on one hand) keeping the lights on. Travelocity's primary business is a website and you need those few people who maintain that billion dollar website.
This sort of thing started in the eighties with Thatcher and Reagan. It's why I have never felt guilty about having a mercenary attitude towards work.
I had a very notable team member at my last employer who was an exact picture of everything opposite to that. He was a complete rock star, always the person called in to put out any fire, always being moved around and temporarily assigned to augment whatever team was having the most trouble. He'd been there longer than anyone else and personally built out a whole lot of bespoke automation tooling with no peer review, no documentation, and no one else really understood it. That specific program really might go under and the company would lose an enormous contract if he ever left.
But is that really a good thing? The only reason they're in that situation is because of the way he works in the first place, combined with outdated processes where the management and senior technical leadership is so narrowly blindered by their focus on user-facing features that they have no awareness of what is happening in the realm of platform and developer automation tooling and how reliant on it they are.
This is a conflict between individual and organizational rationality. And I don't expect individuals to solve it or blame them for being individually rational at the expense of organizations. By all means, keep up the hustle and do what is best for you and your family. But man, there has to be a better way to accomplish collective action.
I don't see any conflict here. I am not and 'the organisation'. I am hired by one to do a job. I lookout for myself first of all. I am not paid to protect 'the org', and lets not kid ourselves 'the org' will NOT protect me. So why would you put org before you?
The way I see it is that you got some goodwill from peers and mgmt but you consciously made yourself replaceable. If mgmt knew you documented all you workload and an intern could just waltz in, read through all docs and do what you do for 1/2 the salary - you will be out on the first bus.
The 'super star dev' - if he goes the business will hurt. Mgmt cant afford let him go.
If I were to pick a role I would definitely go with the 'star dev' over you.
Mainly because they can negotiate his pay as he has leverage. Also they don't have to play too much of office politics as they are in position of power already.
Just last week, I reiterated to execs that part of the job of an engineer is to "document themself out of a job" (regarding documenting designs, code, processes, etc. so well that other engineers could take it up). An earlier time, when I mentioned that more verbosely, I asserted that the kinds of hires who will do that (automatically, or by embracing the culture we nurture) tend to be the best engineers, and the most valuable to the org.
This goes against old advice about job security for some people, like "be the only one who knows how to do that thing the org thinks is important". And against more recent job security advice, where job security is about hopping between orgs rather than investing with one. Popular contemporary gems of advice seem to include "let your project be guided by your resume keyword goals, then hop to another company for a salary bump in 1-3 years, before the chickens of your misaligned work come home to roost at the org." :)
I can't say that everyone will recognize when an individual invests in working for their colleague/team/org rather than solely for themselves. But, besides on-principle reasons for doing that, some people will recognize it, especially people who do it themselves, and those are some of the people you probably most want to work with.
>'the org' will NOT protect me. So why would you put org before you?
This kind of thinking. . . would you set off on a horseback ride and NOT feed your horse?
I would defend my current company because I have relations to the people working there that make up the company as a whole. If you expect blind obedience, I probably would leave for another company.
You can be a team player in order to make your life easier and others that work with you. But laying down all of your cards on the table leaves you vulnerable to exploitation by less scrupulous people.
What I was critisising was a view that you as a worker should think of the wellbing of organisation first and foremost. Its a slippery slope that can lead to harmful outcomes for the individuals.
There are winners and losers. I think he definitely won.
If you ever find yourself in an organization that is full of "rockstar" or cowboy coders, it's often easier to get out and find something better, than it is to fix that broken culture.
>But man, there has to be a better way to accomplish collective action.
I've always said that the main purpose for programming languages is for engineers to communicate intent to other engineers. (including the original author; who may have lost that mental context 6-12 months down the road).
If programming languages were only about telling computers what to do, we'd all be coding in assembly.
Damn. That is pure gold. Thank-you. Get this on a t-shirt or something, would you?
This is the one point I think you have to be really careful with. Only ever do this when you have thoroughly investigated and concluded beyond any doubt that the crappy inputs you're given are beyond the control of your manager to fix.
I haven't counted but I swear most people I meet could work 50 % as much and get just as much done if they would just get their broken situation straightened out. There is so much wasted work poured into weird problems "beyond our control" but which really are fully in the control of the worker's manager.
The leading cause of this wasted work? The person doing the work "doesn't want to be seen as one who complains" or "doesn't mind the extra challenge."
But what about the time/money you're bleeding in the process?! Sorry, this is one of my pet peeves.
Example: The CTO really wants the table on the careers page to render the text color coded by the age of the job posting. Will it be easy to do this? No, our table text color is hard coded so we will have to rewrite the table module from scratch. Is this of any value to any paying customer or job applicant? No, no one cares about the text color.
But, after you have advised management it may not be valuable to your users and it will be very time consuming, you better hop on board the table text color train 100% and ship those stupid table colors.
One of my favorite quotes that illustrate that is from the movie Boiler Room.
“There is no such thing as a no sale call. A sale is made on every call you make. Either you sell the client some stock or he sells you a reason he can't. Either way a sale is made.”
Unfortunately this failed me hard. I realized this after recently getting several rejection (at the screening level, not even the interview level) for reasons I can reasonably extrapolate “other candidates have much more relevant “experience” than you, quotations denoting professional experience, as opposed to some shit I put together on my own.
It kinda dawned on me, that instead of wasting time working on things I was curious about or that interested me, I should have instead been working on things I’m not particularly interested in, but are in demand.
For me it's multiplayer games, game engine architecture, computer architecture (built my own 8-bit computer). Learning Rust recently too. I get really excited about solving hard problems and bugs.
If I have to work for a boss to get paid, there is no way I would also spend my free time on projects just to impress some people. I got a little money buffer and no family though. So this attitude might not work for others.
"Fall in love with some activity, and do it! Nobody ever figures out what life is all about, and it doesn't matter. Explore the world. Nearly everything is really interesting if you go into it deeply enough. Work as hard and as much as you want to on the things you like to do the best. Don't think about what you want to be, but what you want to do. Keep up some kind of a minimum with other things so that society doesn't stop you from doing anything at all." - Richard P. Feynman
Generally, me neither. However this attitude does not meld well with a stagnate career.
For that matter, why do some genetic disorders reliably correlate with having only a set of narrowly defined interests, or no persistent interests at all? What does an "interest" even mean at a biological level? Are we always in control of what we are capable of caring about and acting towards, separate from what we merely tell ourselves we want?
It's refreshing to see advice dispensed from years of experience while also maintaining a tone of humility.
And, I will say, these tactics are somewhat inversely effective when correlated against the disfunction of the organization. His point about getting fired even though he (made his boss fear + made his boss happy) tells me that in that organization there was a lot of disfunction.
All organizations are bureaucratic and disfunctional to some extent, but in the really bad ones, I saw a lot more Machiavellian tactics that were successful.
In the worst organizations, it feels different tactics are needed: look for nepotistic relationships with your "tribe," write terrible code that no one understands, or do something like that.
These days I use javascript, vue, node, etc.
6 years ago, I was pretty much only a Linux guru. Good at that but not much else. If I didn't get up to speed on these new platforms, I'd be toast.
I find the latter to be tedious. No matter how similar or far apart they are from the previous iteration of the same tools, learning to use new tools slows down the productivity. It gives quick learner a false sense of comfort without added benefit of experience. Everyone wants to have something shiny to play with at some point, but this constant flow of reinvention makes it tiresome for anyone that has not encounter the limit of an existing system.
I might be biased as my current place has thrown away 2 code base (one in Java and one in PHP uncool languages) and the expertise which goes with it to embrace micro services powered by python. It's been two years in the making and the new product is just barely an MVP, now overdue by two quarter. We have bled decent developers and the impact is quite noticeable when it comes to domain knowledge.
Lastly it felt that some of my former colleagues have treated this job as jump board to find greener fields and I fear this isn't something too uncommon in the field.
- It over-emphasizes the normativity of job security and not having missed a paycheck but if your calculus is at the level of paychecks in an era where developers are paid this handsomely, you might be optimizing for the wrong thing.
Financial security and job security should not be that tightly coupled for an industry that pays above average and where switching jobs every 4 years is not a bad thing. Ride the bull in the sense of riding the bull market and get a financial advisor, save up on that surplus and give yourself your own "paycheck"s if need be.
- It over emphasizes "be a good guy and go the extra mile for your boss" which is another way of saying be willing to be underpaid for the work done in the name of a fallacious goal of "not getting laid off". Having been in a massive, no-prisoners lay-off by a big name company early in my career cleared any illusion of control and loyalty.
You can sing all the songs and do the dances for your employer, if say the market decides asset/profit ratio is going to be a certain number, you're out. This is a harsh reality people find difficult coming to terms with and make superstitions around what might protect them from the wrath of the market gods. You can't, and that's OK.
- Branding; the transferability of your branding is overemphasized. Your purple-heart beyond-the-call-of-duty bug fixes is not likely to make it out of your manager's mind to your new recruiters. XX% of software engineers won't have any constant supply of widely applicable plus novel insights to blog about, and that is not a bad thing. Let your previous accomplishments, salary, level and title be your branding. We call that a CV and that does 99% of the work in a high labor demand market.
Note that it's called "The Old hackers guide" and he mentions he started in '86 (roughly about the same time I started in tech, I'm in my late 50s). Job security definitely becomes more of the issue as you get into your 50s. The handsome pay is usually going to the folks in their 30s. The FAANG corps that pay handsomely aren't hiring devs in their 50s.
> switching jobs every 4 years is not a bad thing
I've had a lot of jobs over the last 5 years and a lot of downtime as well. If I didn't have to switch jobs every year or two, I wouldn't as interviewing is awful at my age - once they see that you're "old" you definitely feel that they have no intent to hire you. Mostly I only end up working for people who are my age or a bit older as they don't have biases against people in their own age group. But my contacts are retiring and there are less people around the industry in my age group every day. At this point I'm considering myself semi-retired. Fortunately I'm in a position to afford to be semi-retired.
tl;dr: the view someone in their 30s sees ("aim for handsome pay") might be very different than the view someone is seeing in their 50s ("it's getting tough to find gigs at all").
I don’t deny your experience by the way, but without hard data isn’t it hard to say if people were rejected for age vs other reasons?
And I share the authors experience even with less years. I’m wrong more than I’d like to be, which is never.
[1] https://www.goodreads.com/book/show/260493.Secrets_to_Winnin....
Two is the right number for this, not three (as the blogpost points out).
Roberts Rules is another formalization of the two-points of discussion before moving on. Any particular debate can have at most, two times when any singular speaker gets to talk. After two tries, the speaker is silenced (to give everyone else a turn at talking).
Two times to talk is the right number, empirically. After that, you're beating a dead horse.
https://www.stickyminds.com/article/management-myth-36-you-h...
This is a replay of a comment I made a few years ago which strikes me as being somewhat timeless.
—————————————————-
I'm 60+. I've been coding my whole career and I'm still coding. Never hit a plateau in pay, but nonetheless, I've found the best way to ratchet up is to change jobs which has been sad, but true - I've left some pretty decent jobs because somebody else was willing to pay more. This has been true in every decade of my career. There's been a constant push towards management that I've always resisted. People I've known who have gone into management generally didn't really want to be programming - it was just the means to kick start their careers. The same is true for any STEM field that isn't academic. If you want to go into management, do it, but if you don't and you're being pushed into it, talk to your boss. Any decent boss wants to keep good developers and will be happy to accomodate your desire to keep coding - they probably think they're doing you a favor by pushing you toward management.
I don't recommend becoming a specialist in any programming paradigm because you don't know what is coming next. Be a generalist, but keep learning everything you can. So far I've coded professionally in COBOL, Basic, Fortran, C, Ada, C++, APL, Java, Python, PERL, C#, Clojure and various assembly languages each one of which would have been tempting to become a specialist in. Somebody else pointed out that relearning the same thing over and over in new contexts gets old and that can be true, but I don't see how it can be avoided as long as there doesn't exist the "one true language". That said, I've got a neighbor about my age who still makes a great living as a COBOL programmer on legacy systems.
Now for the important part if you want to keep programming and you aren't an academic. If you want to make a living being a programmer, you can count on a decent living, but if you want to do well and have reasonable job security you've got to learn about and become an expert in something else - ideally something you're actually coding. Maybe it's banking, or process control, or contact management - it doesn't matter as long as it's something. As a developer, you are coding stuff that's important to somebody or they wouldn't be paying you to do it. Learn what you're coding beyond the level that you need just to get your work done. You almost for certain have access to resources since you need them to do your job, and if you don't figure out how to get them. Never stop learning.
It really pays off to listen and stay open minded before you start enforcing best practices you've picked up from previous experience and assignments.
Give yourself the opportunity to actually feel like an impostor deliberately (if only for a brief period of time)! Really dig into the reasons why things are run a certain way before you propose changes: this will set you up for success and will attract a lot of goodwill.
I know this sounds trivial, but humility is an extremely underrated trait in tech, especially if paired with experience and the power to pull off change for the better.
Shifting political winds, bad manager, bad company direction, bad economy can all cause you to lose your job.
The best way to have peace of mind is financial security, which requires a different mindset.
Lots of good stuff in there.
Also from my side, don't silo into technologies, embrace being polyglot. Being able to jump in, because X Developer expert isn't available (sick leave, vacations,...) and something needs to be done right away, can be a very welcomed help.
Regardless of how one hates technology XYZ, if that is what makes the customer happy and willing to come around again, use it. Their customers don't care about your opinions.
And most important, be loyal to the team, not the company per se. Many of the team members will cross each others at several companies. Companies themselves come and go.
We have an interview question that asks about what you do in exactly this situation and people inevitably focus on "being right and winning" or "picking the right vs. the wrong solution". In reality it typically is picking one of many good but not perfect solutions and then moving forward as a team. If you answered by explaining your rule I'd be impressed. Bonus points if you shared the historical basis/significance.
Regarding the “Two-And-Done” Rule: I feel like have experienced quite the same, what made me leave the company and take a job where I know my opinion is more valued. I'm just curious if this happens to many people . I always see a good argument or discussion as a refresher for my mind, but a lot of people seem to feel uncomfortable with it.
It all still bites you/yourself.
Good luck in your job search!
Sounds like a line I could use settling lengthy back and forth in code reviews.
Curious what techniques people use to settle disagreements in code reviews.
Notice, almost nothing related about specific technical skills or language, framework etc.
It's all about the soft 'people' skills, took me a while to realize as en engineer.
Of course, you also need to keep up technically!
If I followed those advice I'd probably implode in a puff of black smoke.
Maybe things will change when I'm older, but for now I've found that being fired has usually actually been a net financial positive and a net career positive (you make 30% more and take 2 months of no pay, usually a better known company).
Maybe I'm wrong, but I'm thinking a 45-year-old who has a 3-year-stint at FAANG, a 3-year-job at a startup, 4-years-at-big-co is going to be infinitely more employable than 16-years at Noname Inc.
Shows how much of a bubble one is in, when other people’s legitimate dreams foster scorn in your mind.
reevaluate your distaste when you have 3 dependents.
In my finding we need a combination of compassionate, supportive policies combined with individual responsibility and prudence. I observe that we have combinations of neither in higher than desirable concentrations.
It obviously helps if you aren’t too spendy.
"So maybe not all of this advice I’ve given applies to you if your priorities are different. Also, maybe I am not qualified to talk about how to deal with some situations like having to job hop between startups and so on. I can only offer what I have learned myself, take away what is useful."
And you just normalize this as something ok?