Hacker News Reader

Comment by Schlagbohrer | Hacker News Reader

Reminds me of the best saying I ever got from my CS professor. She would make us first write out our code and answer the question, "What will the output be?" before we were allowed to run it.

"If you don't know what you want your code to do, the computer sure as heck won't know either." I keep this with me today. Before I run my code for the first time or turn on my hardware for the first time, I ask myself, "What _exactly_ am I expecting to see here?" and if I can't answer that it makes me take a closer and more adversarial look at my own output before running it.

View on HN

Isn't this the whole idea of TDD? Write your assertions, then write the code the fulfill it.

I'm not 100% convinced, while iterating fast on an early prototype, what's wrong with legitimately not knowing what e.g. the data structure will end up looking? Just let it run, check debugger/stdout/localhost page and adjust: "Oh, right, the entries are missing canonical IDs, but at the same time there are already all the comments in them, forgot they would be there – neat". What's wrong with that? Especially at uni, when working on low-stakes problems.

The point of university isn't to get things done - it is to imprint knowledge into your brain. If you are approaching school with the attitude of "how do I get this over with as fast as possible," you are wasting your time and the time of the teacher.

> what's wrong with legitimately not knowing what e.g. the data structure will end up looking?

But that's not what the above comment said.

> Just let it run, check debugger/stdout/localhost page and adjust: "Oh, right, the entries are missing canonical IDs, but at the same time there are already all the comments in them, forgot they would be there

So you did have an expectation that the entries should have some canonical IDs, and anticipated/desired a certain specific behavior of the system.

Which is basically the meaning of "what will the output be?" when simplified for programming novices at university.

This is a restatement of the old wisdom that to safely use a tool you must be 10% smarter than it is." Or stated differently, you must be "ahead" of the tool (capable of accurately modeling and predicting the outcome), not "behind" (only reacting). TDD is kind of an outgrowth of it. I've lived by the wisdom, but admit that for me there is a lot of fun in the act of verifying hypotheses in the course of development, even in the "test case gap" when you're writing the lines of code that don't make a difference in terms of making a long term test case go from red to green, or doing other exploratory work where the totality of behavior is not well charted. Those times are the best. "Moodily scowling at the computer screen again," has been a status update from chilluns on what I'm doing more times than I like to admit.

I agree with this. Writing a prompt isn't good enough on its own. Knowing what the desired output and result paired with understanding how an app should work is still very essenntial.

Reply on news.ycombinator.com