I thought about this a lot on and off over the years and what I think the best predictor is of what I like to use and what I don't is rhythm. Some tools just get me in a groove, a relatively fast but still comfortable pace where there is a sense of progress at regular intervals, a reinforcement that pushes you along to the next one and so on.
(And yes, I know this sounds a lot like I'm describing a drug.)
So for example in JS running in a browser I'd much rather use console.debug() when I'm writing new code because it feels more in rhythm, whereas when I'm debugging existing systems, I will use breakpoints and stepping rather than switching back to the IDE to find where to stick in a debug statement, and snap out of it.
Now whether other people share this motivation or indeed this is my real motivation and not just some retconned explanation I came up with, I don't know.
But I'm sure it'd be interesting to examine software not just in terms of raw performance (where faster === better) and static UX analysis, but to actually look at the rhythms it creates and whether sometimes a slightly slower but more evenly paced UX makes users feel better about your product.
I think the best predictor is of what I like to use and what I don't is rhythm
It's a good word! I guess some use that vague word, "being in flow". I think that's definitely part of what we talked about in the episode. You don't want things to be in another "mode" that takes you out. So solution could be either that you are "always" in the debugger or that debugging shouldn't feel different than normal coding. And that kind of switch is more important than saving a few seconds.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
I thought about this a lot on and off over the years and what I think the best predictor is of what I like to use and what I don't is rhythm. Some tools just get me in a groove, a relatively fast but still comfortable pace where there is a sense of progress at regular intervals, a reinforcement that pushes you along to the next one and so on.
(And yes, I know this sounds a lot like I'm describing a drug.)
So for example in JS running in a browser I'd much rather use
console.debug()when I'm writing new code because it feels more in rhythm, whereas when I'm debugging existing systems, I will use breakpoints and stepping rather than switching back to the IDE to find where to stick in a debug statement, and snap out of it.Now whether other people share this motivation or indeed this is my real motivation and not just some retconned explanation I came up with, I don't know.
But I'm sure it'd be interesting to examine software not just in terms of raw performance (where faster === better) and static UX analysis, but to actually look at the rhythms it creates and whether sometimes a slightly slower but more evenly paced UX makes users feel better about your product.
It's a good word! I guess some use that vague word, "being in flow". I think that's definitely part of what we talked about in the episode. You don't want things to be in another "mode" that takes you out. So solution could be either that you are "always" in the debugger or that debugging shouldn't feel different than normal coding. And that kind of switch is more important than saving a few seconds.