[kodah]

> Most of the gatekeeping of what is and isn't "coding" is done by novices who don't really know what they're talking about. Beginners tend to want a hard line with "coding" on one side and "not coding" on the other, but that's not a very useful way to model interactions with computers.

I disagree. There's a meaningful distinction between what is code and what is formatting because the concerns are quite different. This distinction is more apparent on frontend applications where the code bits are actually dealing with the fact that there's a single process doing all these seemingly asynchronous things, the use of very infrastructure-like components (eg: pubsub implementations, stores, etc). Formatting and design doesn't need to deal with the how, it needs to deal with the why. The powerhouse of a developer is knowing both.

Trying to shoehorn peoples attitudes into discriminatory experience levels based on your perception of that rhetoric is an odd behavior unto itself. These topics merit talking about because ultimately they affect how we think, reason, and organize on different layers of projects.

You actually somewhat proved my point with your example of CSS. It more recently became capable of more "code like" qualities, but it can definitely be used for just styling and formatting. Without discussion someone may never know the difference or why you'd use some of CSSs computational capabilities. Another crossover is YAML; YAML can be very markup language oriented but it also supports aliases, pointers, etc.

[lolinder]

I agree that the distinction you're drawing is valuable, but it's not a distinction between "code" and "not code": both aspects are defined with a language that the computer parses, interprets, and executes on. One happens to be a declarative language that deals with the what and why, and the other an imperative one that deals with the how.

> Trying to shoehorn peoples attitudes into discriminatory experience levels based on your perception of that rhetoric is an odd behavior unto itself.

I think this is a bit of an overreaction to my words. Referring to someone as a beginner is not discriminatory, we all start as beginners and it's okay to not know things. It's also okay (and desirable!) for those of us who do know better to help novices to learn the material and the culture better than they now do. And the fact is that "what counts as coding" is not a discussion that serious developers have between themselves.

> These topics merit talking about because ultimately they affect how we think, reason, and organize on different layers of projects.

I believe that "code" and "not code" aren't useful categories for dividing up CSS, HTML, YAML, JavaScript, Haskell, and C. We're capable of enough nuance to distinguish between them while still acknowledging that they're all languages which we use to tell a computer what to do. Let's talk about them in that nuanced way, not try to split the world into a code/everything-else binary.

[kodah]

> both aspects are defined with a language that the computer parses, interprets, and executes on.

Sure, but low order definitions of "code" being something that takes an input and produces a different output do not relate to the real world unless you believe modern word processors require programmers.

> Referring to someone as a beginner is not discriminatory, we all start as beginners and it's okay to not know things.

I think you're missing the point that the statement you made applies to a wide variety of discussion, not simply binary code|not_code discussions.

> Most of the gatekeeping of what is and isn't "coding" is done by novices who don't really know what they're talking about

This statement would also imply anyone trying to sort out coding from formatting, from styling as a novice. There's a reason we separate these activities in programming that has to do with how you model applications not to mention empowering the people who have expertise in doing them.

While I agree that code|not_code is not helpful, trying to make the definition of code so low order that it's meaningless is also not helpful. There's a bar there that belongs in the middle and I think you both have missed it. I was merely calling out equally harmful wording that you were using to correct harmful wording.

[andrewaylett]

It's not "code" and "not code", it's "software engineering", "programming", and "using a computer".

So many more people program computers than think they're programming. Anything that allows a computer to reproduce what would otherwise be a manual set of steps is programming. Made a bookmark in your browser? That's programming. Excel is definitely programming. And have you ever tried styling a web page using only the browser dev tools? CSS is hardcore programming, and people who claim otherwise are often snobs who find CSS too hard so they call it "not programming" in order to feel better about themselves.

Software Engineering is a whole different ball game. It's not so much what as how and actually the "programming" bit is almost always the easy part. That's why Software Engineers run away when someone asks them to look at "this really useful spreadsheet than $PERSON made" -- chances are that person doesn't think of themselves as a programmer, but that's what they've been doing and they're actually really good at it. But only in isolation, while Software Engineering involves working with whole systems and (more importantly) both the people who use them and the people who work on them.