4 ms·
That is a very _interesting_ take. I think it's ~wrong but, like most interesting takes, there's some truth to it. I think the "truth" here is that, well yeah y
by randiRando 4y ago
That is a very _interesting_ take. I think it's ~wrong but, like most interesting takes, there's some truth to it. I think the "truth" here is that, well yeah you're not thinking about some things, that's literally what I consider flow, it's not thinking about **how** you're going to do X but it's higher level than that and focusing on "do x".
I think it's the difference between thinking/taking the action "walk to the door and open" (X in the flow state) and "ok get up, left leg forward, right leg forward, left leg forward, right leg forward, move arm to door, grab, twist, pull". Flow is just not thinking about the things that are not important (a lot of code is just gluing and can be done in a flow state - still allowing you to stop and think about the real important places). What your friend is calling out is that yeah I guess that sometimes you can "automate"/flow things that actually are important but to be honest I don't think that happens very often in this context (software, real use(r)-cases) because their use-case are usually so narrow and specific (we should design software to allow them to "flow" the unimportant stuff - click next for the additional questions - did you notice the button responds on mouse click up? I hope not, I hope we made that piece "flowable")
- marcosdumay 4y agoThere is something to be said about flow in mechanical activities, because on those, yes, you are mostly not thinking, just following the "rhythm". Safety is normally one of the first things to get out of your head during that. But programing is nothing like mechanical activities.
- wizofaus 4y agoBut the act of typing on the code and running/debugging it should be. Any toolset where you have to wait excessive amounts of time just to be able edit/ compile/launch/debug/review results is not really going to make you think more carefully about your code (an exception could be made for super long compile times, which do force you to be more careful with what you input, but I'm not really convinced it can help you write better code).
- eitland 4y agoProgramming for me is both: - reading and understanding existing code - a often very goal oriented activity (but sometimes exploratory) where I (try to in the latter case) transform a part of the system according to my visions of a better system - the mechanics of moving the caret around (arrow keys, file selection), selecting text (shift and ctrl modifiers in addition to arrow keys), using shortcuts to invoke pre defined transformations (automated refactoring) etc. It is the thinking I get paid the good money for. But if I was constantly struggling with my tools then it will take more time and I would get exhausted faster.
- marcosdumay 4y ago> the mechanics of moving the caret around You can't hurt yourself moving the caret around.
- eitland 4y agoI thankfully don't suffer from it but ask anyone with RSI about that. My broader point however is that if even a small but non trivial part of my brain capacity must be used to deal with the mechanics. In a way it is like when I learned to use a climbing harness for work and learned to trust it, the effect on my output when I worked in the field was amazing because everything I did was no longer interrupted by constant considerations and adjustments to stay safe.