Hacker News new | past | comments | ask | show | jobs | submit login

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.




> 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.


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?


  are you designing a database schema and writing queries against it = kind
I worked in a project using MongoDB. Initial implementation was easy and quick to iterate. After a few years when it was evident that it was not sustainable. Two years of painfull effort was required to squeeze out MongoDB.

  are you doing frontend development (or something similar where fast paced change means new technology, new best practices etc. all the time) = unkind
React already won, front-end tech is stable in last 4 years. It is an easier part of my job. Front-end development require high upfront learning, but it is boring at some point.

  are you doing text processing analysis of structured data following well understood schemas = kind
I know some pipelines on structured data that are hell. I worked with XML (FpML) and systems that produced/consume these, It would make most people cry. It is very easy to create massive technical debt where data is flowing. Any change needs to be done from both ends. It is not like front-end where I can refactor components as much I want.

Because programming is such diverse field, I would be careful with labeling anything kind/unkind.


>Any change needs to be done from both ends.

If the change needs to be done on both ends it is probably an integration problem, which I labelled unkind.

The use of the words kind/unkind is probably not well-thought out, because kind implies easy, but there is nothing in the description of the term that means it is an easy thing to do.


Kind because there is an obvious path forward. Unkind because there is uncertainty over time. In programming there is no objective measures for code quality, cost of maintenance or even productivity of individuals.

I would argue that programming is fundamentally unkind. You can only learn a small fraction of stack and operate on assumptions. It is very hard to learn from other people's experiences as it is hard to quantify complexity. If someone is preaching for microservices you can only understand tradeoffs by having a specific knowledge/experience. That why we have people still using PHP for new projects because they are so entrenched in their local maximum.


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...


to expand on this I sort of have to expect, if this whole kind/unkind thing is to mean anything at all, that any reasonably large area of human endeavor (sports, programming, politics, law, music, etc. etc.) will have some sub-fields that are either kind or unkind, although I suppose some areas (like politics or business) might skew extremely towards the unkind.


> 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...

PS Novak's probably more clutch than Rog.


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.


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.


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.


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).


> 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.


> 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-sim...

[1] https://www.slideshare.net/mobile/tobyS/webdav-the-good-the-...

[2] https://dilbert.com/strip/1995-11-17


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.


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.


>programming as work >rules are stated

I'm not sure where you work but I'd love this kind of environment.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: