Flow Charts

I recently read Weinberg's Psychology of Computer Programming, which was written at about the time that time-sharing operating systems (like Unix) began to push out batch computing systems. This is exactly the sort of thing he was concerned about.

When you have a long turnaround time for feedback, you get a strong incentive to "desk check" before you send off your work.

I wouldn't say I use them often (and when I do, it's usually some form of business process modeling rather than software control flow) but I don't think it's quite fair to assert that flowcharts became obsolete with punch-cards.

At they very least they are a useful "language" to describe program-like logic to non-programmers. That includes beginner programmers, as others have noted, but also includes interested non-technical parties. In my experience it is the best way to explain/document convoluted decision trees to non-programmers.

More broadly, I hear a lot of complaints about UML and other diagrammatic ways to design or describe programs. I don't really get it. I mean, I understand why one might think that the formal UML language is complicated and convoluted (because it is that) and why one might think it fails to live up to the promise of a visual way to specify/write software (because it does fail to do that), but surely I'm not the only one who just drops most of the formalism and uses a pseudo-UML format to communicate (and sometimes even reason about) software design? How do you sketch programs without some UML-like notation? (I suspect UML was partially a formalization of existing ways to sketch programs to begin with.)

My mum's ex IBM, she worked in Cobol and Fortran and taught me to program. She doesn't know much modern stuff, so I can't really talk about my daily work with her, sadly. When I was at university, in 2006 there was an "IBM Mainframe Contest" - I was using the same OS she used to use! So we had some fun conversations about that :)

My father is a retired EE and was programming embedded machines in assembly language before I "caught the programming bug". When I was mostly doing embedded systems, we had plenty we could talk about. That hasn't changed now that he's retired since the basis of hardware logic and software logic is the same (Boolean Algebra identities). But I've done some interesting things in software as a result ... like using Karnaugh maps to minimize complex branching.

Incidentally, I'm pushing 50 and used punch cards in my computer math class in high school as well as for my lower-level computer science classes in college (Cmp Sci 201 was Fortran at Penn State back then). My son is a second semester senior in Media Effects (currently studying what affects app store engagement) and also has a minor in IST. Computing has been around long enough for three generations to "partake".

FTA "COBOL code was written on paper, sent to a punch operator, who would type the punch cards"

Nitpick. When I learned COBOL in 1990 we had terminals, typed the code like gentlemen.

What they taught us was 1) flowchart the process 2) write it out by hand on graph paper 3) type it up.

I still use flowcharts. Not all the time, and not well: that kind of thing works much better on fan-fold paper!

But it helps me keep the logic I had in mind as I bang out code.