[h3mb3]

> 3. Solve the generic problem not the specific one.

It's good that you provided the example...

> i could write a program that reads a csv row by row, converts it to my internal model, then emits those data into a ndjson file. Or I could just write a program that converts csv to ndjson , agnostic of the data. The former costs you every time the model changes. The latter is useful for a variety of system architectures again in the future.

...because in this case I can agree (although I'd need to drill into the details a bit more). Anyway, far more commonly (in my experience) unnecessary effort is spent on making generic code when a solution only targeting the specific problem in hand would suffice. Then later the requirements change or your original assumptions turned out to be wrong, and you need to spend time changing the generic solution to fit the new problem. This can require 10x the effort vs. just continuing from the specific and simple solution.

I guess the difficult art is to be able to recognize those exceptions where it is in fact reasonable to do the extra work for the generic solution. There was a recent submission [1] here about "YAGNI exceptions" which included a few common cases.

[1] https://news.ycombinator.com/item?id=33230216

[maerF0x0]

Yeah I basically try to think something along the lines of "for 10% more effort can I make it so when the Product Manager changes their mind I can either have 0, or minimized additional work to do" . In the case of changing the csv to ndjson, we can actually just treat each row as "just data" and not try to parse it into whatever the PM said.