Hacker News Reader

Comment by btilly | Hacker News Reader

One intermediate solution is to ask people to code everything out in pseudo-code. Think about what it would do. Then when they are happy about it comment it all out, and below each line of pseudo-code write real code doing the same thing.

This lets you do exploratory programming, and also generates verbose comments for the TA to look at.

(This strategy is discussed in Code Complete.)

View on HN

That's true. But it (generally) doesn't let you discard your wrong ideas quickly, which is where the approach I was trying to describe gets most of its benefit. What you describe is much more akin to a waterfall model with a bunch of pseudocode and design up front but without an automated tool (the computer) actually able to run your program and tell you if it is going well.

That depends on which wrong ideas you're thinking about.

Actually writing down pseudo-code is good at flushing out hidden assumptions, points of confusion, etc. I've found that tracing through pseudo-code can help identify bottlenecks and design flaws. And it is all much cheaper than a real program. So you get to discard a lot of wrong ideas quickly.

However coding up a test program and being able to run through cases quickly on a computer catches slightly different classes of mistakes. You might not catch a logic error in your code, but you are more likely to figure out how an external API works.

I think that both skills are valuable, and both let you discard wrong ideas quickly. They just catch different kinds of wrong ideas. :-)

Reply on news.ycombinator.com