What programming is
Making software that works is really hard. I don’t say this because I’m a programmer and I want it to sound more impressive; I wish it were easier. But we programmers put endless hours into getting it right, and still your laptop blue-screens, your phone reboots, the rocket crashes into Mars.
The words we use to describe making software (in job ads, for instance: develop, design, write, architect, build, engineer) are glibly positive. They make it sound like a monotonic process, like laying bricks. But any programmer knows that working code comes in fits and starts. Most of the hours go not into designing or building, but into understanding: what a library call actually does, what’s happening in some code you’re trying to modify, why a bug doesn’t show up in the debugger. (This is why it’s hard to estimate how long a programming task will take; to estimate the task you have to understand it, but it’s the understanding that takes the time.)
Perhaps the best way to describe it is this: making software is reasoning about code. The methods of reasoning about code are the same as those of math or logic – considering all the cases that might arise, arguing by induction, breaking a larger argument into parts – although in programming we usually do it informally. In order to do a better job of programming (to program faster, with fewer bugs), we have to do a better job of reasoning about code.
In my next few posts I’ll talk about a few ways we’re trying to do that at Skydeck.