Mentions personal use of Design Patterns.

Transcript context

…How would you hire differently today if you were trying to build a software team for the Opus 4.7+ era? Yeah, I mean, this is another, I'm sure I don't know, and like we're all sort of iterating and learning very rapidly. But, you know, one high level theme, two themes I'm gonna point out. One is, I suspect what you really want now are people who can think outside the box. 'Cause there's no box anymore. You know, the box is established practice. There are a lot of engineers, you know, who've made their careers. You know, I've read the Design Patterns book. I've read the manual, like the style guideline for React or whatever. I know this is a good database design pattern, and that's a design database pattern. We have decades of industry experience telling us this. I've learned to understand when that pattern is good and when that pattern is bad. I've seen it all before, or I've read from people, studied from people who have, and I know the right way to do things, the established way, and I'm gonna do that. And that's all out the window. I mean, you can keep doing that today, but then you're not taking advantage. So we're all... I think you said something earlier in this call about how we're all figuring it out, we're all doing new things, we're all downloading, telling Claude to extract gestalt summaries of what everyone else is doing. It's all new. Oh, I should start building custom UIs. I hadn't been doing that. There's no best practice that I'm aware of. certainly know, you know, establish best practice with a history behind it of how to vibe code your own UI tools to your custom workflow. So we're all making it up as we go and all kind of idiosyncratic to no one's distilled the big patterns yet. So what makes sense for me isn't going to make sense for you because you have different tools, different needs, different situation, different skills, different preferences. And There may be some pattern that's going to underlie a lot of what we all want, some set of design principles, but no one knows them yet. And so it's -- and we're all -- people are posting things, but then they're all obsolete a week later. They're not at the sort of level of, you know, depth and quality of, you know, and universality of, you know, what's kind of emerged, gradually emerged over decades of, you know, more traditional software development. So, yeah, being able to think outside the box, being comfortable navigating without a map, I think, is really important. And then, this I'm just guessing, is that communication skills are really important because, you know, one thing, I'm not, I don't know what it feels like to be doing, you know, professional production, running a software company today, 'cause I'm not doing that right now, but what I hear from the people who are is that, What used to be a team is now a person, and what used to be three teams is now three people. And so, because everyone's running their own suite of agents, and so the amount of coordinating with other people, each person needs to do a whole team's worth of coordinating with other people. ople. And so, because everyone's running their own suite of agents, and so the amount of coordinating with other people, each person needs to do a whole team's worth of coordinating with other people. And my guess is communication skills are important, and that may also overlap with... There's some overlap with being a good communicator with another person and being a good communicator with an agent.…

Stored transcript either side of the excerpt. The highlighted words are the published quote; the surrounding text is unedited source, never generated.