Steve Newman: commitment

Transcript context

…Yeah, definitely, definitely, Claude was doing a lot of spelunking in the database schema to try to, you know, like, what's a reply versus an original message? And like, how do you go from like a user ID to a username? And like, yeah, the integrations were far and away the worst part. And I have to think, you know, like, of course, You know, there are all these solutions for this, but, you know, people are, you know, first-party providers are building MCPs and other kind, you know, and other APIs, and there's all these, you know, there's Tasklet and all these other services out there that are, and, you know, Claude Cowork, and, you know, all these other, everybody's building the integrations, and I have to think that's where a lot of value is going to be. But if you're, yeah, if you're just coding your own solutions, that's been really the hardest part. for me as someone with a lot of software engineering background, but rusty and no like, you know, kind of specific experience with the details of all, you know, everything that's going into these apps. You know, there's a lot I did to set up. Flare and hosting and like connecting, you know, understanding how to connect an Android app to a, you know, through a Docker container into a web app and everything, which wasn't hard because I know how all that stuff works. I don't know how it would have been otherwise. And then, you know, I think, but the main thing that's hard is not getting complacent. There's always the next level of productivity And it's so hard to unlearn the habit of the world is the way it is, and your tools are the way they are. And every now and then, maybe there's a new release, or you might look into a new-- maybe I'm going to switch from Google Docs to Notion or whatever. But mostly, your tool set is just static, and just unlearning the idea that you have to adapt your workflow to the tools rather than the other way around. And then figuring out, and then figuring out what to do with it. Like I, another thing I've always assumed I would do and I haven't done is something that works, works more with the detail of, so like, you know, I've got this sort of unified inbox, but, you know, so, you know, one e-mail I get every day is the San Francisco Chronicle daily newsletter. And, It's this long scrolling thing full of news items and ads, and I don't want to see the ads, and I don't want to see the food updates, and I don't want to see the sports articles unless they're about the Warriors. But I do want to see this and this. And I'd always assumed I would write some filter to show me just those parts, and multiply that times 50 other examples of e-mail that I get regularly. And I haven't gotten around to doing it. Maybe that's a good choice that I'm subconsciously deciding that it would be more trouble than it was worth. I think probably not. I need to motivate to... ly. And I haven't gotten around to doing it. Maybe that's a good choice that I'm subconsciously deciding that it would be more trouble than it was worth. I think probably not. I need to motivate to... I don't want to have to build 50 features, so I have to come up with some conceptual framework for how I can get to the point where I just sort of say one or two sentences about each one to Claude, and Claude can figure out what to do with it in a way that I will trust that I'm still seeing the information I need to see, and I just haven't motivated to take a step back, and I probably need to dive in and fumble around and do it wrong the first time, and then eventually I'll settle in on a good way of doing that. So it's that push to actually take advantage of all the new opportunities and do the exploration. Another habit I've been having, my whole software engineering career, I always worked very hard to think things through, understand the problem upfront, kind of measure twice, cut once. Really understand the problem, make sure you've pulled out all the details of the use case, go and talk to the person who wrote the spec, find out what they forgot to put in, think through the four different ways you could structure the code. Do all that work up front, so then when you have to do all the long tedious work of writing and testing and debugging the code, that you kind of get it right-ish the first try. I think that's totally wrong now. Like the just dive in, do it wrong, throw it away, redo it is so much the better approach now. It's not at all my nature. And so I've been having like relearning that also is what's hard for me. Do you have thoughts on when to revert? This has changed for me and it's probably gonna change again. We just got 4/7 in the last few hours. So recognizing it's a moving target, I don't know. Six months plus ago, I would have told people that it's often easier to get the thing to work once in or in one shot than to have it fail and then figure out how to fix it. So I used to advise if it's not working and you're kind of stuck, if you're like looping at all, revert back to the last known good state, try that prompt again, maybe say, Here's kind of a bit of what went wrong last time, and you'll probably have a better chance of getting it to work that way versus trying to get out of that stuck state. These days, I don't feel like that's as big of a problem. I haven't found myself doing that recently. Do you have like rules of thumb or best practices for when you would press on versus fall back?…

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