how to be a coder (or something)
April 5, 2016
I was talking with with a friend the other day about coding and discussing how to get ‘into’ it if you aren’t in school or otherwise may not have the resources to do formal learning. I basically repeated a bunch of the stuff I communicated at the OLA panel I did a year or so ago (two years? I can’t remember).
Normally when I see these sorts of things people talk about languages and this and that but not really how a person who might’ve not been tech/coding oriented could get into it. Because for people who don’t do coding or otherwise spend a lot of time working with tech, many don’t always grasp that one of the first things you need is perspective. As in, without the right perspective the likelihood that you’ll ever really get into it or understand why it matters isn’t very good.
This is also one of the areas wherein people who’ve mostly just studied coding or tech generally fail to communicate appropriately. Coding (and programming languages) incorporate certain ideas, perspectives, and worldviews. For myself, the years I spent studying logic have given me a fairly good philosophical context for the hows and whys of coding. I understand many of the underlying assumptions for programming languages and the theoretical ideas about the world that they communicate.
An analogy: most people look at coding as a skill and programming languages as a tool. This is perfectly fine. Certainly one way to look at it. But like any other tool, you need context to understand how and when to use it. The way a lot of ppl approach trying to teach coding is very similar to just giving someone a hammer and telling them to build a house. The very first thing that the person needs to even begin is to understand what a hammer is and how to use it.
The difference being, of course, is that hammers are so mundane and prosaic that most people are likely to already have this knowledge. We don’t have the same luxury when it comes to coding.
I got back into coding (after a long pause) in a roundabout and kind of really boring way. I had a fairly common problem that I wanted to solve: like most digital cameras, the one I used name the pictures some jumble of alphanumerics that was mostly meaningless to me. But… say if you were in China for a year and come back with hundreds of pictures from various places and various times, maybe you want to rename them to give each image somewhat better context. A more descriptive filename. And maybe, like me, you do not want to sit there and manually rename each and everyone of those files.
So… I started googling for solutions. I was not comfortable or familiar with the commandline back then. But I did have a mac and it included this <a href=”a href=”https://en.wikipedia.org/wiki/Automator_%28software%29%5Cn”>https://en.wikipedia.org/wiki/Automator_%28software%29\n</a”>handy little app called ‘Automator’</a>. From my googling I found a few tutorials for how to use automator to build a little app that would bulk rename a folder of images and give them a numerical sequence.
For me, this is the critical perspective that allows you to understand what kind of tool coding is and how to use them. Its about encountering certain kinds of problems and knowing if and when to apply this particular tool. Using the above example, I never needed that little Automator app before because batch renaming was usually a handful of items. So it was faster and easier to do it manually (it wasn’t worth the time or effort to learn something new). But when the number of images reached several hundred? It was definitely worth it.
I think one of the reasons the general inducement that ‘everyone should learn to code’ isn’t meaningful or all that helpful is precisely because of the above. When we swap out ‘coding’ with another tool like a hammer, the problem becomes clear. We don’t go around saying that everyone should learn to be a handyman or plumber. We don’t go around saying that everyone should learn to be a mechanic. These are all useful skills and knowing how to use the tools is valuable.
Realistically, though, not everyone has the inclination and, more importantly, not everyone has the need. Sure, I could learn plumbing. Nothing is stopping me. I could even learn it on my own, since there are plenty of resources for DIY stuff like that. But is it a good use of my time? Not really. It matters but I have other interests and, also important, different skills that are valuable in their own right. I can pay someone to take care of my plumbing.
(Yes. There is an argument here for people knowing rudimentary skills outside of their balliwick. Knowing enough plumbing to unclog a toilet or drain is worthwhile. Buying a plunger and learning how/when to use it doesn’t take all that much time and effort. But this same logic can and should apply to coding. Not everyone needs to be able to code a webapp from scratch. But a lot of people could benefit from having some rudimentary knowledge.)
Re: Rudimentary knowledge. Part of what I’m saying here is that, by and large, I think a lot of people would benefit from being able to at least view problems from the coding perspective. To seeing hundreds of images and knowing that there is/must be some way to rename all of them, rather than doing them individually. Then being able to take this knowledge – that a tool exists to solve this problem – and apply it in some way.
That last bit? ‘In some way’? Doesn’t necessarily mean coding. Doesn’t even necessarily mean learning how to use a graphic script making like Automater. It could be as easy as googling ‘windows batch rename files’ and being able to parse the results to find the right GUI tool1.
Very much in the same way that I can look at a clogged toilet and think, “I need to grab the plunger” without actually being a plumber myself. Or even really understanding how plumbing works and is constructed. Its enough that I’m able to first identify the problem and then either know which tool to use to fix it or how to get that information.
In some ways, I think those short-ish coding workshops would be much better if they focused on building this up. Helping people to learn how to identify problems for which coding is a useful tool and how to troubleshoot the problem.
(Like if I were to ever offer a *nix commandline workshop, I might actually just do as I describe above. Give everyone a folder with a hundred files and have them figure out a way to batch rename them. This would give them the beginning to start viewing problems like this from a coder’s perspective, how to troubleshoot for solutions, and learn a few tools that’ll help them to solve the problem. They might not formally learn all that much about the *nix environment – in the way of commands and such – but these workshops, tbh, usually try to dump way too much information anyway. They generally just become an exercise in following directions rather than learning anything you’ll be able to retain.)