Bumper-Sticker Computer Science (1985) [pdf]

Bumper-Sticker Computer Science (1985) [pdf](bowdoin.edu)

81 points by mattrepl 11 years ago | 18 comments

japhyr 11 years ago |

"The sooner you start to code, the longer the program will take."

I certainly benefit from regular reminders of this.

agumonkey 11 years ago | |

I'm a little stumped by that, I'm all for repl oriented development, ~zero round trip time etc etc but I have to admit that when you thought the problem through in your head long before writing any, then the right code will fall through. So are instantaneous cycles good or bad ?

japhyr 11 years ago | | |

For me this advice is about developing your spec to an appropriate level of detail before writing any significant amount of code. I'm still in the phase where writing code is fun, and it takes a little discipline to think my spec through enough to make my code-writing time efficient.

mattrepl 11 years ago | | |

Instant feedback makes coding more tangible but can be harmful. One may get caught in an edit-eval cycle and spend time solving the wrong problem.

Regularly stepping back and reevaluating assumptions/goals helps. (And write supporting tests, if you swing that way.)

apricot 11 years ago | | |

So are instantaneous cycles good or bad ?

Three pounds of flax.

contingencies 11 years ago |

I went through each quote carefully while adding some missing ones to my fortune clone/database at https://github.com/globalcitizen/taoup and noticed two things versus modern sources: (1) The weight lent to optimization related concerns seems higher than today. (2) Comprehension of the non-electronic context of programming seems higher than today.

I think these are probably valid cultural reflections, potentially ascribable in part to the (edited, time-lapse) nature of paper-publishing versus electronic.

cafard 11 years ago |

I've always been fond of Thompson's rule for first-time telescope makers: "It is faster to make a four-inch mirror then a six-inch mirror than to make a six-inch mirror."

51Cards 11 years ago |

With regards to the Linux kernel bug in another thread today...

"The first step in fixing a broken program is getting it to fail repeatably" - Tom Duff / Bell Labs

japhyr 11 years ago |

> Don't make the user provide information that the system already knows.

I wish the IRS followed this advice.

ot 11 years ago |

If this was published now, it would be "Computer Science in a Tweet"

neduma 11 years ago |

It was published 1985. Wonder if anyone is not applicable now?

shill 11 years ago | |

"Allocate four digits for the year part of a date: a new millennium is coming."

Nobody starts projects using two digit years anymore, right? And most of the existing software that did was patched and or replaced for Y2K.

Also the part about a new millennium coming is temporarily not applicable.

fizbin 11 years ago | | |

Heh. That's my dad's quote - I remember seeing that page tacked to his office cubicle wall back in the 90s when Unisys still employed programmers who had office cubicles.

nitrogen 11 years ago | | |

I'm amazed that shortly after Y2K most everyone switched their paper forms and handwritten dates back to two-digit years. Humanity never learns.

Maro 11 years ago | |

Maybe this: "‪The job's not over until the paperwork's done."

I've worked a few jobs in the last 10 years (non-gov't), and I didn't experience paperwork around programming work.

EliRivers 11 years ago | | |

The paperwork is the code review, the test results, the QA approval, the verification against requirements, the approval to merge, and so on.

The paperwork has moved into a digital format, but it's still there.

buro9 11 years ago | | |

If you're a consultant there is still a degree of paperwork to do. Documenting the approach, the work itself, the handover, the install and troubleshooting.

If you're in big business or government then there is still paperwork. These are political organisations and even doing a good job isn't satisfactory, in many cases I'd argue that appearing to do a good job on paper is what your task really is and any delivery of a working piece of code is second to it.