|
|
|
|
|
by nickelpro
1094 days ago
|
|
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. |
|
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.