500. The Coders' Mindset and Transformation of Society feat. Clive Thompson
unSILOed with Greg LaBlanc
The Meritocratic Nature of Biking and Urban Transportation
This chapter delves into the metaphor of biking versus public transport and cars to illustrate the relationship between effort and results. It emphasizes the satisfaction and predictability that comes with biking, contrasting it with the frustrations of delays and unpredictability in other modes of transport.
What effects will generative AI have on coding and software engineering? Will it make anyone a coder? Will it just turn software engineering into copy/paste exercises? How will the top coders use AI to hack their own efficiency and productivity, and why is it so hard for the large tech companies to do the same things that the smaller ones do?
Clive Thompson is a journalist for the New York Times Magazine and Wired as well as the author of multiple books, including Smarter Than You Think: How Technology Is Changing Our Minds for the Better and Coders: The Making of a New Tribe and the Remaking of the World.
Greg and Clive delve into the cultural and societal impacts of the rise of coders, exploring how the coding mindset infiltrates various aspects of life and business. They also discuss the nature of work in software engineering, the shift towards iterative and agile methodologies, and the potential future shaped by generative AI and its implications for the field. Clive explains the paradoxes of efficiency, the challenges of maintenance over creation in coding, and how his life experience and interests converge in his upcoming book about cycling across the United States and the future of mobility.
*unSILOed Podcast is produced by University FM.*
Show Links:
Recommended Resources:
Guest Profile:
His Work:
- Amazon Author Page
- Smarter Than You Think: How Technology Is Changing Our Minds for the Better
- Coders: The Making of a New Tribe and the Remaking of the World
- Wired Articles
Episode Quotes:
Why do coders need an intense level of focus?
If this thing happens [in coding], it will change this other thing. If that thing changes, this thing over here has to happen, and that's also reliant on this other thing. And it's so hard to get the structure of this in your head that you might spend several hours just looking at what you're trying to do, just thinking about it, sort of, getting it in your head. And when it's finally there, then you can begin to do the work. And of course, a couple interesting things fall out of this psychology. One is that you want to stay there. It took you three to four hours to get there, so you don't want to leave. So, you want to stay there for 10, 15, 20, 48 hours.
The huge problem with managing coders.
[18:15] This is a huge problem with managing coders is that they love learning, in a weird way. You would argue, isn't this an ideal employee? Someone who is eager to learn. Constantly learning new things. Very few employees are like, “I am just omnivorous in my spare time when I'm not being paid, I'm going to do more of this.” I mean, how many accountants at your company go home, and then from eight o'clock at night to two in the morning, do more accounting for fun, just voluntarily? That's a coder, right? And what they're doing is they're going home, and they're doing crazy new forms of software that they're not really allowed to do at work, but they often try and bring that in, and they'll be like, “I'm now obsessed with this framework. Hey, boss, can we use this? And it’s like, “No! That framework is experimental and not reliable, and I want you to do the same old boring thing we've been doing for 30 years, because that is reliable.” And this is just a very hard thing. There's an excitement in the craft that a lot of software developers have that's not what the job requires.
An interesting analogy between law and coding
That's a great analogy that I'd never heard or thought of before, which is that law needs to be patched the way that software needs to be patched. Because it's the same challenge, which is that [in] writing code and writing law, you're trying to create a system that other people are going to use. Humans are going to use it. And so you, the author of the law, or you, the author of the code, have to try sitting at your desk to imagine all the things that those dozens, hundreds, thousands, millions, or billions of humans will do with this system. And you can't. There's no way you can. So, you have to just put it out there and watch and see what they do, and then fix it as it goes, basically. And, of course, the more critical the system, or the less critical system, the more or less you can get away with.
The mental character of coding is closer to that of an artist than it is to many other forms of engineering.
Coders hate being interrupted, and that's part of why they're regarded as being such irascible weirdos. [It] is like, if you tap them on the shoulder, they'll bite you.There's something delightful about that mentality of focus. There's something maybe even [to] be learned from it. It's one of the reasons why I realized the more I talked to coders about their attentional needs, and the sweep and drama, and a sort of, epic mental toil, that it reminded me of novelists, of artists, of poets, of temperament. The mental character of coding is closer to that of an artist than it is to many other forms of engineering.
Remember Everything You Learn from Podcasts
