Hacker News Reader

Comment by mkreis | Hacker News Reader

That reminds me of Amazon's method "working backwards": https://www.productplan.com/glossary/working-backward-amazon...

You start e.g. with a press release and then make your way backwards to the user stories and backlog.

It's a very useful approach to think big and focus on the problem instead of the many little issues that need to be solved.

The problem is that programming is still knowledge work. That means you can not specify everything beforehand without doing the actual work. (Like writing a novel, which can not specified before.) The solution would imho be a good balance between description the big picture/desired result (good) and spec'ing out every little detail and screen in advance (bad).

View on HN

I remember seeing a programming tutorial that used this approach as well fairly early in my software engineering education. I want to say it was part of the SICP MIT course but I could be confusing it with something else.

It was pitched as something like "wishful thinking programming" IIRC. First you write the highest-level "business logic" code that you want to write with made-up constructs that have no implementation, then only once you've established that it feels good to write code using those constructs do you implement them.

I remember this also being the same approach that was used in a CPU-building course I took (NAND 2 Tetris): start with the instruction set, then implement it.

Wishful thinking is mentioned several times in SICP, both in terms of to be implemented functions and in separation of concerns.

Oftentimes in the book, they will write out a function with reliance on a variety of other functions that haven't been written yet, but which show a blissfully declarative outline of exactly what the function does. Then you go and write the sub-functions.

Looking at the code after is quite nice, but it takes a bit to wrap your head around writing large swaths of code that can't run -- especially when you're used to writing REPL-driven code and consistently checking/"testing" it

This is an actual advantage of test-driven design; unit tests are bad for their stated purpose (they aren't good at testing things and are expensive to maintain), but because they make you write clients for your APIs before implementing them, you actually have some hope of knowing they're useful.

I think you should consider writing unit tests before coding but then delete them and then write regression tests after. Though, haven't tried this approach yet.

Reply on news.ycombinator.com