6 ms·

It's a crazy important quote and everyone should really keep it in mind when they set out to do something. Many people have problems focusing on the task they

It's a crazy important quote and everyone should really keep it in mind when they set out to do something. Many people have problems focusing on the task they set out to do. It's a type of procrastination. Insert that famous gif from Malcolm in the Middle. This is relevant to startups as well (and business in general): Being able to decide whether something is in scope of a project or not. You are encountering a roadblock, how do you react? Do you set out to solve it perfectly or do you work around it (or even, do you give up)? The quote you pasted is the perfect way to put it into words. Another common theme I hear about is people asking: "How do I become a successful [profession here]?" (eg. "streamer", "youtuber", "musician", "programmer", "writer", ...). The answer is always the same: "Start".

3pt14159 8y ago
I think there is a time in a programmer's life when writing tools to make yourself more effective is finally worth it. For me, that time started about two years ago. At 31, a full 25 years since first learning how to program[0] I finally felt like I could be trusted to make the right calls on when to invest the time to abstract or create generation or code parsing tools; and when to do things the old fashion way. After two years of spending about 20 to 40% of my time on tooling I'd wager I'm about 10x faster than I was at 30 and about 20x faster than I was at 25. The problem now isn't writing the code. The problem now is that the code is so fast that I don't have the same amount of passive time to think about features / strategy. I have to intentionally set aside time for it and I find it unnatural. Also, I know too much about cybersecurity which is good for my end users, but bad for my feature productivity. [0] Poorly. My mum taught me how to code QBASIC. I altered video games.
- ryanmarsh 8y ago
  > I think there is a time in a programmer's life when writing tools to make yourself more effective is finally worth it. Indeed yak shaving should only be done when one has the breathing room to do so. It's just good common sense, except there are exceptions. Slack was a yak shaving effort. The most valuable things I've shipped have all been yak shaving efforts. I guess I'm just better at building tools than anything else. Perhaps I enjoy it more. shrug To each their own, but if you're trying to ship a product instead of a bald yak you're going to have to do it the ugly way, with tools you could fix, etc...
  - T-hawk 8y ago
    Shipping is a feature. Your product must have it. That recursively applies to each tool used to make the product as well.
    - ryanmarsh 8y ago
      Shipping is a feature. Your product must have it. I think I’m going to frame that and put it on the wall. Did you come up with that or did you hear it somewhere?
      - T-hawk 8y ago
        Originally from Joel Spolsky: https://www.joelonsoftware.com/2009/09/23/the-duct-tape-programmer/ https://www.joelonsoftware.com/2009/09/23/the-duct-tape-prog...
- dustingetz 8y ago
  This worldview does not take into account network effects, which consolidate the aggregate investment of many people onto a few bad projects. For example Common Lisp is a more effective language than Javascript and always the wrong choice. Corollary: ClojureScript is ecosystem-compatible with Javascript, and TBD if it is a long run better choice!
- da02 8y ago
  What do you mean by, "I know too much about cybersecurity which is good for my end users, but bad for my feature productivity"?
  - 3pt14159 8y ago
    This is most easily explained by examples. Before: I'll get my clients to give me access to an S3 bucket that I can push their data to. Now: I'll make sure I get my clients to give me a password or public key to encrypt their data before I push it to the S3 bucket because many people fuck up security on those things. To my end user, it's obviously more secure, but it isn't lining my pocketbook and most end users don't care about security, even if they should. Same thing with security headers or anything, really. Security slows you down at some point.
  - brazzledazzle 8y ago
    One thing that pervasively infects every decision is the principle of least privilege. Basically it’s the idea that someone/something should only have the minimum access necessary to do what they/it is supposed to do. It applies to infrastructure access control, network communication, application access control, everything. Once it becomes a default part your thinking you sometimes have to make conscious tradeoffs so you don’t spend forever perfecting things and not delivering any value. Ideally a lot of that thought and effort is common or reusable though.
enriquto 8y ago
> It's a crazy important quote and everyone should really keep it in mind when they set out to do something. I don't agree at all. It seems to me that the most interesting advances of mankind have happened precisely when people were trying to do something else, and had to invent new tools. The tools turn out to be more important than the final result because they can be used by other people.
- misternugget 8y ago
  > when people were trying to do something else, and had to invent new tools. (Author here.) My point was not that you shouldn't invent tools if you need them. By all means, go ahead. My heart beats for creating tools (especially tools to create other tools...). What I wanted to express was this: if you want to write _a book_, first write the book and only then worry about the tools. If you then notice that you need a custom toolchain to get the book in exactly the shape you need it to be, do it. I've had people tell me that they would love to write a book, but, well, the existing tools are not sufficient enough. And I think that's the wrong approach to writing a book: write something and you'll quickly realize that the tooling is not your biggest hurdle.
  - scrollaway 8y ago
    You keep wording what I'm trying to say far better than I ever could. I'm not surprised you wrote a book :)
  - bocklund 8y ago
    > I've had people tell me that they would love to write a book, but, well, the existing tools are not sufficient enough. That’s hilarious. Humans were hand writing books on paper and giving them to other humans to hand write copies. A good craftsman never blames his tools.
    - dragonwriter 8y ago
      > Humans were hand writing books on paper and giving them to other humans to hand write copies. Not very many were, and a big reason for that was the available tooling. > A good craftsman never blames his tools Someone who writes a book by blames the available tooling support for the low quality of its content is a craftsman (but, per the saying, not a good one) blaming his tools. A person who chooses not to write a book at all because the anticipated opportunity cost given the existing tooling support and that person’s personal utility function is not.
