I guess it depends on the complexity of ones personal finances? The author had multiple currencies, investments, and who knows what else.
I ran a small business for a while, and I would draw a parallel to that. Once a family's finances hits the complexities of a small business, multiple assets, loans, cars, long term savings, investments, I'd say the granularity is worth it. I would certainly like to try it out.
I must have read half a dozen intro-to-accounting books, and it never ever clicked for me. I understood the concepts, the benefits, but it just felt 'wrong'.
It wasn't wrong of course, there is so much history, ingenuity and the invention of double entry accounting, but I just couldn't get my brain to understand it.
The way the concepts settled in my head was: double entry accounting is just an excellent way of modelling a graph with nodes and edges. Accounts are nodes, transfers are edges. Every edge has a source and a destination.
For a paper ledger, each column is graph node, and each row is a graph edge.
That was enough for me to be able to learn the rest of the things I needed for interacting with the accounting world.
But I also realised that that description really only helps a very small part of the population. :D It makes things so much worse for most people.
"Hey could you help me understanding this accounting thing?"
"Sure, but first thing is, let's learn graph theory! You know who Dijkstra right?"
Whole buckets of nope.
But thats a digression from your actual question - whats the point?
It presents a rigid set of rules of recording transfers, everything has to have a from account and to account (i.e. a graph edge), every row must add up to zero.
Because of that, it makes it easy to spot any mistakes in data entry. If any of your rows dont add up to zero - then you've made a mistake.
I really enjoyed reading this, and it is inspirational as it is something I have wanted to do for a long time. And as a software developer, it really appeals to me.
How do you think it compares time-wise to using existing accounting software? Was the time investment worth it to get the control and visibility you now have?
> How do you think it compares time-wise to using existing accounting software?
Author here. I tried various consumer budgeting apps before I ended up building my own (and then going to Beancount). The main problem with every one of the apps I tried is that they don't handle investments well. 99% of my money is invested and having net worth figures which are wildly wrong because the app is only tracking bank accounts really annoyed me. That was the reason I built my own thing in the first place.
> Was the time investment worth it to get the control and visibility you now have?
Absolutely yes. I think it helps me really understand where my money is going, how I can make it work harder etc. Even though the RE part of FIRE doesn't appeal to me, the FI part does and knowing where I stand at all times has been very motivating.
Thank you for taking the time to reply - thank you!
I have question on a more personal front - please feel no obligation to reply.
What impact has having such clear visibility into your accounts had on your relationship with your wife? It feels like it would be a great catalyst for communication, trust and building things if shared finances was a key part of the relationship.
I think this part was the most inspirational - it takes a lot of courage to be that open about finances, even with partners, perhaps especially with partners.
i had a read through but I couldn't figure this out: What does it improve on compared to jsut regularly doing a git pull and git push to a different origin?
Also, can the destination be something other than GitLab?
Goal is to do a full mirror repo to repo incl. all branches in an automated way. It's indeed nothing else than a git pull, git push but automated (with API key). Yes the destination can be different but a provider needs to be developed for that (currently only GitLab & GitHub supported). Developed this to have a full local mirror of all my GitHub projects; but it can also work the opposite way; where you have a local GitLab you want to mirror to GitHub.
That is a really interesting investigation, but I am curious - how did the author go about evaluating whether or not was following a process? How did they measure success / failure ?
But a fascinating experiment and something I’ll try with Codex
I was reading through the article genuinely looking forward to a methodical discussion on all the negative points raised about other protocols
For example this was about one of the other protocols
“ There is no key rotation that preserves your social connections. You would need to create an entirely new identity.”
It didn’t elaborate much, but briefly mention Marmot, but I thought it was about Nostr? It was confusing enough for me to shrug and move on. Which is a shame, because it feels like it might be important to understand.
Marmot is a subprotocol based on Nostr (and MLS signatures): https://github.com/marmot-protocol/marmot that's used for private messaging while using Nostr for identity.
Your specific example is true - nostr currently doesn't have generally available key rotation solutions, there are couple proposals in works thought. This is also noted in the article with "Nostr is not perfect. Key management remains challenging, though solutions like NIP-46 and hardware signing devices are emerging."
Sidenote - the article you just read is hosted on nostr. Did you notice that? The comments under it are powered by nostr, etc. It's pretty seamless - habla.news is just one of the client apps that fetches it from many relays. Nostr phone apps (like Amethyst) also display the same article and allow interacting with it, commenting, etc.
"Trygve Reenskaug created MVC while working on Smalltalk-79 as a visiting scientist at the Xerox Palo Alto Research Center (PARC) in the late 1970s. He wanted a pattern that could be used to structure any program where users interact with a large, convoluted data set. His design initially had four parts: Model, view, thing, and editor. After discussing it with the other Smalltalk developers, he and the rest of the group settled on model, view, and controller instead."
With numbers like, if it scares customers a good strategy is to implement the filtering very gradually over time, over 6 months or a year. The fall off is way less scary, and it can be described as improving bot filtering.
It’s not as honest, but more palatable unfortunately
I ran a small business for a while, and I would draw a parallel to that. Once a family's finances hits the complexities of a small business, multiple assets, loans, cars, long term savings, investments, I'd say the granularity is worth it. I would certainly like to try it out.
reply