A blog by Justin Hunter to pollutes your mind

The Serendipity of Colliding Worlds

2025-11-04T00:17:58Z

In another world, I'm a writer. Not a writer of blog posts or code, but a write of fiction. In that world I went to the Arcadia University in Philadelphia and got an MFA in Creative Writing. In that world, I have a collection of short stories that was published at the height of the pandemic by a small, independent publisher. In that world, I'm not just another tech bro. I'm someone else entirely, immersed in the worlds I have created in my own mind.

But there is the other world. The world of tech and code and startups and valuations. The world of open source, of code editors, of side projects, and of product management. In that world, I am a developer and a product manager. I am a consumer of all the newest trends in tech. I am, as you see on this blog, a sharer of thoughts on those trends.

Those worlds are separate but related. They make up a whole, and that whole is me. We all live in multiple worlds with various levels of segregation achieved through happenstance or considered planning. For every person you think you know at work there is a different version of that person at home, a different version sitting in their car at lunch or lifting weights at the gym before work. All of their versions of themselves unify into the whole person, of whom you might only know a part.

Yet, every so often, there is a collision of worlds. Today I experienced one such collision. I was reading the front page of Hacker News like I do every morning before my kids get up for school. I'm drawn to Hacker News because it skews technical, but the topics often stretch beyond the technical or are only tangentially related to the technical. It was one of these tangentially related articles that caught my attention this morning. At the time, the article was ranked 4th on Hacker News. It was a piece called My Truck Desk, written in the Paris Review.

Now I know The Paris Review from my literary world, and I was immediately intrigued by its appearance on Hacker News. Though such sources of information are not foreign to the site—I often see articles from the Los Angeles Review of Books and similar—there was still something intriguing about "high brow" content from a decidedly analog publication such as The Paris Review appearing on the front page of Hacker News.

I read the article without paying attention to the author, as I usually do. It's an unfair practice that I should get better at. Throughout the read, I was drawn in by the author's voice, the storytelling, and the author's own descriptions of their worlds colliding. As I reached the end of the article, the author was mentioned again with more details about who they were. And I was immediately struck by a collision of my literary and tech worlds.

The article was written by Bud Smith. I don't know Bud personally, but I interacted with many of the students who were in his MFA cohort. Bud was one cohort behind me in Arcadia University's MFA program. I knew him by reputation and by his cohort-mates. I knew him by proximity.

Arcadia is not a big school. It's not the most well-known MFA program in the country, but it's a good one. It taught me a lot, and I am a better writer for it. It has also produced some incredible talents, including Bud. But never in a million years would I have expected something Bud had written to appear on Hacker News. Those worlds are too far apart, separated by an endless stream of prose, bracketed off by code and semi-colons and syntax errors.

And yet, there he was. On the front page. A collision of worlds.

Pausing Coding To Write

2025-10-23T00:41:31Z

Last year I wrote about how learning to code made it significantly harder for me to write creatively. I believe the brain uses the same part for both coding and for writing prose or poetry. This makes it very hard for me to be able to do both. As long as I'm coding and it is scratching the creative itch, it's nearly impossible for me to write something like a short story or a novel.

That said, even in the midst of coding quite frequently from 2023-2024, I managed to pull out a novel I had written in 2018 and revise it. I polished it and wrote multiple drafts. This was incredibly difficult and the idea of trying to write a new novel entirely was daunting. There's a difference between editing/revising and writing something net new. I would equate it to fixing bugs versus building a new project in coding.

As I submitted that novel to literary agents in hopes of representation (I landed an agent in March!) and as the book was eventually sent out "on sub" to publishers, I needed a way to distract myself from the slow-moving world of publishing. I wanted to write a new novel to do that. But I couldn't do it while I was actively writing code and building new side projects.

So, over the last few months I've reluctantly slowed my coding. Instead of building new things, I have focused on writing a first draft of this new novel. It's largely worked. I have written code here and there, and I have slowed down on my new novel here and there, but I'm now at over 100k words and nearly done with the first (read: vomit) draft.

A big part of the reason it has even been possible for me to shift from coding to writing prose again is that my new job is entirely focused on my working in product management instead of a mix of product and engineering. This frees up my brain...or maybe it makes my brain demand a creative release. And I have been able to fill that gap with this novel.

Maybe one day I'll figure out a way to balance both code and prose. But until then, I'll just have to accept the challenge of pausing one to pick up the other.

An Idea For Two Withered Technologies

2025-10-09T00:29:11Z

I've been exploring RSS a lot lately as I try to remove (or at least distance) myself from social media. There are many good options on the market, including self-hosted options, native mobile apps, and web apps. The problem I am facing is that I don't want yet another app.

As I've been playing around with the Rust programming language more and more, I started building an RSS feed reader just to advance my skills with Rust. But in the process, I had an idea.

What if I didn't need a new app to receive RSS feeds and read them? What if I could combine two withered technologies (RSS + Email) to create exactly what I wanted? To see how it felt, I mocked up a simple service that fetched my own RSS feed for this blog, filtered only for new updates, and then I used the lettre crate to spin up a simple SMTP server to send emails from a domain I already own with the content of the new feed item.

This worked relatively well. There are improvements I can make for sure. See the image below for an example of the simple test:

Things I like about this idea:

No new application to download or sign into (it's just email)
Replicates the power of newsletters by delivering the new feed items directly into my inbox
Can be run by anyone

But is it all that interesting overall? I don't know. I think I'll build this out a bit more and run it for a few weeks to see how it feels. I think automatically labeling and moving these emails into folders in my email client would enhance the experience. We'll see!

Video Games As A Time Capsule

2025-10-08T00:29:11Z

As I watch the Seattle Mariners and Detroit Tigers play in the 2025 Major League Baseball playoffs, I'm transported back in time. This year was the first time the Mariners won the American League West division in 24 years, but we have to go back even further. We have to go back to 1998.

The summer of 1998 for me was one full of anxiety, excitement, and baseball. I had finished middle school and was trying to prepare myself for the world of high school. At the same time, I was living in San Diego, as I did every summer as a kid after my parents' divorce, and I was watching the San Diego Padres do something special. The Padres were a team I first fell in love with in 1996 when my father took me to my first Major League game. I didn't know the world of hurt I was in for.

The Padres had been a middling team for their entire existence. They made it to the World Series in 1984, only to be swept by a juggernaut in the Detroit Tigers. But that was about it. That 1996 team I fell in love with made the postseason only to be promptly swept. But 1998 felt different. I spent the summer cheering the team on, going to games when my dad could take us, and generally trying to ignore the looming shadow of high school.

When that summer ended and I returned to my life in Tucson, Arizona, I had to face two things: high school and no more baseball. The Arizona Diamondbacks were in the midst of their inaugural year up in Phoenix, but I didn't want anything to do with them, and I didn't have an easy way to get to the games 90 miles north. To get my fix, I was able to listen to Padres baseball on the nascent web (yes, streaming radio broadcasts were a thing on the web in 1998) and I was able to play Major League Baseball Featuring Ken Griffey Jr. on the Nintendo 64 with my friends.

The game came out in May of that year and was populated with the current roster at the time. Since it came out after the season had already begun, and since development of games takes forever, the developers surely used the 1997 season stats to help define the players' capabilities in the game. This is important because Ken Griffey Jr., the title player, played for the Seattle Mariners. And the Mariners were STACKED in 1997.

Check out the numbers for the 1997 Mariners:

Standard Batting Table
Rk	Player	Age	Pos	WAR	G	PA	AB	R	H	2B	3B	HR	RBI	SB	CS	BB	SO	BA	OBP	SLG	OPS	OPS+	rOBA	Rbat+	TB	GIDP	HBP	SH	SF	IBB	Pos	Awards
1	Dan Wilson	28	C	3.8	146	563	508	66	137	31	1	15	74	7	2	39	72	.270	.326	.423	.749	96	.347	102	215	12	5	8	3	1	*2/H
2	Paul Sorrento*	31	1B	2.4	146	513	457	68	123	19	0	31	80	0	2	51	112	.269	.345	.514	.859	123	.371	121	235	13	3	0	2	9	*3H/D
3	Joey Cora#	32	2B	2.6	149	649	574	105	172	40	4	11	54	6	7	53	49	.300	.359	.441	.800	110	.354	109	253	6	5	8	9	2	*4H	AS
4	Álex Rodríguez	21	SS	5.7	141	638	587	100	176	40	3	23	84	29	6	41	99	.300	.350	.496	.846	120	.393	130	291	14	5	4	1	1	*6/D	AS
5	Russ Davis	27	3B	1.8	119	455	420	57	114	29	1	20	63	6	2	27	100	.271	.317	.488	.805	109	.358	109	205	11	2	3	2	2	*5/HD
6	José Cruz#	23	LF	1.6	49	198	183	28	49	12	1	12	34	1	0	13	45	.268	.315	.541	.856	120	.368	116	99	3	0	1	1	0	7/H	ROY-2
7	Ken Griffey Jr.*	27	CF	9.1	157	704	608	125	185	34	3	56	*147*	15	4	76	121	.304	.382	.646	1.028	165	.427	158	393	12	8	0	12	23	*8/D7	AS,MVP-1,GG,SS
8	Jay Buhner	32	RF	3.3	157	665	540	104	131	18	2	40	109	0	0	119	*175*	.243	.383	.506	.889	132	.397	137	273	23	5	0	1	3	*9/HD	MVP-19
9	Edgar Martínez	34	DH	6.2	155	678	542	104	179	35	1	28	108	2	4	119	86	.330	.456	.554	1.009	165	.439	169	300	21	11	0	6	11	*D/3H5	AS,MVP-14,SS
Rk	Player	Age	Pos	WAR	G	PA	AB	R	H	2B	3B	HR	RBI	SB	CS	BB	SO	BA	OBP	SLG	OPS	OPS+	rOBA	Rbat+	TB	GIDP	HBP	SH	SF	IBB	Pos	Awards
10	Rich Amaral	35	LF	-0.5	89	210	190	34	54	5	0	1	21	12	8	10	34	.284	.327	.326	.653	73	.301	74	62	7	3	5	2	0	7H34/89D56
11	Mike Blowers	32	1B	0.6	68	177	150	22	44	5	0	5	20	0	0	21	33	.293	.376	.427	.802	112	.362	113	64	4	0	4	2	1	3H5/79D
12	Brent Gates#	27	3B	-0.4	65	170	151	18	36	8	0	3	20	0	0	14	21	.238	.298	.351	.649	71	.290	62	53	6	0	2	3	0	54H/637D
13	Rob Ducey*	32	LF	0.9	76	151	143	25	41	15	2	5	10	3	3	6	31	.287	.311	.524	.836	115	.347	106	75	3	0	0	2	0	79H8
14	Lee Tinsley#	28	LF	0.1	49	133	122	12	24	6	2	0	6	2	0	11	34	.197	.263	.279	.542	43	.259	39	34	4	0	0	0	0	7H/8D9
15	Roberto Kelly	32	LF	1.1	30	129	121	19	36	7	0	7	22	2	1	5	17	.298	.328	.529	.857	122	.373	121	64	2	1	1	1	0	7/H8D
16	Andy Sheets	25	3B	0.2	32	102	89	18	22	3	0	4	9	2	0	7	34	.247	.299	.416	.715	86	.327	84	37	1	0	5	1	0	5/64H
17	John Marzano	34	C	0.1	39	96	87	7	25	3	0	1	10	0	0	7	15	.287	.340	.356	.697	85	.327	88	31	2	0	2	0	0	2/HD
18	Álvaro Espinoza	35	MI	-0.6	33	78	72	3	13	1	0	0	7	1	1	2	12	.181	.213	.194	.408	9	.187	-11	14	2	1	3	0	0	64/H5
19	Raúl Ibañez*	25	OF	-0.4	11	26	26	3	4	0	1	1	4	0	0	0	6	.154	.154	.346	.500	27	.206	4	9	0	0	0	0	0	/9H7D
20	Rick Wilkins*	30	DH	0.1	5	14	12	2	3	1	0	1	4	0	0	1	2	.250	.286	.583	.869	122	.347	102	7	0	0	0	1	0	/2DH
21	Dan Rohrmeier	31	DH	0.1	7	11	9	4	3	0	0	0	2	0	0	2	4	.333	.455	.333	.788	113	.378	124	3	0	0	0	0	0	/HD3
22	Brian Raabe	29	IF	0.0	2	4	3	0	0	0	0	0	0	0	0	1	2	.000	.250	.000	.250	-26	.181	-14	0	0	0	0	0	0	/54H
23	Giomar Guevara#	24	MI	-0.2	5	4	4	0	0	0	0	0	0	1	0	0	2	.000	.000	.000	.000	-100	.059	-141	0	0	0	0	0	0	/4DH6
Rk	Player	Age	Pos	WAR	G	PA	AB	R	H	2B	3B	HR	RBI	SB	CS	BB	SO	BA	OBP	SLG	OPS	OPS+	rOBA	Rbat+	TB	GIDP	HBP	SH	SF	IBB	Pos	Awards
24	Jeff Fassero*	34	P	0.0	2	5	5	0	1	0	0	0	0	0	0	0	2	.200	.200	.200	.400	6	.181	-13	1	0	0	0	0	0	1
25	Jamie Moyer*	34	P	0.0	1	3	3	0	1	0	0	0	0	0	0	0	0	.333	.333	.333	.667	77	.301	70	1	0	0	0	0	0	1
26	Derek Lowe	24	P	0.0	2	2	2	0	0	0	0	0	0	0	0	0	1	.000	.000	.000	.000	-100	.000	-136	0	0	0	0	0	0	1
27	Omar Olivares	29	P	0.0	1	2	2	0	1	0	0	0	2	0	0	0	1	.500	.500	.500	1.000	166	.452	176	1	0	0	0	0	0	1
28	Ken Cloude	22	P	0.0	1	2	2	0	0	0	0	0	0	0	0	0	0	.000	.000	.000	.000	-100	.000	-136	0	0	0	0	0	0	1
29	Josías Manzanillo	29	P	0.0	2	1	1	0	0	0	0	0	0	0	0	0	0	.000	.000	.000	.000	-100	.000	-150	0	0	0	0	0	0	1
30	Bob Wells	30	P	0.1	3	1	0	1	0	0	0	0	0	0	0	1	0		1.000				.724	375	0	0	0	0	0	0	1
31	Bob Wolcott	23	P	0.0	1	1	1	0	0	0	0	0	0	0	0	0	0	.000	.000	.000	.000	-100	.000	-150	0	0	0	0	0	0	1
32	Mike Timlin	31	P	0.0	2	0	0	0	0	0	0	0	0	0	0	0	0								0	0	0	0	0	0	1
33	Heathcliff Slocumb	31	P	0.0	2	0	0	0	0	0	0	0	0	0	0	0	0								0	0	0	0	0	0	1
34	Scott Sanders	28	P	0.0	1	0	0	0	0	0	0	0	0	0	0	0	0								0	0	0	0	0	0	1
35	Greg McCarthy*	28	P	0.0	1	0	0	0	0	0	0	0	0	0	0	0	0								0	0	0	0	0	0	1
36	Norm Charlton#	34	P	0.0	4	0	0	0	0	0	0	0	0	0	0	0	0								0	0	0	0	0	0	1
37	Bobby Ayala	27	P	0.0	4	0	0	0	0	0	0	0	0	0	0	0	0								0	0	0	0	0	0	1
	Team Totals			37.4	162	6385	5614	925	1574	312	21	264	890	89	40	626	1110	.280	.355	.485	.839	119	.372	120	2720	146	49	46	49	53
	Non-Pitcher Totals			37.3		6368	5598	924	1571	312	21	264	888	89	40	625	1106	.281	.355	.485	.841	119	.372	120	2717	146	49	46	49	53
	Pitcher Totals			0.1		17	16	1	3	0	0	0	2	0	0	1	4	.188	.235	.188	.423	14	.202	1	3	0	0	0	0	0

Provided by Baseball-Reference.com: View Original Table
Generated 10/8/2025.

Oh, and they had both Randy Johnson and Jamie Moyer on the starting pitching staff.

So, the Mariners had a great offense and Ken Griffey Jr. was already my favorite player. Despite being a huge Padres fan, I spent my time playing as the Mariners. When my friends and I would play, no team was off limits, but whoever got to the team first got to play as them. I always raced to select the Mariners. I played countless hours throwing nasty Randy Johnson sliders, followed by 100mph fastballs. I would hit bombs with Griffey and rake doubles with Alex Rodriguez and Edgar Martinez.

I can still see the interface as clear as if I were back in 1998. The game did a great job representing the capabilities of each player based on the historical stats and amplified (presumably) by their prior-season stats. I can still remember playing as the Padres occasionally and being frustrated by how inept the team was in the game when the real Padres were having their best season.

All of this brings me to the point of this article. I still have that game. I still have my Nintendo 64. I can fire the game up and experience it exactly as I did in 1998. There is something special about that. It's a time capsule of memories. It's a baseball card come to life. If I ever want to remind myself how good the Mariners offense was back then, all I have to do is plug the N64 in, hook it up to a TV, and insert the cartridge. If I want to see Randy Johnson in his prime and a 40-homer version of Jay Buhner, I can do it any time I want. And this applies to every other team in the game.

In 1997, the Florida Marlins beat the Cleveland Indians in the World Series, so I can experience the game's developers' predictions of what that meant for the 1998 season by playing as either of those teams. If I want to play as current Cubs (another playoff team) manager Craig Counsell, I can select the Marlins and enjoy "The Chicken" and his unique batting stance.

Try doing that with any games made in the last decade. Every sports game—and just about every game—is internet-connected. Rosters update in real-time. If you play the same game the following season, you can connect and update the roster to the current year's roster. You lose the history. You lose the time capsule.

It feels a lot like tearing a baseball card up every year.

Yes, there's some millennial nostalgia at play here, but I miss being able to return to the way things were without being constantly prompted to update to the way things are now. We don't need to live in the past, but we shouldn't lose it. We should be able to remember it and experience it where possible. That game, in that specific year, meant a lot to me.

I'm thankful I can play it today exactly as I played it back then.

Falling Out Of Love With Farcaster

2025-10-04T14:29:11Z

It's been nearly three years since I joined Farcaster, a "sufficiently decentralized" social protocol. I wrote about my tentative optimism about the protocol back then while acknowledging that I had been burned in the past when expectations ultimately didn't live up to reality.

Unfortunately, Farcaster has failed to live up to the expectations I had three years ago. I'll explain why, but first, here's a quick primer on how the protocol works.

Farcaster's Protocol

Farcaster achieves its self-determined sufficient level of decentralization through the use of both blockchain smart contracts and a blockchain-like network of Snapchain nodes.

The blockchain smart contracts manage name/handle registration and paying for storage. Storage payments go to the protocol and ensure posts, comments, likes, etc are not pruned. Snapchain nodes do all of the actual storage of Farcaster data as well as routing between other nodes. Much like a blockchain network, Snapchain nodes must store an entire copy of the entire network's data.

Technically, anyone can run a Snapchain node, but as you might expect, most people rely on a few paid services to manage this for them. Farcaster itself has a client (confusingly) called Farcaster. The Farcaster client runs its own Snapchain nodes, but there are service providers that allow app developers and other clients to plug into hosted and highly available nodes.

Onboarding to Farcaster requires cryptocurrency. This is simply due to the nature of how the naming system works and how it interacts with the blockchain. This, of course, is quite the hurdle for many people.

Every post, follow, like, and more is data stored on Snapchain nodes. Every user has a paid storage allocation. If they exceed the allocation, older data can be "pruned" which means deleted forever. Users can pay for more storage at any time.

Farcaster's Promise

The promise is one rooted in one of the web's most loved and most abandoned primitives. RSS. Dan Romero, one of Farcaster's co-founders, wrote about the idea of RSS+ which was the original spec for the Farcaster protocol. It's worth a read, but it's also important to recognize that Farcaster did not use RSS. No piece of the original inspiration was used.

This runs counter to the idea of using withered technology to build something new. This is not a critique of Farcaster's design decisions. Instead, I'm just pointing out that no matter what the original intent was, Farcaster was not built to satisfy the RSS+ spec.

So, then, what is Farcaster's promise? It is to build a sufficiently decentralized social network. What does sufficiently decentralized mean? According to Varun Srinivasan, another Farcaster co-founder, it means:

A social network achieves sufficient decentralization if two users can find each other and communicate, even if the rest of the network wants to prevent it. This implies that users can always reach their audience, which can only be true if developers can build many clients on the network. If only one client existed, it could stop users from communicating. Achieving this only requires three decentralized features: the ability to claim a unique username, post messages under that name, and read messages from any valid name.

I think Farcaster has largely achieved their design goal. The concept of social networks and decentralization is a topic for an entirely different blog post.

What Changed?

For me, Farcaster's promise was not just about decentralization and open networks. Those things are important to me. However, the big promise I was most interested in was an implied promise (or maybe just something I hoped for). It was a protocol that was on the blockchain or blockchain adjancent that enabled portability, data ownership, and composability, all without catering to the lowest common denominator of blockchain's ecosystem to this point: gambling.

Unfortunately, Farcaster—in its pursuit for growth (and having users on a social protocol is very important)—has leaned entirely into the worst memes of blockchain. Every bad thing people say about crypto and blockchain is now supported on Farcaster and encouraged. Launching random coins, prediction markets, speculation—it's all leverage for growth that has, so far, not come. My belief is that Farcaster had hoped to attract most of crypto Twitter with these devices, but the play has not worked.

Now, someone might say that Farcaster the protocol does not support these things. This is an app-layer implementation. That's true. But a protocol does not exist in a vacuum. Wait, actually, it does. It is the app layer that gives the protocol oxygen and life. So, while the protocol does not explicitly drive gambling and crypto speculation behavior, the app layer does. And in doing so, the protocol attracts developers who want to build crypto speculative applications. It's an isolation machine that creates an echo chamber of behaviors that are rarely challenged.

Farcaster could have been better. Better for whom, though? For me, surely. But who else? If Farcaster's entire growth strategy is to attract crypto-native people who enjoy the speculative side of blockchain, then they could not be better. They are hitting their target. If their goal was to grow beyond crypto, they are failing. I'm not sure that's the goal though.

Dan Romero has stated that they need to grow with crypto first. The problem with this strategy is that it paints them into a corner. Take Bluesky as an example. They grew with the Twitter exodus after Elon Musk took over. This created a very left-leaning user base. It's an echo chamber of its own because of this. Growth strategies have long-term effects, so Farcaster's decision to attract crypto Twitter type users should be considered in the long-term sustainability of the protocol and the app layer.

This brings me back to my personal feelings. Farcaster has lost its place in my heart because of its trajectory, and that's OK. As long as the team has a plan and understands it, they don't have to cater to me. Everyone has an ego, and I'm no different. So, I do think they should focus outside of crypto (it may be too late for this), but what I think is irrelevant to anyone but me.

I'll still use Farcaster, but my activity has already decreased. There are a lot of people I genuinely enjoy following and interacting with, and I don't want to lose those connections. But The level of effort I have put into the protocol and the app layer over the last three years will not be maintained. And maybe that's for the best, regardless of the protocol. Social media does not make us better. It tends to make us worse. And that is yet another topic for an entirely different blog post.

If you want to find me, I'll be posting here more.

Sketching With Ollama

2025-04-10T00:59:44Z

When I was first learning how to code, I naturally started with what I thought was the most accessible and visible part of coding—frontend. What a wake-up call that was to discover that frontend development wasn't just some HTML and CSS. But, I'm glad that's the path I took, even if it was difficult.

Part of that path meant designing my own websites and apps, then designing apps for others, then eventually designing apps for companies I founded. Thing was (and still is), I'm no designer. I tried to create some crude designs in—no joke—Apple Keynote. I eventually broke down and tried Illustrator and Gimp. The learning curve for these technologies was steep, but that ultimately wasn't the problem. I couldn't visualize a thing until I started making it. Designing ahead of building didn't work for me.

Luckily, I stumbled upon this book. Sketching With CSS effectively threw the notion of designing in the traditional sense out the window. Instead, Sean Fioritto, the author, suggested that developers do their designing by using CSS and designing on the fly. This resonated with me because the feedback loop was so fast. I could make some tweaks to CSS and see my design live on a web page. I could test breakpoints and various devices. It changed my entire workflow.

This works well for small projects. Solo projects and prototypes especially benefit from this approach. Established products probably still need traditional design (maybe more so now than ever before), but for me building my own things and in the very early stages of building things I hoped would get big, designing on the fly in code made sense.

I have the same feeling when working with AI models today. The form factor is completely different, but the frustration is similar. When building an AI-powered application, many developers are trying to craft the perfect prompts ahead of time, pick the perfect model ahead of time, and effectively build their application on paper before testing it in the real world. To make matters worse, testing in the real world costs real money and likely leads to developers not creating the best experience possible. If you've spent $10 tweaking a prompt and you feel like it's 80% of the way there, are you going to spend another $10 for the additional 20%?

Fortunately, AI model development has been happening largely in the open. There are still closed models from some of the big companies, but many capable and comparable models are open source and available for you to run locally. The hardware requirements of these models vary, so ymmv. However, you have the tools to do for AI development what sketching with CSS did for frontend development for me.

I call this sketching with Ollama.

Ollama is optional. You can use any tool you want that allows you to run local AI models and access them via an API, but I like Ollama for its simplicity and built-in compatibility with the OpenAI SDK.

But how, exactly, is using a local AI model similar to sketching with CSS? It's simple, actually. Instead of having to create something basically perfect ahead of time, you can iterate live. You can do it without fear of spending too much money. You can do it with the same freedom developers have when making live CSS tweaks to edit frontend designs. That 80% you were able to get to while paying for a hosted model can now get to 100% through constant iteration. And here's an interesting knock-on effect:

If you can get a less capable model to do what your app needs, when you go to production and use a higher-powered hosted model, it's going to outperform yout local tests. So in a sense, sketching with Ollama is actually better than sketching with CSS.

On Reading Widely (And Wildly)

2025-04-08T00:59:44Z

I recently read an article that at first glance feels pretentious. It links to the Mensa Reading List for grades 9-12, and when you take a look at that list and try to imagine the average high school student picking up even one of the books on this list, you might start to roll your eyes. But as I read further, the article makes a compelling case that the list is important for how it challenges young minds to think critically.

I realize that Mensa-level reading isn’t about elitism; it’s about stamina. About learning to sit with a thing you don’t yet understand, and may not even like, and figuring out why it matters anyway.

When I stopped to look at the list, I realized I had read many of the books on the list, and I had read them in high school. And by many, I mean 15-20%. Some of the books I read for fun and some were high school requirements. I want to split those two categories and discuss them each individually.

Reading for fun

This is a bit of a misnomer. For me, I read for fun because my step mom forced me to. Which, by definition, means it wasn't fun. At least, not initially. Every summer, when my sister and I would visit my dad and step mom, we were stripped of three things:

Our friends
Television
Video games

Much of the summer days were spent with my dad sleeping because of the shift work he had. So, my sister and I not only had the common entertainment outlets we were used to throughout the rest of the year and needed to entertain ourselves in different ways, we also had to do this while being incredibly quiet all day.

(Quick aside: To this day, it bothers me when someone closes a door without turning the handle first. If you've never grown up needing to be quiet, you are probably unnecessarily loud in your daily life.)

When our step mom worked, which was off and on over the years, my sister and I would sneak some television in. We'd pull out the Game Boy my dad kept in the side table in the living room. But by and large, those were not options. So, we read.

Our step mom encouraged (read: forced) reading and reading comprehension. She would make us write short book reports on the books we read. She would take us to the library and Barnes and Noble. When Amazon became popular, there would be a constant stream of book deliveries every summer.

It was in these summers that I discovered Stephen King and Jack London. It's where I read The Red Badge of Courage and Treasure Island. I also discovered comic books during these summers. My step mom would take us to the antique shops all around San Diego County, and many of these shops had old comic books. Nothing super valuable. Just some dollar copies of old comics that I would buy or she would buy for me. This was an allowable form of reading during those summers, and because of that, I was exposed to a different style of prose and reading.

I was able to read Christine before I should have been based on my age. I read violent things and sexual things and had relatively unfiltered access to words that sparked conversations and questions. Outside of being forced to read in the first place, this is the biggest ingredient to my love of reading. I was not censored and could explore. I've carried this on with my own children allowing them to read well beyond their grade levels.

All of this reading for fun could have had an adverse affect on me in high school if my curriculum was behind my own level of reading. Fortunately, that wasn't the case.

Reading in high school

I went to public high school in Arizona. I'm not sure what the rankings looked like in the 90s and early 2000s, but if you look now, you'll see Arizona ranks poorly in public education.

So, it would be be easy to assume that when it comes to literary education in high school, Arizona would also rank poorly. And it probably does. Maybe I got lucky, but my high school experience was filled with reading some of the greatest pieces of literature, including many of the works appearing on the Mensa List.

In high school, I read Beowulf. I read The Illiad and The Odyssey. I read John Updike and Shakespeare. I read the first poem that ever made me stand up and take notice of the form—Dylan Thomas's Do not go gentle into that good night. I was then exposed to Robert Frost and Langston Hughes and Edgar Allan Poe.

This all spanned across the entirety of my four years of high school, but I had one teach in particular that probably expanded my reading experience more than anyone else. Mr. Wetzel didn't just teach us literature, he allowed us to experience it. When we read something and the term or concept was new, he explained it with pageantry. He acted out the use of a main gauche when we were reading La Main Gauche by Guy de Maupassant. He taught us what a pommel horse was when we read a story that mentioned it (can't remember what the story was, unfortunately) by climbing onto his desk and pretending to swoop and swing like an olympian.

It was in that class where I read Macbeth for the first time. It's where I read The Hobbit and The Lord of the Rings trilogy. It's where I read Cyrano de Bergerac, a play that expanded my mind so much that I can see its influence everywhere from modern film and television to modern novels.

I don't remember if my classmates got as much out of high school literature as I did. I don't know if my memories have altered themselves as memories do and tinted the experience in a brighter hue. But I know the things I read in high school cemented the joy of reading in me for life.

Wildly reading widely

Perhaps—likely because—of my experience, I read anything and everything today. I read fiction and non-fiction. Graphic novels and audio books. I read on Kindle and I read paperbacks. My desk at any given time is littered with multiple in-progress books.

It's not uncommon in tech circles to see people reading. Many people in tech are well-educated, and with that education comes a love (or at least a drive) of reading. Yet, many skip reading fiction. Non-fiction is important. In the picture above, you can see four non-fiction books clearly visible. Those books's publication dates span every decade from the 1960s through the 1990s. But mixed in there are novels.

I don't think anyone would debate the impact of science fiction novels on the way humans perceive the world. Ask anyone who has read 1984 or Brave New World how those books shape their feelings toward government and technology and you'll surely get clearly formed answers. But science fiction is not the only form of fiction that expands the mind, unlocks creativity, and helps one think.

Romance and crime and literary works all do this. A "beach read" can stimulate the mind and lead toward a widening of understanding as well as the classics if you allow it to.

Fiction is the counter-balance to non-fiction. When you combine them, your worldview changes drastically. Your ability to process events and information changes drastically. So, when I say read wildly, I mean read as many books as you can (multiple at one time if your brain allows for that). Read across genres. Read poetry and comics. Read non-fiction and essays. Read the classics, then pick up something off of Reese's Book List.

As we march forward in a world with decreasing attention spans and an addiction to video over text, and as we march into an unknown future both inhibited by and unlocked by artificial intelligence, books remain humanity's greatest tool for mental freedom and creativity. I'm glad I experienced them the way I did growing up, and even if your experience is different, you can still grow your awareness, understanding, and empathy through books by reading at whatever pace suits you.

But read widely. And go wild.

Product and Engineering in the Age of AI

2025-04-04T00:00:00Z

There have been dozens of hot takes in response to Replit CEO, Amjad Masad, saying that he doesn't think people should learn to code. While this may be considered another such take, I'm actually much more interested in the alignment AI causes with product- and engineering-capable people. So, I guess, let's get this out of the way up front. Should you still learn to code?

Yes.

With that out of the way, let's explore something more interesting. Product management as it has existed—and it has only had a very short life—is dead. But to be fair, AI didn't kill it. In fact, AI is likely its savior (more on that in a minute). Product management has been on its death bed since organizations began to realize the value of technical product management which gave way to engineers doing product research and development. In many cases, product management never got the chance to exist properly because PMs were treated as if they were project managers.

Even in organizations where product management was taken seriously, it has become evident that coordinating with developers when you are non-technical results in a reduction back to project management. The highest performing product and engineering teams seem to have a common trait in that they have product managers with an engineering background, or they have engineers doing what would amount to product management.

Maybe this is a good time to step back and define product management.

What is product management?

Product management is hard to define, but I like to think of it in analogies. So pick your analogy and skip the ones you don't like.

Product managers are like conductors in an orchestra—they don't play the instruments, but they know enough about the instruments to help those who do play perform at their best.

Product managers are like a racing pit crew—they aren't driving the car, but they know as much about the car as the driver and can guide the driver through the race.

Product managers are like film directors—they don't act in the scenes or operate the cameras, but they have the vision for the final product, coordinate diverse specialists, make critical decisions about what stays or goes, and ultimately take responsibility for whether the project succeeds or fails.

Once you've picked your metaphor and have a perfect understanding of what product management is, let's define what it is not. Product management is not a role that carries any real power. Influence, sure. Power, no. A product manager can't fire people, generally. A product manager can't MAKE something happen. They are politicians, but with less power. They are diplomats, but with more knowledge.

That might be the last meme of this article, but no promises.

Product management is dead

Back to my original point. Product management was designed to help engineers build the right thing for the right people at the right time. However, engineers speak a different language than many product managers. So, many product development teams realized that they could put engineers and former engineers into this role and see much better results. When you don't have to translate between normie speak and engineer speak, the process is much faster. Trust me, I learned this over time as I became more technical.

I started out in the tech world working at a massive insurance company on their claims app. I didn't know how to code, but I had a basic understanding of tech. My job was to translate the results of my research into requirements documents engineers could understand. This was a steep learning curve. In my next job, I worked for a startup and it was there that I learned the value of understanding code and engineering practices as part of the product roadmap, prioritization, and release flow. Eventually, I did learn to code, worked as a developer at a few places, and then leveraged that experience to propel my product career forward.

So, it came as a surprise when I took a short detour and worked for a larger, pre-IPO startup who had a whole team of product managers who were non-technical. I saw the differences in-person and as stark as day and night. Communication is filled with much more friction when product managers and engineers don't have a shared language and shared understanding of technical capabilities.

If you follow early-stage startups, you'll see a lot of these companies focused on engineering hires only. The stated reason is efficiency, but I think it's actually a solution to communication problems, which of course translates to better efficiency.

So, product management is dead, right?

Long live product management

Product management is not dead, and you should learn to code, and engineering as we know it will be changed forever. All of these things appear to be true at once.

In a recent episode of Lenny's Podcast, Lenny interviewed Eric Simmons, the CEO of Stackblitz. You might not know Stackblitz, but you probably know Bolt, their AI coding app that allows you to build entire projects in the browser using AI. In this interview, both Lenny and Eric make predictions about the future of engineering and product management. One prediction stood out.

They both agreed that product management will become more important than ever in the age of AI. In fact, they suggest without explicitly stating this that product management will become more important than engineering. But it will require a certain type of product manager.

Creating apps with AI requires a type of prompting that should feel familiar to product managers. In normal product management, you might write a high-level document or you might get detailed with a full PRD (product requirements document). Prompting AI to code uses the same methods. Go broad and let the AI be creative, or get detailed and make the AI be specific. Then, just like in product management, there's a back-and-forth review and adjustment period.

This image is nonsensical and hilarious. I asked ChatGPT's new image generation model to represent what I said above and this is what it came up with. Unlike a good PM, I didn't ask for any revisions. 10/10 no notes. But I digress...

The skills necessary to prompt AI to build the right thing for the right people is a direct descendant of product management. But there's an extra step that will make product managers superhuman as AI continues to take hold. That step is learning to code.

But wait, if AI is doing the coding, why should the person prompting have to learn how to code? This is pretty simple actually, and it's the exact same reason many startups are turning to technical, former-engineer, product managers today. If you understand the code, if you understand what's possible and what's not, you can correct and guide an LLM significantly better.

This creates a chicken and the egg problem if you're not careful. If you need to learn to program to be a good AI-age product manager, how do you learn to program in a world where AI is probably doing the teaching. The answer, to me at least, is simple. You prompt some more. Prompting is conversation. Prompting is asking questions and following up. Prompting is testing theories. Prompting is what humans have done forever, we just called it talking.

And traditional ways of learning to program aren't going to just dry up. There will be courses on YouTube, blog posts, and—can you believe it?—books. But, in my very biased opinion, the best way to learn how to code is to build things for yourself. Do that as many times as it takes for you to start understanding the conversation your engineering friends are having. Do it as many times as it takes to start catching logical issues in AI outputs when you prompt it to build something.

This future, powered by AI, is much more likely to be populated with more product managers, not fewer. And the ones that make it will have the coding skills necessary to execute in an environment where AI does a good chunk of the coding itself.

The Substack Paradox: When Platform Branding Trumps Custom Domains

2025-02-14T01:50:14Z

When you think about services that allow you to create content online, the services usually fall into two categories:

All of the content, from everyone, lives on the platform's main domain (example: Twitter/X)
The content lives on a subdomain of one of the platform's domains (example: Glitch, Netlify, Substack)

In fact, this pattern dates back to the earliest days of the consumer web. In the mid-1990s, GeoCities pioneered this approach by organizing personal websites into themed "neighborhoods" like SiliconValley for tech content or Broadway for entertainment. Each site lived at an address like geocities.com/SiliconValley/Ridge/1234. Other services like Angelfire and Tripod followed similar patterns. These early platforms democratized web publishing by giving millions of people their first chance to create content online, even if they didn't own a domain name.

The evolution continued through the blogging era with services like LiveJournal and Blogger, where again users typically published on subdomains. This history makes today's platforms part of a long tradition of making web publishing accessible to everyone.

In the first case, everyone knows what they are getting into. They are creating content specifically for the platform while trying to use the platform for exposure (in most cases). There is no expectation that your content will live on a domain specific to you.

However, in the second case, there is generally an expectation that the content you create lives on a domain specific to you. When platforms provide this path they will normally allow users to add a custom domain to these sites either for free or as a paid feature (my company, Orbiter, allows users to add a custom domain on paid plans, for example).

It is this second case we're going to focus on—platforms in which users create content with the expectation that the links to this content will have some sort of reference back to them. Normally, people who use these platforms desire the branding of their own custom domain. If these people are not technical and aren't comfortable with custom domains, they are often happy to keep their content on the provided subdomain (something like justin.platformdomain.com). What's interesting to me is the situation where people may be capable of adding a custom domain but choose not to because the platform's brand is more powerful than their own.

You might think most platforms have a brand that is more powerful than the end user's. But this isn't necessarily the case. A simple blog like the one you're reading this on, when tied back to my name or domain is significantly more powerful than if it were tied to a specific platform. That's because this blog is portable. I currently host it on Orbiter, but I used to host it on Vercel. And before that I hosted it on Netlify. The fact that I have been writing on my own domain instead of linking my content to the domain of the hosting platform means I have power. I have control. And since we're talking about writing specifically, that's a nice transition into the antithesis of users wanting their content to live on a custom domain.

That antithesis is Substack.

Substack is a newsletter platform that many people use as a general blogging platform as well. The writing people do on Substack is aggregated and there are discovery features similar to social media. However, the content is linked back to the individual writers through a subdomain on Substack's main domain. Substack does offer custom domains (they didn't always), but the vast majority of content you'll find on Substack uses the subdomain approach and forgoes the custom domain. Why is that?