anderspitman 8y ago
I'd say it's a balance. I try to lean towards staying focused on my goal while keeping an eye out for potentially more important detours.
purplezooey 8y ago
this is how a lot of cool shit got done in history though, not focusing on the task necessarily

3pt14159 8y ago

I think there is a time in a programmer's life when writing tools to make yourself more effective is finally worth it. For me, that time started about two years ago. At 31, a full 25 years since first learning how to program[0] I finally felt like I could be trusted to make the right calls on when to invest the time to abstract or create generation or code parsing tools; and when to do things the old fashion way. After two years of spending about 20 to 40% of my time on tooling I'd wager I'm about 10x faster than I was at 30 and about 20x faster than I was at 25. The problem now isn't writing the code. The problem now is that the code is so fast that I don't have the same amount of passive time to think about features / strategy. I have to intentionally set aside time for it and I find it unnatural. Also, I know too much about cybersecurity which is good for my end users, but bad for my feature productivity. [0] Poorly. My mum taught me how to code QBASIC. I altered video games.

ryanmarsh 8y ago
> I think there is a time in a programmer's life when writing tools to make yourself more effective is finally worth it. Indeed yak shaving should only be done when one has the breathing room to do so. It's just good common sense, except there are exceptions. Slack was a yak shaving effort. The most valuable things I've shipped have all been yak shaving efforts. I guess I'm just better at building tools than anything else. Perhaps I enjoy it more. shrug To each their own, but if you're trying to ship a product instead of a bald yak you're going to have to do it the ugly way, with tools you could fix, etc...
- T-hawk 8y ago
  Shipping is a feature. Your product must have it. That recursively applies to each tool used to make the product as well.
  - ryanmarsh 8y ago
    Shipping is a feature. Your product must have it. I think I’m going to frame that and put it on the wall. Did you come up with that or did you hear it somewhere?
    - T-hawk 8y ago
      Originally from Joel Spolsky: https://www.joelonsoftware.com/2009/09/23/the-duct-tape-programmer/ https://www.joelonsoftware.com/2009/09/23/the-duct-tape-prog...
dustingetz 8y ago
This worldview does not take into account network effects, which consolidate the aggregate investment of many people onto a few bad projects. For example Common Lisp is a more effective language than Javascript and always the wrong choice. Corollary: ClojureScript is ecosystem-compatible with Javascript, and TBD if it is a long run better choice!
da02 8y ago
What do you mean by, "I know too much about cybersecurity which is good for my end users, but bad for my feature productivity"?
- 3pt14159 8y ago
  This is most easily explained by examples. Before: I'll get my clients to give me access to an S3 bucket that I can push their data to. Now: I'll make sure I get my clients to give me a password or public key to encrypt their data before I push it to the S3 bucket because many people fuck up security on those things. To my end user, it's obviously more secure, but it isn't lining my pocketbook and most end users don't care about security, even if they should. Same thing with security headers or anything, really. Security slows you down at some point.
- brazzledazzle 8y ago
  One thing that pervasively infects every decision is the principle of least privilege. Basically it’s the idea that someone/something should only have the minimum access necessary to do what they/it is supposed to do. It applies to infrastructure access control, network communication, application access control, everything. Once it becomes a default part your thinking you sometimes have to make conscious tradeoffs so you don’t spend forever perfecting things and not delivering any value. Ideally a lot of that thought and effort is common or reusable though.

enriquto 8y ago

> It's a crazy important quote and everyone should really keep it in mind when they set out to do something. I don't agree at all. It seems to me that the most interesting advances of mankind have happened precisely when people were trying to do something else, and had to invent new tools. The tools turn out to be more important than the final result because they can be used by other people.

misternugget 8y ago
> when people were trying to do something else, and had to invent new tools. (Author here.) My point was not that you shouldn't invent tools if you need them. By all means, go ahead. My heart beats for creating tools (especially tools to create other tools...). What I wanted to express was this: if you want to write _a book_, first write the book and only then worry about the tools. If you then notice that you need a custom toolchain to get the book in exactly the shape you need it to be, do it. I've had people tell me that they would love to write a book, but, well, the existing tools are not sufficient enough. And I think that's the wrong approach to writing a book: write something and you'll quickly realize that the tooling is not your biggest hurdle.
- scrollaway 8y ago
  You keep wording what I'm trying to say far better than I ever could. I'm not surprised you wrote a book :)
- bocklund 8y ago
  > I've had people tell me that they would love to write a book, but, well, the existing tools are not sufficient enough. That’s hilarious. Humans were hand writing books on paper and giving them to other humans to hand write copies. A good craftsman never blames his tools.
  - dragonwriter 8y ago
    > Humans were hand writing books on paper and giving them to other humans to hand write copies. Not very many were, and a big reason for that was the available tooling. > A good craftsman never blames his tools Someone who writes a book by blames the available tooling support for the low quality of its content is a craftsman (but, per the saying, not a good one) blaming his tools. A person who chooses not to write a book at all because the anticipated opportunity cost given the existing tooling support and that person’s personal utility function is not.

anderspitman 8y ago

I'd say it's a balance. I try to lean towards staying focused on my goal while keeping an eye out for potentially more important detours.

purplezooey 8y ago

this is how a lot of cool shit got done in history though, not focusing on the task necessarily