Not to mention, the app you're in can inject JS into the page it renders. Best practice is to open in your default browser and then allow the deeplink in the callback_uri to return you back to the original app
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.
