4 ms·

I had a similar experience. My first programming teacher in high school was also my geometry teacher; a subject he taught extremely well (at least from my 15 ye

I had a similar experience. My first programming teacher in high school was also my geometry teacher; a subject he taught extremely well (at least from my 15 year old point of view). His programming class however sucked all the fun out of it. His brother-in-law was a retired manager at Motorola and gave him a bunch of (even for the time) thoroughly obsolete suggestions: 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 remember him saying "If you're a professional programmer, there's a good chance you'll have a manager who isn't a programmer and they'll be reviewing your work!" I think he took his brother-in-laws advice too much to heart, because he really felt like he was giving us all a real taste of what being a "real" programmer was like. 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) Any programming classes taught to minors should favor core fundamentals, exploration and creativity and avoid dwelling on industry practices which often have a shelf-life measured in years.

itronitron 8y ago
>> "If you're a professional programmer, there's a good chance you'll have a manager This is the number one reason that schools should not try to teach students employable skills, because they usually get it very wrong. Teaching youngsters business processes that will be 10 years old when they graduate from college severely limits what they can achieve. I am all for teaching coding and other creative activities, but these should be explorations. Let the student discover on their own the degree of technical rigor they want to apply themselves to.
flukus 8y ago
> 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.

itronitron 8y ago

>> "If you're a professional programmer, there's a good chance you'll have a manager This is the number one reason that schools should not try to teach students employable skills, because they usually get it very wrong. Teaching youngsters business processes that will be 10 years old when they graduate from college severely limits what they can achieve. I am all for teaching coding and other creative activities, but these should be explorations. Let the student discover on their own the degree of technical rigor they want to apply themselves to.

flukus 8y ago

> 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.