12 ms·

Can anyone elaborate on what Carmack is suggesting here? To specialise in some tool early in your career? Or something else? I don't quite get it. (Or at least

by st1x7 6y ago

Can anyone elaborate on what Carmack is suggesting here? To specialise in some tool early in your career? Or something else? I don't quite get it. (Or at least I don't get why it would be such a good idea.) Carmack is usually great to listen to, by the way; check out some of his interviews or talks if you haven't before.

soneca 6y ago
My take: learning the fundamentals of the web and programming is essential to become a good senior software engineering some day, but knowing React is what gets me hired at junior positions.
elyseum 6y ago
To me, it’s about being able to bring (direct) added value to a company. Focussing on specific tooling is an example of doing that. Learning deeply is important as well, but it usually brings value to the company on the long term (if at all).
eeks 6y ago
I believe he means that by better understanding the tools, one better understands the trade.
- elyseum 6y ago
  True. Learning tools doesn’t have to be a negative thing.
- szszrk 6y ago
  You said what I wanted to say but in 5% of my comment length. I would love to speak English that well.
- gorjusborg 6y ago
  With an added caveat that this is an indirect path to that knowledge, but perhaps a more job-compatible one.
szszrk 6y ago
He kind of explains it in the following tweets in thread. I think he says more or less: "I'm usually advocating for undestanding deeply the problem and being an expert in the matter, not in the tools that solve it that come and go quickly. But in reality it's ok to be learn the tool, as it also brings you knowledge on the same matter, eventually. It may not be as comprehensive, but it's still desired. And people who understand tools that solve the problem are also needed and it may fill some real world needs." I find it very relatable, as I'm kinda doing that at my work. I'm no expert in anything but solve problems very skillfull coders embarrass themselves at. Not that they are dumb. They are smarter than me, more expierienced as well. But they often lack a wider view of the issue, don't take account so many things. The OS in their code, neglect the existance of network, delays, assume weird things about how other software work and so on. The almost always neglect that people just lie sometimes or will fight to death to prove they tested corectly while I know they made trivial mistakes while testing. All people do. I just verify that once more. Sometimes coders ask me (after I help them with an issue) what apps do I code at our company, while I don't code at all. It would take me a year to Hello World using company internal standards. I just troubleshoot a lot. I know options. I read what you guys write here and try to understand what problems you have or don't have when using different aproaches. So I can suggest new ways of debugging, solving issues, simplifying things. I like my job. Except for the part when developers lie to me, but in general it's a cool job ;)
- dgb23 6y ago
  Interesting! I love debugging, writing (specs and docs), learning from others, teaching others (doing this part time rn), writing/tuning tools and libraries and refactoring. I sometimes wish I had more time for these things, I often have to overlook them in the face of time/budgets/features.
patrec 6y ago
I think his argument is fairly simple: 1. Learning (fundamental) stuff deeply is the way to become great. 2. But knowing how stuff works fundamentally at an abstract level (e.g. being able to write your own toy OS) is not directly economically useful (and/or very time consuming to get to that stage). So it won't get you a job. 3. So for starters learn just one thing that people actually use (say git) deeply at a concrete level. That is economically useful, because most devs will only have fairly superficial git skills, so you becoming the go-to person for git will provide economic value to the company. 4. At the same time, this is an effective way to bootstrap a more abstract deep understanding. E.g. if you really master git, you will also learn a fair amount of abstract concepts that go beyond the concrete tool (deep understanding of git implies the ability to implement at least a toy version yourself, which will teach you useful stuff; in particular if you can implement your own version of git you are probably already better than 90% of programmers). 5. Be mindful that you will be blinkered at this stage (because you only know a single thing and thus lack a basis for comparison), so don't become opinionated yet. I think this a great early career strategy as long as you pick the right thing to deep-dive into. E.g. if you picked AspectJ or Agent Learning or CASE tools or the semantic web around 15-20 years ago (at the peak of their hype-cycle), this possibly wouldn't have worked out so hot. In particular, learning some things like Spring or Freudian Psychology will probably harm rather than help your intellectual development. Making a good pick is hard if you lack experience; I'd say if in doubt pick something really everyone in your line of work uses but most people have not mastered and where there is value in mastery (and you can see how mastery might tie into things you want to learn more about at a fundamental level). Also, preferably pick something that has been around for at least 5 years (unless you are quite confident in your nose for trends).
- pmart123 6y ago
  Nice explanation.
