Please notice that some long-term goals are in conflict, but some are not—see the examples provided by lsusr here.
In jobs, there are often two types of knowledge: company-specific and company-independent. An example of the former would be knowing who is who in the company structure, or some specific details about navigating company bureaucracy (who needs to approve your vacation, how to file expense reports, how to buy tickets for business trips and how to get them reimbursed), or products that were developed withing the company and will never be used outside of it. An example of the latter is general profession-related skills (if you are a programmer: programming skills, or knowledge of generally used tools and libraries), or social-skills, or other general skills (such as math).
So, yeah, if you find yourself pushed towards spending too much time (small amounts are inevitable) obtaining company-specific knowledge, that is unlikely to be profitable in long term (useless outside the job, which also worsens your negotiation position within the job), so try to avoid it, or quit. But if you spend your time learning general skills (e.g. becoming a better programmer), then there is no conflict: you become better at your current job and improve your position on the job market.
(Ironically, company-specific things can be useful for you, if you are the one who creates them. For example, using a software framework developed internally in the company usually sucks a lot. But if you are the one who develops it, that is great, because you learn the general skill of designing and developing software frameworks. It just sucks to be everyone else in the company, because they are spending their time adapting to the outputs of your work. You get better; they get stuck with the things you designed before you got better.)
Not a complete answer (also I am running out of time now), but perhaps choose a more generally useful skill. There is an article I currently can’t find, written by Paul Graham, about how you should choose skills that keep more options open. For example, math in general has lots of uses, programming is more specialized, programming in Java is even more specialized, programming in Java Server Faces version 1.0 is utterly useless… therefore, unless there is a good reason to do otherwise, study math. This is more important the younger you are, when you have more time to get long-term benefits of the general skills. (If you are five years before retirement, just learn whatever will get you most money in short term, when the thing becomes obsolete, it will no longer be your problem.)
Thanks, Viliam. I appreciate your insights. I read a few Paul Graham essays, and I loved them, and I’m going to read all of them.
I agree with you that acquiring generally useful skills such as mathematics is a good bet. I’ve been in the software industry for ~3 years, and sadly the most mathematics I’ve used in my software job is multiplication.
I tend to perform best if I have a north star to motivate my learning and practising. This north star is something for me to figure out, and it’s a never-ending process.
I came across this interview with Demis Hassabis recently. (Demis inspired me to study CS in the first place.) He said there is no defined career path in academia if you want to be a career engineer, meaning that academia loses the best engineers because they choose to work in the industry. I’m very excited about the many new opportunities that allow engineers to contribute to research projects in the industry, so for me, this seems like a nicely defined goal to go after.
Please notice that some long-term goals are in conflict, but some are not—see the examples provided by lsusr here.
In jobs, there are often two types of knowledge: company-specific and company-independent. An example of the former would be knowing who is who in the company structure, or some specific details about navigating company bureaucracy (who needs to approve your vacation, how to file expense reports, how to buy tickets for business trips and how to get them reimbursed), or products that were developed withing the company and will never be used outside of it. An example of the latter is general profession-related skills (if you are a programmer: programming skills, or knowledge of generally used tools and libraries), or social-skills, or other general skills (such as math).
So, yeah, if you find yourself pushed towards spending too much time (small amounts are inevitable) obtaining company-specific knowledge, that is unlikely to be profitable in long term (useless outside the job, which also worsens your negotiation position within the job), so try to avoid it, or quit. But if you spend your time learning general skills (e.g. becoming a better programmer), then there is no conflict: you become better at your current job and improve your position on the job market.
(Ironically, company-specific things can be useful for you, if you are the one who creates them. For example, using a software framework developed internally in the company usually sucks a lot. But if you are the one who develops it, that is great, because you learn the general skill of designing and developing software frameworks. It just sucks to be everyone else in the company, because they are spending their time adapting to the outputs of your work. You get better; they get stuck with the things you designed before you got better.)
Not a complete answer (also I am running out of time now), but perhaps choose a more generally useful skill. There is an article I currently can’t find, written by Paul Graham, about how you should choose skills that keep more options open. For example, math in general has lots of uses, programming is more specialized, programming in Java is even more specialized, programming in Java Server Faces version 1.0 is utterly useless… therefore, unless there is a good reason to do otherwise, study math. This is more important the younger you are, when you have more time to get long-term benefits of the general skills. (If you are five years before retirement, just learn whatever will get you most money in short term, when the thing becomes obsolete, it will no longer be your problem.)
Thanks, Viliam. I appreciate your insights. I read a few Paul Graham essays, and I loved them, and I’m going to read all of them.
I agree with you that acquiring generally useful skills such as mathematics is a good bet. I’ve been in the software industry for ~3 years, and sadly the most mathematics I’ve used in my software job is multiplication.
I tend to perform best if I have a north star to motivate my learning and practising. This north star is something for me to figure out, and it’s a never-ending process.
I came across this interview with Demis Hassabis recently. (Demis inspired me to study CS in the first place.) He said there is no defined career path in academia if you want to be a career engineer, meaning that academia loses the best engineers because they choose to work in the industry. I’m very excited about the many new opportunities that allow engineers to contribute to research projects in the industry, so for me, this seems like a nicely defined goal to go after.