Flowcharting programs is ridiculous. When we’re talking software and interconnected files, okay yeah, I can see how that would make sense. But for simple, ASCII programs I think you can narrow the design spec down to 1) an example text file showing what you want the input to look like and 2) an example text file of what you want the output to look like. After this, pseudocode is just a waste of time. You might as well sit down, open your browser to Google and try to hammer text file number one into text file number two.
It’s a lot like that game where you try to get from one word to another by changing one letter at a time:
I think it’s a mistake to try to make programming into some sort of “clean” business, adhering to timetables and such. It’s a lot more like math than engineering or science: you’re faced with a problem and you either “get it” immediately and knock it out in a couple of minutes or you bang your head against it for hours and days until you finally “get it”. The only way to get better is to be able to draw on a large number of previous experiences. It’s not a fluid intelligence thing, but rather intuition and crystallized intelligence and practice.
I think it would be fun to write an RPG, starting from the lowest possible level of abstraction. Of course, I feel the need to sorta maybe learn something useful in the process, which is why I’m not starting with assembly (although that’s a rabbit hole I’ve previously explored with great fascination).