- amitranade 6y ago
  Nice explanation. MIT’s “The Missing Semester of Your CS Education” attempts to address some of your points https://missing.csail.mit.edu/ https://missing.csail.mit.edu/
rammy1234 6y ago
we understand things at superficial level most of the time. we don't spend time to mastery. start being a generalist and learn as many things you can and want. Now pick one or two skills where you would like to go deep and gain mastery.
2OEH8eoCRo0 6y ago
"An investment in knowledge pays the best interest." - Ben Franklin
throwaway2245 6y ago
> Can anyone elaborate on what Carmack is suggesting here? To specialise in some tool early in your career? Or something else? I think he is overall suggesting that you should find your business value - your value as an employee to the business you work for. He seems to be specifically talking about "career advice", as advice for employment, so slightly outside of his own experience. He is suggesting a shortcut to this business value is to know one tool deeply enough that you become the go-to person for that tool in your company (whether or not that is in your job description).
patja 6y ago
On one of my first programming jobs, they weren't quite ready for me, so they just told me to read all the manufacturer's documentation on the platform we were using. I managed to read most of it cover to cover. Within a month I was being recognized for doing things others who had been there a year weren't even aware were an option. I've always been the type to open up a new application and explore what every single menu option offers, as well as at least digesting the whole table of contents/index to the help file or documentation.
thrower123 6y ago
It seems to tie in closely with the article from last week or so about "Blub Studies." Learn your tools, learn them well. Knowing the details of how real software actually works really compounds over time. And a huge amount of it transfers, because we just keep building newer and ever so slightly better mousetraps. https://www.benkuhn.net/blub/ https://www.benkuhn.net/blub/
silicon2401 6y ago
Probably not what he intended, but what I gained from his advice is that it's better to deeply understand a project than to just focus on building out features. I often fixate on the latter to the detriment of gaining understanding of the bigger picture. So whereas you could focus on one feature and get it done quicker, if you dive deep and understand more of the bigger system it's part of, you can not only go into features with better conceptual understanding, but you can even understand how changes will relate to other parts of the system and foresee potential consequences. For any fan of Carmack, Doom (the game), or just video games in general, I recommend reading "Masters of Doom". Carmack's story honestly reads like a programming/general nerd rockstar in the book, and it's a lot of fun. Also helps me understand what kind of personality it takes to be considered one of the best ever at something: for much of his early life, Carmack was essentially awake just to program. His home was basically a mattress and a computer at one point, IIRC.
- AlchemistCamp 6y ago
  That was a fantastic read. It pretty much defined my standard for an engineering work ethic. There are other books he played a prominent role in that I enjoined. Dungeons and Dreamers was a side by side story and contrast between Carmack and Id's path vs Richard Garriot and Origin Systems. The History of the Future features a much older John Carmack at the top of the industry, joining Palmer Lucky and a team of young entrepreneurs to build Oculus and VR. The entrepreneurial and technical ride is at least as wild as the one in Masters of Doom.
kenferry 6y ago
It's pretty interesting that there's so much variation in how we're understanding the advice. I read this as John suggesting a stair step path to "learn deeply". If you can section off one defined area, a tool, it's possible to learn _that_ inside and out in a reasonable amount of time. Then you're useful and people want you around. From there you can expand outward or down or whatever. This would be as an alternative to dabbling, learning the most commonly known things across a wide area.
iamcreasy 6y ago
Here is my interpretation. Carmack is saying learning something deeply, for example learning all features of a tool, helps in the long run, but in this approach it takes a while to provide value. An alternate approach is to learn a subset that provides immediate values. In the case learning only the subset of features of the tool that are being used at that time. That's more tractable and allows you to provided immediate value. He is leaning towards the 2nd approach because first groups of people are opinionated without broad experience. Elon Musk said something very similar. He said, lets say you need to use a wrench, but if you start from the very basic it would be extraordinarily difficult to start working. Instead you can just starting learn about the wrench and go backward from there. This was you are providing immediate values to the work at hand.

