Yesterday I improved the home page in my toy app. I drew pictures in GoodNotes on my iPad, exported them to Dropbox, cut them up in Paint 3D, dragged them into VSCode, and included them in HTML in an ERB template for our Rails app. I know I’m supposed to include them with
image_tag but I don’t yet understand how. I expected to see the changes immediately in the browser, with auto-refresh, but that’s broken somehow. I restarted the whole Rails server to test it. When I finally pushed to GitHub, CircleCI picked it up and deployed to Heroku and now it works. The home page is a tiny bit better.
Developing software, we use a lot of tools. Sometimes it’s smooth, like the deploy this time. (That was about four hours of work last Sunday, but it’s good now.) Sometimes it’s rough, like trying to modify an ERB template when I don’t understand Rails 6 front-end conventions.
Yesterday I learned some new terminology for these feelings. In relation to me, a tool is ready-to-hand, unready-to-hand, or present-at-hand. (Words by Heidegger, described in this paper.)
The tools you use habitually are ready-to-hand.
When I use GoodNotes, git, HTML, the browser, I’m not thinking about them. I reach for them like I do a spoon, they’re right there and I can get the image on the page or the bite into my mouth. These tools are ready-to-hand because they work like an extension of me. I don’t have to think about using them, I just type “git status” and “git push,” I can whip out
<img class="silverware" alt="a spoon" href="images/spoon.jpg">.
Inspect is normal now — which is an accomplishment. A year ago, I didn’t have Ctrl-Shift-I (open dev tools) memorized. Working on front-end skills means bringing these tools ready-to-hand.
Years ago I did that with git. I studied it, made friends with it, and now I reach for branches and cherry-picks regularly. Other people don’t do this, because git is hard to make sense of. But I’m comfortable with its command-line.
Until it breaks, until I have unmerged changes but there’s no merge in progress and “Crap!” Do I have anything I need to salvage before clearing this mess out with
git reset --hard origin/master?
When you have to think about the tool, it is unready-to-hand.
When a tool breaks, it becomes unready-to-hand. You can still use it to do the task, but you have to think about the tool. You have to google something, or check the man page. Your concentration on the task is broken.
Like right now! This computer just froze up thoroughly and I had to hard-reset it. What was I writing?
Tools I don’t understand well are unready-to-hand. My Ruby is not smooth. ERB, I can only google and copy spells. When that gets hard, I fall back to HTML which is ready-to-hand for me.
When Rails server didn’t autorefresh, I let that hold me back, restarting it each test. If that had been smoother, I’d have done more iterations, and the page would look better. Because that tool required my attention, it was unready-to-hand, and the outcome took a hit. So did my mood.
But at least it ran. Sometimes I can’t get Rails to serve the page at all, and then I’m stuck. When I can’t use it at all, it isn’t even unready-to-hand.
When you can only look at the tool, it becomes present-at-hand.
When all I can do is stare at an exception in the log, Rails can’t be a tool. It becomes an object of study in itself. When a tool becomes something you look at and notice, instead of something you use, it is present-at-hand. When the track pad freezes up, I start looking at the keyboard, noticing its attachment to the computer. This is a time for stepping back and studying the tools.
Development tools are present-at-hand when we study them. In the hours I spent studying it, git wasn’t actively helping me. But later, that understanding brought it ready-to-hand.
This is about us.
These states aren’t a property of the tools themselves. They’re a property of my relation to the tool. HTML is ready-to-hand because I’m familiar with it. Rails is unready-to-hand because I don’t understand how it works, I only know some spells. When Rails breaks it becomes present-at-hand until I figure out how to fix it.
But when I do study Rails, and then work with it consciously for a while, I gain the ability to use it comfortably. It moves to ready-to-hand, it becomes an extension of my cognition. When I can express my intentions using Ruby about as comfortably as in English, that’s power.
When a tool becomes unready-to-hand, like when Rails server didn’t auto-refresh, I have a choice. I can step back, study it, fix it, and bring it ready-to-hand again. (I can shave the yak.) Or I can proceed in the task, stilted, dragging the tool along, to a less-satisfactory outcome.
Spend time learning, and bring more tools ready-to-hand.
Stepping back and studying the tool doesn’t feel like progress. It is not getting my task done. Except, it is giving me the ability to get the task done more efficiently and more effectively.
The fastest way to get a tool from unready to ready is to bring in a person who understands it. I’ll pair with Avdi, a Rails expert, on this Rails auto-refresh problem. He’ll teach me something about Rails, and together we’ll diagnose and fix the problem. Then work will proceed more smoothly, I’ll get the homepage to a better state, and I’ll be different: I’ll be a person for whom Rails is closer to ready-to-hand.
(BTW, you can bring him in for pairing too.)
It’s the rare tool that when you get it, you immediately get it. The Apple Pencil was like that. Stick it to the side of the iPad, boom, they’re talking, I’m writing.
I become a better developer by extending my own abilities, by getting familiar and comfortable with more tools. The programming language, IDE, build tools, version control, libraries, templates, frameworks, command line utilities — the list goes on and on. These are like growing extra fingers or gaining a few inches in height. My work gets smoother and outcomes get better.
Someday, after a lot more learning, I may even make a decent web page in Rails.