> Everything started with being handed a specification. From there, you had to write a solution in pseudo code, which was a separate language from the one we we

> Everything started with being handed a specification. From there, you had to write a solution in pseudo code, which was a separate language from the one we were learning (TrueBasic I believe). Once your pseudo code was handed in and approved, you could begin programming; however, you had to document up-front all the variables you were going to be using and document their purposes. In addition, you had to explain in plain english what each subroutine did and what variables it would access and state whether it would simply read or read and write them (and then explain why). I think that's good to start with, for a start it's mostly just the CS equivalent of "showing your work". It's also important to they develop the ability to break a problem down and to beginners doing this at the same time they're fighting the compiler can be overwhelming. I agree exploration and creativity are important, but they could make room for that as well, more so when they're more comfortable with everything else. As an approach it's quite similar to literate programming, which still has it's champions. > Sadly, this was 1998, and I suspect software development hadn't operated like that for a good 15-20 years (or if this was a weird practice localized to Motorola in the 70s) I think we're about the same age, but when I entered the industry (05-ish) UML (https://en.wikipedia.org/wiki/Unified_Modeling_Language https://en.wikipedia.org/wiki/Unified_Modeling_Language) and gantt charts wer in decline as agile became the hot new thing.