Don’t Learn to Code — Learn to Automate
Does anyone remember a few years ago, when the mayor of New York decided to learn to program? It was a heady time, because it wasn’t just him. I remember these surreal commercials where Miami Heat forward Chris Bosh was encouraging children to learn to code for the good of humanity or something. There was this sudden, overwhelming sentiment that humanity should abandon the folly of any non-programming pursuit and learn them some Ruby or whatever. Andy Warhol, were he alive in 2012, no doubt would have said, “in the future, everyone will write code for 15 minutes.”
Jeff Atwood wrote an interesting rebuttal to this zeitgeist, entitled, “Please Don’t Learn to Code.” The covers a good bit of ground and makes some interesting points, but the overarching thesis seems to be, “avoid thinking of writing code as the goal and learn to solve problems.” I think this is an excellent, philosophical point, but I’d like to add a bit of nuance.
I’ve written in the past about how important I think that it is to be a problem solver, to the point where I wrote a post about liking the title “problem solver.” So please don’t think I disagree with his take that a lot of programmers get too hung up with the particulars of code. I don’t — I think that’s a very common issue. But, at the same time, I think the mayor of New York and Chris Bosh and others have a point that Jeff doesn’t really address, per se. Specifically, the world is getting dramatically more technical, which means that a lot of pursuits are being automated out of existence, while other pursuits require an increasing degree of technical savvy. My fiancee, a professional copy editor, is finding aspects of her job to be easier if she knows a bit of HTML and CSS.
So while I wince alongside Jeff at the thought of people randomly learning programming languages because they think it’ll make them rich or because they want to be a person that writes lots of code, I don’t think we can simply say, “stay out unless you’re serious and willing to spend years getting good.” The rapidly evolving technical landscape has created this black hole of technical savvy that’s sucking in even people well past the event horizon.
The advice that I’d offer on this subject creates a pretty fine distinction. I don’t think that everyone needs to learn to code by any stretch. What I think that everyone needs to start learning about and understanding is how to automate. Or, if not how to do it themselves, at least how to recognize things that could be automated and have meaningful discussions about whether the effort is worth it or not.
Automation in Real Life
It might be best to offer an example here. Tonight, I was working with a friend on some course materials to be communicated via Power Point. We were making slides that were largely images with a few large-font words scattered here and there. We’d paste the pictures into the slide deck, resize a little and then use my Mac’s trackpad laboriously to center the images. At one point, he said, “there should be some shortcut key in Power Point that you can hit and it just auto-centers the thing vertically and horizontally.”
That, my friends, is automation at the moment of conception. Centering something on a Power Point is just the kind of brainless, maddening, time-consuming task that makes a good candidate for automation. You know what I’m talking about, where you drag the thing around using movements as microscopic as possible, hoping to see that line appear that indicates that it’s in the middle. It’s so hard to find and you’ve got to go so — wait, there! Crap! Missed it. Back up, try it again.
Of course, the conversation doesn’t end here, by any stretch. The talent for which I’m advocating — the talent of savvy automation — involves an assessment like the following, and a potential automation at the end.
Does Power Point already provide this capability and we just don’t know about it?
Doesn’t seem like it after a bit of quick googling. If it did, a blog about Power Point secrets would probably just need two lines to describe it “Step 1: hit magic key sequence. Step 2: there is no step 2.” But still, it might exist.
Is it worth doing more research?
Not right now. We’re almost done with the slide deck. On a broader scale, it might be worth doing.
Would it be worth it to us over the long haul?
Hard to say. I’m not entirely sure how much time in my life is wasted to this problem. It’s probably some but I’m not the most avid Power Point user, so you figure it might take years for it to add up to hours of my time. And who knows how long fixing this problem would take?
Would it be worth it for humanity over the long haul?
Hmmm… almost certainly. Even if I waste hours on this only after years of Power Point use, humanity probably wastes hours on this after microseconds go by. Lots of people somewhere are swearing at Power Point right this very instant.
Could we sell it if we made it?
Meh, doubtful. But maybe for a pittance here and there. Or maybe we could just do it, donate it to the greater good, and reap a reputation benefit.
Okay, so what’s the next action?
Let’s set aside a time box of an hour to research this at a good time for low priority tasks, such as sitting in an airport. A nice interim goal might be to see if we can get it going in a limited scenario. On just a blank slide, does the “ctrl-E” shortcut do the job for horizontal centering? If so, can we find a way to do vertical centering and then somehow chain those shortcuts? If yes, then, bam, problem solved with just a bit of configuration. We’ll know we’ve succeeded when we can hit a single shortcut and have horizontal and vertical center of a single image on a blank slide. If that little test works, we can write a blog post, bask in some win, and then move on to more scenarios.
Poor Man’s Coding?
Okay, so that was a little hokey, but I’d like to point some things out here. First up was identification of a crappy task and the recognition of an automation candidate. Figuring out the exact coordinates for centering something is the perfect job for a computer. After that came a sequence of questions contemplating the possibility that there might be an existing solution, that coming up with a new one might not be worth it, or that coming up with a new one might be time consuming enough as to offset any gains. In the world of software development, that goes by various names such as “discovery,” “requirements analysis,” and “sprint 0.”
After that came a tentative plan of action along with some risk mitigation. Let’s invest a bit of effort in seeing what we can do, but let’s cap that amount of effort so that we don’t run off tilting at windmills. And then there was a concrete strategy that involved carving a larger potential effort down into the smallest slice that might provide some incremental value. This is known in the software development biz as an agile (or, if you want, “lean”) approach to a software project. And then, finally, in spite of the lack of writing of actual code, came implementation and a clear, verifiable description of what success looks like. In the biz, that’s called “Acceptance Test Driven Development” (ATDD).
But forget the terms and the parallels to programmer shop-talk. The more important point is that successful software development projects — projects that involve code and IDEs and compilers and whatnot — are just a special case of successful automation projects. You can automate all manner of things, even some very non-trivial things, without actually writing any code. In this vein, Jeff’s point is absolutely spot on. Coders like to code, but writing code ought not to be a first class goal when there are problems to be solved.
Throughout human history, there’s been a sort of “pain is gain” approach to the repetitive. There was value in putting your head down, getting into a rhythm, and working hard at menial tasks. But throughout most of that human history, we didn’t have computers. It turns out that computers are really, really good at doing repetitive, menial tasks — tasks that involve precision and not judgment. They’re far better at them than we are, so it makes sense to let computers do them.
It’s obtuse to suppose that a prerequisite for every job in the future will be the ability to implement sophisticated, specialized computer applications. But it’s not at all obtuse to suppose that, given the ubiquity of computing, a prerequisite for every job in the future will be the ability to recognize which tasks are better suited for humans and which for computers. Learn at least to recognize which parts of your job are a poor use of your time. After that, perhaps learn to use your ingenuity and creativity to automate using the tools that you know (such as googling for solutions, leveraging apps, etc). And, if you’ve come that far, maybe it’s time to roll up your sleeves and take the plunge into learning to code a little bit to help you along. Because, while there’s no need for the mayor of New York to write any code, it couldn’t hurt him to be ready to jump if something opens up in the city’s IT department.
What would you think of the idea of, rather than teaching the basics of the programmer mindset, teaching the application of the scientific method to the everyday world as a core skill? This seems to line up with the premise of, say, the Lean Startup.
(I’m not trying to be cute with a Socratic thing here — genuinely curious if you think that would cover the value of everyone learning a bit of programming)
I have long been of the opinion that our education system(s, worldwide) have forgotten to teach basic skills like abstract thinking and problem solving as these are too, well, abstract and impossible to measure with exams. Teaching the scientific method as a philosophy in itself would not be sufficient either, it would only work if this was woven into the very backbone of everything we learn/teach so that its very importance is not underlined by, “oh gosh, we need a new teaching subject, How to think properly” but by the fact that it should be practised in everything we do.… Read more »
Part of the problem is that our school system is designed to be as difficult as you’d like it to be, and not difficult by default. For example, you can graduate high school in the United States, without having a single class in chemistry, physics, or higher level math. Unless you are one of the “smart” kids, you simply are never forced to expose your mind to the more difficult subjects. So, when we think of teaching everyone coding or the scientific method, I think the key takeaway is not the knowledge gained itself, but rather the brain exercise and… Read more »
I best remember the teachers that somehow provided significant leaps forward in my critical thinking skills, and that’s not hard for me to remember, because there were very few of them. It’s hard for me to generalize my own werid journey through the education system to a larger trend, but it certainly does seem to suffer from some pretty intense observer effect.
I definitely agree with the idea that perhaps “coding”, per se, isn’t The Thing, and I freely admit bias towards something I do for a living and for fun. I’m probably not explaining my thoughts really well, but in my mind, “teaching a mindset” or “teaching people to think” is probably going to be largely ineffective outside of a mandatory-classroom setting. (And, I’d argue, mandatory-classroom settings aren’t particularly effective at teaching anything interesting.) IANAE(ducator), but I would imagine that “teaching people how to think” would need to be done indirectly. Teaching how to code, seems to me, is a good… Read more »
I suppose it does seem as though teaching people how to problem solve would be harder than putting problems in front of them and letting them practice solving them. It’s not something I’ve ever really tried to do, myself, so it’s hard for me to form too strong of an opinion.
This is brilliant, and thanks to you, I’ve now crowned myself as an Agile Problem Solver who is adept at identifying Automation candidates – and running a website/CMS without a Copy- Template functionality should be banned!
Hi, I must agree with you, knowing how to code is not all that should be required of a developer. I mean, yes, the knowledge is necessary, but not having the ability to shorten processes and automate actions is a big problem in my book. I employ 6 coders now and honestly, I’m more interested in finding out what are their automating and problem solving skills, rather than just their coding. After all, the latter can be easily improved and taught (http://www.shorelabs.com/blog/2015/06/11/the-best-of-free-online-web-development-courses/) whereas sensible thinking, making long jobs short and implementing automation are not as easy to teach or demand.
I agree with you. A programmer’s first thought on every problem should be: “Is it feasible to do this manually or to make a script for it?”. On a side note… Did you come up with an automated solution for your problem? (For the greater good of humanity) 🙂
If you have a calculator that can do complicated math, why bother doing it by hand ? If there is an app that can automate things for you, I don’t think there is a need to understand the fundamental of it. The point is that only if it’s in your area of expertise, it’s worth the time to understand all the nuts and bolts, but spending several years to become an expert in an area that you weren’t isn’t the best approach. However, there are times that someone else’s calculator just doesn’t 100% fit your needs and that’s where your… Read more »