build quality software w/ https://teapawt.org/t.co/KQiiOo1rSR (YC W26) past: snowflake, robust intelligence, stanford
SF, Palo Alto
Joined September 2017
- Tweets731
- Following274
- Followers328
- Likes4.4K
'Make something that people want' is a good pointer, but at a deeper level, i think that's just downstream of caring about your customers. listening to them, not just viewing them in terms of what they can do for you
It's easy to see through someone who behaves transactionally
how to become the type of person who's great with customers (part 1)
- my uncle has a sweet yet badly trained boxer named Buddy. i've been thinking about Buddy a lot lately.
- Buddy learned that if he constantly barks and growls when guests are around, my uncle will eventually cave and give him treats to shut him up. poor Buddy has made his life materially worse by doing this, and he doesn't even know it. by being mean he gets what he wants - treats & pets from my uncle. but the poor guy is missing out on the same good treatment from every other guest who comes to his house.
- I see a lot of folks doing the same thing: behaving transactionally and getting rewarded for it.* I see it all over the startup world - from interacting w customers, to interviewing candidates, to fundraising (oh my god, fundraising - post for another day).
- let's focus on a specific example today: what can Buddy teach us about being kickass at customer support?
- pick a random customer to do this exercise with: step outside the bounds of the normal transactional relationship and push yourself to go a little bit beyond what you'd normally do for them. ask about their life, their partners, their children. write this down if you have to (really!) so you can ask about these things next time you see them.
- I promise that it will pay surprising dividends to treat a random $20 a month customer like a large enterprise customer (other folks like @mynameisyahia have posted about this!)
- people come to you for help when something isn't going right. They will remember how you made them feel in the moment; before you've fixed their problems, you can at least make them feel heard. To quote Thich Nhat Hanh: "the most precious gift we can offer others is our presence."
- ultimately, what makes or breaks you here is caring. in today's day & age, intelligence itself is automatable. if you're the type of person who can demonstrate this sort of care consistently, you have an insane edge over your competition
- however, there's an additional, unintuitive lesson that took me a while to learn: caring for your customer does NOT mean agreeing to everything they say. it means operating in their best interests, even if it means disagreeing with them.
- think of a "waiter at a fine French restaurant" - a great waiter doesn't let you order a bad wine pairing.
* for more reading on this, check out this lovely article from @threepointone: sunilpai.dev/posts/collectin…
Ketan Agrawal retweeted
giving feedback, part 2: what to do when you're not sure what is wrong, exactly
- imo, the hardest feedback to land is what Slava Akhmechet calls "ambient feedback": when something isn't quite right but it's hard to put your finger on exactly why things aren't working with a coworker.
- ironically, this type of feedback is especially difficult to deliver if the receiver is well-meaning and generally good natured. Folks can and will over-index on feedback in a way to please you. Founders should be especially wary of this failure mode -- you can easily end up compromising your teammates' strengths in light of perceived weaknesses.
- An apt quote here from Nathaniel Hawthorne: "easy reading is damn hard writing". It takes a lot of patience and effort to convey thoughts accurately and simply to another person, especially if you want them to change their behavior. If you're anything like me, it's easy to underestimate the asymmetry in how long feedback should take to write vs. read.
- So writing feedback for murky/uncertain failures is really, really challenging. This is not the school essay that you submit in a mad rush a minute before the final deadline. It's going to take time to get right, and you should get comfortable with that.
- Ok, so how do you actually fix these "ambient failures"?
- I recommend starting from a base of great examples of places that didn't feel right to you, even if you don't know exactly why. I learned how to do this from my friend Brian, who is a deft and tactful leader: collate examples from your mentees/employees into a private document which you can reference later. The examples don't need to be grouped or even labeled with what went wrong; a description for your future reference will do.
- Come feedback time, build from these example documents into to themes: when scanning over examples, you will start to group them, somewhat unconsciously, into themes.
- these themes are going to be much more accurate because they are backed up by evidence. It's a lot harder to be defensive when you have concrete examples to point to as well.
- In the worst case, you might notice that the themes start looking like the job description. At that point, a more serious conversation about role fit / performance is warranted.
- Remember, the ultimate goal of feedback is to help the other person get better, so in any case, the feedback must come along with a proposed plan to help someone get there (which involves your assistance!!)
- I personally enjoyed Radical Candor by Kim Scott if you're looking for further reading on how to do this whole process well.
- Ironically, the feedback process (gathering evidence into a document for later analysis) has been surprisingly useful for supercharging our team's coding agent workflow as well, in the form of agentic lints. The specifics here are a poast for another day.
YC was simultaneously such a valuable experience for us, and also something that if done over, we would’ve changed some things about how we approached it
Recommended reading!
how to avoid the mistakes I made during YC, part 1: the pivot
- I recommend that you come into YC with an “inkling of PMF”.
- For context, I entered YC with very little confidence or work done on my original idea. People tell you that going in that you don’t need an idea & pivoting during is totally fine.
- Of course it is fine to pivot – nobody is going to execute you by firing squad if you do. But the success stories (Brex, Deel) obscure the overall survival rate of companies that pivot.
- Look at the facts of how YC is set up: you have 10-12 weeks to scale a company as quickly as possible; to raise a great round in ‘26 you should probably be doing 1M+ ARR.
- it’s not right to perform gymnastics with the definition of ARR. To get to that ARR milestone, your life is going to be 100x easier if you have genuinely made a sale doing your current idea BEFORE going into YC.
- YC partners write about the pivot for a simple reason: they want you to pivot if your idea is bad! If you've spent 10 years working on something, you’re unlikely to pivot. There is definitely truth in this.
- If I were to do YC again, I would certainly have worked on my idea for a bit before entering. There is a sweet spot here - probably a few months, maybe less, to get an inkling of PMF. In my experience these kinds of companies tend to kill it during the batch.
see thermostats as the amazing cybernetic beings they are
Yes, and if you hire an HVAC technician, and when he comes over, he says that he doesn't believe in machines with 'goals' - maybe says "that's mystical thinking, only physics is real" - fire him immediately. Someone who can't *see* thermostats for the amazing cybernetic beings that they are will be very bad at fixing one, making one, or inventing the next one.
Coming soon: your agents can draw interactive, freeform animations in Whiteboard. examples below powered by the Pele rendering library (thank you @kepano for the amazing open-source lib!)
You can click around in the diagram to see the underlying code. And since Whiteboard is a VSCode fork, you get all the power of LSP, goto-definition etc when inspecting the code :)
we throw very good parties
partiful.com/e/UTzv7T1ioGfUC…
it's actually insane how much better this is than a raw textual diff
introducing diffsthatgetyoustiff.com
diffr is a rust & wasm-based library for beautiful, structural diffs. available as a claude code mod, tui, and a client-side only website (it all runs in wasm!).
blog: dev.fast/blog/diffr
only you can prevent slop
something that keeps bothering me is how some people see slop as something that is happening to them, like they're some kind of helpless bystander powerless to do anything about it
excuse me but you are a software engineer, you literally learned how to make sand think and make computers do your bidding?! and now you can't do anything about it? please
the 2 things you should know to cut through all the noise:
1. you need to give your agent a way to verify its own work (i just posted about this so won't rehash)
2. your codebase is memory
the 2nd is not new either, we have always had lint rules, compilers with good diagnostics and strong type systems, LSPs, etc to help us write better code. there is no difference when agents write the code instead, you just need more of them, and stronger ones.
forget rules and skills. you can add those later.
yes, your codebase is a form of memory to agents! agents love extending what already exists. so every nit and every annoyance you've ever seen, every mistake and bad pattern you observe from agents, needs to turn into a constraint, or the agents will just keep repeating those same mistakes like a virus in your code. then you keep observing and repeating this process until your codebase is locked down enough that even agents with little context can one shot a high quality PR.
an even better direction is to refactor/rewrite your code such that agent anti-patterns become categorically impossible. use type systems to your advantage, use libraries/frameworks that reduce the architectural search space, or heck, create your own framework like we did for grok bot and design high quality primitives and well thought out APIs
Ketan Agrawal retweeted
Reject non-understanding.
Slop grenades are not just code and PRs. We run a real risk that *reading* gets entirely discounted, because of the exhaustion of getting low-quality and unverified AI prose being thrown at you all the time.
There's a thread going viral about a 'perf improvement' attributed to a compiler change. The PR *description* itself has the AI telling this person it's *not* due to the compiler change, it's how the algorithms and data structures have changed. And the implication is that a similar win could have been attained otherwise.
I want AI in the service of understanding the universe and enhancing human cognition and creativity.
so we have the fork primitive in agent harnesses now, and that's useful.. but what about merge 🤔
i often find myself spawning a bunch of sidechats in codex, but then reach a conclusion that should make its way back into the main chat!
Idk if the models need it.. but we humans do!
(Not plan mode exactly, but something that scratches the same itch, something better…)
