Comment by i_like_robots | Hacker News Reader

Comment by i_like_robots | Hacker News Reader

> Never start coding (making a solution) unless you fully understand the problem. It’s very normal to spend more time listening and reading than typing code. Understand the domain before starting to code. A problem is like a maze. You need to progressively go through the code-test-improve cycle and explore the problem space till you reach the end.

I agree with a lot of the points made by the author (2, 5, 7, and 8 really resonate with me too) but I think this one is my favourite. One strategy I've used which is successful - but not very popular - is "readme based development". The concept is simple, if we're building something new then the first thing we should do is summarise the project in the readme. If we spend time describing the problem and scope of the project and finessing it down to a few sentences before we start coding then we should have a better chance of staying on track and have an easier time communicating with others. The bigger the project the more useful this can be but unfortunately the majority of folks I've worked with do not like writing.

This point makes literally no sense to me. He says don't start coding before you fully understand the problem, and then he says the way to explore the problem space is coding (the code-test-improve cycle).

By the way I agree with the last part. Sometimes the best way to understand the problem is writing a half-broken solution for it. You just have to be aware that what you're writing probably won't solve the problem, and make sure all the other stakeholders are aware too (that's usually the hardest part).

I agree. There is exploratory coding. It’s a bit like talking to yourself (or your rubber duck) or writing things down, or drawing. It’s the kind of thing you do to load up your head with inputs to just play and it’s incredibly powerful.

I usually go about it differently than hold off coding. I do try to understand the problem fully before I implement anything. I try to figure out what abstractions make the most sense and what to optimize for. Then I write a preliminary implementation and almost without fail I learn something new that changes the parameters of the "problem". Scrap it and do it again just with more knowledge. No amount of analysing and understanding up front have produced a better or faster result for me.

I suppose we can only accurately define a problem when there are no big unknowns, so I wouldn't prescribe readme based development in every scenario - a quick and dirty exploration of the space which can then be scrapped is more important sometimes.

I've found this sentiment is common among people who dislike coding. They feel code is a burden and do whatever they can to minimize the amount of it that they do.

I've consistently outproduced peers by picking up the compiler early in the cycle and throwing away what I've done if it isn't working out. It requires a bit of self awareness, judgement and taste to know if something isn't going to work but I think the people who hate coding also can't stand throwing effort away like that.

I think the author makes a distinction in the very point you critique between the problem and the solution. If you don't understand the problem, it doesn't matter how dirty your hands get, you'll have trouble solving it. Once you understand roughly what you're trying to solve, you should figure out how to solve it by messing around and seeing what works (as is stated in the article).

Internally where I work we use RFCs if we want to propose a new feature/addition, it helps bring others in to skim the doc to find out if there is anything they need to add. It's not too bad, I quite like this

It should be easy to talk a pointy-haired boss (PHB, see Dilbert) into "readme-based development" (RBD). In fact, you can probably get funding for training, aka pizzas.

That's because RBD is basically Amazon's "write the press-release first" methodology and no PHB will say "we won't use something that Amazon says makes them successful."

The pizzas come from another Amazon saying.

I think it's key to think about the wording here

> understand the problem

> code-test-improve cycle

I think you're first trying to understand a non-programmatic problem, a business problem, a user problem. Then you start to explore the solution to that problem. Yes, you'll learn more about the "problem" as you solve it, but the cycle explores how you're solving the problem.

With big projects spanning across years, the "problem" is often a moving target. Adding new features alters the problem space dynamically. The best you can do as a maintainer is to be mindful of the original problem that the solution was architected for, and extend the thing without crossing certain boundaries and assumptions.

Absolutely, we can always try to assume that our predeccesors or past selves had the best of intentions but nothing beats writing down the context and problems at that moment in time for future reference.

> The best you can do as a maintainer is to be mindful of the original problem that the solution was architected for, and extend the thing without crossing certain boundaries and assumptions.

Speaking of boundaries and assumptions, one of the most important realizations I have had about software development is the true meaning of modularity:

Software modules are the things whose boundaries limit the spread of assumptions.

Readme based development sounds like a great idea!! Thanks.

"Doc > Test > Code" is something I can get behind :)

Reply on news.ycombinator.com