Published in


The “science” in programming

Photo by Rohan Makhecha on Unsplash
  • Above all, programming is engineering. You are taking an established set of procedures, guidelines and disciplines, and applying them to new problems. It’s often a rather ill-disciplined branch of engineering (I certainly know engineers who sneer at it as a result), but done well I think the term applies, so I tend to prefer “software engineering” to “computer science”.
  • It’s worth thinking of it also as a craft. This is the positive side of that rather weak discipline: since each problem is a little different, programming generally doesn’t quite reduce to rules, but taking the care of a serious craftsman then becomes really important. It’s not just a matter of knowing the bits and pieces — there’s a lot of practice involved, in mastering how to put them together well in a host of different configurations. (I sometimes say that I learned to program in the best medieval fashion, apprenticing to my father in his craft back when I was 14.)
  • I’m even comfortable describing programming as an art. Certainly this isn’t true for everyone, and it’s really an art that only speaks to other programmers, but when I look at code it totally engages the aesthetic side of my brain. When I use words like “pretty”, “elegant” or “ugly” to describe a block of code, I’m not speaking metaphorically: it’s as true for me as when I am looking at a painting or sculpture.
  • Start with a question or problem that you are trying to understand.
  • Gather data about that question.
  • Based on the data, formulate hypotheses about what might be going on.
  • Come up with falsifiable experiments that either support or disprove your hypothesis.
  • Do those experiments.
  • Analyze the results, and based on those decide whether you are off-base or whether it is worth following this line of thought.
  • To begin with, you have a problem you need to solve: the bug in question.
  • Start by gathering data. So much data. All the data. This is where junior engineers often stumble, because it feels like you surely must be wasting time on all this data gathering, but it’s often necessary to do quite a lot. Look at the errors. Talk to users about what they are seeing. Add print statements. (Yes, they’re old-fashioned, but there’s still often nothing quite so useful as a bunch of printlns.)
  • As you gather the data, keep looking in it for patterns. (When necessary, pull in other programmers to act as rubber-ducks in your search for patterns.) Start trying to come up with hypotheses about what might be going on, but keep comparing them with the data to see if it fits. If not, keep gathering data. How long does this take? There is no set answer — I’ve had bugs where I spotted the pattern in five minutes, and others where it took five months. But there’s nothing for it but to keep gathering new-and-different data, and seeing what you can see in it.
  • Once you have a hypothesis, figure out how to test it. Yes, you can just dive in and fix it, but ideally be more formal about it. The best approach, if you have the luxury of it, is to start by writing a failing regression test that illustrates the problem, and which, if your hypothesis is correct, will work once you have corrected it.
  • Then you fix the bug, after you have a nicely falsifiable experiment. If the test starts to work — great! You have good evidence that you have not only fixed the bug, but that you understand what you have just done and why it works. And if not, you’ve disproved your hypothesis, so it’s time to step back and come up with another one.



Everything connected with Tech & Code. Follow to join our 1M+ monthly readers

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Mark "Justin" Waks

Lifelong programmer and software architect, specializing in online social tools and (nowadays) Scala. Architect of Querki (“leading the small data revolution”).