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.
Henry@left_pad
here's @rsnous on the dread of using debuggers: "it's not sufficient to just give people a tool that theoretically does the thing. It has to be integrated in the experience in a way that works emotionally"
ref: twitter.com/rsnous/status/…22:30 PM - 05 Oct 2020Omar Rizwan @rsnouswhen I used to TA intro systems programming, kids similarly dreaded using gdb -- they would do almost anything, even if it took way longer and they were completely stuck, to avoid breaking it out
5
18
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 (8)
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.
Was just thinking about this again...will def have a listen.
Something I have noticed is probably less emotional and more psychological, which is the developers who are, for the lack of a better word, entertained by more complicated and abstract solutions. I think it might be "psychological overexcitabilities" or "hyper brain".
Evaluating their decisions in the context of the overall project and it seems less about just being smart and making the right engineering trade-offs - all good devs do that - but there's this decision-making thing some programmers have that's tied to personal gratification. To some extent they make engineering choices based on how stimulating a solution is for them, not how rational or ideal it is for the system (and its users and other programmers).
It's weird. I don't understand it, but your post got me thinking about it again...
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...
I’m thinking it’s less intentional seeking out the complicated, and more like a subconscious bias for complicated things, where easy and simple is quickly dismissed and discarded because it’s not engaging their minds. It’s like their brain goes, “No, cant be right - that’s too easy and obvious. There’s gotta be a more to it...” and they go for something more complicated and mentally stimulating even though the outcomes are the same. I’ve seen this everywhere I’ve worked and tons examples online. The frontend community is full of it.
I’ve heard this referred to as “hyper brain”.
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)