Why do we experience the dread of using certain tools over others (debugger vs. console.log)? Have you thought about how you feel when programming?
35:31 Omar: Once I kind of started introspecting about like, what am I thinking and feeling when I'm programming and why am I not doing things? I noticed that there were all these weird emotional forces that are really determinative of what I'm doing at any given time.
35:45 Omar: And I originally noticed the debugger thing, I tweeted about this, because I was TAing a class in college with freshmen and sophomores who were learning how to program in C and they hated using the debugger. Like they would do almost anything to avoid, to avoid having to pull up the debugger. And again, it's always tempting to tell them. we did usually tell them, like, why don't you open the debugger? But I think at the same time, there's something to learn from that. Like, why don't people want to use the debugger?
Do emotions matter when we are programming, or is that something we leave at home? Or is it something we should hone in on?
Omar joins me to talk about his time working on Dynamicland, or rather, more the way of thinking about programming that Dynamicland tries to embody.
(maybe you've heard of Bret Victor from famous talks like Inventing on Principle (55min) or Learnable Programming)
It's not just able making coding easier, but making computation a more dynamic medium in the sense of using the real world: space, community, our bodies.
In this 40min podcast we talk through a bunch of Omar's tweets: the tyranny of using a list for every UI, how design can at many terms remove a user's control, materiality of physical books, how tech is seen as discrete features vs. a coherent whole, epistemology and knowing things like people, end user programming, and the importance of understanding our emotions when coding.
- Full transcript at https://hopeinsource.com/emotional!
- initial tweet
Top comments (6)
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.
Emotions matter a lot.
I remember coming into work after drinking beer all night. My brain fried, Ididn't do well coding that next day.
Fast forward to 20 years of sobriety, plenty of rest and good health, every day is a new adventure. Can't wait to get started and am focused all day long.
Feeling good emotionally makes for good days.
A real good topic to talk about, I'm here to see how this talk goes forward in this chat. Think that more and more become experienced, more emotions will be reflected from code. Like thinking about how the code should be matured or how the code be distributed or how to introduce youngsters to the code and likewise
Thanks! I sorta brought this up again in another tweet I had about essays around the "human side" of programming that we tend to forget. Something that's been interesting to think about is how the ideas of a creator (even if unconscious) trickle down into the code (the names, how it's structured, etc). Like Rails for DHH as it's creator, etc.
Kind of a long read (and rather academic language at times) but I appreciated this gist.github.com/hzoo/c5e8e1e3f63ba... around the idea of mental models that are built (and dissolved) as people join and leave a codebase. We all have different definitions for terms and vocabulary, sometimes we need a shared one (can also think law)
haha maybe we need some specific examples for this? I don't know if people are necessarily purposely seeking things that seem complicated.
ah yes! Maybe that fits with the idea of choosing things that seem to fit their mental model, or at least makes sense for their current situation even if it doesn't work for anyone else. Other times we just get used to things, "this is the way things are done", which leads into interesting discussion on "folklore practices", twitter.com/modernserf/status/1309...