I have a personal rule which has worked really well for me: if I do a project, the price of doing that project is that I have to write about it.
Back when Twitter threads didn't suck (they could be viewed by people without Twitter accounts) I'd use those - tweet a description of my project with a link, then follow it with a few photos and screenshots.
This is a good piece in that there is absolutely truth to it -- but it's also a bit dangerously non-specific in that it potentially leaves founders with the notion that whatever they happen to think is tautologically correct. To supplement this piece, I would make three specific recommendations that I think tack into the same themes (namely: mistakes founders make -- including trusting the wrong people at the wrong times), but with quite a bit more detail.
First, Tim O'Reilly wrote a superlative piece in 2013, "How I Failed."[0] I cannot recommend this piece highly enough, and it had enormous impact on me as a founder. Its message is quite a bit more complicated than the Graham piece: there are times to stand your ground and resist conventional wisdom (HR in O'Reilly's piece), and there are times when expert practitioners of that conventional wisdom will save your bacon (the CFO in O'Reilly's piece). And the truth is more complicated still in that O'Reilly's specifics may or may not be the ones that a founder needs to apply to their own situation.
Second -- and I recommend this whenever anyone mentions Jobs -- is Randall Stross's "Steve Jobs and the NeXT Big Thing"[1], a history of NeXT written at Jobs' darkest hour. An extraordinary book that will leave you with a much more nuanced view of Jobs: not only in terms of his strengths (definitely those!) and his weaknesses (here in spades!) but especially the way that the NeXT experience surely informed Jobs's (much more successful) return to Apple. (It is a galling failure of the Issacson biography that he spends so little time on NeXT.) Selfishly, I would also recommend our Oxide and Friends discussion of the book.[2]
Third (and finally): a very common specific mistake that technical founders make is how they build out a go-to-market team. This isn't discussed nearly enough, and I was on a podcast episode of Software Misadventures ("Ditching the Rules to Build a Team that Lasts"[3]) with my own co-founder (who came up on the go-to-market side) in which he elaborates on this mistake -- and how founders can avoid it.
Something I've learned is that you don't love and connect with people because of who they are; you don't often find people you magically feel close to or interested in right at the beginning. You can't hold out for that.
You love and connect with people because... you love and connect with them. The more time you spend, the more you share about yourself, the more moments you have together- relationships will usually become deep and meaningful as a result, almost regardless of where they started. If you ask questions that tug on the threads of a person's life, you'll find that almost everyone is interesting. If you take a leap and invest time and energy in people, you'll find life-giving connection you didn't even know could have been there.
It can be hard to bootstrap this process. Like financial poverty, it takes energy to invest in the interactions that eventually lift you out of the lack of energy, which can be a catch-22. But the advice is the same: scrimp and save at first, and then spend strategically until you can get the flywheel going.
But I can almost guarantee that the boundary you're facing is your own shortage of energy, not a shortage of opportunities for connection. Not to trivialize that; it's still a hard place to be in. But I think it would be more productive to re-frame things as such.
Back when Twitter threads didn't suck (they could be viewed by people without Twitter accounts) I'd use those - tweet a description of my project with a link, then follow it with a few photos and screenshots.
These days I use my blog, with my "projects" tag: https://simonwillison.net/tags/projects/
I blog all sorts of other stuff, but if I was ever to trim back the one thing I'd keep doing is projects. If you make a thing, write about that thing. I wrote more about that here: https://simonwillison.net/2022/Nov/6/what-to-blog-about/#pro...
Projects with a GitHub repository make this even easier: describe the project in the README and drop in a few screenshots - that's all you need.
(Screenshots are important though, they're the ultimate defense against bitrot.)
I have many projects from earlier in my career that I never documented or captured in screenshot form and I deeply regret it.