I see value in this article, but it seems to think about code as working in isolation. Snippets. You can see everything.

Many times you’re working with libraries or interacting with existing code, where not everything is so clear, the “specification” is fuzzy at most, and how the outcome state is achieved is far from obvious. So, code _can_ happen to you and you then need to dig the why.

I agree with your point. In my experience, code happens to you more often than not because when you run something, most of the code that's running was not written by you.

There could be a whole another article titled "Code Happens to You" about debugging other people's code, including dependencies and sometimes even the compiler.

I find this particularly with UI frameworks with a large, ever-changing surface. Adobe Flex was absolutely terrible for it. iOS has some of the same issues. Trying to work out why some text has reflowed and bumped down your controls may not technically be "code happening to you", but it sure feels like it.

I would argue that the puzzle-solving paradigm could be useful if you go in understanding that the nature of the "puzzle" is to solve for every possible edge case and understand why those edge cases materialized in the first place. There are times where working backwards into code that fits a model is a reasonable way to do it. But this does, at least, presuppose that you understand your code to be deterministic, not some voodoo you copy/pasta.

I agree with the identification of these two attitudes, but I'd like to add they they are not mutually exclusive, or that one is strictly always more correct than the other.

In a slightly different light, I'd call the first attitude "academic" and the second "practical", without any particular positive or negative attributes.

They are both valuable and appropriate at the right times. This article is in the context of learning, and I do recall interactions with learners of both attitudes. Those embedded too strictly in either generally did worse than those who would think academically about a problem, approach it practically and evaluate it academically.

We have the strict "documentation tells this, and so therefore my code is correct" kind of adherence to the academic attitude, but when they lack the experience needed to fully understand the documentation, and are too rigid to do experimentation to validate their understanding..

We have the strict "but it works when I do that" but avoids referring to the documentation to try and understand WHY it works when you do that, and so miss out on opportunity to learn how to think up that solution without brute force.

Middle ground is way to go.. Read documentation, experiment to validate, analyze resulting solution to gain deeper understanding.

Attitude 1 is a true description of what is going on; but if you're dealing with a large, complex system that you can never grok completely, then Attitude 2 seems to be a more useful way of approaching things. At least sometimes.

Attitude 1 seems like particle physics, which isn't much use for describing macroscopic processes like a bouncing tennis ball.

Having also taught coding to new programmers: Yes, “like learning to speak a new language” is a bad metaphor if it’s delivered the way it’s presented in the text. However the same metaphor delivered with the added details that the language is very simple, and the listener very literal becomes good. And so goes the beginning CS class.

My two categories of coding learners might be: those that overthink it with amazingly creative ideas, and; those that don’t and accept it as simple. The latter group may learn syntax and algorithms more quickly, and the former’s liability quickly becomes an asset. The two groups rarely see eye-to-eye but collaborate powerfully.

>The two groups rarely see eye-to-eye but collaborate powerfully

This resonates with me. I’ve worked with some programmers who I respect a lot but doing CRs my mind got blown because they took the hyper-efficient approach of “do the minimum but no more” and my mind is “well there’s this edge case, this can be refactored easily, you could hook this up here instead” and I’ve pretty much just accepted that my style isn’t their style. Code gets merged, business has continuity, I keep working with awesome people.

That said, I don’t really write a whole lot of code and never have. I still consider myself a SWE but I can typically make the computer do what I need it to using pre-existing things and scripts.