[nickvanw]

I would put it even more simply: just knowing Engineering isn't enough if you want to excel past a certain point, unless you're going to go extremely deep and become a subject matter expert in something (storage, hardware, etc). That is something most people are not going to do, because it requires dedication and to be extremely intelligent.

Instead, you can go very far by understanding a job one "hop" from your own - sales, marketing, finance, you name it. People who can understand the domain and translate that into code are worth 10x more than people who need to be told what to do and have it spelled out to them. If you haven't actually had butt-in-seat time understanding that domain, you probably know less of it than you think you do as well.

I see plenty of people who assume they could do the job of a sales engineer, marketer, whatever. I'm confident that many people are smart enough to do so, but having the capability does not mean having the knowledge to do a job well. Learn that knowledge.

[calvinmorrison]

This is one of the reasons a good ERP tech is often someone who started in business and shifted into consultant role.

Areas where domain specific knowledge outweighs the technical aspects, you need to be cross functional.

And overall - the biggest take away for me is that Computer Science is probably not the right degree for most people. Understanding object notation or algorithms, in my experience is interesting but much less useful than understanding business terms or learning use cases.

[siva7]

A CS degree is useful for, well, computer science and less so for most software development business use cases. It seems counterintuitive at first but makes more sense the more experience you get over different business roles.

[scarface74]

So how much more is someone “worth” who can understand the different parts than someone who made their career knowing how to play the promotion/leetCode/system design/behavioral interview game at any of the large tech companies and position themselves to show “scope” and “impact” by getting on the prime projects?

It’s a much more straightforward path and one I would recommend to anyone starting their career today.

I didn’t take that path. But seeing people who did have it much easier. No I’m not complaining. I’m good with where I am

[dayvid]

Even in those companies at the higher level you need additional skills to figure out impact and opportunities (opportunity sizing, XFN alignment, communication, good writing, etc.). Interviewing mainly gets your foot in the door.

There are some genius ICs who can just code and not be concerned about these things, but more often the higher levels are people who are good at their skill along with business, data analysis, product and communication skills.

[scarface74]

I agree with this completely and honestly didn’t think about this.

In my department in BigTech (consulting) your first paragraph is expected from an L5.

Good written and verbal communication skills and being able to work with customers is the expectation of an L4/new college grad.

Now that I think about it, I don’t think I have met an L5 SDE that I would let have anything to do with my customers directly. But I’m equally sure they wouldn’t let anyone in my department push code to core services (even though I have found a bug in the code of a core service and worked with an SDE to fix it).

[nickvanw]

Well, in my opinion, it remains to be seen whether big tech compensation for this style of work is sustainable long-term. Of course, if you're already pulling 800k/y in TC at Google/Amazon/whatever, great, you did wonderfully. If you're a brand new engineer starting your career, are there going to be a lot of those 800k jobs that offer you free daycare, dry cleaning, lunch and massages? I wouldn't bet on it. I say this as someone that has also not taken this path, but have nothing but respect for people who make a great living that have.

Otherwise, I think this is exactly how big companies succeed - they build career paths, tools and workflows to bring context to large groups of smart people to get them moving in the same direction. Ultimately there still have to be people to create the bridge, but the lever you get is massive when you have 1000s of talented engineers. You can't expect them all to understand how $x works, but you can pepper teams with extremely smart and talented experts and professional managers who collectively get them working on the impactful parts of the problem.

TL;DR there isn't a linear path, my advice is mainly for people thinking about how to be able to build value. If you can do that, you'll always be able to get a job.

[scarface74]

I spent most of my career on the “enterprise dev” side of the bimodal distribution of tech compensation. I only landed on the BigTech side by doing a slight pivot (cloud consulting).

I don’t see the day coming anytime soon that the divide narrows where it does make sense to be on the “enterprise dev” side (where most developers are) over the $BigTech side.

I’m objectively good enough at all of the areas that the article lists - I have to be to succeed in true “consulting” (as opposed to staff augmentation). But that wouldn’t have mattered unless I jumped ship to the $BigTech side.

Most outside consulting companies aren’t paying their top employees what I make as a mid level employee at my current job.

I have one or two connections I could probably leverage on the enterprise dev side that would allow me to make more if I jumped ship. But that’s only because I have $BigTech experience on my resume.

I’m not disagreeing with you. Even before working at $BigTech, I could throw my resume up in the air and get a job as a developer without doing the leetCode monkey dance because I had the skills you listed and I spoke directly to CxOs and Directors at small companies based on my network.

