You did not explicitly state the goal of the advice, I think it would be interesting to distinguish between advice that is meant to increase your value to the company, and advice meant to increase your satisfaction with your work, especially when the two point in opposite directions.
For example it could be that “swallow[ing] your pride and us[ing] that garbage language you hate so much” is good for the company in some cases, but terrible for job satisfaction, making you depressed or angry every time you have to use that silly language/tool.
I think it’s more that learning to prioritize effectiveness over aesthetics will make you a more effective software engineer. Sometimes terrible languages are the right tool for the job, and I find it gives me satisfaction to pick the right tool even if I wish we lived in a world where the right tool was also the objectively best language (OCaml, obviously).
You want to be tending your value system so that being good at your job also makes you happy. It sounds like a cop-out but that’s really it, really important, and really the truth. Being angry you have to do your job the best way possible is not sustainable.
The goal is writing good software to solve a particular problem. Using haskell to write an SPA is not going to work well whether your doing it for someone else or for yourself (assuming you care about the product and it’s not just a learning/fun exercise). It is a perfectly valid decision to say that you’ll only work on products where Haskell is a good fit, but I would strongly recommend against using Haskell where it’s not a good fit in a production setting, and would consider it low key fraud to do so where somebody else is paying you for your time.
but terrible for job satisfaction, making you depressed or angry every time you have to use that silly language/tool.
My experience is that once you get over yourself, and put in the effort to properly understand the language, best practices, etc. you might not love the language, but you’ll find it’s actually fine. It’s a popular language, people use it, and they’ve found ways to sand down the rough edges and make the good bits shine. Sure it’s got problems but it’s not as soul destroying as it looked at first sight, and you’ll likely learn a lot anyway.
(I’m not talking about a case where a company forces you to use a deprecated language like COBOL or ColdFusion . I’m talking about a case where you pick the language because it’s the best tool for the job).
This is in general good career advice. You’ll lose out on a lot of opportunities if you refuse to put yourself in uncomfortable situations.
You did not explicitly state the goal of the advice, I think it would be interesting to distinguish between advice that is meant to increase your value to the company, and advice meant to increase your satisfaction with your work, especially when the two point in opposite directions.
For example it could be that “swallow[ing] your pride and us[ing] that garbage language you hate so much” is good for the company in some cases, but terrible for job satisfaction, making you depressed or angry every time you have to use that silly language/tool.
I think it’s more that learning to prioritize effectiveness over aesthetics will make you a more effective software engineer. Sometimes terrible languages are the right tool for the job, and I find it gives me satisfaction to pick the right tool even if I wish we lived in a world where the right tool was also the objectively best language (OCaml, obviously).
You want to be tending your value system so that being good at your job also makes you happy. It sounds like a cop-out but that’s really it, really important, and really the truth. Being angry you have to do your job the best way possible is not sustainable.
The goal is writing good software to solve a particular problem. Using haskell to write an SPA is not going to work well whether your doing it for someone else or for yourself (assuming you care about the product and it’s not just a learning/fun exercise). It is a perfectly valid decision to say that you’ll only work on products where Haskell is a good fit, but I would strongly recommend against using Haskell where it’s not a good fit in a production setting, and would consider it low key fraud to do so where somebody else is paying you for your time.
My experience is that once you get over yourself, and put in the effort to properly understand the language, best practices, etc. you might not love the language, but you’ll find it’s actually fine. It’s a popular language, people use it, and they’ve found ways to sand down the rough edges and make the good bits shine. Sure it’s got problems but it’s not as soul destroying as it looked at first sight, and you’ll likely learn a lot anyway.
(I’m not talking about a case where a company forces you to use a deprecated language like COBOL or ColdFusion . I’m talking about a case where you pick the language because it’s the best tool for the job).
This is in general good career advice. You’ll lose out on a lot of opportunities if you refuse to put yourself in uncomfortable situations.