Was an interesting ready but sad to see that there is nothing special for matching or restructuring tagged unions (beyond the special cased optional type). That's one of the things from Rust I miss the most in my day to day work with C/C++.
It appears Tabula also gets the substituted content instead.
What I'm seeing is that for example, POS is substituted to & !ë on every line in every file, etc. I can see by comparing to the rendered PDF for other common text (like my name, the local supermarket, etc) that those all seem to be 1:1 substitutions too.
The core software itself is completely agnostic to currency or country. Otoh the importer ecosystem is somewhat US focused but a) you can easily write importers yourself b) I just published importers for a bunch of UK institutions (e.g. HSBC, Barclays, AJ Bell) - see the other post hanging around the HN frontpage :)
> 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.
> What impact has having such clear visibility into your accounts had on your relationship with your wife?
That's a great question. Thankfully when it comes to finances we are very aligned in our habits and goals. So we find it very natural to be open because we know that we're both going to be aligned.
Where we differ heavily though is how much we are willing to really getting onto the nitty gritty details. She really likes knowing how our money works but she also has no interest in spending so much time and effort on it.
But that works great because I love this stuff. So every month or so we have a "finances session" where I sit down with her, take her through the books and make sure we're both happy with everything.
Obviously this very much depends on the couple whether this works but it has for us so far!
Would you consider a follow up blog post about how you structure and approach your monthly finance sessions? I understand that it would be well outside of your topics of software engineering, performance and open-source, but I find that the human component of our industry is often missing. An insight into how someone has successfully navigated that would be a wonderful read.
Given the comments on this post and the other Beancount one in the frontpage, I definitely think there's enough I want to say for at least one if not two followups. Stay tuned!
I'm talking about apps similar to Mint and YNAB. Specifically I used to use an app called Yolt (which was shut down) and then was on an app called Emma for a bit.
I'm sure GnuCash would also work just fine but ultimately it's also a full double entry system. I never tried it because I came across ledger/hledger/beancount first and, being command line tools, they appealed more to my sensibilities.
Firstly, thanks for the thoughtful comments across the post. Really happy you found it insightful!
> But it's best to build a strong portfolio of going fast (where needed), going slow (where high leverage), and if everyone agrees your "going slow" led to huge returns you get the best of all worlds.
I guess maybe I oversold this a little in the post but I definitely think that product orgs value speed more than infra orgs: there's often an mismatch when I speak to product engineers on how fast they expect us to build things for them vs how fast we can actually go while considering all our other customers and not breaking other usecases.
> my protip for prospective staff engineers is to _never_ say you only care about [speed, stability]
Fully agreed, both are important for engineers to have. As above, I think the relative composition of them varies though depending on the area (just pulling numbers from the top of my head, maybe it's 70/30 in favor of speed in product orgs, 30/70 in favor of stability in infra orgs).
> surely we can agree impressing customer stakeholders is even more important in (healthy) product orgs
You're absolutely right for what I say in the post; reflecting I think I maybe did not go into this topic in enough detail for the nuance it deserves (but the post already felt long enough!).
Let's split the discussion into 3 different areas (as IMO they each work slightly different): infra/devex, B2C and B2B.
* Infra/devex: as I say in the post, it's critical to impress your other team's managers as that's how you prove impact.
* B2C: your customers are consumers so it's all MAUs, revenue etc. There is no "customer stakeholder" who will give you direct feedback for your promo packet
* B2B: here's where it gets interesting. So if your management chain is directly able to talk to customers (and especially senior managers) to solicit feedback without middle layers (parter manager, account managers, PMs) then yes you're absolutely correct. But often this is not the case: the middle layers act as a filtering point so you get only a fuzzy sense of how stakeholders in the other company about a specific technical thing you worked on. So again it's sort of at the whim of how your manager feels the other company's managers feels.
The basic point I was trying to make is that if you're working on external facing product, from my understanding, even if you impress your external stakeholders, it's not like in your promo packet you can attribute concrete quotes to the customers. quotes like "we couldn't have done X in our company without the work of Y engineer in your org who worked on Z". Whereas this sort of quote is extremely common to see in infra promo packets.
Hope this made sense, I'm not sure I communicated this last point well!
> But he can only do so because he is a staff software engineer.
I don't agree with this at all. This is how I've worked for my entire time at Google, all the way from new grad L3 joining the company till today. Ignoring the spotlight does not mean "don't get attention from other people" but "don't chase the project execs are focusing on".
Whenever I've work on a project, I make a very active effort to make sure engineers are aware of it, especially if I think they would find it useful. But that's different than going to my execs and asking "what's the highest priority at the moment" and working on that.
Would you rather be working on some obscure internal website for employees to track their performance that no one cares about or something related to Google ads? Which would you suggest a new grad work on?
It sounds cynical. But I never personal tried to get ahead at BigTech, it was never my goal, I just saw the struggles that others had navigating the promo process from L4 (entry level) -> L5 and L6->L7. It seemed like L5->L6 was the easiest for some reason.
I would say it's worked out pretty well for me at least given my career trajectory! Feel free to draw your own conclusions from my resume (it's on my about page).
I think you are conflating "exec attention" with "important projects": these are very much not the same thing.
Fair point. So if you are saying “get on important projects” is the lever, we are in complete agreement.
You can put important projects on your promo doc and if you communicate it well, you are golden. That’s far more important than “executive attention” when it comes to the promotion committee.
Just don’t be the guy who is working on the internal comp tracking system that no one thinks about more than once a year
I'm very well aware of the privilege afforded to me by my company and the time I'm working in. I tried to emphasize in the post several times that this is not a "universal guide to success" and that in other companies or teams, a different approach and strategy might be needed.
The whole reason I wrote this post at all was, with the success of Sean's work on HN recently, I felt people were leaning too far into the direction of "you need to constantly move around and go where the exec attention is". I just wanted to show that, from my singular experience, it is possible to carve out a different path in some positions while still being ambitious and "successful" (for some definition of success).
Yeah sorry if my assessment was a bit callous and overly critical, and I hope you don't take it personally. I meant what I said up front that it was very well articulated and made a lot of sense.
The reason I wrote what I wrote is because I came into the industry in the year 2000, and multiple times throughout my career experienced a rug pull of my own mental model of my value as a software engineer. It's very painful and something that I think ICs in deep-thinking professions like software are very vulnerable to.
> Yeah sorry if my assessment was a bit callous and overly critical, and I hope you don't take it personally
Not at all. Thanks for reading and taking the time to comment!
> and multiple times throughout my career experienced a rug pull of my own mental model of my value as a software engineer
Sorry to hear you've had that experience. Unfortunately, over the past year we've once again entered the "let's question software engineer's value" space with AI so you're very right to warn on the risks of not overselling your importance as a SWE. It pays to always be watchful and introspective on what changes are happening around you and how to best adapt to them.
> Would a PM be responsible for this sort of broader thinking in a more typical team?
Good PMs do exactly this in product teams yes. But unfortunately PMs are not immune to shifting priorities and moving around either, just like I describe for engineers. So it's very hard to make it work but the best PMs I know somehow manage anyway!
My goal with this post was not to claim this is a universal template to success for everyone but simply sharing an approach that worked for me.
I tried to point out several times that, yes there are places where a "move fast with leadership" approach works better. And yes this only works in the biggest companies capable of sustaining an infra team for a long period of time.
It's definitely a high risk high reward strategy but if you have the context from being the space for years and you've done your due diligence by speaking to your customers before you build things, you reduce the risk significantly.
Of course the risk can never be zero though and luck definitely played a role in past successes.
