May 15, 2012
There have been a lot of discussions today about developer Jeff Atwood’s post pleading people to not learn to code. Atwood is responding to the “everyone should code” and new features like Code Academy that promises to introduce people to the ins and outs of programming.
I tend to agree with the sentiment behind Gina Trapani and Benjamin Stein – there’s a big difference between professional development and coding. One of the things coding teaches is analytical skills, logical workflow, and debugging. Few other activities combine these into situations that require all three.
What Atwood is correct in noting is “[coding] puts the method before the problem. Before you go rushing out to learn to code, figure out what your problem actually is.”
For better or worse, in my department I am the person most people come to for questions regarding programming and code. People wonder if they should take Steve Ramsay’s Ruby course (they should, it’s great) or what language they should start with. Writing code, however, is not the first step.
Writing code is about solving problems. Digital humanities practitioners should be building, and writing code certainly falls within that domain. But if you think writing code is your starting point, then you are framing the issue incorrectly. What you need is to identify solutions to problems. Building your tool is little different than your standard research paper: identify your problem, determine your users (audience), do your research, figure out where your solution fits and how it’s different from existing solutions.
Writing code is not your first step. Identify the problem first.