That ultimately, the industry wants engineers to manage the business, instead of managing software.
If I had known this I would not have gone through university at all. I would have attempted my own business from the start and learned on my own.
Instead the entire school system seemed to be about learning technical knowledge, from math and physics in high school, to computer science in university. Then you go to interviews and you get technical tests, followed by some technical focus at the beginning of your career... but then after a few years once senior level expectations start to kick in... the expectation shifts and it's about learning how the business works, and how to make profit with software.
It was confusing why this shift happens in software. It might make sense in other industries where younger people need to replace older people (i.e. something with physical labor). So I'm now reevaluating how to look for a company that will leverage all of my existing technical knowledge or I will need to reconsider what to do because my career expectations don't align with the average software company's engineer expectations.
I wish I could upvote this twice. A strong product intuition with middling technical knowledge will take you a lot further than razor sharp technical skills.
Unfortunately technical knowledge is all the school system and the cottage industry of interview prep companies focus on. If you can't get an MBA later, 4 courses I would recommend every CS undergrad take are, accounting, corporate finance, economics and maybe theatre.
I'm not sure this is universal. For a lot of "full stack" type jobs sure, the complexity is not the code but managing business and how code fits in that. However I think there is still a lot of hard science problems out there which require a full technical education.
Leetcode-infested technical interviews aren’t there to assess your technical competence; they’re used as a signal to gauge your tolerance for absurd organizational demands and your willingness to carry them out without question.
You need to make sure management knows your value. Don't assume that they will notice it on their own. I worked with a guy that constantly bragged about how smart he was and his daily accomplishments. I though he was a jerk. I now feel that he knew the system way better than me.
To add to that: there may be nothing more important than your relationship with your manager. To the point that I'd say, if you don't deeply trust your manager, and have a relationship where you can be genuinely open and transparent with him/her, you should find another job. It really makes life a lot better when you and your manager are simpatico and clearly "on the same team" (and "on the same page") and not in a borderline (or outright) adversarial relationship.
Part of this is knowing your own value to the company. Many folks I’ve worked with on the dev side think this means pointing out number of closed tickets or other KPIs. Much better is to understand and show how your work impacts company revenue. If you solve a blocker preventing a major new feature from launching, you should be talking about the new feature you enabled and the new customers that purchased as a result. That’s far more impressive than the ticket closed count which is stupidly easy to game.
Learned (and still learning): imposter syndrome is a lie, don't hesitate to ask for help, document everything religiously, learning never stops, and burnout is real.
1. Don't get tunnel visioned into the problem you're solving. Prioritize maintaining your professional relationships, especially with your manager, over all else. Prioritize what your manager cares about over whatever you think is more important.
2. Async-communication does not replace real-time communication. People cannot help but reveal more when you're communicating in real-time. This is crucial because of the next point.
3. Do NOT assume good intentions. Sadly, the tech industry is full of backstabbers across organizations of all size. If people have an issue with how you're doing something, no matter how small, no matter how trivial, expect that it'll go directly to your manager and be kept hidden from you.
Somewhat true if you remain a programmer. Much less true once you have an understanding of the business.
As a programmer your skills are very replaceable. Your domain knowledge less so, and your knowledge of the code base even less so.
If you intend to stay at this level then its worth highlighting this value regularly to management. Because they are for sure being reminded daily that there's a fresh-grad waiting to elite code for little money.
But ultimately yes, coders can be replaced. Ots not terribly hard, crumbs even an AI can do it.
Understanding the business though is next level. By understanding the short, medium and long term needs of both the business and the customers you are well positioned to target "doing the right work" rather than just the "fun work".
As a part-coder part-manager you are slso more able to bridge the knowledge gap between upper management (who are exclusively business) and the coders (who are exclusively technical. )
Focusing on clear communication in terms that suit the audience really assists job security. For example selling the eradication of some technical debt, as a business advantage, yo upper management is more likely to suceed if it aligns with business goals than just "the techs want to pretty up the code."
Everyone else is giving vague "life lesson" posts, so I'll buck the trend: Django and React. I put off learning web dev stuff for far longer than I should have out of some mistaken sense of purity or something. Instead I only started early looking into them around me 2021 or so, when I could have been learning as early as 2010!
E.g. working the website of a forefront AI lab doesn't feel meaningful. More like you're the idiot for having spent your life on web dev, while some are fixing humanity's last problem.
I wouldn't say I learned this too late, but ashamedly, I didn't learn this truth until after ShellCheck was released. I have thousands of hours of experience writing Python, Ruby, and Perl, but I no longer have any use for them.
I realized, being a manager overseeing people, chasing after career progression was a wrong path. I should have stuck to what I like more, engineering, not bullshitting.
I did this, so I completely agree with this advice.
But of course then you really need to do the business first, and right, and the coding comes second.
If you plan to go down this route I recommend exposure to accounting either at school or college (or via external self study.) I did it at school, and while I'm not involved much in accounts these days, being able to read them, and understand them, is really useful and important.
Yes I’m sure that everyone can build a for profit business that replaces even the income of a mid level enterprise dev.
Surely you are not suggesting someone work full time and then spend their time off working on side projects? This is the most toxic traits of our industry.
First of all, I don't think it's ever "too late" as long as you're breathing. That said, there are things I wish I'd learned earlier.
I couldn't give you a complete list of those things off the cuff, so I'll just pick one that is sort of "top of mind". I haven't thought this out in detail, so consider this me basically "thinking out loud".
So... to put it in very loose terms, I'd say I wish I'd learned to really appreciate the importance of focusing on human to human interactions and how people communicate, interact, evaluate, and understand each other. Of course that's tritely obvious on one level, but to really really internalize those lessons is a different thing.
And while it might seem silly, I'll say that one thing that helped me learn a lot was watching the TV show "Billions". Very early on in that show I kept noticing certain behaviors by the various characters that led them to bad (or sub-optimal) situations, or behaviors they used to improve their standing, etc. And I'm NOT saying that any of those characters should be seen as role models mind you. Just that watching the show kinda "smacked me in the face" in a very visceral way with regards to appreciating some things I had not really fully appreciated before.
To illustrate (spoiler warning if you haven't seen the show)... in Season 1 there's a tense meeting with the two main characters - Chuck Rhoades and Bobby Axelrod, to sign a settlement that had already been agreed to. Note, they had an agreement that made everybody happy. This should have been a simple "show up, sign the papers, call it done" deal. But Axelrod let his ego cause him to start mouthing off at Rhoades, who in turn let his ego be offended and then he ratcheted up his demands for the settlement, which eventually led to Axelrod tearing up his settlement payment check, and walking out without signing the deal. This led to all sorts of bad shit and was a suboptimal outcome for everybody involved.
The lesson (as I took it)? Detach your ego from things. Focus on the outcome you want, not how things make you feel in the moment. Don't let a brief moment of anger derail something you've been working on for months (or years, etc).
And there are very many similar lessons embedded in that show. I do recommend it to basically everybody, FWIW.
Anyway, getting back on point. I guess I'd add that I now realize that I was probably too focused on technology qua technology earlier in my career. And again, I knew that this wasn't optimal on some level. But it takes a while sometimes to go from a surface / superficial understanding of something, to a really deeply internalized understanding. Now, I get more the importance of the "human element", understanding how the business works, understanding the interpersonal dynamics of a company, etc.
Edit: let me add one more thing.
Don't whine, or complain, or sulk at work. Ever. Just don't. it might feel good, but there is basically zero chance that doing so will help your situation at all, and a very high chance that it will hurt your standing in the org and compromise you at some point. If you have a legitimate grief, sure, talk to your manager in a strictly business-like, professional manager. Eg, "Look boss, you have me doing X, and I'll do it as long as you want me to, but I'd really prefer to be doing Y. Do you think we could find a way to shift my role more to Y" or something along those lines. But sulking, acting pissed off, bitching around the water cooler, etc. are no behaviors that will help you. Trust me on this. And don't ask me how I know. :-)
You only have 1 to 5 years left for your tech career unless if you're world class level programmer. AI is not good enough yet but the next versions of AI in the coming years is going to eliminate at least 90% of software engineer's jobs. Most companies have already stopped hiring.
For savings it will soon fail. Urban land value rises with a growing working-population. What are the demographics in your area? In New Zealand we have immigration pressuring land value, however if our economy tanks then urban land values will dive.
For prepper? Good luck keeping your land against your violent neighbours when anarchy hits!
Rich enclaves might grow in value, but you need to already be rich to buy in.
AI?
How many hours do you spend programming? There's a lot of work that AI won't replace: like understanding client needs. Maybe you haven't been through a few past hype cycles? Predictions of needing less developers have been made before.
That age discrimination post VC infection is real. Back when I started in 90 we had senior engineers with white hair. I distinctly remember brushing aside my father's advice when he cautioned me about such things. "No, not in software. It is a pure meritocracy". Hah. (Implicit lesson: listen to your elders /g)
Second lesson then was that engineering as a career is for chumps; young ones: start your own business.
Age discrimination is real, of course, just about everywhere.
My experience though is different to yours. I joined a bootstraped company in 1992 as emp number 1. Basically me and the founder. We were both in our 20s.
In those years everyone in computers was young. We had no "adults in the room". We did a lot right, and a bunch wrong. I grew a beard to look older. When we had programmer user-group meetups everyone was our age.
That hasn't really changed, except now we are the grey beards :)
Of course we had young workers, I was one of them. Except we also had actual grey beards and -no one- ever said silly things such as "anyone over 30 is over the hills" as was the norm (here on HN) in the 21st post "internet". It was very much a different field, and yes, my first two jobs were with startups, as a matter of fact.
I am 50. Been in software development since 1996 and found it easier to get jobs post 45 than ever. I did my first stint at BigTech at 46 and found what most would consider good paying jobs within 3 weeks both in 2023 and last year.
That ultimately, the industry wants engineers to manage the business, instead of managing software.
If I had known this I would not have gone through university at all. I would have attempted my own business from the start and learned on my own.
Instead the entire school system seemed to be about learning technical knowledge, from math and physics in high school, to computer science in university. Then you go to interviews and you get technical tests, followed by some technical focus at the beginning of your career... but then after a few years once senior level expectations start to kick in... the expectation shifts and it's about learning how the business works, and how to make profit with software.
It was confusing why this shift happens in software. It might make sense in other industries where younger people need to replace older people (i.e. something with physical labor). So I'm now reevaluating how to look for a company that will leverage all of my existing technical knowledge or I will need to reconsider what to do because my career expectations don't align with the average software company's engineer expectations.
I wish I could upvote this twice. A strong product intuition with middling technical knowledge will take you a lot further than razor sharp technical skills.
Unfortunately technical knowledge is all the school system and the cottage industry of interview prep companies focus on. If you can't get an MBA later, 4 courses I would recommend every CS undergrad take are, accounting, corporate finance, economics and maybe theatre.
I'm not sure this is universal. For a lot of "full stack" type jobs sure, the complexity is not the code but managing business and how code fits in that. However I think there is still a lot of hard science problems out there which require a full technical education.
Leetcode-infested technical interviews aren’t there to assess your technical competence; they’re used as a signal to gauge your tolerance for absurd organizational demands and your willingness to carry them out without question.
You will like this article on compliance training: https://radicalcontributions.substack.com/p/escalation-theor...
Great article, I never find articles interesting anymore (it's on me for sure) so it was nice to enjoy reading after so long. Thanks for posting it
At least leetcode it meritocratic! I didn't go to Stanford but I could learn how to BFS :)
You need to make sure management knows your value. Don't assume that they will notice it on their own. I worked with a guy that constantly bragged about how smart he was and his daily accomplishments. I though he was a jerk. I now feel that he knew the system way better than me.
To add to that: there may be nothing more important than your relationship with your manager. To the point that I'd say, if you don't deeply trust your manager, and have a relationship where you can be genuinely open and transparent with him/her, you should find another job. It really makes life a lot better when you and your manager are simpatico and clearly "on the same team" (and "on the same page") and not in a borderline (or outright) adversarial relationship.
Part of this is knowing your own value to the company. Many folks I’ve worked with on the dev side think this means pointing out number of closed tickets or other KPIs. Much better is to understand and show how your work impacts company revenue. If you solve a blocker preventing a major new feature from launching, you should be talking about the new feature you enabled and the new customers that purchased as a result. That’s far more impressive than the ticket closed count which is stupidly easy to game.
That the same people you admire will destroy your job.
- I was a Flash developer and Steve Jobs killed Flash with the iPhone. In all fairness, for its security problems.
- So I went to infrastructure and then Bezos released AWS.
- So back to UI development, and Dan Amabrov and a few others made my React project a legacy one.
- Now I'm waiting for Sam to deprecate my frontend dev job with AI.
Maybe you have the right ideas and good judgements but your timing is off.
Learned (and still learning): imposter syndrome is a lie, don't hesitate to ask for help, document everything religiously, learning never stops, and burnout is real.
I'll share a few.
1. Don't get tunnel visioned into the problem you're solving. Prioritize maintaining your professional relationships, especially with your manager, over all else. Prioritize what your manager cares about over whatever you think is more important.
2. Async-communication does not replace real-time communication. People cannot help but reveal more when you're communicating in real-time. This is crucial because of the next point.
3. Do NOT assume good intentions. Sadly, the tech industry is full of backstabbers across organizations of all size. If people have an issue with how you're doing something, no matter how small, no matter how trivial, expect that it'll go directly to your manager and be kept hidden from you.
You're as disposable as any other worker drone. Plan accordingly.
Somewhat true if you remain a programmer. Much less true once you have an understanding of the business.
As a programmer your skills are very replaceable. Your domain knowledge less so, and your knowledge of the code base even less so.
If you intend to stay at this level then its worth highlighting this value regularly to management. Because they are for sure being reminded daily that there's a fresh-grad waiting to elite code for little money.
But ultimately yes, coders can be replaced. Ots not terribly hard, crumbs even an AI can do it.
Understanding the business though is next level. By understanding the short, medium and long term needs of both the business and the customers you are well positioned to target "doing the right work" rather than just the "fun work".
As a part-coder part-manager you are slso more able to bridge the knowledge gap between upper management (who are exclusively business) and the coders (who are exclusively technical. )
Focusing on clear communication in terms that suit the audience really assists job security. For example selling the eradication of some technical debt, as a business advantage, yo upper management is more likely to suceed if it aligns with business goals than just "the techs want to pretty up the code."
> Somewhat true if you remain a programmer. Much less true once you have an understanding of the business
Everyone is replaceable. I’ve never heard of any company of more than 5 people who didn’t survive after someone left.
If you hit hit by a bus tomorrow, your company would send your next of kin flowers and “thoughts and prayers” and forget you exist within a month
Everyone else is giving vague "life lesson" posts, so I'll buck the trend: Django and React. I put off learning web dev stuff for far longer than I should have out of some mistaken sense of purity or something. Instead I only started early looking into them around me 2021 or so, when I could have been learning as early as 2010!
It'll probably all be automated within a few years :/ Not a good time to learn web dev.
There's no such thing as too late.
That grunt work will never feel meaningful.
E.g. working the website of a forefront AI lab doesn't feel meaningful. More like you're the idiot for having spent your life on web dev, while some are fixing humanity's last problem.
You have to aim high from the get-go.
The most useful programming language is Bash.
I wouldn't say I learned this too late, but ashamedly, I didn't learn this truth until after ShellCheck was released. I have thousands of hours of experience writing Python, Ruby, and Perl, but I no longer have any use for them.
That tech job is as much about business and people as any other industry. I.e. “tech” part is only a small part of it.
I realized, being a manager overseeing people, chasing after career progression was a wrong path. I should have stuck to what I like more, engineering, not bullshitting.
A manager who doesn’t like bullshit can be a very powerful resource to their employees.
agreed. depends on how competent a manager is or the org is in recognizing their employee's skills.
Build your own profit business, no matter how small it is, as earlier as possible.
I did this, so I completely agree with this advice.
But of course then you really need to do the business first, and right, and the coding comes second.
If you plan to go down this route I recommend exposure to accounting either at school or college (or via external self study.) I did it at school, and while I'm not involved much in accounts these days, being able to read them, and understand them, is really useful and important.
Yes I’m sure that everyone can build a for profit business that replaces even the income of a mid level enterprise dev.
Surely you are not suggesting someone work full time and then spend their time off working on side projects? This is the most toxic traits of our industry.
First of all, I don't think it's ever "too late" as long as you're breathing. That said, there are things I wish I'd learned earlier.
I couldn't give you a complete list of those things off the cuff, so I'll just pick one that is sort of "top of mind". I haven't thought this out in detail, so consider this me basically "thinking out loud".
So... to put it in very loose terms, I'd say I wish I'd learned to really appreciate the importance of focusing on human to human interactions and how people communicate, interact, evaluate, and understand each other. Of course that's tritely obvious on one level, but to really really internalize those lessons is a different thing.
And while it might seem silly, I'll say that one thing that helped me learn a lot was watching the TV show "Billions". Very early on in that show I kept noticing certain behaviors by the various characters that led them to bad (or sub-optimal) situations, or behaviors they used to improve their standing, etc. And I'm NOT saying that any of those characters should be seen as role models mind you. Just that watching the show kinda "smacked me in the face" in a very visceral way with regards to appreciating some things I had not really fully appreciated before.
To illustrate (spoiler warning if you haven't seen the show)... in Season 1 there's a tense meeting with the two main characters - Chuck Rhoades and Bobby Axelrod, to sign a settlement that had already been agreed to. Note, they had an agreement that made everybody happy. This should have been a simple "show up, sign the papers, call it done" deal. But Axelrod let his ego cause him to start mouthing off at Rhoades, who in turn let his ego be offended and then he ratcheted up his demands for the settlement, which eventually led to Axelrod tearing up his settlement payment check, and walking out without signing the deal. This led to all sorts of bad shit and was a suboptimal outcome for everybody involved.
The lesson (as I took it)? Detach your ego from things. Focus on the outcome you want, not how things make you feel in the moment. Don't let a brief moment of anger derail something you've been working on for months (or years, etc).
And there are very many similar lessons embedded in that show. I do recommend it to basically everybody, FWIW.
Anyway, getting back on point. I guess I'd add that I now realize that I was probably too focused on technology qua technology earlier in my career. And again, I knew that this wasn't optimal on some level. But it takes a while sometimes to go from a surface / superficial understanding of something, to a really deeply internalized understanding. Now, I get more the importance of the "human element", understanding how the business works, understanding the interpersonal dynamics of a company, etc.
Edit: let me add one more thing.
Don't whine, or complain, or sulk at work. Ever. Just don't. it might feel good, but there is basically zero chance that doing so will help your situation at all, and a very high chance that it will hurt your standing in the org and compromise you at some point. If you have a legitimate grief, sure, talk to your manager in a strictly business-like, professional manager. Eg, "Look boss, you have me doing X, and I'll do it as long as you want me to, but I'd really prefer to be doing Y. Do you think we could find a way to shift my role more to Y" or something along those lines. But sulking, acting pissed off, bitching around the water cooler, etc. are no behaviors that will help you. Trust me on this. And don't ask me how I know. :-)
HTH.
If there is something to be done, and it also needs to be done right, you can never rely on others. You have to do it yourself.
no matter your age and experience level, you can move organisations if you know how to tell stories.
You only have 1 to 5 years left for your tech career unless if you're world class level programmer. AI is not good enough yet but the next versions of AI in the coming years is going to eliminate at least 90% of software engineer's jobs. Most companies have already stopped hiring.
Save as much money as you can and buy land.
Land? Why?
For savings it will soon fail. Urban land value rises with a growing working-population. What are the demographics in your area? In New Zealand we have immigration pressuring land value, however if our economy tanks then urban land values will dive.
For prepper? Good luck keeping your land against your violent neighbours when anarchy hits!
Rich enclaves might grow in value, but you need to already be rich to buy in.
AI?
How many hours do you spend programming? There's a lot of work that AI won't replace: like understanding client needs. Maybe you haven't been through a few past hype cycles? Predictions of needing less developers have been made before.
Utter nonsense peddled by people who invested way too much money into AI.
That remapping Caps lock to Esc is great.
That age discrimination post VC infection is real. Back when I started in 90 we had senior engineers with white hair. I distinctly remember brushing aside my father's advice when he cautioned me about such things. "No, not in software. It is a pure meritocracy". Hah. (Implicit lesson: listen to your elders /g)
Second lesson then was that engineering as a career is for chumps; young ones: start your own business.
Age discrimination is real, of course, just about everywhere.
My experience though is different to yours. I joined a bootstraped company in 1992 as emp number 1. Basically me and the founder. We were both in our 20s.
In those years everyone in computers was young. We had no "adults in the room". We did a lot right, and a bunch wrong. I grew a beard to look older. When we had programmer user-group meetups everyone was our age.
That hasn't really changed, except now we are the grey beards :)
Of course we had young workers, I was one of them. Except we also had actual grey beards and -no one- ever said silly things such as "anyone over 30 is over the hills" as was the norm (here on HN) in the 21st post "internet". It was very much a different field, and yes, my first two jobs were with startups, as a matter of fact.
I am 50. Been in software development since 1996 and found it easier to get jobs post 45 than ever. I did my first stint at BigTech at 46 and found what most would consider good paying jobs within 3 weeks both in 2023 and last year.