5 ms·

David Epstein's Range has a lot to say about this topic. Carmack's idea of 'deep' work [0] is environmentally dependent. It works for him and for the places he

David Epstein's Range has a lot to say about this topic. Carmack's idea of 'deep' work [0] is environmentally dependent. It works for him and for the places he has been at. But it is not a universal rule for learning in all environments. Epstein uses Tiger Woods and Roger Federer as his headline case, but goes into many other forms of learning. Woods' golf is a kind learning environment; the rules are clear, the feedback is quick, the skills are straightforward. Federer's tennis is an unkind learning environment; the rules aren't as clear, the feedback isn't as quick, and the skills are more murky. A lot of tennis is the mind-game aspect and in elite tennis, you don't get the same person very often. With programming and development, the environment Carmack talks about is a kind learning environment (rules are stated, feedback is a compile away, skills are practicable). Contrast this to the business/marketing people whose environment is unkind (unclear rules, long feedback cycles, skill overload). Epstein relates the method to be great at a thingy is to know what environment you are in. This gives the keys to success. In kind learning environments like programming, golf, or chess, the key is practice and drilling, to do it until you can't be bad anymore. In unkind learning environments like tennis, jazz, or marketing, the key is to learn as many things as you can as broadly as you can, to gain a reservoir of ideas to use. [0] not Cal Newport's idea of 'deep work', to be clear.

almost_usual 6y ago
This is an interesting perspective, from a technical view it seems like the difference between writing library and debugging a system. Programming a library referencing an RFC seems kind, the rules are already there. Debugging a performance issue in a large distributed system is unkind, you need a lot of existing knowledge and ideas to know where to start.
- mason55 6y ago
  I don't know, I think debugging a perf issue in a large distributed system still falls under kind work to me, assuming you actually have a way to tell when it's fixed. Yes, you need a lot of knowledge, but the rules and outcomes are still clear. Compared to writing a novel or painting, it's very clear when you've reached success and it's hard to argue that you've been successful. IMO the "unkind" work that a typical engineer does is things like writing specs. The work itself does not give you any feedback about if you're making progress or doing a good job. Of course it's all on a sliding scale, and if your perf issue takes four weeks to surface after each deploy then that's a much less kind environment. But, in general, anything that you can put clear metrics around is much closer to the "kind" bucket to me because those metrics give you a clear path for improvement and iteration (the major risk is getting stuck in some local maximum).
  - username90 6y ago
    > I don't know, I think debugging a perf issue in a large distributed system still falls under kind work to me, assuming you actually have a way to tell when it's fixed. Yes, you need a lot of knowledge, but the rules and outcomes are still clear. Compared to writing a novel or painting, it's very clear when you've reached success and it's hard to argue that you've been successful. The same goes for poker, you know when you won a hand. However winning a hand doesn't mean you learned something, similarly successfully debugging a large performance issue doesn't mean you learned something either. The learning we actually care about in software engineers isn't kind at all.
- Balgair 6y ago
  Epstein kinda treats things as a binary: un/kind. But I think there is a spectrum of 'environmental kindness'. Troubleshooting is a good case of this. If all you do is debug a single system, then you'll get really good at it, via practice. It starts out environmentally unkind, but ends up being environmentally kind via repeated use. While if you have to debug multiple systems and add in new systems, then you stay in an environmentally unkind situation. Being a mechanic on your own car is one thing, but working in a shop with new cars and problems coming in all the time is another.
- webmaven 6y ago
  > Programming a library referencing an RFC seems kind, the rules are already there. Depends. Is there a reference implementation? A format/protocol validator? An interoperability matrix? What's the ratio of SHOULDs and MAYs to REQUIREDs, SHALLs, and MUSTs? Does the RFC reference other RFCs? What are the answers to these questions regarding those? I mean, I wouldn't ever describe the task of implementing a SOAP[0] or WebDAV[1] library as 'kind'. Oh, and if you're working at a sufficiently large org, be prepared to battle it out with a competing internal implementation for the coveted position of 'company standard'. Note that you (or your boss) may not actually want to win that battle, as internal customers will make all sorts of unreasonable demands[2], and implementing them all will cut into your real work and negatively affect your evaluations and career advancement. Also, refusing to implement those requests will get you labelled as "not a team player" and negatively affect your evaluations and career advancement. Fun times! [0] https://www.shlomifish.org/humour/by-others/s-stands-for-simple/ https://www.shlomifish.org/humour/by-others/s-stands-for-sim... [1] https://www.slideshare.net/mobile/tobyS/webdav-the-good-the-bad-and-the-evil https://www.slideshare.net/mobile/tobyS/webdav-the-good-the-... [2] https://dilbert.com/strip/1995-11-17 https://dilbert.com/strip/1995-11-17