Part of the reason could be how long it took Substack to introduce custom domains. Substack launched in 2017 but they did not allow writers to link a custom domain until 2020. We're now nearly five years past that announcement though, so I don't think the delay is the reason most people today still choose to live on Substack's subdomain.

Another reason might be that linking a custom domain requires a one-time $50 payment. This is not for domain registration. Presumably it is there to offset the cost of Substack creating SSL certificates and renewing those certificates every year. But that cost is low and it would take many many years for the cost of renewing certs to equal $50. The fee might exist as a deterrent to linking a publication to a custom domain. After all, Substack is free for writers, so they are surely hoping that those writers will generate new readers and writers simply by displaying the Substack name in the domain and elsewhere. Regardless of the reason, it's not obvious to me that people who would otherwise link their Substack site to a custom domain would balk at the $50 payment.

Instead, I think the reason we don't see more people use custom domains with Substack is because Substack has become a status symbol. Much like YouTube created the Creator Economy and made people into "YouTubers", Substack has created a new category for creators in newsletters. People ask each other if they have a "Substack", not if they have a newsletter. You subscribe to Substacks, not to newsletters. As a writer on Substack, you are part of a club. You are one of the creators. Substack creates emails just for you, making you feel like an insider. Your domain having "substack" in it lends some credibility to your writing. After all, if you put it on Substack, you must be serious, right? Not like all those other bloggers out there.

