4 ms·
“Mastering” is a tricky term to use here. It could imply simply gaining a level of competency/proficiency that means you basically can use the language to acco
by travisgriggs 5y ago
“Mastering” is a tricky term to use here.
It could imply simply gaining a level of competency/proficiency that means you basically can use the language to accomplish things without feeling owned by the language. I think this is the kind the author is getting at.
But mastering can also mean rising to a guru level of proficiency where you can do things with the language that the majority of your peers cannot.
I find this second difficult to achieve in a polyglot sense. I used to be able to do guru level things with Smalltalk. For the last 10 years I’ve done no Smalltalk and embraced the way of the polyglot, becoming moderately proficient in Python, Kotlin, Swift, Linux cli, Elixir, C, but in no ways do I have the bandwidth to chase “guru level” with any of these. That kind of mastery usually comes from focus and experience, something that’s difficult (impossible?) to achieve when your task switching cognitively. Even with Smalltalk, I would have to swim in the waters a while before I felt I was in a master position again.
This kind of mastery also makes you a better programmer. “To boldly take this language to solutions no one has tried before” will definitely hone skills.
At the end of the day, it really boils down to “keep pushing yourself to learn new and varied things” and you’ll grow. If you decide to cache in and just leverage your acquired wisdom, you’ll stagnate.
- lytefm 5y agoYes, I feel like aiming for a T or Pi shape is a good analogy: Try to truly master the 1 or 2 languages you work with most of the time. Have a good enough knowledge of other languages in order to learn and grow or to use them for specific needs. Edit: typo.
- kedean 5y agoI like splitting it into competency and expertise. In my own personal experience, you can be competent with as many languages as you want, but most people can only hold expertise in a few at a time. Generally, your expertise is going to be the ones you actually use daily, because use is the only way to deepen your understanding. I, for example, and primarily a Java and Python developer during the day, so those are my expertise. Those are the ones I feel confident telling someone to come to me with any questions on, the ones that I know the internals of, the ones I can confidently solve most problems in without having to look much up. As a web developer in my younger days, I considered myself an expert in PHP and Javascript, but I know that I no longer hold that status with them. I could immediately understand if I were to read anything with them, but to start something from scratch I would need some lead-in time, so I'm only going to call myself competent. I use Ruby periodically today, but not on important enough things that I need to understand it deeply, so again I would only call myself competent. I'll sure put all of those on my resume though, along with other competencies and former expertise.
- jerf 5y agoI am disenchanted with "guru level" work in a language. The old saying about "if I'm just barely smart enough to write the code, I'm not smart enough to debug it" is true immediately, and then even more true if there's a 3-6 month delay. I appreciate being back in a language long enough to not have to look things up all the time, but the dialect of all of them I write in gets simpler and simpler over time. Portable guru knowledge like "I know how to write an interpreter/compiler" and "I know that for this task there must be a library in $LANGUAGE" and "I know that language construct/function call looks simple but it has to be an O(n^2) algorithm for it to be doing what it says its doing" is much more useful.
- igouy 5y ago> … a tricky term to use here Strange to me that no one has mentioned fluency (as programming languages are languages).