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.
"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.
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.
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.
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.
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.