This dynamic actually mirrors what happened with GeoCities in its heyday. Having a GeoCities site in a prestigious "neighborhood" like SiliconValley carried a certain cachet. People would proudly share their GeoCities addresses, and the platform became synonymous with personal publishing on the web. The key difference is that GeoCities eventually faded as web standards evolved and users demanded more control, leading to the rise of custom domains and self-hosted solutions.

The web was once made up of individual websites living on the custom domains purchased and maintained by the creators of those sites. Over time, that has eroded as platforms have made creating content online easier and easier. But we still have examples of platforms that make things easy and allow people to control the content and the branding of their sites through custom domains. And when the option is available, people tend to take it. Except for with Substack.

Substack is the next iteration of YouTube. A platform where it seems at first like you are not locked in but you kind of sort of actually are.

Now, there is an entire flip side to this story. Substack's product marketing has put them in this position. And as a for-profit company, this is the exact position they probably want to be in. They have done many things right over the years to create both a good product and great positioning. There's nothing wrong with that. And it's not like they don't let people set up custom domains.

I don't know if Substack is the start of a trend that will lead to fewer and fewer custom domains on the web, but it is a clear indicator that people will trade ownership and control for certain benefits if the benefits feel strong enough. History shows us this pattern repeats - from GeoCities to LiveJournal to Medium and now to Substack. I've written on Substack before, but I'll stick with putting my writing on a domain I control where I can move between providers whenever I want.