by st1x7 6y ago

soneca 6y ago

My take: learning the fundamentals of the web and programming is essential to become a good senior software engineering some day, but knowing React is what gets me hired at junior positions.

elyseum 6y ago

To me, it’s about being able to bring (direct) added value to a company. Focussing on specific tooling is an example of doing that. Learning deeply is important as well, but it usually brings value to the company on the long term (if at all).

eeks 6y ago

I believe he means that by better understanding the tools, one better understands the trade.

elyseum 6y ago
True. Learning tools doesn’t have to be a negative thing.
szszrk 6y ago
You said what I wanted to say but in 5% of my comment length. I would love to speak English that well.
gorjusborg 6y ago
With an added caveat that this is an indirect path to that knowledge, but perhaps a more job-compatible one.

szszrk 6y ago

He kind of explains it in the following tweets in thread. I think he says more or less: "I'm usually advocating for undestanding deeply the problem and being an expert in the matter, not in the tools that solve it that come and go quickly. But in reality it's ok to be learn the tool, as it also brings you knowledge on the same matter, eventually. It may not be as comprehensive, but it's still desired. And people who understand tools that solve the problem are also needed and it may fill some real world needs." I find it very relatable, as I'm kinda doing that at my work. I'm no expert in anything but solve problems very skillfull coders embarrass themselves at. Not that they are dumb. They are smarter than me, more expierienced as well. But they often lack a wider view of the issue, don't take account so many things. The OS in their code, neglect the existance of network, delays, assume weird things about how other software work and so on. The almost always neglect that people just lie sometimes or will fight to death to prove they tested corectly while I know they made trivial mistakes while testing. All people do. I just verify that once more. Sometimes coders ask me (after I help them with an issue) what apps do I code at our company, while I don't code at all. It would take me a year to Hello World using company internal standards. I just troubleshoot a lot. I know options. I read what you guys write here and try to understand what problems you have or don't have when using different aproaches. So I can suggest new ways of debugging, solving issues, simplifying things. I like my job. Except for the part when developers lie to me, but in general it's a cool job ;)

dgb23 6y ago
Interesting! I love debugging, writing (specs and docs), learning from others, teaching others (doing this part time rn), writing/tuning tools and libraries and refactoring. I sometimes wish I had more time for these things, I often have to overlook them in the face of time/budgets/features.

patrec 6y ago

I think his argument is fairly simple: 1. Learning (fundamental) stuff deeply is the way to become great. 2. But knowing how stuff works fundamentally at an abstract level (e.g. being able to write your own toy OS) is not directly economically useful (and/or very time consuming to get to that stage). So it won't get you a job. 3. So for starters learn just one thing that people actually use (say git) deeply at a concrete level. That is economically useful, because most devs will only have fairly superficial git skills, so you becoming the go-to person for git will provide economic value to the company. 4. At the same time, this is an effective way to bootstrap a more abstract deep understanding. E.g. if you really master git, you will also learn a fair amount of abstract concepts that go beyond the concrete tool (deep understanding of git implies the ability to implement at least a toy version yourself, which will teach you useful stuff; in particular if you can implement your own version of git you are probably already better than 90% of programmers). 5. Be mindful that you will be blinkered at this stage (because you only know a single thing and thus lack a basis for comparison), so don't become opinionated yet. I think this a great early career strategy as long as you pick the right thing to deep-dive into. E.g. if you picked AspectJ or Agent Learning or CASE tools or the semantic web around 15-20 years ago (at the peak of their hype-cycle), this possibly wouldn't have worked out so hot. In particular, learning some things like Spring or Freudian Psychology will probably harm rather than help your intellectual development. Making a good pick is hard if you lack experience; I'd say if in doubt pick something really everyone in your line of work uses but most people have not mastered and where there is value in mastery (and you can see how mastery might tie into things you want to learn more about at a fundamental level). Also, preferably pick something that has been around for at least 5 years (unless you are quite confident in your nose for trends).

