Unlike what this review seems to imply, the author of the book doesn't actually discount that concept - he says it's true for a certain kind of activity, one with reliable feedback, such as programming. Quote from the interview I linked:
"The way that chess works makes it what's called a kind learning environment. So, these are terms used by psychologist Robin Hogarth. And what a kind learning environment is, is one where patterns recur; ideally a situation is constrained--so, a chessboard with very rigid rules and a literal board is very constrained; and, importantly, every time you do something you get feedback that is totally obvious--all the information is available, the feedback is quick, and it is 100% accurate. Right? And this is chess. And this is golf. You do something: all the information is available; you see the consequences. The consequences are completely immediate and accurate. And you adjust accordingly. And in these kinds of kind learning environments, if you are cognitively engaged you get better just by doing the activity. On the opposite end of the spectrum are wicked learning environments. And this is a spectrum, from kind to wicked. Wicked learning environments: often some information is hidden. Even when it isn't, feedback may be delayed. It may be infrequent. It may be nonexistent. And it maybe be partly accurate, or inaccurate in many of the cases. So, the most wicked learning environments will reinforce the wrong types of behavior."
That is actually discussed in this review (kind versus wicked learning environments). It just isn't at the top of the article because it's not as catchy.
Would you count coding as a kind or a wicked environment? To me, it seems wicked - standards change, you switch languages, frameworks come and go. On the same token, it could be 'kind' if you isolate yourself to one or two robust languages (i.e. your career is built on C++).
Even for that, though, if you define your criteria for success, it's mostly possible to measure the outcomes and learn whether your approach was successful or not. One key there is remembering that subjective metrics are valid - user happiness and developer happiness are two of the most useful ones I know of for measuring the system's overall health and effectiveness, and while they're not objective, they can still be measured reasonably quickly and regularly.
For fields like public policy, though, there are just so many confounding factors and the timeframes are so long that it becomes nightmarish, maybe even impossible, to genuinely learn anything. The subjective metrics of citizen happiness and functionary happiness that are analogous to my software ones above are worthless because of rollout times measured in years or decades and the infinite array of factors, confounding and otherwise, that go into people's satisfaction with society.
Even relatively straightforward things like farming have learning cycles measured in years for things like crop rotations.
The universe is just not a friendly learning environment.
Programming is an aberration in almost every respect, as a product of the human mind that can actually have useful impacts in the world (most friendly environments are human constructs that are not "useful" per se, like board games or musical performance or sports).
That's definitely less kind, and it's a huge problem in practice. I think it's still not that bad -- people can and do get much better at designing things for medium- to long-term maintenance over the course of a few years.
Coding is something you can learn on your own with a tool, some books or manuals, and time. The compiler provides a lot of feedback, debuggers and manuals give you a lot of information to develop your skillset. A few books on algorithms and data structures and specific domains (like graphics or network) will get you to a solid point as a programmer.
But developing systems that are high quality, multi-component, interacting with other complex systems, and sustainable is another thing altogether. It is costly, tradeoffs are sometimes non-intuitive, and you probably need to have a mentor or a good work environment to really get skilled at it, or the right kind of analytical mind. But you'll still have a lot of failures along the way and need to develop a lot of different skills.
Nah, even that is extremely kind, unless you never see how your program is doing a few years later.
Usually you get feedback within 1/2 a year. That complicated search system with your own fantastic DSL an absolute nightmare to modify? Kind feedback. Your system works fine with 100 users but falls over with 10,000? Kind feedback. You used a trendy new js framework that disappeared 2 years later? Kind feedback.
And better still our industry has tons of people who write lots of books or do podcasts or do conferences where they talk about how their projects went wrong, and how they fixed them. Whether it was the GoF design patterns, or Code Complete or one of the many others.
Coding is kind. The dichotomy is based on feedback availability, quality, and delay. While the environment does change over time, it continues to be kind: 99% of the time, you're able to hit compile and see instantaneous, accurate feedback. Doesn't matter which language, framework, or standard you're using (except maybe Malbolge). Even debugging is kind save perhaps for heisenbugs, but that's a bit of a stretch to declare the whole field a wicked environment.
I disagree with the other responses. I think it's both. You can get very quick results and feedback for experiments related to implementation. Code compiles or doesn't, tests pass or they fail. But whether you actually built the correct thing is definitely "wicked." A lot of times subtle bugs and user feedback surface weeks or months after the fact. It can be very hard to find out whether what you did worked for the business need, which is ultimately the main point of the job.
It depends, in some regards it's kind as the results are seen immediately (is a path bringing more or less compilation errors, etc), whereas as in others it takes time to see if the decision you made was good or bad (did the architecture you chose scale).
Once you code for long enough, every language begins to look the same and it becomes easy to switch. I have worked full time with PHP, JS, Java, Python, Objective C, and C++. That's at both multiple startups and at a FAANG.
In fact, if you choose one strongly typed language and one weakly typed to know in depth (eg Java and JS) it's really easy to move to others.
The trap that people fall into is that they focus too much on learning the ins and outs of a framework and not the important concepts. Or they are stuck in a problem domain that's very thin on CS concepts, like web dev or frontend dev. You don't learn concepts that make it easy to transition.
From my own experience, focusing on CS and math (esp. stats) and systems programming have made it really easy to move around.
It has helped that in the last 10 years most of the languages have converged to an extent.
Like before things like generics and lambda expressions C#/Java were quite different to Python/Ruby, and js used to be quite an abysmal language but with some nice features nothing else had (still is an awful language to an extent). I think C# 2.0 and 3.5 really changed that language for the better, Java spent a lot of time getting to the C# 3.5 level.
And I remember a time when C++ was almost incomprehensible if you'd never worked in it, but now it seems to be a lot less daunting as you've got bridging languages like Rust and Go.
I must admit I've still no interest in Haskell/F#/etc. I tried Lisp about 10 years ago and it just seemed such a pain, for me I find imperative programming so much easier to map out complex interactions in my head. I also find set based programming like SQL very easy. But functional, ugh.
Agreed, I feel like most languages have converged into some kind of variant of C#. Even JS, if you count Typescript.
For multithreading, I would take functional over imperative any day though. The multithreaded code I write in Java ends up looking like functional code by way of chaining futures, but it is still hindered by the use of shared memory and synchronization (or lack thereof).
I enjoy C++, and the additions in C++ 11 and 14 are mostly good ones. But they don't do anything to make the language more approachable IMO.
neat, that's how i basically intuit the difference between playing basketball and working. feedback in basketball is immediate and (mostly) obvious; not so in many work environments. basketball for me is like a microcosm of work (working in teams, varying skillsets, differing tactics, etc), which leads directly to my oft-reliance on basketball analogies at work. =)
"The way that chess works makes it what's called a kind learning environment. So, these are terms used by psychologist Robin Hogarth. And what a kind learning environment is, is one where patterns recur; ideally a situation is constrained--so, a chessboard with very rigid rules and a literal board is very constrained; and, importantly, every time you do something you get feedback that is totally obvious--all the information is available, the feedback is quick, and it is 100% accurate. Right? And this is chess. And this is golf. You do something: all the information is available; you see the consequences. The consequences are completely immediate and accurate. And you adjust accordingly. And in these kinds of kind learning environments, if you are cognitively engaged you get better just by doing the activity. On the opposite end of the spectrum are wicked learning environments. And this is a spectrum, from kind to wicked. Wicked learning environments: often some information is hidden. Even when it isn't, feedback may be delayed. It may be infrequent. It may be nonexistent. And it maybe be partly accurate, or inaccurate in many of the cases. So, the most wicked learning environments will reinforce the wrong types of behavior."