ignoramous 6y ago
> Federer's tennis is an unkind learning environment; the rules aren't as clear, the feedback isn't as quick, and the skills are more murky. A lot of tennis is the mind-game aspect and in elite tennis, you don't get the same person very often. The Inner Game of Tennis [0] for folks interested in learning more about this. [0] https://www.amazon.com/Inner-Game-Tennis-Classic-Performance/dp/0679778314 https://www.amazon.com/Inner-Game-Tennis-Classic-Performance... PS Novak's probably more clutch than Rog.
- suyash 6y ago
  Anyone who has played some tennis can attest that it's more mental than physical specially when you're playing against opponents of the same level. No magic about that.
- Austin_Conlon 6y ago
  Novak also has to deal with hostile crowds a lot more, who are in denial that he’s on track to surpass Roger and Rafa. He’s possibly under-appreciated because he doesn’t have the flair of the other two, but rather a robotically consistent, precise, and relatively low risk style.
d23 6y ago
> In kind learning environments like programming I'd agree this is the case up to a point with programming, but some of the most important aspects of the job are in the things that are unkind, like how well your design will hold up under future maintenance. Often times there are no feedback mechanisms whatsoever for whether you've done a good job. Or they're slow and coarse and can be ignored or justified away. It's easy to just hop onto the next project and leave the mess you've made behind. The more subjective stuff like how to approach problems as well as what to write and not to write in the first place -- these are what separate people who can technically do the job from those at higher levels. And often even a successful application here ends up getting overlooked by the very fact that it Just Works and doesn't make a lot of noise. This is just one aspect of the unkindness. There's also how effective you are, how reliable your systems are, how productive you are, whether you pick the right things to invest in learning about, how well you solve problems, how well you debug, how well you coordinate with peers, how well you are able to understand and navigate existing systems, and how well you communicate technical ideas. Many of these things compound in positive or negative directions over time. I've yet to see any good materials teaching most of this stuff, and I suspect plenty of people will go their entire careers without ever really figuring out or being aware of a large chunk of it.
- bryanrasmussen 6y ago
  The description of programming is kind really depends on what you are doing: are you building things that all sorts of different systems need to integrate with that you don't necessarily know what the technical specifications of these systems are = unkind are you designing a database schema and writing queries against it = kind are you doing frontend development (or something similar where fast paced change means new technology, new best practices etc. all the time) = unkind are you doing text processing analysis of structured data following well understood schemas = kind I mean really, they gave two examples of sports one which was kind one unkind - but for programming it is just kind?
  - Balgair 6y ago
    Epstein goes through many other examples of learning environments in the book, most of which I found to be very entertaining and informative. To be clear, Range is not an academic article, and is very much in the 'pop-psych' genre like Gladwell or Talib. That said, it's well worth a Christmas vacation to read through. Gates had it on his best books in 2020 list for a reason (though it was published in 2019). Pick up a copy yourself from the local library (if open/online) or you can buy it yourself: https://www.amazon.com/Range-Generalists-Triumph-Specialized-World/dp/0735214484 https://www.amazon.com/Range-Generalists-Triumph-Specialized...
nickjj 6y ago
I was nodding along until the last sentence of: > In unkind learning environments like tennis, jazz, or marketing, the key is to learn as many things as you can as broadly as you can, to gain a reservoir of ideas to use. I think this very much applies to kind (programming) too. Sometimes the biggest programming level ups requires broadly knowing about this, that and the other thing. For example, you can practice writing file upload code until your eyes bleed but if you're unaware of the implications of what uploading to local disk brings in a containerized or Heroku-like platform then a lot of what you know suddenly falls apart. Your entire basis of what you've been doing might need to be rewritten or drastically altered (creating a "storage" abstraction, etc.). With software development it's super valuable to get a broad understanding of many parts of the stack, not just individual features. I say "feature" here because in a golf analogy a feature would be putting within 6 feet, chipping under 20y, or using a driver. In golf you can individually learn these things in isolation and your overall game improves in the end. In programming this isn't as clear cut IMO.
ookookookook 6y ago
>programming as work >rules are stated I'm not sure where you work but I'd love this kind of environment.
- deleted 6y ago
  [deleted]

almost_usual 6y ago

This is an interesting perspective, from a technical view it seems like the difference between writing library and debugging a system. Programming a library referencing an RFC seems kind, the rules are already there. Debugging a performance issue in a large distributed system is unkind, you need a lot of existing knowledge and ideas to know where to start.

mason55 6y ago
I don't know, I think debugging a perf issue in a large distributed system still falls under kind work to me, assuming you actually have a way to tell when it's fixed. Yes, you need a lot of knowledge, but the rules and outcomes are still clear. Compared to writing a novel or painting, it's very clear when you've reached success and it's hard to argue that you've been successful. IMO the "unkind" work that a typical engineer does is things like writing specs. The work itself does not give you any feedback about if you're making progress or doing a good job. Of course it's all on a sliding scale, and if your perf issue takes four weeks to surface after each deploy then that's a much less kind environment. But, in general, anything that you can put clear metrics around is much closer to the "kind" bucket to me because those metrics give you a clear path for improvement and iteration (the major risk is getting stuck in some local maximum).
- username90 6y ago
  > I don't know, I think debugging a perf issue in a large distributed system still falls under kind work to me, assuming you actually have a way to tell when it's fixed. Yes, you need a lot of knowledge, but the rules and outcomes are still clear. Compared to writing a novel or painting, it's very clear when you've reached success and it's hard to argue that you've been successful. The same goes for poker, you know when you won a hand. However winning a hand doesn't mean you learned something, similarly successfully debugging a large performance issue doesn't mean you learned something either. The learning we actually care about in software engineers isn't kind at all.
Balgair 6y ago
Epstein kinda treats things as a binary: un/kind. But I think there is a spectrum of 'environmental kindness'. Troubleshooting is a good case of this. If all you do is debug a single system, then you'll get really good at it, via practice. It starts out environmentally unkind, but ends up being environmentally kind via repeated use. While if you have to debug multiple systems and add in new systems, then you stay in an environmentally unkind situation. Being a mechanic on your own car is one thing, but working in a shop with new cars and problems coming in all the time is another.
webmaven 6y ago
> Programming a library referencing an RFC seems kind, the rules are already there. Depends. Is there a reference implementation? A format/protocol validator? An interoperability matrix? What's the ratio of SHOULDs and MAYs to REQUIREDs, SHALLs, and MUSTs? Does the RFC reference other RFCs? What are the answers to these questions regarding those? I mean, I wouldn't ever describe the task of implementing a SOAP[0] or WebDAV[1] library as 'kind'. Oh, and if you're working at a sufficiently large org, be prepared to battle it out with a competing internal implementation for the coveted position of 'company standard'. Note that you (or your boss) may not actually want to win that battle, as internal customers will make all sorts of unreasonable demands[2], and implementing them all will cut into your real work and negatively affect your evaluations and career advancement. Also, refusing to implement those requests will get you labelled as "not a team player" and negatively affect your evaluations and career advancement. Fun times! [0] https://www.shlomifish.org/humour/by-others/s-stands-for-simple/ https://www.shlomifish.org/humour/by-others/s-stands-for-sim... [1] https://www.slideshare.net/mobile/tobyS/webdav-the-good-the-bad-and-the-evil https://www.slideshare.net/mobile/tobyS/webdav-the-good-the-... [2] https://dilbert.com/strip/1995-11-17 https://dilbert.com/strip/1995-11-17

ignoramous 6y ago