Product Market Fit Is Like The Speed Limit

2025-01-07T14:16:29Z

I’m old enough to remember MapQuest. To me, it was ground-breaking technology. You’d head to your computer, wait for the dial-up internet connection to finish its series of whirs and pops, then you’d enter a starting address and a destination address. MapQuest would then design the most optimal route for you and include some satellite imagery of the path. It would also include turn-by-turn instructions, and this is where the fun began. You’d fire up your printer, print the whole thing out, then lay it across your lap or hand it to your buddy during a road trip.

We know how this story ends. Google Maps came along, then the iPhone came along. Printing a map was no longer needed. Services native to the device riding along with you in the car provided a better, more real-time experience. You might think this story is about MapQuest finding (re-finding? The company actually originated in 1967) product market fit and then losing it. But it’s not. This story is about driving directions and estimated arrival times.

I know, it feels a bit like I pulled the rug out from under you. Maybe one day, I’ll write about MapQuest, but today I want to focus on the concept of product market fit, and how it’s easy to misinterpret it as your destination. Let’s get back to map software and navigation.

When you’re using Google Maps or any other navigation service, you expect two main things:

The driving directions from your starting point to your destination
The estimated arrival time (or at least the estimated drive time)

Those two inputs power the output of arriving at your destination. When building products, we too often focus on the outputs and not the inputs. Product market fit, for example, is an output. But it is also an input. The problem with the way we tend to focus on product market fit is that we focus on it as if it is ONLY the output.

