I am also a computer science assistant professor like Cal Newport so I can relate to what he is trying to say here.
An academic paper in computer science usually consists of applying a well defined "technique" to a well defined "problem." For example
applying "Support Vector Machines" to "Text Classification" or applying "Expert Systems" to "Medical Diagnosis" or
applying "Particle Filters" to "Robot localization"
The crux of what Newport is referring to is that in practice, many(most?) academic researchers don't deeply learn new techniques that are outside of their immediate research agenda after leaving grad school. They will certainly be AWARE of new techniques and might learn their high level ideas but they won't really learn them deeply enough to be able to improve them or use them in a non-trivial way. It is much much easier to continue exploiting and building upon the techniques they have already mastered than to invest several painful months(years?) to master completely new techniques.
So what Newport is suggesting that you should stop applying your current methods that are easy and very productive for you and make a substantial investment of time and energy to master the latest techniques - even if you don't exactly know how you're going to apply them
A programming analogy: If you're a C++ programmer, stop doing C++ projects and spend at least 3 months until you're an expert in Python. If you're a Python programmer, stop writing Python and invest several months in becoming an expert in Go. (the analogy is not perfect because mastering a new language is probably a bit easier and more fun than the kind of things Newport is talking about)
Here are a couple of thoughts I had on this:
(1) How applicable is this idea outside of academic research? For example, in academia there is a big reward for being the FIRST person to apply a given technique to a certain problem, but outside of research being the 2nd or 3rd person to do something can be just fine. (See: Friendster, MySpace, Facebook). So maybe you can afford to wait until someone has shown a great application of a new technique and only then jump in and try to exploit it.
(2) An opposing but also convincing idea is that it is better to focus your efforts in one area to avoid spreading yourself too thin. Such focus allows you to gain "comparative advantage" and to easily do things that are difficult for people who don't have your deep experience. In other words, it is better to spend your efforts trying to become the world's greatest Python hacker than to jump on the bandwagon of every new programming language that comes out and ending up as a "Jack of all trades, master of none."
My conclusion: I do think it is worthwhile to challenge yourself not to just stick to what you already know (which in my personal experience is VERY easy to do especially if you find that you're very productive using what you know). But you also have to be selective. Life is too short to try to be a master of everything. And there is great value in gaining a very deep expertise in a particular topic or technique.
Switching languages every 3 months does not sound like a way for most mortals to get a lot of concrete things done, although perhaps you will have a payoff of knowledge after several years, assuming you do not already know several languages.
Most mortals will end up with some half-baked newbie projects and a huge long list of languages they have used, apply for jobs and find that any given job is really only interested in one or max two blub languages
Indeed, academia rewards this kind of technique focus, in large part because academia is not much about truth and more about making a name with sexy stuff, connections, writing big grants, etc.
And also, Python, Riak, Redis. And these are only the tools that I did use with great success.
Others are PHP, MySQL (and other *SQL), Java, C#. Of course, once I found out that they are "no good" for finding new exciting problems to solve, I dropped them, so I didn't become a "master" of them. With the exception of MySQL, which I think I am a "master" of.
EDIT: also, I never claimed that 3 months is the magic number. It was a (wild) guess by someone else.
Second Edit: Also, for quite some time I have been studying C, Haskell, Lisp and to lesser extend some other stuff. I am already quite familiar with the type of problems they shine at. Once such a problem emerges, I will readily jump on it, and will intensify my learning of the tool in question.
It is good to know multiple languages, but I think at some point you are only marginally making your job easier by learning yet another. The article, at least as I read it, speaks to learning something new that makes solving a problem, that was previously out of touch, significantly easier.
Maybe a different programming analogy would be that you know C++, and then you learn some electronics and realize that you can now build a small wristwatch computer using a basic microcontroller – something that would have been impossible with the full-fledged PCs you are used to programming on.
I can confirm that this works for a programmer. I didn't even know that I function like this, before reading the article.
I will go even further, and state that it works for everything.
And it's very often better to be a "master" of several trades, than a "grand-master" of one. Of course, if you are the grand-master of a trade, things are completely different, as we all know.
I was once a medical student. But before that, I wasn't attending a high school specializing in natural sciences, but an "English Language School" (I'm from Bulgaria, Eastern Europe). So knowing English made me a better medical student. One day, I discovered the general purpose computer, and I became obsessed with that. Being good at computers, made me even more outstanding amongst my colleagues.
I learned Linux, server administration, network administration and I was a god.
I decided to switch careers (computers are so much fun), and I became a programmer. Lacking the education, I started at the lowest possible position - a Junior Visual Basic programmer in a company, close to the end of the world :).
And guess what, I was WAY better than my colleagues. I had almost no experience, but I was already a scientist. You won't believe me, but there are so many programmers out there who are not scientists. And I knew Linux, I knew networking. I was learning Python in my spare time, and I started discovering problems, so easy to solve with Python. I was already a god at that company, from day one. Not to mention that I was already learning "web". HTML, CSS, JavaScript, web servers, reverse proxies, "http accelerators", databases etc.
I was very fast to land a python web programming job after a few months of "experience". And guess what? I was already learning "NoSQL" databases in my spare time. I knew how to solve problems with CouchDB. We started implementing stuff in CouchDB. I also became obsessed with XMPP, and started using it to solve more problems. That's how I found Erlang (ejabberd).
I learned Erlang, and I was now able to solve even more interesting problems. The new job offer followed...
Now I write Erlang services (and I utilize XMPP), and I find new problems to solve with my new tools - Redis, Riak, riak_core. And I am exploring more tools. I wonder what will be the next big thing. Haskell? Ocaml? Lisp? C? (yes, I have yet to utilize the power of C). But I am certain it will follow. I can't help being myself.
During all this time (roughly 5-6 years since I program), I never really became a "grand-master", but knowing all these tools is really a new experience of its own.
The single tool that I left behind is Visual Basic (never really liked it anyway). All the others are of great use to me till now. Even Medicine. It was the best one to teach me how to deal with complex systems.
Could you elaborate on what you mean when you say are a scientist and there are many programmers who are not scientists?
I presume he's talking about people who probably shouldn't be programming (those that routinely write code the likes of which show up on thedailywtf.com; you know, stuff that assigns variables multiple times in a row). Apart from that, it's also telling that even most "computer scientists" don't know much outside of programming, even for the domains they work in. I count myself lucky that I get to work with people who have PhDs in basic sciences on a daily basis; just keeping up in work discussions requires delving into some really interesting science papers and books. Granted, I couldn't write you Dijkstra's algorithm right away, but that's why I keep the CLR book around.
Correct. I am talking about people who are not very good at logic and scientific reasoning. People who know how things "are" (because someone taught them so in the university) and don't care why. People who blindly follow "design patterns" and use their "hammer", regardless of the screw they are trying to deal with.
People who say "I only learned Pascal at school. Let's use that for the problem at hand" (No offence to Pascal and people using it).
People who know the Java standard libraries by heart (and have an excellent diploma because of that), but can't produce a simple working program, because they lack understanding of the nature of computing.
The above are real examples of people I have worked with.
(2) An opposing but also convincing idea is that it is better to focus your efforts in one area to avoid spreading yourself too thin. Such focus allows you to gain "comparative advantage" and to easily do things that are difficult for people who don't have your deep experience. In other words, it is better to spend your efforts trying to become the world's greatest Python hacker than to jump on the bandwagon of every new programming language that comes out and ending up as a "Jack of all trades, master of none."
My conclusion: I do think it is worthwhile to challenge yourself not to just stick to what you already know (which in my personal experience is VERY easy to do especially if you find that you're very productive using what you know). But you also have to be selective. Life is too short to try to be a master of everything. And there is great value in gaining a very deep expertise in a particular topic or technique.
I've come to the conclusion that, if possible, it's best to be a "jack of all trades, master of one". It may take longer, or you may never truly attain mastery, but being flexible and not just willing, but eager to push yourself to learn new and different things is always a good thing. If nothing else, find something you enjoy enough to get enough skill in to pay the bills and then play with other things in your spare time.
This is particularly interesting to me, because while I find I could become obsessed with something enough to attain deep mastery, I find there are so many awesome things to learn and play with that I don't want to miss out on them. This could explain why I didn't go to grad school (and go on to become a professor, a once dream of mine) and haven't founded my own startup, but instead prefer to languish at a 7-4 day job with the government and sample everything from robotics to music to cooking to search and rescue in my spare time. To be sure, I still push myself at the job (it's funny you specifically mention C++ and Python: I'm finishing up Coplien's Advanced C++ while delving back into Python for the robotics as well as smartphone/tablet programming, and Go has also piqued my interest). The one limiting factor to try and keep me focused is that I try to keep my learning to tools that are open source, so as not to suffer from lockin and platform obsolescence. Plus there's the technical superiority of open source software in general.
You might have difficulty focusing (or a preference not to) but with a day job and so many other interests, you would get a lot of benefit from focusing your programming efforts, because the left over time is so limited.
Which one is the most viable way out of 'languishing'?
You might have difficulty focusing (or a preference not to) but with a day job and so many other interests, you would get a lot of benefit from focusing your programming efforts, because the left over time is so limited.
Well, I do have a bit of a problem focusing; I've got dozens of projects scattered in my home directory that are half finished, it's just the discipline isn't there.
Which one is the most viable way out of 'languishing'?
I get back to my side software projects every once in a great while; once I make something worth releasing, I'll put it out there. Maybe just find some OSS projects to help with; I'm good at cleaning up other people's code. I'm not willing to sacrifice one of my hobbies to go back to grad school or found a startup (both of which would also require moving), but I sometimes fancy I could quit my day job and freelance.
An academic paper in computer science usually consists of applying a well defined "technique" to a well defined "problem." For example applying "Support Vector Machines" to "Text Classification" or applying "Expert Systems" to "Medical Diagnosis" or applying "Particle Filters" to "Robot localization"
The crux of what Newport is referring to is that in practice, many(most?) academic researchers don't deeply learn new techniques that are outside of their immediate research agenda after leaving grad school. They will certainly be AWARE of new techniques and might learn their high level ideas but they won't really learn them deeply enough to be able to improve them or use them in a non-trivial way. It is much much easier to continue exploiting and building upon the techniques they have already mastered than to invest several painful months(years?) to master completely new techniques.
So what Newport is suggesting that you should stop applying your current methods that are easy and very productive for you and make a substantial investment of time and energy to master the latest techniques - even if you don't exactly know how you're going to apply them
A programming analogy: If you're a C++ programmer, stop doing C++ projects and spend at least 3 months until you're an expert in Python. If you're a Python programmer, stop writing Python and invest several months in becoming an expert in Go. (the analogy is not perfect because mastering a new language is probably a bit easier and more fun than the kind of things Newport is talking about)
Here are a couple of thoughts I had on this:
(1) How applicable is this idea outside of academic research? For example, in academia there is a big reward for being the FIRST person to apply a given technique to a certain problem, but outside of research being the 2nd or 3rd person to do something can be just fine. (See: Friendster, MySpace, Facebook). So maybe you can afford to wait until someone has shown a great application of a new technique and only then jump in and try to exploit it.
(2) An opposing but also convincing idea is that it is better to focus your efforts in one area to avoid spreading yourself too thin. Such focus allows you to gain "comparative advantage" and to easily do things that are difficult for people who don't have your deep experience. In other words, it is better to spend your efforts trying to become the world's greatest Python hacker than to jump on the bandwagon of every new programming language that comes out and ending up as a "Jack of all trades, master of none."
My conclusion: I do think it is worthwhile to challenge yourself not to just stick to what you already know (which in my personal experience is VERY easy to do especially if you find that you're very productive using what you know). But you also have to be selective. Life is too short to try to be a master of everything. And there is great value in gaining a very deep expertise in a particular topic or technique.