2 ms·

In the old days, the first step was think through the logic very carefully, because every mistake took a long time for the cards to get collected and run throug

In the old days, the first step was think through the logic very carefully, because every mistake took a long time for the cards to get collected and run through the machine. Most people started by scratching their head and looking into space for a long time. Then they started drawing some sketches of flow (maybe with flowcharts, but often not doing that formally). Then they wrote out the code on coding sheets that had columns matching the columns on cards. Then they spent time reading the code and thinking like the machine. Only then were cards punched. And those cards were certainly checked for typos before submitting the job. This was all because the turnaround was so slow. Another fun card fact was that most people drew diagonal lines on their card decks, so you could more easily put them in order if they got scrambled. The consequence of all of this is that debugging cards was actually not all that common, because you were doing checks at all the preliminary steps. This was all quite fun, actually. Think of driving a standard-shift car, compared with an automatic.

majewsky 6y ago
> Most people started by scratching their head and looking into space for a long time. Then they started drawing some sketches of flow (maybe with flowcharts, but often not doing that formally). Then they wrote out the code on coding sheets that had columns matching the columns on cards. Then they spent time reading the code and thinking like the machine. This sounds a lot like how I work when writing new code that's not just a quick throw-away script, but built to last. If implementing a new feature takes me one week, then the first one is usually spent just reading the existing code and thinking about the other parts of the application and environment are going to interact with the new feature. It takes more time initially, but it saves me a ton of pain down the line, and luckily my managers appreciate that trade-off as much as I do.
wazoox 6y ago
Ah yes. I remember an article talking about how Jean Ichbiah programmed, and his card decks were always right at first run even when writing awfully complex programs :)

majewsky 6y ago

> Most people started by scratching their head and looking into space for a long time. Then they started drawing some sketches of flow (maybe with flowcharts, but often not doing that formally). Then they wrote out the code on coding sheets that had columns matching the columns on cards. Then they spent time reading the code and thinking like the machine. This sounds a lot like how I work when writing new code that's not just a quick throw-away script, but built to last. If implementing a new feature takes me one week, then the first one is usually spent just reading the existing code and thinking about the other parts of the application and environment are going to interact with the new feature. It takes more time initially, but it saves me a ton of pain down the line, and luckily my managers appreciate that trade-off as much as I do.

wazoox 6y ago

Ah yes. I remember an article talking about how Jean Ichbiah programmed, and his card decks were always right at first run even when writing awfully complex programs :)