Have I lost you? Don’t worry it’ll come together.

Returning to the maps and navigation analogy, product market fit is more akin to the yet another input in the equation that I have not mentioned yet—the speed limit. If the estimated arrival time is an input to the eventual arrival, what are the inputs to the estimated arrival time? The inputs are speed limits along the way and the distance to the destination. The distance is static. However, just like product market fit, the speed limits are dynamic. They are ever changing. Not paying attention to the speed limits along the way can drastically change the outcome of your journey.

When taking a long road trip, you may notice that when traveling exactly at the speed limit your estimated arrival time tracks the same from beginning to end. When you travel slightly above the speed limit (this is not an endorsement for speeding!), your estimated arrival time slowly decreases the longer you do this. And, of course, the opposite is true. If you are traveling slower than the speed limit, the estimated time of arrival increases over time.

Finding product market fit is like reaching the ideal speed to make sure you arrive at your destination when expected. But product market fit is not static. It is not the distance traveled. It is the speed limit. Along the way, the market can change, competitors can arrive on the scene, employees can come and go, and every decision you make as a product manager can have an impact on the state of the company’s product market fit.

Marc Andreessen, co-founder of a16z and co-founder of Netscape, popularized the concept behind product market fit in 2007 when he said:

In a great market—a market with lots of real potential customers—the market pulls product out of the startup.

