3 ms·

I do not believe flow has any significant relationship to whether the underlying thing you are creating is going to interface with a pre-existing tool or be a n

by mlthoughts2018 8y ago

I do not believe flow has any significant relationship to whether the underlying thing you are creating is going to interface with a pre-existing tool or be a new creation. I frequently need to reach states of deep flow when I am reading large inter-related files for refactoring, or modifying existing code to use a new library, or to follow tutorials for something only tangential, like new deployment tooling. Reaching states of flow is necessary no matter what you’re doing, and given the insane explosion of modern process overhead and meeting-centric corporate culture, it’s important to protect flow time and make it known how important flow is. Whereas I can see how people might try to use thinking like in your comment to undermine flow time, and falsely act like it’s somehow better to deny developers workspace or blocks of time for getting into flow states.

tommymachine 8y ago
I have to agree with this. You're either writing assembly code yourself, or you're using code that was invented by someone else (and even the assembly code will have been invented by someone!). If using libraries/frameworks is something you do consistently, you can absolutely reach a state of deep work while working with them. Libraries should help keep the flow going at a high level by keeping one from being bogged down with having to reinvent the wheel. In fact, if they didn't contribute to flow, I don't think we'd use them!
- hinkley 8y ago
  I think you're confusing using a library you've already been using (in which case I agree) and introducing a new library. Most people engaging in NIH aren't removing a library that is already being used in your build process. They're deciding it's easier to implement URL processing (spoilers: it's not) than to use a library that already exists. The exception to that is when the existing library turns out to be a dumpster fire and you rip it out and replace it with something else or a custom version.
  - mlthoughts2018 8y ago
    Either way, the decision to (usually wrongly) believe that writing it all yourself is easier/better has little to do with flow.

tommymachine 8y ago

I have to agree with this. You're either writing assembly code yourself, or you're using code that was invented by someone else (and even the assembly code will have been invented by someone!). If using libraries/frameworks is something you do consistently, you can absolutely reach a state of deep work while working with them. Libraries should help keep the flow going at a high level by keeping one from being bogged down with having to reinvent the wheel. In fact, if they didn't contribute to flow, I don't think we'd use them!

hinkley 8y ago
I think you're confusing using a library you've already been using (in which case I agree) and introducing a new library. Most people engaging in NIH aren't removing a library that is already being used in your build process. They're deciding it's easier to implement URL processing (spoilers: it's not) than to use a library that already exists. The exception to that is when the existing library turns out to be a dumpster fire and you rip it out and replace it with something else or a custom version.
- mlthoughts2018 8y ago
  Either way, the decision to (usually wrongly) believe that writing it all yourself is easier/better has little to do with flow.