[cpressey]

I agree with your point. But to riff off dschiptsov's comment, how do you define "programming" (as opposed to, say, "coding"), and how does knowing programming help you answer questions like "How can I speed up harvesting on my farm?"

I would call the ability to understand and solve those kinds of problems analysis, not programming. It used to be the case that "systems analyst" and "programmer" were two different job titles; at this point, they've largely merged, but I still see them as two different skill sets. (And then there's "software engineer" which is a whole other can of worms.)

[empoman]

That's a fair question, so I'll try to explain how I see it. Problem analysis as you mentioning it, to me, seems like the theoretical form of programming. So here I see "coding", or programming, as an easy way to practice problem analysis in a real context, and not just by going through a text book like we do with math in school.

And I agree with you regarding programmers and system analysts. There are so many titles and job descriptions nowadays that try to look fancier than the other just to make it easier arguing for a higher salary. Even if what they do is basically the same. Here in Sweden, there is a long running "joke"-ish alternative title for a cleaner, and that is "hygiene technician". One sounds fancier than the other, but it really isn't.

Regarding how speeding up the harvesting would be done, I have no idea since I am not at all familiar with how a farm works. The point I was trying to make is that if you have knowledge about the domain of farming, AND you know how to program (or if you are good at problem analysis, which I think you are if you can program), then I'm sure that it would be easier to think of something than if you weren't.

Does it make sense or am I just rambling like a crazy person? :D

[cpressey]

That's a reasonable answer, and yes, it makes sense.

You could say analysis is a theoretical form of programming, or correspondingly, that programming is an applied form of analysis -- specifically, applied on computers.

I guess my main reservation is that if kids' first exposure to analysis is through programming, there's a risk of skewing their perception towards looking for solutions that use computers. ("When all you have is a hammer, everything looks like a nail.")

In my experience, I've seen problems that have been approached like: We're doing X too slowly, and it's costing us; what kind of computerized tool can we build to let us do X more quickly? And after the tool has been built, it introduces a new set of processes with its own set of burdens, and X is not really done significantly more quickly. My conclusion is that you often need to step back and re-examine what people are actually doing (and why), and what they actually want to accomplish (and why.)

(And a significant obstacle with that is that people develop habits, and they get comfortable with them, and don't want to change them -- so, without knowing the details of the problem, the first step in "How can I speed up harvesting?" would probably be to have some willingness and flexibility to try out variations in your methods of harvesting.)

If we can find ways of teaching kids to program that build their problem-solving skills while also not clouding their heads with the idea that computers are necessarily part of the best solution, I'm all for it.