I haven’t done a coding interview in over a decade.

[6510]

I imagine if you are really good at the other job the software can teach people a lot. You can force patterns where they should exist (do things in the right order) and not force them where they shouldn't be.

I think with less skilled labor the developer knows even less than they think.

Say the job is stacking boxes, you have an order 4 hours worth of heavy boxes and 4 hours worth of light ones. In software one is tempted to think there are 2 ways of doing the job. First order 1 then 2 or first 2 then 1. Push this button when order 1 is done!

It might not be humanly possible to stack heavy boxes non stop for 4 hours but it is definitely a bad idea. Thanks to the new software it's going to take 6 hours and cut the "resting" time (time doing light boxes) in half.

[giantg2]

"because it requires dedication and to be extremely intelligent."

I'm a dumb-dumb. Being a dumb-dumb in two domains isn't very helpful either. Everyone wants experts.

[cyrusatjam]

I see a stronger argument in a similar vein: "instead of spreading your knowledge thin, focus on your improving your ability in the domain you're paid to be good at."

But I'd counter that this doesn't mean you must permanently focus on one domain. On the contrary, every area of focus has a learning curve. And as many jaded HN commentors will point out, being exceptionally good at CS does not translate to being paid well, or being good at your job.

Naturally, even if you don't care to learn about Sales, Design or Product in the course of your Software Engineering career, you will still have to learn more than just pure Maths and CS. Simple skills: estimations, task breakdowns. More complicated skills: interfacing with other teams, juggling priorities, assigning work and pipelining tasks between teammates on 2+ person projects. And obviously, negotiating for compensation is entirely-unrelated to your work yet very impactful on your salary.

P.S. Nobody wants experts, people just want someone who can get the job done. Often times the hardest problems in an organization are not technical problems--they are communication problems. Having an understanding of multiple domains helps you bridge that gap and communicate at eye-level with other stakeholders.

[giantg2]

"Nobody wants experts, people just want someone who can get the job done."

Yet most of the time they select for those people who can get it done by looking for expert qualifications on resumes.

"Having an understanding of multiple domains helps you bridge that gap and communicate at eye-level with other stakeholders."

At least my experience in finance is that the blocker isn't communicating but rather bias. I once had some questions about a story related to an accrual. The title was for a daily accrual yet the acceptance criteria was for a monthly accrual with a daily snapshot. I brought this up and the PO told me "build it the way I say". Three weeks later I was showing my code to a consultant and he was like "why is it working this way". I told him. So then the PO listened to him after we wasted a sprint on the initial implementation.

[Zetice]

Totally disagree; if you can be a dumb-dumb in two domains, you're going to do a lot better, overall, than just being a dumb-dumb in one domain.

Wanna know why? Cuz you're not actually a dumb-dumb. <3

[giantg2]

I'm pretty sure I am. I've even had a manager tell me in a 1-on-1 "not everyone has the potential to be more than a mid level". Here I am 10 years into my career and still a midlevel.

[Zetice]

That person is awful at their job, ignore them.

[giantg2]

Even if I ignore them, it's hard to ignore the facts.

[Zetice]

Like the fact that you’re incredibly insistent that a random stranger believes you’re dumb?

[solarmist]

With what you've said, it makes sense to feel that way. I would encourage finding ways to think about it/express it, one that doesn't make it a character flaw.

Can you phrase it in a less absolute/intrinsic way, though? "I am a dumb dumb" isn't a solvable problem.

I encourage you not to personalize this (Using "I am"). You may not be a mediocre software engineer, but that does not equal YOU being a dumb dumb.

That's a false equivalence. I'm sure there are areas where you are not a dumb dumb.

[solarmist]

I understand what you're attempting here, but invaliding someone's feelings, even if they aren't true, doesn't work and isn't helpful. All it does is make a person not trust their feelings (at best) instead of calibrating their feelings and understanding where they come from.

Instead, accept that they feel some way. And encourage them not to let those feelings hold them back (also, avoid "but"s those also minimize or invalidate feelings).

For example, even if someone is suicidal, psychologists are trained to listen and accept their feelings.

Then help them understand why they feel that way and if other interpretations or actions can make extreme thoughts and feelings more manageable or understandable.

Depressed/suicidal people have the most accurate grasp of reality. Self-delusion and protection from self-harm are built-in into the psyche, so it's not that their feelings are inaccurate, but that unrealistic optimism is the only way humans (and other animals) can cope with reality.

[BeFlatXIII]

That's what lying on your résumé and practicing believing those lies for the interview are for.