[nickelpro]

It's contextual, and the author is presenting it as universal.

If you don't know how to build the thing, the author's advice is on the right track. If you're unfamiliar with the problem space, just bang away at it. Write that god object, that 500 line function, hardcode all the things. You wouldn't be able to come up with useful abstractions so don't bother trying. Get your stupid terrible code to work, the tiny demo operational, and then take a step back and understand your creation and refactor.

If you do know how to build the thing, if this is your 5th time writing a task scheduler and you know what the ground work for a new one should look like, trust your instincts.

[lhnz]

  > If you're unfamiliar with the problem space, just bang away at it.
  > Write that god object, that 500 line function, hardcode all the things.
  > You wouldn't be able to come up with useful abstractions so don't
  > bother trying.

I take your point about this applying to the context of prototyping. But speaking universally, I'm trying to explain a third way in which you don't try to pick abstractions or apply hyped patterns or find code that you can make DRY, but instead try to write your code conservatively as if it were to be featured in a programming tutorial for newbie engineers. You try to make it easy to understand but you don't make choices about the solution that would require more understanding than you currently have.

In this case, it's not about applying "object-oriented design & algorithms & design patterns & frameworks & abstractions & higher-order functions & monoids & whatever else you found on Hacker News". It could be writing a god object or 500 line function, but only if these are easy to understand.

Basically, I think we should write programs as communication to ourselves and others and as a form of "theory-building". I think our artifacts should fit into this objective and communicate understanding. (I am heavily Naur-pilled, e.g. https://pages.cs.wisc.edu/~remzi/Naur.pdf)

[nickelpro]

Then I disagree with you. If you don't know how to build a static asset server or a Vulkan renderer or an arena allocator at all, then you don't know how to build those things conservatively either.

The first pass in situations you have never been in before is always going to be completely worthless. You do not have any tacit knowledge of the problem space. Your prototype is strictly to gain that tacit knowledge, zero mental stamina should be spent on anyone that isn't between the chair and the keyboard understanding that code.

Once you've built that prototype, you use it as a reference for the ground up "conservative" or whatever other implementation strategy you want to take for the real thing.

[lhnz]

I think perhaps conservative means something different to you that it does to me.

You can write code conservatively by avoiding higher-level abstractions and preferring boring technologies. If you look at the engineering indulgences discussed within the article, they are all things that you can conservatively avoid without any prior understanding of the problem.

The intuition behind this approach is described within Sandi Metz's "The Wrong Abstraction" talk (https://sandimetz.com/blog/2016/1/20/the-wrong-abstraction).

I also disagree that zero mental stamina should be spent on anyone that isn't between the chair and the keyboard. If you're a software engineer working within a company, the approach should generally be understandable by your team at least.