Something frustrating is when a company is being _clever_ with their nouns. Sometimes it's relatively innocuous, but spending time remembering what unique name I should be searching for instead of something obvious is not my idea of a good time.
Nucleus Nouns
11–20 of 23 posts
Re: Nucleus Nouns
#12Nice article Ben! I think the HN crowd would be more familiar by calling those "Entities" but I like the new perspective of all companies only handling two or three of them really well. I think there is more nuance about it for the SaaS-pocalypse though. I have been talking to hundreds of B2B companies and customers are now vibe coding solutions when they need something that the platform doesn't support: a dashboard,…
Something I'm really good at is ending my articles with half-baked ideas :) so thank you for challenging it Regarding "entities", totally understand. I like to write in ways that my mom would understand- not the HN community. In fact, I have a post called "Everything is a Spreadsheet", where I explicitly defined that Entity Noun relationship. Should have linked it! Back to the Saaspocalypse... my startup is reckoning…
> The ultimate "what's your moat" question
One effective moat might be "Your LLM has never been trained on our closed source codebase."
Re: Nucleus Nouns
#13This makes me think of domain models in domain-driven design. Very useful to think about what these models are and how it makes sense to set them up & relate them in your area of work.
Re: Nucleus Nouns
#14Nice article Ben! I think the HN crowd would be more familiar by calling those "Entities" but I like the new perspective of all companies only handling two or three of them really well. I think there is more nuance about it for the SaaS-pocalypse though. I have been talking to hundreds of B2B companies and customers are now vibe coding solutions when they need something that the platform doesn't support: a dashboard,…
[dead]
Re: Nucleus Nouns
#15Nice article Ben! I think the HN crowd would be more familiar by calling those "Entities" but I like the new perspective of all companies only handling two or three of them really well. I think there is more nuance about it for the SaaS-pocalypse though. I have been talking to hundreds of B2B companies and customers are now vibe coding solutions when they need something that the platform doesn't support: a dashboard,…
Something I'm really good at is ending my articles with half-baked ideas :) so thank you for challenging it Regarding "entities", totally understand. I like to write in ways that my mom would understand- not the HN community. In fact, I have a post called "Everything is a Spreadsheet", where I explicitly defined that Entity Noun relationship. Should have linked it! Back to the Saaspocalypse... my startup is reckoning…
Oh yeah the SaaS-pocalypse is so new and there are so many different ways to try and understand and tackle it. Scary but exciting times!
Re: Nucleus Nouns
#16This makes me think of domain models in domain-driven design. Very useful to think about what these models are and how it makes sense to set them up & relate them in your area of work.
Never heard of this! This would’ve saved me a blog post. I tried all sorts of queries to see if this philosophy existed, and “domain” didn’t pop up in my head. Thank you!
Re: Nucleus Nouns
#17Prompt engineering, hallucinations, quota, context limit, auto compaction.
Sometimes the nucleus aren't just nouns are barely mentioned.
Re: Nucleus Nouns
#18This is quite insightful. Often in my projects, some central nouns come up over and over again in discussions about architecture, until they become embedded in the actual software and the interface.
Since I started using AI tools to assist, I've found a lot of both utility and frustration revolves around my use of these nouns in prompts (in the context of, e.g. "during the 'quickpay' confirmation phase..."). When the bot settles into understanding these nouns, it seems to get a better handle on the architecture as a whole. When it suddenly forgets them and has to go figure out what they mean by scanning the code base, I know it's about to do something staggeringly redundant and stupid.
Re: Nucleus Nouns
#19"Knowing names is my job. My art. To weave the magic of a thing, you see, one must find its true name out. In my lands we keep our true names hidden all our lives long, from all but those whom we trust utterly; for there is great power, and great peril, in a nam- what's that? Yes, I did move the Issue into the Backlog before starting the Sprint. No, it was seven Story Points. Break it down into two Subtasks? Yeah, can do. Then I'll mark it as Ready." -- Ursula K. Le Guin (mostly)
Re: Nucleus Nouns
#20Nice article Ben! I think the HN crowd would be more familiar by calling those "Entities" but I like the new perspective of all companies only handling two or three of them really well. I think there is more nuance about it for the SaaS-pocalypse though. I have been talking to hundreds of B2B companies and customers are now vibe coding solutions when they need something that the platform doesn't support: a dashboard,…
Something I'm really good at is ending my articles with half-baked ideas :) so thank you for challenging it Regarding "entities", totally understand. I like to write in ways that my mom would understand- not the HN community. In fact, I have a post called "Everything is a Spreadsheet", where I explicitly defined that Entity Noun relationship. Should have linked it! Back to the Saaspocalypse... my startup is reckoning…
Domain specific knowledge has been the moat for a long time, hasn't it? Outsourcing isn't new. Maybe you can do in a weekend for $500 what would have taken a month and $20k before, but code itself isn't a barrier to competition - even really good code.
On the other hand, much of the code I write is in an industry where training and operations manuals are closely guarded corporate secrets that make up the recipe or soul of a company. The job of the SWE is to deeply understand the processes and procedures that employees follow, and to write code that helps facilitate those and then gets out of the way. A lot of it comes from walking around and seeing how people are actually using the software and what works, and what's a pain point. I've always maintained that the value is in the operations manuals, and the code is just a logical extension of that. But that's where SaaS usually is insufficient because regardless how versatile and broad it is, it doesn't usually encapsulate enough domain knowledge, let alone the proprietary stuff.