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'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.
Hopefully not, and it's probably correlated with how technically complex the domain is. From my experience it's most of the web industry, but web software has increasingly evolved into gluing libraries together.
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.
You don't have to go through technical interviews for senior engineering roles? I'm someone who excels on the business side, and am not seeing that happening.
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.
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.
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.
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.
Go to where you're valued the most, even if where you are is pretty good. Sometimes leaving a good thing is hard -- but it can be good. I left my jobs pretty much when they became the most fun, but my career has been better off for it.
Getting a new job in a new org is always difficult. New people, new process, new everything, and you don't have your past reputation to gloss over mistakes -- which you're more likely to make in a new org than an old.
But ultimately, sticking around because things are comfortable might sound good, but you'll look back after 10 years and wonder just what you did.
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."
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.
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 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.
Deleted Comment
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.
Getting a new job in a new org is always difficult. New people, new process, new everything, and you don't have your past reputation to gloss over mistakes -- which you're more likely to make in a new org than an old.
But ultimately, sticking around because things are comfortable might sound good, but you'll look back after 10 years and wonder just what you did.
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 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