The market needs to be fulfilled and the market will be fulfilled, by the first viable product that comes along.

The product doesn’t need to be great; it just has to basically work. And, the market doesn’t care how good the team is, as long as the team can produce that viable product.

In short, customers are knocking down your door to get the product; the main goal is to actually answer the phone and respond to all the emails from people who want to buy.

And when you have a great market, the team is remarkably easy to upgrade on the fly.

This is the story of search keyword advertising, and Internet auctions, and TCP/IP routers.

Conversely, in a terrible market, you can have the best product in the world and an absolutely killer team, and it doesn’t matter—you’re going to fail.

You’ll break your pick for years trying to find customers who don’t exist for your marvelous product, and your wonderful team will eventually get demoralized and quit, and your startup will die.

This is the story of videoconferencing, and workflow software, and micropayments.

What these opposing situations doesn’t mention is that you can swing between them. Markets change, but so does your product. In a frothy market, your shitty product can find product market fit. But what happens when the market cools off? The product and the market are now bad, and thus there is no fit. What happens when the market remains viable but the product doesn’t adapt to the changing competitive landscape? The market is still good, but the product is no longer a fit. You’ve once again lost product market fit.

This may seem obvious, but it is surprisingly not obvious when put into practice. Too many startup founders and product managers chase the holy grail of product market fit, when in reality, they should be chasing the destination. The destination, of course, is not the product roadmap. In our maps and navigation analogy, the roadmap is not the destination there either. The destination is a vision, and this too can change.

