Live data from Hacker News

We are rebuilding Monica

monicahq.com

51–60 of 101 posts

Re: We are rebuilding Monica

#51
post #46
post #37

Earlier quoted context omitted.

Cause and effect is reversed here. The trends leading to collapse of the family , neighborhoods and friendships predate facebook by at least 40 years. Bowling Alone describes the collapse covering the 80s & 90s, and the trends were 20-30 years mature by then.

Your theory is that Facebook not only had no impact on that but could have done nothing to improve things? That seems implausible to me. I think at best you could claim that cause and effect are quite tangled here.

I wouldn't say no impact, but a trailing impact. They understood the cultural changes demanding new ways for people to status signal and maintain connections with friends & family.

That's what I mean about reversing cause and effect. There are larger causes (see my other comment below) that Facebook was innovative to take advantage of.

Re: We are rebuilding Monica

#52
> I now see relationships as their own domain rather than an attribute attached to a contact

I mostly skimmed this announcement, but this seems pretty obvious to me? Relationships form a graph, so it seems reasonable to use graph modeling techniques to handle them. At the least RDF triple style [1].

One thing I'd also strongly consider, in this age of LLMs, is how much you can store in text. A personal CRM seems like the kind of thing I want to check in to github, rather than deal with Postgres or even SQLite. And if you have a good structured text format (e.g. Markdown with YAML frontmatter, XML, json) then you can just point an agent at a repo and extract information that the app developer didn't even expect or add APIs for. Same for transformations. A full db engine is then more a performance optimization that can be applied for app-specific functionality.

1. https://en.wikipedia.org/wiki/Semantic_triple

Re: We are rebuilding Monica

#53
post #15
post #8

I'll take "things you should never do" for $1000 Alex. https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Written before LLMs made Big Rewrites an absolute doddle.

As an American English speaker, I'm going to assume "doddle" is a synonym for quagmire.

Re: We are rebuilding Monica

#54
post #15

Earlier quoted context omitted.

Written before LLMs made Big Rewrites an absolute doddle.

LLMs have meaningfully decreased the cost of rewrites, such that many rewrites that wouldn't previously have made sense now do. They are still significantly costly and often a bad idea.

They also remove the secret menu item of rewrites which is to have some peace from management because you’re not delivering anything for a long time while you do the rewrite.

I predict AI will cause the number of rewrites people ask for to go down.

AI is better at doing Ship of Theseus rewrites too, and those are the superior option because they leave the system available for hotfixes at all times.

Re: We are rebuilding Monica

#56
post #28
post #24

Earlier quoted context omitted.

An absolute doddle assuming you have an absolutely excellent test suite. Otherwise on any nontrivial codebase you will still have regressions that make it to production and you will waste your time squashing bugs rather than writing new features.

the thing companies seem to be finding out is that quality is much more important when you're shipping 3-5x more per sprint and incident rates are multiplying at an even higher factor. allocating even less time to code review and testing is the norm, however, and it feels like the modern Agile SDLC is breaking a bit under this new mode there's good skills to write test suites but each codebase needs its own bespoke i…

I have a rule of thumb that goes something like, if you want to get people to use something 2x as much you need to make it 4x more reliable. The reliability becomes a enticement, and you will often underestimate how much more popular it will get, so if you aim for 2x you will likely see 3x and still have a lower incident rate per week than you experienced with lower traffic.

None of your users or managers think about errors as fraction of interactions. Even despite trying to label things as 99.99% reliable. Some managers will claim they do, but they aren’t being honest with themselves. Usually when they get mad it will be about having to deal with a problem happening twice in a week or a month. So now they’re yelling at you while you want to yell at them about being dishonest.

Re: We are rebuilding Monica

#57

After screaming into my pillow about the recent Facebook f**ery and the destruction of the individual and their relationships, I had a moment of appreciation and human-ness when I read, "Built because my memory is bad.; I created Monica because I kept forgetting details about people I genuinely cared about." That's the kinda thing we should be building and supporting together. I may start using it, even if that's a h…

I am not the target audience for this product, but I can’t get over the irony of building a CRM specifically to track details about people you genuinely care about

Re: We are rebuilding Monica

#58
post #15
post #8

I'll take "things you should never do" for $1000 Alex. https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Written before LLMs made Big Rewrites an absolute doddle.

it is sort of amazing what I think is practical.

"rewrite in python." "no, let's try rust."

"I don't like the grand piano in the basement, let's see how it looks upstairs"

Re: We are rebuilding Monica

#59
post #8

I'll take "things you should never do" for $1000 Alex. https://www.joelonsoftware.com/2000/04/06/things-you-should-...

Can't help but notice that this line is not true anymore in 2026: > It’s harder to read code than to write it.

what? my impression is that it's truer than ever and this is why so many open-source projects are limiting ai contributions. and the reason GitHub can't seem to stay online for more than a day.

Re: We are rebuilding Monica

#60
post #56
post #28

Earlier quoted context omitted.

the thing companies seem to be finding out is that quality is much more important when you're shipping 3-5x more per sprint and incident rates are multiplying at an even higher factor. allocating even less time to code review and testing is the norm, however, and it feels like the modern Agile SDLC is breaking a bit under this new mode there's good skills to write test suites but each codebase needs its own bespoke i…

I have a rule of thumb that goes something like, if you want to get people to use something 2x as much you need to make it 4x more reliable. The reliability becomes a enticement, and you will often underestimate how much more popular it will get, so if you aim for 2x you will likely see 3x and still have a lower incident rate per week than you experienced with lower traffic. None of your users or managers think about…

right, that was always the most surprising thing I saw when I made the career leap into tech

for all of it's vaunted 'big data' and 'metrics-driven outcomes' and whatnot, as soon as a single medium-to-large user starts complaining about an obscure component or wanting new features it was all hands on deck, roadmaps be damned, data out the window, who cares about CVEs/tech debt/fixing MVPs, let's do it MVP (again) instead of building something maintainable and extensible and then forget all about it like a child with ADHD when the next largeish user sends your C-suite an angry DM

meanwhile the core features that most people are happy with and the entire reason they chose your solution gets ignored and one day you look in your lunchbox and the food is all gone and C-suite's golden parachuted out to some cushier job somewhere else

Post reply on HN