skydeck

Already a member? Login.

Skydeck Blog

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.

4 Responses to “What programming is”

  1. dens says:

    hey jake – just heard you joined skydeck. rad! hope all is well.

    /dens

  2. James Worthington says:

    Spoiler: functional programming and type safety?

  3. Nick says:

    This is very true. To understand a piece of software you have to model its behavior. When you design a piece of software you have to follow three steps.

    1- What the piece of software is expected to do.
    2- How you are going to implement it (coding).
    3- Why you implementation choice is the right one (test, peer review, mathematical proof).

    The first and third steps are the most difficult. Unfortunately most of the software engineers focus on the second because it’s easy and rewarding.

  4. Parag R. Kudtarkar says:

    I would totally agree …

    Guys imagine this.. You program a bomb that goes off at a particular time . But while testing the timer crashes .

    Guess who has to go and check what’s wrong with it…..:)