pmart123 6y ago
Nice explanation.
amitranade 6y ago
Nice explanation. MIT’s “The Missing Semester of Your CS Education” attempts to address some of your points https://missing.csail.mit.edu/ https://missing.csail.mit.edu/

rammy1234 6y ago

we understand things at superficial level most of the time. we don't spend time to mastery. start being a generalist and learn as many things you can and want. Now pick one or two skills where you would like to go deep and gain mastery.

2OEH8eoCRo0 6y ago

"An investment in knowledge pays the best interest." - Ben Franklin

throwaway2245 6y ago

> Can anyone elaborate on what Carmack is suggesting here? To specialise in some tool early in your career? Or something else? I think he is overall suggesting that you should find your business value - your value as an employee to the business you work for. He seems to be specifically talking about "career advice", as advice for employment, so slightly outside of his own experience. He is suggesting a shortcut to this business value is to know one tool deeply enough that you become the go-to person for that tool in your company (whether or not that is in your job description).

patja 6y ago

On one of my first programming jobs, they weren't quite ready for me, so they just told me to read all the manufacturer's documentation on the platform we were using. I managed to read most of it cover to cover. Within a month I was being recognized for doing things others who had been there a year weren't even aware were an option. I've always been the type to open up a new application and explore what every single menu option offers, as well as at least digesting the whole table of contents/index to the help file or documentation.

thrower123 6y ago

It seems to tie in closely with the article from last week or so about "Blub Studies." Learn your tools, learn them well. Knowing the details of how real software actually works really compounds over time. And a huge amount of it transfers, because we just keep building newer and ever so slightly better mousetraps. https://www.benkuhn.net/blub/ https://www.benkuhn.net/blub/

silicon2401 6y ago

Probably not what he intended, but what I gained from his advice is that it's better to deeply understand a project than to just focus on building out features. I often fixate on the latter to the detriment of gaining understanding of the bigger picture. So whereas you could focus on one feature and get it done quicker, if you dive deep and understand more of the bigger system it's part of, you can not only go into features with better conceptual understanding, but you can even understand how changes will relate to other parts of the system and foresee potential consequences. For any fan of Carmack, Doom (the game), or just video games in general, I recommend reading "Masters of Doom". Carmack's story honestly reads like a programming/general nerd rockstar in the book, and it's a lot of fun. Also helps me understand what kind of personality it takes to be considered one of the best ever at something: for much of his early life, Carmack was essentially awake just to program. His home was basically a mattress and a computer at one point, IIRC.

AlchemistCamp 6y ago
That was a fantastic read. It pretty much defined my standard for an engineering work ethic. There are other books he played a prominent role in that I enjoined. Dungeons and Dreamers was a side by side story and contrast between Carmack and Id's path vs Richard Garriot and Origin Systems. The History of the Future features a much older John Carmack at the top of the industry, joining Palmer Lucky and a team of young entrepreneurs to build Oculus and VR. The entrepreneurial and technical ride is at least as wild as the one in Masters of Doom.

kenferry 6y ago

It's pretty interesting that there's so much variation in how we're understanding the advice. I read this as John suggesting a stair step path to "learn deeply". If you can section off one defined area, a tool, it's possible to learn _that_ inside and out in a reasonable amount of time. Then you're useful and people want you around. From there you can expand outward or down or whatever. This would be as an alternative to dabbling, learning the most commonly known things across a wide area.

iamcreasy 6y ago

Here is my interpretation. Carmack is saying learning something deeply, for example learning all features of a tool, helps in the long run, but in this approach it takes a while to provide value. An alternate approach is to learn a subset that provides immediate values. In the case learning only the subset of features of the tool that are being used at that time. That's more tractable and allows you to provided immediate value. He is leaning towards the 2nd approach because first groups of people are opinionated without broad experience. Elon Musk said something very similar. He said, lets say you need to use a wrench, but if you start from the very basic it would be extraordinarily difficult to start working. Instead you can just starting learn about the wrench and go backward from there. This was you are providing immediate values to the work at hand.