1. Please Learn to Code

    Jeff Atwood recently made a blog post entitled Please Don’t Learn to Code. In it, he comments on the codeyear.com project.

    To those who argue programming is an essential skill we should be teaching our children, right up there with reading, writing, and arithmetic: can you explain to me how Michael Bloomberg would be better at his day to day job of leading the largest city in the USA if he woke up one morning as a crack Java coder? It is obvious to me how being a skilled reader, a skilled writer, and at least high school level math are fundamental to performing the job of a politician. Or at any job, for that matter. But understanding variables and functions, pointers and recursion? I can’t see it.

    Jeff seems to be confusing “understanding how to write computer programs” with “being a crack Java developer”. He concedes that the mayor of New York needs to have basic literacy and high school level mathematical knowledge, but somehow he doesn’t understand why learning to program is a necessary basic skill in the 21st century.

    First, let’s dispense with his specific points before I wax philosophical about the benefits of learning to program.

    It assumes that more code in the world is an inherently desirable thing. In my thirty year career as a programmer, I have found this … not to be the case. Should you learn to write code? No, I can’t get behind that. You should be learning to write as little code as possible. Ideally none.

    This is a case of missing the forest for the trees. Perhaps Jeff has spent so much time blogging about software engineering principles and coding practices that he’s forgotten that all of that advice is inapplicable if you don’t already know how to code. The above is analogous to stating, “The mathematical proofs that are the most enlightening and easiest to understand are the shortest most elegant proofs. Avoid proving unnecessary lemmas and strive to reduce complexity in your proofs wherever possible. This means the best proofs are the ones you never write at all! In conclusion, don’t learn mathematics.” He seems to be inflating the scope of a specific software engineering practice to the level of a prohibition against ever writing code, and hence, allowing anyone to ever learn to program lest they add more code to this teetering pile we’ve already got!

    It assumes that coding is the goal. Software developers tend to be software addicts who think their job is to write code. But it’s not. Their job is to solve problems. Don’t celebrate the creation of code, celebrate the creation of solutions. We have way too many coders addicted to doing just one more line of code already.

    Yes, solving problems is the goal. And sometimes as a developer you can solve problems without writing code. This is a valuable principle to avoid adding more unnecessary complexity if you don’t need to. But again, it is not a reason to not learn how to program. It is advice to pull someone back from the edge of just coding without thinking about what really needs to be done. People who don’t know how to program don’t have that problem. Again, this is Atwood missing the forest for the bark of the particular tree he is standing right next to. It is akin to saying to a novice writer who wishes to learn the basics of story structure and plot pacing, “After years of writing your magnum opus novel, you may be tempted to continue adding epilogue after epilogue to a story that you have been engrossed in for so long, and whose characters you don’t wish to leave behind. But no, you must finish it. Eventually every story comes to an end, and you have to publish it.” 

    It puts the method before the problem. Before you go rushing out to learn to code, figure out what your problem actually is. Do you even have a problem? Can you explain it to others in a way they can understand? Have you researched the problem, and its possible solutions, deeply? Does coding solve that problem? Are you sure?

    This is more of the advice to experienced programmers, incorrectly aimed at people deciding whether learning to program is a worthy goal. More importantly it begs the question “How do you know if coding solves your problem if you are unable to code?” True, he does throw a bone out later in the blog post: 

    I suppose I can support learning a tiny bit about programming just so you can recognize what code is, and when code might be an appropriate way to approach a problem you have.

    But he equates this superficial knowledge to the ability to detect when a plumber is needed. Really? And how will you evaluate whether the coder you hire knows what he is doing? How will you specify the problem in a way that is thought out well enough that a programmer can actually accomplish it? Programming is more complicated than plumbing. There, I said it. Jeff, you have taken a bad analogy and run wild with it. Learning to program involves learning to think in a clear, logical manner. If you don’t, things don’t work correctly. In thirty years of programming, it’s easy to forget the time before you learned to program, when solving problems was an ad-hoc fuzzy mess. I’ve seen new programmers, they aren’t used to breaking down problems into clear logical components and ensuring things are consistent and make sense. This is something programming teaches you over time. Exactly the thing Jeff is saying you shouldn’t learn.

    It assumes that adding naive, novice, not-even-sure-they-like-this-whole-programming-thing coders to the workforce is a net positive for the world. I guess that’s true if you consider that one bad programmer can easily create two new jobs a year. And for that matter, most people who already call themselves programmers can’t even code, so please pardon my skepticism of the sentiment that “everyone can learn to code”.

    Who said anything about professional programmers? Mayor Bloomberg clearly isn’t gunning for a job in the field of software development. Unlike, say, recreational plumbing, programming is an inexpensive, easy to pick up skill that allows you to understand the world we now live in. Just yesterday, there was an article about how a judge shot down Oracle’s lawyer's claims about the rangeCheck function, because he programmed in his spare time:

    I have done, and still do, a significant amount of programming in other languages. I’ve written blocks of code like rangeCheck a hundred times before. I could do it, you could do it. The idea that someone would copy that when they could do it themselves just as fast, it was an accident. There’s no way you could say that was speeding them along to the marketplace. You’re one of the best lawyers in America, how could you even make that kind of argument?

    To which Oracle’s lawyer replied:

    I’m not an expert on Java — this is my second case on Java, but I’m not an expert, and I probably couldn’t program that in six months.

    Just like reading, writing and arithmetic, in the modern world, you need to have programming literacy. Not just “how to use Word”, but how to code. You can only get that knowledge by learning to code.

    Back to Jeff:

    It implies that there’s a thin, easily permeable membrane between learning to program and getting paid to program professionally. Just look at these new programmers who got offered jobs at an average salary of $79k/year after attending a mere two and a half month bootcamp! Maybe you too can teach yourself Perl in 24 hours! While I love that programming is an egalitarian field where degrees and certifications are irrelevant in the face of experience, you still gotta put in your ten thousand hours like the rest of us.

    Again, this is analogous to saying “It takes a long time to become a professional mathematician! You have to study for many years and there are only a few slots available! You can’t just pick up a book on algebra and become an algebraist in a weekend! We don’t need more sub-par mathematicians in the world. The existing mathematicians have got this covered, please stay home and don’t learn any math.” There is a vast divide between learning to program and aiming to become a professional developer. Yes, if more people learn to code, more bad programmers will be produced, and some of them will go on to become bad professional developers. But, in addition, more good programmers will be produced, and more of them will go on to become professional developers.

    As our society leans more and more heavily on automation and computers, being able to understand how to use those resources to your advantage becomes more and more necessary. Not everyone will become a virtuoso programmer with short elegant programs that are easy to understand and modify. But does that really matter for 90% of people? Is it better to learn to program, and then code up a tangled monstrosity script that automates a tedious process you were doing by hand, or is it better that you not learn to program at all? I would argue the former.