Programming Isn’t Coding

For most non-Windows developers, a giant amount of time is spent using the terminal. Unfortunately, doing anything in the terminal is, if not a struggle, something very new to most beginning programmers.

I frequently see students move to directories by repeatedly cd-ing one directory deeper (instead of doing a single cd dir1/dir2/dir3 command), not being aware of tab-completion, being confused why they can’t click on the line to move the cursor around, and many other things.

It’s become a cliché that git is inscrutable, for a good reason.

This is an area where I know that my level of experience with git works against me when trying to help students. I’ve been using git purely from the command-line for so long that I feel very comfortable with it, not to mention spending a lot of time reading about the implementation details. This leads to the problem of trying to teach something when you don’t remember what it’s like to not understand it at all.

I think the students would be better served if they learned to use git using GUI tools, at least initially, but that would be an anathema to the dev culture. One could argue that GUI tools don’t expose all the functionality of git, but guess what? The command-line interface doesn’t really “expose” it at all either – you need to just know about it. At least with a GUI, users can see the buttons and a visualization of the commit graph to get a sense of what’s possible.

I love using Emacs and vim, but I can’t really recommend them to students. There’s so much to learn to just get the basics working, not to mention actually taking advantage of the real power of the editor.

Where I teach, students use VS Code. That’s still a very powerful editor, but students have no real idea how to take advantage of it. When I tell students about Cmd- / Ctrl-p for jumping to files, something I would consider the absolute basics for using VS Code effectively, their minds are blown.

Discoverability is a very hard user-interface problem, no doubt about it. Like most expert tools, programming text editors generally make a tradeoff to be more powerful for experts at the cost of being less easy to get started with for beginners.

“React Week” is always rough for teaching.

Previously, when we were still on class-based React, it was weird, because students had to learn about ES6 class syntax, which adds a whole new bunch of weirdly non-orthogonal syntax. That was rough, but hooks are even more challenging.

I happen to like the hooks-based approach to React, since I come from a background of using React via Clojurescript (using Om originally, now reagent/re-frame). However, if one isn’t already used to a functional style of programming, it’s another giant thing to learn.

It doesn’t help that doing functional programming in vanilla Javascript is something that requires a lot of discipline, since the language doesn’t help you at all in avoiding mutations. Even worse though, is that React does absolutely nothing to help you avoid doing things incorrectly.

It is so hard for students to learn to use hook-based React correctly when it seems to work for so long doing things “wrong” – i.e. directly mutating state vars, or doing unsafe state updates (e.g. referring to the render value of state when setting the new value). Students write a bunch of code, things seem to be fine – it works, no errors or warnings – but then they add some other change, which causes things to start failing in very confusing ways – updates get silently lost, things don’t get re-rendered – and students don’t know why.

At least they have create-react-app to streamline getting started – if they had to learn to use webpack, babel, et cetera before they could learn React, there is no way they would get anything done. Even that has its strange issues though. One of the most frustrating is when its auto-building stops working, so students are making changes and, as far as they can tell, nothing they do works – because their code isn’t actually running at all!

If students just had to deal with one or two of these things, it would be okay. All disciplines have their tools and practices you need to learn that are somewhat ancillary, but that’s just a consequence of specialized tools.

However, with programming, there’s this infinite fractal of new weird things you need to deal with – there’s a reason the term “yak shaving” comes from programmers, not machinists. When people are trying to learn programming, but there’s this never-ending rathole of baffling tooling things that bite them, it’s really easy for fatigue to set in and people to get very discouraged. It’s so disheartening when everything they do leads to more incomprehensible hassles that become conditioned to avoid learning their tools in depth; just get the code working, don’t try to dig more into why things work or how to do them more effectively.