4,840 karma · joined April 17, 2011
https://soloterm.com
Long story short: you should probably use a bigint unless you have a pretty good reason not to. Good reasons exist! If you do use a UUID, make sure you use a version that is time-sorted.
1: https://planetscale.com/courses/mysql-for-developers/indexes...
I'm working incredibly hard to provide a better life for my family. For my two-year-old twins. Finishing projects is part of that work. It's not easy but I think it's worth it.
If you're curious about my story of working, side-hustling, and spending time with my family here's an hour of me talking about it: https://saas.transistor.fm/episodes/bootstrapping-with-kids.
It's full of nuance that you might be wishing was in the article.
In that paragraph I'm describing how I work. The very next sentence is:
> These things work for me, but you'll need to find what works for you.
It's not prescriptive, just descriptive.
You're 100% right and weirdly, that did not occur to me until today. Insightful comment!
Some of the stories I hold onto when I'm having a tough time finishing are those of writers who talk about what a struggle it is to write. Jerry Seinfeld on the Tim Ferriss show was one of my favorite interviews ever. He talks about about how his advice to young comedians is to just work. There's no way around it. That's been a great comfort to me. The War of Art is another good source of inspiration.
Happy to share! The first piece I wrote for GitHub's ReadME Project was called "Publishing your work increases your luck" (https://github.com/readme/guides/publishing-your-work) and I was able to write it as a result of an interview I did with them previously.
Before I wrote that first piece, I reached out to the ReadME Project and told them that I had wanted to tell the story of my past year of overcoming fear and embracing putting myself out there. They agreed that that fit in their "developer stories" section and did an interview of me, which they published here: https://github.com/readme/stories/aaron-francis.
After that they reached out and said "sometimes we have our developer stories have a corresponding guide, do you want to write one" and so that's where the Publishing guide came from. I wrote it all for them and then they have a full on team of editors, proofreaders, illustrators, etc to help push it over the finish line. Before I wrote it I gave them an idea / outline of what I was gonna say, to get the green light. Their editing has been very light, more flow than content. Like... move this sentence up; you repeated yourself there. That kinda thing.
The only time I had a piece really torn apart was this one https://handsontable.com/blog/modularizing-to-improve-the-de... and it was because my voice just didn't fit their blog at all. What you see on the site there is about 35% of what I originally wrote before it was completely toned down. It happens though! It's their blog, so it's gotta fit their voice. (Coincidentally that was the last piece I wrote for them. Ha!)
Let's take one not related to software at all! I turned a shed into an office over the course of many months: https://twitter.com/aarondfrancis/status/1333866090573811723. I wanted to give up and burn it down at some points, but I powered through and ended up with the perfect shedquarters!
I also did a podcast many years ago that was hard for me to produce, but I powered through until I felt like it had reached its natural conclusion: https://www.youtube.com/playlist?list=PLI72dgeNJtzr2Hd6Uscin....
I created a course teaching college students financial accounting that's made over 100k in the 5 or 6 years it's been live (http://acct229.com). That was a freakin grind that I thought about quitting a lot.
I also started doing tech YouTube videos recently and each one is a tiny exercise in finishing (and it feels great to ship!): https://www.youtube.com/@aarondfrancis/videos?view=0&sort=p&...
I wrote and released an open source package called Sidecar (https://github.com/hammerstonedev/sidecar) for managing Lambda functions from Laravel. That led to me speaking at Laracon Online (https://www.youtube.com/watch?v=0Rq-yHAwYjQ) and also to being asked to produce a course for Laracasts (https://youtu.be/0Rq-yHAwYjQ?t=11759). Speaking at the first Laracon led to speaking at the second Laracon Online (https://youtu.be/f4QShF42c6E?t=21744). Both of these led to me being profiled by GitHub's ReadME project at https://github.com/readme/stories/aaron-francis. (The shedquarters is featured here!)
That interview led to another piece called "Publishing your work increases your luck" at https://github.com/readme/guides/publishing-your-work. I gave a talk on that article at GitHub Universe. That article led to... this article. And here we are!
Each of these things have 1) felt awesome to release and 2) directly increased my luck, my bank account, or led to the next thing.
Hope those examples hit home a little harder!
> You can free yourself from this pain without lifting a finger.
Sometimes the cost of doing things is pain. I was going to say the cost of doing _great_ things is pain, but honestly, the cost of doing anything is usually some level of pain.
I hear your feedback, but I don't fully agree with all of it. I do understand the sunk cost fallacy quite well, but thinking about the time committed can be a useful framing to help push past the fear of releasing or drudgery of the last 10%.
> If you tell yourself that every time you don't release a project, the fix is not to release the project, but to stop telling yourself these lies.
I mean, if you never ship you're literally the kind of person who doesn't ship though. You can tell yourself whatever you want, but eventually you'll stop believing yourself because you know it's not true!
Perhaps you'll enjoy my other piece more: Publishing your work increases your luck (https://github.com/readme/guides/publishing-your-work)