> Federer's tennis is an unkind learning environment; the rules aren't as clear, the feedback isn't as quick, and the skills are more murky. A lot of tennis is the mind-game aspect and in elite tennis, you don't get the same person very often. The Inner Game of Tennis [0] for folks interested in learning more about this. [0] https://www.amazon.com/Inner-Game-Tennis-Classic-Performance/dp/0679778314 https://www.amazon.com/Inner-Game-Tennis-Classic-Performance... PS Novak's probably more clutch than Rog.

suyash 6y ago
Anyone who has played some tennis can attest that it's more mental than physical specially when you're playing against opponents of the same level. No magic about that.
Austin_Conlon 6y ago
Novak also has to deal with hostile crowds a lot more, who are in denial that he’s on track to surpass Roger and Rafa. He’s possibly under-appreciated because he doesn’t have the flair of the other two, but rather a robotically consistent, precise, and relatively low risk style.

d23 6y ago

> In kind learning environments like programming I'd agree this is the case up to a point with programming, but some of the most important aspects of the job are in the things that are unkind, like how well your design will hold up under future maintenance. Often times there are no feedback mechanisms whatsoever for whether you've done a good job. Or they're slow and coarse and can be ignored or justified away. It's easy to just hop onto the next project and leave the mess you've made behind. The more subjective stuff like how to approach problems as well as what to write and not to write in the first place -- these are what separate people who can technically do the job from those at higher levels. And often even a successful application here ends up getting overlooked by the very fact that it Just Works and doesn't make a lot of noise. This is just one aspect of the unkindness. There's also how effective you are, how reliable your systems are, how productive you are, whether you pick the right things to invest in learning about, how well you solve problems, how well you debug, how well you coordinate with peers, how well you are able to understand and navigate existing systems, and how well you communicate technical ideas. Many of these things compound in positive or negative directions over time. I've yet to see any good materials teaching most of this stuff, and I suspect plenty of people will go their entire careers without ever really figuring out or being aware of a large chunk of it.

bryanrasmussen 6y ago
The description of programming is kind really depends on what you are doing: are you building things that all sorts of different systems need to integrate with that you don't necessarily know what the technical specifications of these systems are = unkind are you designing a database schema and writing queries against it = kind are you doing frontend development (or something similar where fast paced change means new technology, new best practices etc. all the time) = unkind are you doing text processing analysis of structured data following well understood schemas = kind I mean really, they gave two examples of sports one which was kind one unkind - but for programming it is just kind?
- Balgair 6y ago
  Epstein goes through many other examples of learning environments in the book, most of which I found to be very entertaining and informative. To be clear, Range is not an academic article, and is very much in the 'pop-psych' genre like Gladwell or Talib. That said, it's well worth a Christmas vacation to read through. Gates had it on his best books in 2020 list for a reason (though it was published in 2019). Pick up a copy yourself from the local library (if open/online) or you can buy it yourself: https://www.amazon.com/Range-Generalists-Triumph-Specialized-World/dp/0735214484 https://www.amazon.com/Range-Generalists-Triumph-Specialized...

nickjj 6y ago

I was nodding along until the last sentence of: > In unkind learning environments like tennis, jazz, or marketing, the key is to learn as many things as you can as broadly as you can, to gain a reservoir of ideas to use. I think this very much applies to kind (programming) too. Sometimes the biggest programming level ups requires broadly knowing about this, that and the other thing. For example, you can practice writing file upload code until your eyes bleed but if you're unaware of the implications of what uploading to local disk brings in a containerized or Heroku-like platform then a lot of what you know suddenly falls apart. Your entire basis of what you've been doing might need to be rewritten or drastically altered (creating a "storage" abstraction, etc.). With software development it's super valuable to get a broad understanding of many parts of the stack, not just individual features. I say "feature" here because in a golf analogy a feature would be putting within 6 feet, chipping under 20y, or using a driver. In golf you can individually learn these things in isolation and your overall game improves in the end. In programming this isn't as clear cut IMO.

ookookookook 6y ago

>programming as work >rules are stated I'm not sure where you work but I'd love this kind of environment.

deleted 6y ago
[deleted]