Comment by SamBam

I've been a sysadmin for a quarter century and I've always said my only real superpower is that I read error messages when they appear, something none of my non-admin coworkers can do, for some reason.

I consider myself a fairly good developer, and I think that's in large part due to knowing, "doing this should be possible, and the reason it's not working right now is just due to stupidity (my own or the developer of whatever I'm using's)". But yes, in a few (thankfully rare) cases it just plain isn't practically possible. Even then, I've given up on problems just to have it nagging in the back of my mind and then randomly coming up with a beautifully simple solution weeks later. That's sort of the essence of what I like about programming (and math too).

Grit is something you gain once you already have an intrinsic motivation, such as already having a belief you can do this. Something has to spark in people that they’re capable in the first place.

  > I think that is a developer's superpower.

I do too, but only because we can do both.

I think comparing math education to programming education is quite apt here. After all, programming is math[0]. Both are extremely abstract subjects that require high amounts of precision. In fact, that's why we use those languages![1]

One of the absolute most difficult parts of math is that you don't have feedback. Proving you did things correctly is not automated. You can't run it and have an independent (not you) mechanism tell you that the output is what you expect it to be. This leads to lots of frustration as you sit there thinking very hard about what you've done wrong. It is frustrating because you're often blind to the mistakes as that's why you've made them in the first place! But the upside is that you quickly become attentive to details and learn those pitfalls very well. This also means you can abstract very well (the entire point of math) as you learn to abuse things on purpose. The struggle is real, but the struggle is important to the learning process. You learn very little if there's no struggle. Your mind is made to remember things that are hard better than things that are easy.

In programming we typically have the opposite problem. You get instant feedback. This makes iteration and solving your specific problem much faster. You can experiment and learn faster as you poke and prod seeing how the output changes. BUT there is a strong tendency to leverage this too much and use it to outsource your thinking and analysis. Iterating your way to success rather than struggling and analyzing. This doesn't result in as strong of neural pathways, so you don't remember as well and you don't generalize as well. Having taught programming I can tell you that countless students graduate from university[2] thinking that because the output of their program is correct that this means that their program is correct. This is a massive failure in logic. Much easier to see in math that just because 3+3=6 and 5+1=6 doesn't mean that the process is equivalent[3]. The correctness of the program is the correctness of the process, not the correctness of the output.

While that's the typical outcome of learning programming, it isn't a necessary outcome and there's nothing stopping anyone from also using the same approach we use in math. Math is only that way because we're forced to[4]! Both have their strengths and weaknesses, but neither is strictly better. The strictly better learning path is the combination and that is the superpower we have. It's just easy to abdicate this power and only do the easy thing.

[0] We can really say this from Church-Turing but if you really have concerns with this statement you'll need to read more up on the theory of computer science and I suggest starting with lambda calculus.

[1] https://www.cs.utexas.edu/~EWD/transcriptions/EWD06xx/EWD667...

[2] and even graduate degrees. You'll also see this idea prolific on HN and I'm sure someone will respond to this comment countering the point

[3] You can abstract this, I'm not going to do some long calculation here but I'm sure most people have done a long calculation where they got the right answer but the process was wrong and they had a professor still mark them wrong (and correctly so).

[4] If you're going to lean on me I'll concede

Trial and error is necessary and beneficial, but not after the student becomes frustrated or anxious/bewildered by the complexity. The research shows that striking a balance between teacher intervention and trial and error is the optimal approach. If a teacher notices that a student is way off course but they keep persisting in one branch of the trial-and-error search space, it’ll be best if they intervene and put the student on the right branch. The student can still use the knowledge of what wasn’t working to find the solution on the right branch, but just persisting would be ineffective.

Gaining true understanding/insight is necessarily trial and error. Teachers cannot teach insight. But they can present the optimal path to gain insight.

Needs qualification. Research shows trial and error learning is very durable, but it’s not the most time efficient (in fact it’s relatively poor, usually, on that front). The two concepts are a bit different. Yes, trial and error engages more of the brain and provides a degree of difficulty that can sometimes be helpful in making the concepts sticky, but well designed teaching coupled with meaningful and appropriately difficult retrieval and practice is better on most axes. When possible… good teaching often needs refinement. And you’d be surprised how many educators know very little about the neuroscience of learning!

Trial and error was the root of what became my IT career. I became curious about what each executable did from DOS and with that did my first tweaking of autoexec.bat and config.sys to maximise memory. Years later I was the only one who could investigate network (and some other) problems in Windows via the command line while I was the junior of the team. Ended up being the driver of several new ways of working for the department and company.

There’s a pretty rich literature around this style of pedagogy going back for decades and it is certainly not a new idea. My preferred formulation is Vygotsky’s “zone of proximal development” [1], which is the set of activities that a student can do with assistance from a teacher but not on their own. Keeping a student in the ZPD is pretty easy in a one-on-one setting, and can be done informally, but it is much harder when teaching a group of students (like a class). The. Latter requires a lot more planning, and often leans on tricks like “scaffolded” assignments that let the more advanced students zoom ahead while still providing support to students with a more rudimentary understanding.

Direct instruction sounds similar but in my reading I think the emphasis is more on small, clearly defined tasks. Clarity is always good, but I am not sure that I agree that smallness is. There are times, particularly when students are confused, that little steps are important. But it is also easy for students to lose sight of the goals when they are asked to do countless little steps. I largely tuned out during my elementary school years because class seemed to be entirely about pointless minutiae.

By contrast, project work is often highly motivational for students, especially when projects align with student interests. A good project keeps a student directly in their ZPD, because when they need your help, they ask. Lessons that normally need a lot of motivation to keep students interested just arise naturally.

[1] https://en.wikipedia.org/wiki/Zone_of_proximal_development

I actually feel like the Unix/Gnu CLI is quite nice (yes I'm used to it already). I feel like it provides a lot of consistency through community standardization and standardization through POSIX and libraries. For example it's quite difficult to find a program that breaks the "-o --option" long/short options and if you do the "man command" or "info command" pages will tell you how to use a program. In my experience this is quite different on for example Windows.

Learning it is a step but once you've learned the basics you can read 90% of the commands.

I’m curious: what do you see as unnecessary about the CLI? Or, to put it another way, in what way should the CLI be changed so that the only remaining difficulties are the necessary ones?

there are 45 million devs in the world (out of which probably 10 can actually program) and 8.5 billion people

we could say 0.5%?

Yea, and I think it is amazing, but in the same time it will work for some and not for others

The same way scratch works for some, redstone for others, and https://strudel.cc/ for third

I think the truth is that we are more different than alike, and computers are quite strange.

I personally was professionally coding, and writing hundreds of lines of code per day for years, and now I look at this code and I can see that I was not just bad, I literally did not know what programming is.

Human code is an expression of the mind that thinks it. Some language allow us to better see into the author's mind, e.g forth and lisp, leak the most, c also leaks quite a lot e.g. reading antirez's code or https://justine.lol/lambda/, or phk or even k&r, go leaks the least I think.

Anyway, my point is, programming is quite personal, and many people have to find their own way.

PS: what I call programming is very distant from "professional software development"

well, technically 2, my second was "good, now do it better"

I’d been thinking more just typing the commands into a terminal window on the big screen, but something like this could be really helpful for seeing the intermediate steps.

woah that looks nice!