←back to thread

1401 points alankay | 1 comments | | HN request time: 0s | source

This request originated via recent discussions on HN, and the forming of HARC! at YC Research. I'll be around for most of the day today (though the early evening).
Show context
di ◴[] No.11940134[source]
Hi Alan,

In "The Power of the Context" (2004) you wrote:

  ...In programming there is a wide-spread 1st order
  theory that one shouldn’t build one’s own tools,
  languages, and especially operating systems. This is
  true—an incredible amount of time and energy has gone
  down these ratholes. On the 2nd hand, if you can build
  your own tools, languages and operating systems, then
  you absolutely should because the leverage that can be
  obtained (and often the time not wasted in trying to
  fix other people’s not quite right tools) can be
  incredible.
I love this quote because it justifies a DIY attitude of experimentation and reverse engineering, etc., that generally I think we could use more of.

However, more often than not, I find the sentiment paralyzing. There's so much that one could probably learn to build themselves, but as things become more and more complex, one has to be able to make a rational tradeoff between spending the time and energy in the rathole, or not. I can't spend all day rebuilding everything I can simply because I can.

My question is: how does one decide when to DIY, and when to use what's already been built?

replies(6): >>11940184 #>>11940254 #>>11940350 #>>11940433 #>>11940618 #>>11943999 #
stcredzero ◴[] No.11940350[source]
Isn't the answer contained in the quote? Do a cost/benefit analysis of the "amount of time and energy" that would go "down these ratholes" versus the "the time not wasted in trying to fix other people’s not quite right tools."
replies(2): >>11940384 #>>11940454 #
austinjp ◴[] No.11940384[source]
But how can you assess this until you have gone down those rat holes?
replies(4): >>11940449 #>>11940486 #>>11945633 #>>11954395 #
1. jonoCodes ◴[] No.11954395[source]
The Lean Startup advocates proportional investment in solutions. WHEN the problem comes up (again, after deciding to do this) determine how much your time percentage wise this took out of your week or month. Invest that amount to fix it, right now. My interpretation would be, spend that time trying to solve part of it. Every time that problem comes up keep investing in that thing, that way if you've made the wrong call you only waste a small portion of your time. But you also are taking steps to mitigate it if becomes more of an issue in the future.