When you have found customers pulling your product out of your hand, it is not time to rest. As a product manager, your job is to understand exactly why that is happening and be prepared for the things that can change it. Are customers pulling the product out of your hands because you were the first to build a solution for their particular problem? Are they pulling because the market is so hot that customers would take literally anything? Are they pulling because you have unseated a competitor that was not doing as strong a job? The only way to get the answers to these questions is to pay attention.

Just like when you’re on a road trip and it seems like each small town you pass through has a different speed limit, each cycle of market conditions and each new competitor and each new feature you release is a change you have to watch for. The way you do this is by paying attention to leading indicators. For each product, the leading indicators of product market fit slippage are going to be different, but they are things you should know innately. If you don’t, return to basics. Figure out what your north star is, and work backwards from there.

If you’re too focused on lagging indicators like revenue, churn, and sign up growth, you can miss the macro view that could help protect you against losing product market fit. This is where I could write an entirely separate article, but I will try to keep it brief and in context here. You are a product manager, not a ticket pusher. If you allow yourself to get consumed by process and tools for execution of deliverables, you will fail to see the changes on the horizon. You will fail to adapt. Your job is not to push things over the finish line. It is to understand the product and the market and the customers. It is to be the product visionary while the CEO is the company visionary.

Do not only look at the speedometer on your road trip. Do not only look at the road directly in front of your car. Look to the horizon. Pay attention to what’s coming.

Watch for those changing speed limits.