Dan Shipper

Yeah.

Um, so I,

I don't expect people will study prompt engineering, but I expect that they will know some basics about certain little tricks, but mostly how to do it well for their specific use cases.

Do you feel like you really don't understand it?

I still don't, but that's because I hired someone who understands it.

Somebody knows.

That's how I would modify this.

We had a little bit of a retro at every about this whole thing, and when we launch something,

Sometimes we label it as an experiment and it's okay for it to be a little rough around the edges, but if we're really launching something, we want it to be good.

And also, on the other hand, when we launch something, I don't want to have to be up all night seven days in a row trying to fix it for my own health.

No, yeah, for real.

So what I've realized is we need a buddy system where if I'm doing this, I need someone else who knows the code base and knows a little bit about it to...

So that when we launch it, if there are problems, it's not just me in my foxhole trying to understand the code base while it's going down and everyone's looking at me.

Because that's pretty stressful.

You can switch off.

You can switch every other night.

Exactly.

And that...

led me to this articulation of how early product engineering teams should work which is the pirate and the architect model where okay you want a pirate and that's i'm a pirate which is like you're just going you're just going as fast as you can you're just trying to find something that like works and people like um and then the architect is a little bit like i want to really understand how the whole system works and make the whole system work together well as a well-oiled machine

And especially in early product work, you actually don't need a full time architect.