I would suggest reevaluating your financial approach. It will take time and effort but you can become independent of your job more quickly then you might expect.
It's a good point. I started that way. I still have friends who are. I'm still surprised by the ways they splash out sometimes, particularly given my knowledge of their base circumstances.
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.
"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."
I am a consultant/contractor, with a new customer/employer about once/year. But, I still think most of the advice seemed on target. Really, one would want to be _able_ to stay employed, regardless of the fact that one chooses to move on frequently. Plus, most of this also applies to a position where you're changing jobs frequently, since your reputation will often precede you.
I just think it provides less security than alternatives. To me, you want career security; the ability to leave at the drop of a hat to somewhere else.
I’d suggest that communication is just as important as technology skills. Most end users and people paying for the technology don’t naturally understand the problems and challenges. These things need to be be explained clearly, in a way they can understand.
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.”
Communication is often thought as a speaking skill I would add that listening is a skill as well —- equally as important, if not more, than speaking. I’ve see so many bad designs because the developer failed to listen to, and fully understand, what the users really wanted.
You are absolutely correct. Over the course of a few phone calls and some simple diagrams, my team managed to shrink what looked like 18 months of effort for 10 people, down to 2 simple, 3 week projects for 3 people. It wasn't wizardry...it was communication.
Your overall point may be valid, but I don't like your Boiler Room quote. If you call me to sell me some stock, and I don't want to buy it, no, I don't have to sell you a reason why I won't buy it. I'm not buying; I don't need to tell you why; and I'm done talking to you now. Click.
Ha, I like the wording on the "The “Two-And-Done” Rule". I came to the same conclusion fairly early in my career. My anaology is a bit more grim, I would "hand them the rope" (so that they could hang themselves) after two arguments. I agree that two is the upper limit. Unfortunately it took me a little longer to drop the "I told you so".
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.
+1 "Two-And-Done" rule. But there are factors that stretch the rule; 1) your certainty of failure if you go the wrong way, 2) the harm to the business/team given a failure, 3) your role in execution of the task.
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.
"1) your certainty of failure if you go the wrong way, 2) the harm to the business/team given a failure, 3) your role in execution of the task."
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.
When I onboarded at Intel in 2005, they had a similar rule called "Disagree and commit." I've generally always followed the same rule, long after I left Intel.
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.
We have that one at Amazon. It took me quite awhile to realize that it meant in the "two and done" sense used in the article, and not the "I will literally die on this hill" sense. Younger me burned a lot of political capital fighting tooth and nail to change the course of a machine which had its tracks laid out by management with motivations separate from my own.
I love this rule! I try to do the same thing. I look at it as an investment...long return. Arguing to win daily is a fools game. As you say, make your point and watch things unfold. Over the long run, if your guidance along the way would have have been correct, well...the arguments stop eventually. The downside is that everyone assumes you are always correct...which is bad. Which means, you need to frame your guidance with some form of caveats/probability.
"Disagree and commit" is also an Amazon leadership principle and it's one of my favourite because it really help with internal discussion by acting as a wake up call for you or the other person.
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.
The part of this rule to watch out for is the "One is, it kind of releases you from responsibility if things should go wrong." Oh no it doesn't, unless you CYA. And by CYA, I mean documentation. I always send an email afterwards stating what was discussed, as I understood it, and requesting that everyone confirm that I understand it correctly. This has the benefit of confirming my understanding, as well as covering my ass if things go wrong.
I should adopt that for here on HN. I sometimes wind up in conversation with zealots (Churchill's definition: someone who can't change their mind and won't change the subject). So: Two and done. If I give them reason to change their mind, and they won't even listen, then two-and-done.
The only caution I will give to this rule is: "Estimate the likelihood of the person making this decision leaving the company."
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.
"Two-and-done" is good, but many times you run into people who don't give a s*t about the outcome. They're just making their employer their own personal debate club. "Oh you think X? Then I'll propose Y. Let's have a debate! Yay!"
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.
Thanks for sharing this. I appreciate the conclusion admitting that there are trade offs to attaining job security. For example, this may not be the best advice for someone trying to maximize their income or title. If you are looking to minimize stress in your career, I think being a hard working, effective developer who’s enjoyable to work with will help you substantially.
Slightly off topic for the topic of "Staying Employed," but "Don't spend everything that comes in, and save a good chunk of your salary." It doesn't matter how much you make, you can always spend more.
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.
Wealth is like a cube of ice too; it will slowly melt whether you like it or not. General inflation, specific CoL line items, or cost of education for your kids etc; they all change without any notion of fairness to your hard work.
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.
Wealth management isn't explicitly mentioned, but it's part of the work that comes with having a high savings rate.
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.
Highly disagree if you start investing young and slowly have your portfolio get more and more risk averse over time you should be able to keep majority of your wealth if not grow it depending on your tolerance to risk and when you start withdrawing from your account.
> 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.
> 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.
My hair isn’t quite as grey as a lot of yours, but I watched, initially enviously, as college students a few years ahead of me graduated into the tail-end of the DotCom bubble and “massive” (for the time!) salaries and signing bonuses, and then with relief for the boring government contracting job I managed to swing when they all started getting laid off and struggled to make those balloon lease payments they’d felt so clever about a few years before.
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.
One thing that seems to work for me: follow your curiosity. Admittedly, I am still a young programmer (shy of 30), but so far this has not yet failed me. During job interviews I usually show some game I made in my spare time, and even though the game hardly shares the same tech stack, my genuine enthusiasm while talking about it and showing it off makes them excited too and make them want to hire me. On top of that I also have some open-source contributions that I made because some project had a bug or missed a feature I needed. I never did it to increase my brand but it sure doesn't hurt. I also share the books I've read on my personal website which can be a nice conversation starter. I usually get to take my pick from several companies whenever I'm looking for a job.
> follow your curiosity. Admittedly, I am still a young programmer (shy of 30), but so far this has not yet failed me.
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.
I think it might depend on what you're curious about and if that interest is valued.
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
I've never understood why "just doing it anyway" was a fair argument when you do not have a choice over the thing you have to work on, but that it isn't when you have a choice in doing something yourself. If what you do is a hobby, you are certainly able to give it up for another one if you aren't happy when doing it, or if it isn't "just your thing." But arguably, it being "not your thing" could just be because of your insecurity and unwillingness to conquer adversity, and thus giving up on something you don't "want" to do but do not stop thinking about regardless would be the wrong decision. That process of getting over your insecurity could take weeks or months or years of time, beyond just trying it a few times before declaring that it's not truly an interest of yours.
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?
While I wouldn't be looking at a game, I would be looking for enthusiasm. Outright technical skill is important, but also how you dig into problems and push a project forward.
Curiosity has a shelf life. It looks better on the young. Also, a lot of ground is covered as time passes, and tech at 40 isn't as interesting and exciting as tech at 30; curiosity is a limited fuel.
As a software engineer with 2+ decades in the field, this always is a worry in the back of my mind.
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 believe this "personal brand" strategy is the way forward.
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'm not saying to be phoney. I'm just saying I'd rather try to keep a positive attitude and not be miserable to be around, if I can avoid it.
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.
"personal brand" in the context of the article is not about marketing oneself, but how to be a personable, reliable, competent, and helpful colleague. This as nothing to do about trying to get more money, but to have a more stable relationship with your company.
To be honest, this is an advice for everyday life, nobody likes a drama queen or a energy vampire around them.
Is it that people are taken in or just noticed overall? This was one of my early learnings in the workplace. A small portion of what I do gets noticed and I could just not have done half my work and nobody would have noticed.
I don't think it's about selling yourself, but rather choosing what impression you'll leave with people.
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".
As used in the article, personal brand is a lot closer to your first paragraph than to snake-oil peddling.
> Personal brand also works like that. When you work on a project, even a crappy project, your personal brand is on display for all potential shoppers to see. And even when everything is going south, others will notice which people are easy to work with, which people can be relied upon to do what they said they would do, and which people consistently produce a quality result.
"Personal brand" isn't some kind of con. It is defining and letting people know who you are as a professional, both good and bad. There's no falsity in that (unless you're deliberately trying to hide a trait that others won't like); if anything, it helps others fit in with you and your managers find a place where you'll function best.
If you prefer to reframe away from the bullshit marketing language, you can think of "personal brand" in terms of integrity, conscientiousness, and reliability. These are virtues that make you valuable.
> 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.
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.
The direct trigger was, servers were on fire, for the third day in a row (approx 30-60 minutes of bad service the previous two days), I was frantically trying to figure out why, he came over my shoulder and asked "what's going on with the servers?" I told him "if I knew what was going on, it wouldn't be going on". Had a meeting later in the day where the earlier quoted statement.
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.
This captures a lot of what I have always wanted to express. I am of same cohort as the author, and aside from being laid off once (which, honestly, was wonderful) I have managed to stay well employed 30 years in tech. I hold no degree. I have no specific super powers. But, yes... everything stated here rings true for me. I would, humbly, add some of my own.
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?
> Oh, he's very popular Ed. The sportos, the motorheads, geeks, sluts, bloods, wastoids, dweebies, dickheads - they all adore him. They think he's a righteous dude.
Sure. Let me clarify first: The craft I refer to is the ability to create clear, detailed diagrams that not only document a system (like a layer 3 diagram), but also to express a series of ideas or concepts that a group of people is trying to wrap their head around. Effective use color, metaphor, and just enough text. These people obviously are not just artists...they need to understand what they draw. This is rare skill. Pictures can sell ideas, gain consensus, and move things ahead faster than a dozen emails and conf calls. Especially with Management. You won't get the attention of management with a 20 page dissertation...much less change their mind. I know, I have tried. In one case, we were trying to convince an army of execs to invest (substantially) in a large re-write. We had explained in detail, why it was needed. In the end it was a single diagram that sold our idea. We showed them how ugly the code base was with a cyclic dependency diagram. That hit them square in the eyes. We got the funding after that.
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.
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.
My bad. What I should have said was "Edward Tufte's books. They contain beautiful diagrams". LOL...Didn't know about "Beautiful Evidence" until you mentioned it.
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.
> 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.
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.
Doesn't that feel incredible? Just one win like that can make a whole month or more of happy thoughts for me. I benefited from a manager like this early on...never forgot. Now, when I can, I pass it on.
The personal brand thing is interesting. I feel like I've had plenty of job security, and I've been through company downsizing, but the layoffs never got big enough to be any threat to me. But I was an Army officer before I got into engineering, and it's obviously a different culture for a very good reason, but due to the fact that the mission is bigger than any person and the organization needs to operate and succeed in environments where all individuals can be killed at any moment, it was always drilled into us to be constantly training your replacement. Make sure you are never the only person who knows what you know or can do what you can do. I've taken that mindset with me and continue to meticulously document everything I do and constantly train others, so that I certainly hope no organization ever fears losing me will drive them out of business, though I don't think they want to lose me, either
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.
> This is a conflict between individual and organizational rationality
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.
That depends on whether the horse likes me or not. I would rather ride a donkey though, temperament means the org is opinionated and has some values and goals.
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.
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.
I think it’s a bit anachronistic. Today, when a project ends at one of these big companies, the people get laid off. They may find another position internally, but everybody starts at zero again. The only thing that matters is the skill set and proficiency demonstrated in your last project. Sucking it up on a bad assignment sets you up for more of the same. And let’s face it, you’re not going to excel. Career aspirations over. Mediocrity is a state, not an identity, and there is a reason most people end up there. The people that liked your attitude working on stupid stuff will help you get more of the same. If you want to go from bad to good, you have to make a change yourself. You have to skill up, maybe quit, maybe go back to school, maybe find someone with big ambitions that is desperate enough to take a chance on you. It’s going to feel like a step down, an admission of failure. Because it is, whether your fault or not. Just get out. But why don’t people do this? Why do they get stuck? Usually this comes down to personal relationships that are not robust to failure, cannot accept downgrade of lifestyle or prestige. These people are stuck faking it forever, living in the land of the dead.
Don't be lazy about staying relevant. You shouldn't jump on every new trend, but you should be knowledgeable enough to discuss it intelligently. This requires some investment, even if it's just taking a Saturday to go through a quick course on Udemy or the like.
Yes. New Stuff doesn't always supplant Old Stuff. And when it does, it does so at different rates. There will always be work available to bridge/replace Old to New. Heck, look at mainframes.
I’m 61 and have been working in high tech since 1983 or so, writing embedded software, doing system administration, and managing people.
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.
In addition to ageism, I think the proliferation of the MBA/McKinsey school of thought really works against older programmers. You have an increasing number of managers who have little to no domain knowledge around 1) Programming, and 2) whatever industry they happen to be working in. What's worse, is that they see no problem with this because they think they "understand business".
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.
One problem in these discussions is the curve of value delivered by an individual developer in a particular situation is short-and-wide and while I agree the senior developers are on a curve shifted to the right, there’s a massive amount of overlap.
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.
> One problem in these discussions is the curve of value delivered by an individual developer in a particular situation is short-and-wide
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.
If I understand your comment correctly, I think we're agreeing (that there is a wide range [high variance] of value delivered across the population: think of a bell curve that's "smooshed" down to be short and wide).
Yes, when you look at those differences any performance drop due to age is going to look tiny in comparison.
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.
“ 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.”
True. But most people reach that point after a few years or never.
Yes, you hit the plateau of that curve pretty quickly. You can't just be an individual contributor and justify 3% raises every year for 30 years, when you hit that plateau on raw skill you need to start finding ways to player-coach the generation(s) of more junior developers behind you. I don't think that necessarily means you have to move into management, but it does mean broadening your definition of impact beyond LoC/commits/tickets.
> broadening your definition of impact beyond LoC/commits/tickets.
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.
>One problem in these discussions is the curve of value delivered by an individual developer in a particular situation is short-and-wide and while I agree the senior developers are on a curve shifted to the right, there’s a massive amount of overlap.
This can also be said of managers. Then why aren´t they discriminated by age too?
Because they are smarter and work the system. Same for sales guys, lawyers and so on. They work the system to their advantage. Developers are one of the few groups that believes in a just meritocracy.
Agree about the value curve. Most developers do stuff that can be learned in a few years and then they just repeat the same thing with slight variation. There are really not that many jobs where you get challenged to grow throughout your career. It’s just repetition (like most other jobs)
I frequently hear that, but in practically every other profession doing the exact same thing for 20 years is still valued. And the underlying reality is you can’t do the exact same thing for 12 years in the computer field. Experience is all the little edge cases that cropped up over time.
Anyone in the trades is doing such a job. If you're a plumber, or electrician, or cabinet maker, or framing carpenter, or a mechanic, even if those 12 years (or 20 years or more) seem similar to people outside the field, you're learning all the time. It never stops, until you do.
It’s not like learning stops but the curve flattens out a lot. Another problem is that in tech 20 year old knowledge is worth way less than 20 year old knowledge in for example cabinet making.
> Another problem is that in tech 20 year old knowledge is worth way less
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.
I could do the same. But really, it's also my value proposition. "What's that you say? Your org has a dozen crappy systems of questionable lineage and you need to migrate to SomethingFromThisDecade? Let me pick it apart for you and we can build a plan together." It's not much, but it's honest work. (and I happen to enjoy it...so win-win)
You might be surprised at how many companies are running 10+ year old technologies that were designed around the constraints of the 10+ year old systems that they replaced. If that's your thing, you can build a pretty strong career around being the person to keep that system humming along.
I’ve worked with a lot of young developers and never met a 25 year old developer that’s creating more value than the average 50 year old developer with 20+ years experience. In theory sure it’s possible, but in practice it simply doesn’t happen even close to 5% of the time.
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.
So senior devs are better than 95% of 25 year olds.
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%.
These days, there is no excuse to have a non-technical manager (unless you are a technical manager yourself). Software is eating the world; it is professional negligence to put someone in charge that doesn't have a detailed understanding of the technology that impacts everything about the modern workplace.
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.
This must be industry variant then. 3 of my 4 jobs in the last 30 years have involved non-technical leadership. The exception was working for a "tools" company where software was the product. But the other 3 are at the "edge" where software enables real devices to be more modern/gadgety. In that context, software programmers are a necessary evil to en-smart-ify gadgets that have traditionally been "dumb." And letting software people be part of the direction is too much of a loss of traditional power.
That’s why I recommend that young people should try to work for a company where the CEO comes from a tech background and understands your work. It’s just natural that someone has more respect for a role they have performed themselves.
Why do you recommend this to young people specifically? Wouldn't it be sound advice regardless of the age of the recipient of this advice? Just curious why you've added that qualifier.
I guess i don’t give advice to people my age ;). getting into tech companies also seems easier when you are young and don’t have much of a resume. Having a resume with years in not interesting companies and uncool tech also seems to make you toxic.
> without the hassles of things like kids to take care of
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.
Can believe it. But: you don't need the whole industry. You need to find one good place to work in. Those exist. May it pay a bit less than soulless corp? Sure, maybe - or maybe not. But my 25+ yr experience shows they do exist.
The spread is quite wide. I got my first kid at 45 and now almost 50 working 75% to take care of two kids the rest of the time.
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.
Yes I feel more productive than many of the younger, childless colleagues at work. In fact I really don't like going to the office due to people talking WAY too much. I have 8-9 hours and then I need to pick up my kid, not using those 8-9 hours to the fullest is something I simply have to avoid. And incidentally my least productive days are the in office days.
> You have an increasing number of managers who have little to no domain knowledge
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.
Yes! It's probably just a demographics thing that will even itself out in the future. I mean: People like you will become managers and there are many programmers in the younger generations to draw candidates from.
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".
I think the general aversion to OSS is more that there is no responsible actor. In many cases, if you integrate a third party paid solution you can file a bug on that solution with reasonable confidence it can be a priority. If you use code from another team at the company you know you can file bugs on them. If you write code yourself you have confidence in fixing it. There is a danger with integrating OSS that you have code in your stack that no one knows well enough to fix and no one is responsible for. If something breaks you might have to learn a sizeable amount of code and domain knowledge to make a fix. Filing bugs on OSS is not viewed in the same way as filing bugs on paid third party solutions as whether the bugs are a priority to an OSS solution seems more risky.
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 think the general aversion to OSS is more that there is no responsible actor.
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).
While I understand your lack of success with bug reports, and I thank you for your stance on (not) closing bugs, note how the average manager got what he wanted:. A proof that reasonable effort has been made, and it's not his fault. This allows survival in a politically piosonous environment. If the bug got fixed is generally not their concern, others will have to deal with it and move on.
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.
Nice job! How long did you have to wait for the new software version after the bug fix?
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.
> I have filed many bug reports for paid software over the years. The bugs were fixed exactly 0% of the time
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.
They jump if you paid for a service contract. If you paid for a product, those companies owe you something fit for its intended purpose, and bugs are not that.
They are still problems that need fixing, some day someone may be doing work on the project without knowing what to work on and having a backlog of issues categorised by importance/etc will be useful in that situation.
It is cost free. It prevents people from filing it again. It provides insight into later problems. It provides a place where people can ask and offer advice on working around it. Sometimes an intractable bug becomes more tractable later. It can provide a clue to a later bug report. Sometimes someone new has a brainwave on how to fix it.
That would require a project be worthwhile to stick around long enough for an opportunity for someone new to come along, let alone come along and be interested in it. It's obvious that most career programmers are only used to ("interested in"?) pushing devops shovelware onto GitHub and other forms of busywork, so it shows in their bug-handling hygiene.
Have you ever filled a bug for the JDK? I was at 20 emails, plus having to create accounts and give paperwork that our company had a license for a one-liner correction of a major bug when I decided to abandon and wrap my code in an exception catcher and manage it on my side...
“ I think the general aversion to OSS is more that there is no responsible actor. In many cases, if you integrate a third party paid solution you can file a bug on that solution with reasonable confidence it can be a priority”
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.
In contra other replies here, we have repeatedly sent bug reports to vendors and got productive, timely, comprehensive support and fixes: Hashi, Snowflake, Databricks, Confluent, and others. We're a Bay Area company of about 500 people, not a market behemoth in any way.
This is my take as well. I build and sell electronics, coded in Rust. (Cortex-M). I started using OSS HALs, device drivers, utility crates, peripheral access libs etc. Each of them had bugs, missing features, or awkward APIs. I got about 10% of my issues and PRs addressed. I now use almost exclusively internal code (with exceptions for debug tools and the cortex-m lib). If there's a problem or limitation, I fix it myself. Far easier than spelunking someone else's code, or hoping a maintainer fixes it.
I've had a few. All solved except one. I suspect only a few people are using my lib, and all are hobbyists. A particular challenge with this lib is I'm attempting to support most (newer) STM32 variants using a single HAL lib, which makes ops testing tough. (This allows me the flexibility to choose whichever variant I'd like on future projects without modifying the code base). I've published code so others can use it as an example.
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.
There is a bit of a programmer trope "its easier to write code than to read it". This leads to reinventing wheels, duplicated effort, etc. When it comes to open source, I take the position that we are all in it together and try to come up with fixes for problems that I see in existing projects, even if I've never used the language before or the codebase is messy. I also think being able to work on code that came before you is a useful skill to have.
> I think the general aversion to OSS is more that there is no responsible actor.
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.
Do you think the "clueless middle managers" the OP alludes to view themselves as such? Or are they too protecting their teams so they can get real work done?
We all see ourselves as the rare exception, the one bucking the status quo and doing things differently.
Thank you for this. We have someone just like this who went into management for the same reason. He does an excellent job of it, I only wish everyone shared the appreciation for his powers of insulation and fighting in the devs' corner all the time.
Quite often your efforts aren't visible to everyone, but it's visible to some and they're thankful for it!
Echoing this. Please for the love of God get your MBA.
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.
It may be "easy" but unless you're in the right program at the right time in your life, and most importantly, have the right career trajectory, the MBA itself won't magically "open doors" into an executive suite. Certainly it's not any faster than just painstakingly climbing the career ladder.
It depends on why you want to get a MBA. If it's for credibility - go to a top 10 school. If it's to learn - you might be better off learning on the job than taking weekend courses.
The young MBA people are intimidated by people who can reject their schoolbook ideas coherently. Most of those people are older, but not all of them. I started noticing this before I was thirty, either reacting to me or to someone I agreed with who happened to be older. It only gets worse.
Recently Ford was in the news here in Michigan regarding layoffs. They found emails saying if an employee is over 55, have a career of large success and as a result are paid above average then lay them off.
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!
>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
Bunt functionally this is correct. If they are both "Senior Devs" they're going to be roughly equivalent. If you are 50 and haven't gotten architect/tech-lead/principal roles etc. you're probably at your ceiling and you aren't really going to be much more valuable than that 25 year old.
> 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.
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.
> increasing number of managers who have little to no domain knowledge
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).
For those who haven't yet experienced ageism, it often starts for you when the hiring manager/director is younger than you are. Beware of the age of the bosses when surveilling a potential new gig.
And you don't have to be 50+ to experience it. My former 30 year old self with a brand new baby had a 25 year old manager, and experienced it constantly. He just couldn't fathom why I wouldn't answer his random slacks at night, or why I thought beer taps, ping pong, and happy hours weren't suitable replacements for good benefits and incentive packages.
Although this isn't the usual use of the term, your comment is a great example of the importance of a manager that values diversity. You can overlook, and drive away, really good employees for really bad reasons. It's not likely that a response to a random slack in the middle of the night had any value to the company's bottom line. Managers that can't accept that not everyone should be like them are bad for the company.
You highlight another good point, in that ageism is just a symptom of a broader psychological phenomena of "othering" others. I suspect that even if I was indeed younger than my manager, simply having a child and entering a new life stage with newer, more important priorities caused me to be treated differently. In a way I think the manager just wanted people who are just like them because they were a lazy manager, and wanted an easy way to relate to others rather than the hard work of understanding other perspectives and experiences. A ton of companies I have worked for preached diversity of thought, opinion, and background, to the wazoo and very rarely have they practiced what they preached.
This is real diversity--some single, some married, some with kids, some without, some older, some younger, coming from all different educational backgrounds, and living in different communities.
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'd go with something along the lines of: "I'm looking for a company where I can show up and work hard during the day, and go home to my family at night. Will that fit the culture here?"
Oh god, that can’t be something anyone can get away with asking. I don’t have a family of my own, but I’m tempted to just fabricate one so I could actually ask something along the lines of what you are suggesting.
‘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'm a 23 year old software engineer and I ask this question on every single interview. It doesn't matter that I don't have kids and don't have to go to bed early every night. I have a life unrelated to my job, and I act in the belief that everyone else also does.
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.
> how do you guys adjust cadence for people with outside commitments - eg let’s say I need to leave every day at 5
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.
You might be surprised, I often lead with an ambiguous "so, how's the work life balance here?" and more often than not interviewers jump in with a fair amount of info and sometimes even "knowing smiles". I don't interview with startups though, so ymmv.
I'm not a dev but the last time I got hired (current gig) I straight-up told them that I'm expensive and creativity is time-consuming. It went over well! You might be surprised at how much bluntness hiring managers can take.
The key thing is really BATNA because that gives you the confidence to say what you've gotta say.
Gah, there’s no way to ask without setting off the alarm bells with these bastards.
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?
If that doesn't go in, well probably it isn't a company that respect my values anyway, and unless I am in trouble of needing a job right in the moment, well there are other opportunities.
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.
+1 and, if as an older dev you show younger manager(s) that you respect and empathise with them, often they'll love you for your experience and perspective. One thing is to "meet them halfway" , not make them feel threatened. I love my current job so I hope to stay a long time, but, if I was interviewing with someone much younger, if it felt relevant I might ask them if it bothered them about my being much older, and what I could do to alleviate any concerns. That's the sort of frank conversation that might be good in interview (possibly not legal for the interviewer to start that topic, but OK for interviewee). Isn't a lot of this just that people simply need to TALK to each other. ;) Not just older and younger devs but democrats & republicans, different gender/ethniticty/religion , drivers/cyclists etc etc ;) This problem is as old as the hills!
My experience is that ageism only kicks in when the company culture is overtly focussed on a sort of "work hard; play hard" ethos. If the key influencers in the company enjoy working with a banterish atmosphere around them, then anyone over the age of 40 (and all women) are in for a stressful time.
Thankfully, there are companies out there which do value older workers and will make the effort to encourage a more diverse/inclusive working atmosphere.
We had a banterish atmosphere (lots of smack talk across the cubicle walls) with almost everyone on the team over 40. But it was grown-up banter, not high school banter. It wasn't passive aggressive, "hah hah only serious"; it was just fun banter. If we really wanted to communicate something to someone, it was handled very differently.
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...
I was precocious/fortunate so I ran into ageism being “too young” to be something like a Lead a couple years ahead of my peers. In part because I worked in college, but more importantly because that team was so well run, and saw the wisdom in trying out some of my ideas to make things better. So I came out into the world both with programming experience and practical project management exposure.
“They” want very cookie cutter people. The more you try to control things, the fewer pleasant surprises you get.
I'm in my late 50s. All the jobs but one I've had over the last ~10 years (there's been about 5 of them) were where I was hired by people older than I am. The one job where I was hired by a person in their early 30s went spectacularly, terribly bad (only lasted 8 months before I bailed and I really should've bailed at 2 months, but I thought I needed to try to stick it out because "that's what you're supposed to do".).
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.
I've hired a few 50+ devs and every time I regret it. Those specific devs learn much slower. They had a complex about their age that made them difficult to work with and connect with. Their work product was bad and no amount of intervention corrected course.
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.
They could have had those roles already. Once you're in those advanced IC type of roles, there aren't really a lot of places that you can go. A lot of the time that role depends on your domain experience within the company -- Usually to "move up", you have to go down a role to a bigger/more-challenging company.
Thus at BigCo, hiring senior devs of advanced age should make sense to do.
Many companies don't have positions titled staff, principle, etc. A lot just stop at senior, or use numbers, etc. My current shop has SE1,2,3,4,5,6. 4 is what most tech companies would call a staff engineer, 5 a principle, and I'm not sure if we actually have any 6s at the moment.
This is entirely dependent on the company. Netflix has one level "Senior Software Developer". My former employer only went up to Principal Developer. My current gig has one Senior Staff Engineer, me. The thing is, I didn't get better in the month between leaving my last gig, and starting this one. So these titles are a bit ambiguous.
This is incredibly wrong and I hope you get an opportunity to meet people to change your mind.
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.
Your anecdata of one doesn't sway my real world experience. Cognitive decline starts at 25 for everyone, and no amount of midwit theory that everyone is equal will change that.
In this thread alone you said “hired a few” older devs, and yet discount one person’s experience as “anecdata” while you claim to have “real world experience.” The difference between the two is not “a few” - 1.
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 like how the story of the "amazing dev" above only tells about how he accomplished checking into work everyday and battling cancer. Every senior dev under 35 that I've hired has a much better narrative surrounding how well they work.
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.
The median age of the entire US labor force is 42.5, construction is 42.9, and "Computer systems design and related services" is 40.6 according to the BLS.[1] In other words, on the scale of human life expectancy, the difference is probably negligible. Even if you were being serious and earnest, you're basing your hypothesis on data that is either incorrect or outdated. (If you actually meant to include mean instead of median, your source isn't a robust data analysis by definition.)
> 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.
That's the industry classification with the largest number of "Software Developers, Applications" occupations from the US Bureau of Labor Statistics[1]. As far as I'm aware, there isn't a comprehensive analysis of occupations by age based on BLS data. I'm guessing your source is a survey that probably has a margin of error larger than the difference between any median ages provided by the BLS for industries that employ the most developers.
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.
Maybe measure - and hear me out on this one - all team members equally, factoring in their total comp. How much more productive is the team for having the individual on the team, regardless of their demographics.
I wish I could watch the end of your career pan out for laughs. Convinced that you're still as competent as you were when you were younger, but those assholes in charge of hiring won't give you a chance.
Problem is management is a pyramid (there is no place for everyone, even the best of them) and in some cultures (I´m in South America) a wealthy and contacted people club.
Even if you are really good, you will not get promoted if you came for a non-wealthy background.
I've had the opposite experience. Most experienced develops tend to learn things much quicker because they've got a lot more experience learning new things. I'll willing to bet the third or fourth programming language you learned came a hell of a lot quicker than the first.
I think this hits the nail on the head. Ageism often goes hand-in-hand with other negatives and is a warning sign about a workplace. Perhaps, ageism does us older devs a favour because we'll get screened out quicker and not have the misfortune to interview at horrible companies ; That said, sometimes older devs don't help themselves. At a place I previously worked at, colleagues my age or older would make sexist/racist/disabled-mocking jokes, utterly inappropriate in the office but they'd got away with for years. The younger folks generally knew not to do this, and were offended, but then often 20-somethings while careful not to be racist or homophobic would simultaneously be blatantly ageist against their older colleagues. I got treated badly by some younger colleagues there actually, suffice to say it was symptomatic of issues in that company and I found a better job.
Ageism is a thing but I don't think it is always due to the fact that you are "old". Companies turn old people away because they do not want to pay for "experience".
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.
And then there's the whole thing about measuring productivity. It's very hard for many managers to understand the qualitative status of a codebase, and to connect future task effectiveness with past decisions that affected that quality.
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").
> It doesn’t pay to be the angry, unapproachable person in life.
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
You mentioned anger. I've found one of the hardest things to do as a male in his mid 40s is resist the anger that arises in response to nearly everything unexpected, unintended or challenging to my thinking. I never was an angry person, but somewhere around 43 I noticed my first reaction to many things was anger. It is a very blinding, unproductive emotion.
I have noticed something similar and I'm "just" 35. I think the best way to explain it is that I don't usually get angry, so when I do, I don't have much practice and the emotion tends to linger. The problem is not with anger per se, but with violence and loss of thinking. You should practice being angry and expressing it, I think. State your anger, explain what's wrong and tell people you don't want to stand for it. There is a difference between being an angry asshole and just being angry.
I had an anger problem as well. It did great damage in my life and to the lives of people I loved and still love.
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.
I'm going to say something not to be flippant, but in the spirit of being helpful, and I'm being genuine in my question: Have you considered seeing a therapist?
It's something that frankly scares me about the career. I'm still young enough with lucky genetics that still get me carded at the liquor store. Yet, I really fear that in the future I'll get rejected from a company because "We are worried you won't be able to learn the new tech".
I've been saving aggressively for retirement for just that reason.
You're doing the right thing saving aggressively, but if some idiots would reject you because, say, you're 54 years old (the age at which Beethoven finished his 9th) - then I'm sure there would be less idiotic people you could work with.
I really love the way this post was written and wish more folks would adopt a similar approach. The author lists his experience and what's he's learned, but also lists his limitations, and areas where he might not be as authoritative, like at the end when he mentions that he's only worked for a few companies and tended to trade salary for security.
It's refreshing to see advice dispensed from years of experience while also maintaining a tone of humility.
> I work at a job
> I got fired
> If I'm skilled enough I don't think it would be an insanely hard task for me to find another job.
Recession is another thing but general layoffs can be fixed it you decide to pick yourself up.
Great advice all around and solid article, works well at any age.
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.
Not that it's a contest, but I'm 63. :-) After a mostly entrepreneurial career--but always around software--I'm back to coding every day for a living. I love the sense of accomplishment--always have. Great advice here, to which I might add that getting comfortable as an independent contractor is very useful as well. For me, there are many philosophical reasons for that, but practical ones as well; the most mundane of which is simply that if you do lose a traditional employee job, you feel comfortable grabbing a contract job in the meantime.
Great question. Generally easier to get a contract job, as the people hiring you tend to want your skills, and care less about things like "culture fit." Generally, I would say the contractor hiring process is more pragmatic. "Show me something you've done kind of like this...great, you're hired." Realizing that it's much easier to "undo" a mistake in hiring a contractor. "Don't come back tomorrow."
This article is perfect. I'm 50 and it describes perfectly the kind of career I've had and techniques I've used successfully. read it carefully if you're a young guy.
My Krusty anti social tech worker shtick finally caught up to me last year, and I was layed off even though I'm pretty sure I got fired
Wish me luck in my job search!
Happened to me, too. I found out that my whole team hated me, actually. I didn't notice and thought I would just reasonably argue my position(s). I have to add that I was working in Zürich in Switzerland (as a German) and my reputation got destroyed, so I had a problem finding a new job until I found one, where they did not check my past employer (as described in the article). This was unintentional and it can happen quicker than you think. The last rule of the Old Hacker "to stop insisting you are right after 2 attempts, even if you are sure you are" hints into the direction that this is a general problem for software engineers rather than just/only a personal flaw - But ofc I will work on and watch out for my "Leumund" much better and more carefully in the future. Also that he was affected: Excluded from decision making meetings. I am not sure, if he knows/understand how bad it might have been for(against) him.
> My own personal way of dealing with this would be to look at it as a challenge
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.
I agree, but a lot of it comes down to other peoples perception of you. Sometimes it is worth doing those dumb esoteric challenges that provide no business value whatsoever.
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.
I’m going to try the two-and-done strategy, I like the idea. A handful of times I’ve wanted to “I told you so”, despite knowing it’s not productive and rude. This seems like a professional way to do it without saying it.
And I share the authors experience even with less years. I’m wrong more than I’d like to be, which is never.
356 comments
[ 4.5 ms ] story [ 370 ms ] threadShows 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."
One of my favorite quotes that illustrate that is from the movie Boiler Room.
Communication is often thought as a speaking skill I would add that listening is a skill as well —- equally as important, if not more, than speaking. I’ve see so many bad designs because the developer failed to listen to, and fully understand, what the users really wanted.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.
If I followed those advice I'd probably implode in a puff of black smoke.
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.
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?
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".
> Personal brand also works like that. When you work on a project, even a crappy project, your personal brand is on display for all potential shoppers to see. And even when everything is going south, others will notice which people are easy to work with, which people can be relied upon to do what they said they would do, and which people consistently produce a quality result.
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.
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?
https://www.youtube.com/watch?v=mHa1zTLrXO8
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 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?
And you just normalize this as something ok?
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.
[1] https://www.dailyzen.com/journal/bloodstream-sermon
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.
Bunt functionally this is correct. If they are both "Senior Devs" they're going to be roughly equivalent. If you are 50 and haven't gotten architect/tech-lead/principal roles etc. you're probably at your ceiling and you aren't really going to be much more valuable than that 25 year old.
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.
[1] https://www.bls.gov/cps/cpsaat18b.htm
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.
[1] https://www.bls.gov/oes/2018/may/oes151132.htm
...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.
It's refreshing to see advice dispensed from years of experience while also maintaining a tone of humility.
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.
It all still bites you/yourself.
Good luck in your job search!
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.
And I share the authors experience even with less years. I’m wrong more than I’d like to be, which is never.