My Reflections on Bret Taylor’s Podcast Conversation with Shane Parrish About AI and Software Development
From code generation to shifting developer roles to organizational decay, here’s what stood out to me in their discussion.
Welcome to the Scarlet Ink newsletter. I'm Dave Anderson, an ex-Amazon Tech Director and GM. Each week I write a newsletter article on tech industry careers and tactical leadership advice.
Free members can read some amount of each article, while paid members can read the full article. For some, part of the article is plenty! But if you'd like to read more, I'd love you to consider becoming a paid member!
I was recently listening to The Knowledge Project podcast by Shane Parrish, and in April he interviewed he interviewed Bret Taylor. Bret Taylor, if you’re not familiar with him, helped create Google Maps (apparently coded a lot of it), was CTO of Facebook, was Chairman of Twitter, and co-CEO of Salesforce (after his company Quip was acquired by them). He is now a co-founder of Sierra, chairman of OpenAI, and a board member of Shopify. So if you’re looking for someone who has been consistently successful in the world of business and tech, I’d put him on the list.
The podcast was from April, but I was just listening to it, and I found the conversation relevant and still timely.
What frequently happens when I listen to a good podcast is that I take notes and use those as ideas for my next newsletter. I’ll jot down ideas, or send Whatsapp messages to myself if I’m out running.
This time, I took enough notes that I decided that perhaps just talking about the podcast itself as my topic would be a fun idea. So let’s get into it!
I’m going to stay in podcast order, because that’s easiest, and if you feel like jumping into the podcast itself, I’m providing some timestamps so you can fast-forward to that part.
Why are founders able to pivot faster than professional CEOs?
Around ~16:20
This isn’t just about leading companies. I’ve repeatedly seen new blood in organizations try to make massive changes, and they struggle as their peers or team don’t buy their plans. In other situations, an existing respected leader might decide to make a massive pivot, and everyone gets in line without a struggle.
His argument is that the founder’s identity is tied up with the company, so they’re given more latitude not just by employees, but by stakeholders as well. This allows them to make big shifts in direction, which is critical if you want to be responsive to changing conditions.
As one small example, I remember when I first joined the Amazon Marketplace organization, the engineering manager was running the team sprint. In my opinion (still my opinion years later), the engineering manager should be a stakeholder of the sprint, not the person running it. So I told the engineers on the team that they’d need to take over sprint planning.
Oh man, so much pushback. It would slow them down. It wasn’t how they did things. They needed the manager to do it because of various reasons.
I realized later that slightly slower change was called for. Particularly as they didn’t know me or trust my judgment, it would have been better to build agreement.
Regardless, it’s an interesting thing to think about, that perhaps being the founder (of a team, or organization, or company) gives you automatic credibility and the ability to make larger changes. Perhaps the fact that the identity of that group is tied up with you as the creator gives you extra power.
Great leaders aren’t just their main job.
Around ~22:00
The discussion is about startup founders. Bret essentially says that many startup founders are past engineers, but they can only be successful if they broaden their attention and skills past engineering.
Success isn’t tied to one thing, like engineering or product. Success, particularly as a founder (but also as a team leader, senior engineer, or manager), means spending time on what matters now. This might be your primary job (e.g., engineering or design), but it might be policy, recruiting, or marketing.
Employees who are unwilling to pivot to what is needed right now will hit a plateau. Certainly founders unwilling to go outside their comfort zone will hit a wall quickly.
I wrote this article touching on why breadth is critical for leaders to be successful.
The most common place I’ve seen this issue is with junior engineering managers. I don’t know how many times I’ve worked with an engineering manager who was an engineer on the team. They’re still doing code reviews. They’re still deep into the design documents on their team. But you know what they’re not doing? Working with the product management team. Attending cross organizational reviews of other people’s projects. Scoping and estimating work for next year.
Almost inevitably, the attention on your previous job ends up dragging you down. Not because it’s bad to do engineering work. But because doing your past job distracts you from your new job.
Potential future changes in software engineering.
Around ~29:44
Programming languages were written for humans (obviously). We built them because assembler is a huge pain to write or maintain. So we developed languages that would make it easier for humans to write things quickly. This is because humans are expensive, and humans who write code are particularly expensive. The time it takes humans to understand, write, and maintain code is the main cost in software engineering.
Languages like Python are built to be forgiving. With Python, you don’t need types. You can say that a name variable is equal to “Dave” and then set it to an array of numbers. Because Python certainly doesn’t care.
But what’s the downside of a forgiving language? With flexibility comes reduced predictability. This means that testing and verifying that our code is still functioning properly is difficult. And that’s one place we’ve made a tradeoff in modern languages. We know writing code is hard, so we make compromises.
But Bret points out that as AI begins to take over coding, code generation costs drop dramatically. If AI takes over writing code, then writing code becomes fast and cheap. If you view code generation as “free,” then the math of what you want to optimize changes dramatically.
If today’s coding languages were built to make coding easy, what do our languages look like when we intend to optimize for error-free code, or easy debugging, or verifiable correctness?
“Instead of optimizing for convenience, optimize for correctness.”
He mentions a correlation to test driven development. When humans argue for/against it, they generally say that the result is that you slow down initial development, but your final output is more accurate. Does that type of development make more sense in an AI world? When test writing and code writing are free, do we change the methodology of software engineering?
One thing I think it hints at is a future in which code isn’t particularly static. When you need a highly paid software engineer to write code, of course you have them write it once, and you run that code for the next 3-5 years (at least). When your code is written by AI for essentially free, do you necessarily need to archive that code forever? What if it is verifiably correct after writing? Perhaps in the future your software is a set of requirements, and code is dynamically written based on current needs. Imagine telling your smartwatch that today you’d like a UI with the time and weather in a shimmering blue color and a button to start a stopwatch towards the bottom. And AI would write unique code for your watch. Anyway, something to think about.