It is just zipped xml, but to do a search and replace while retaining document structure is very very complicated, and I’m struggling to think of how to combine sed and awk to achieve it.
- the site said it would be worked on collaboratively, but I couldn't find a way to do that? I interpreted that to mean multiple people woroking on it together
- I would find this more valuable if it was less text editor and more interactive editor. If the goal is group consesus, expanding the tool so more people in the group could modify it would be good
- What is the reason for having default names like "SprintReady" instead of "Sprint ready" ?
- Zoom to all and zoom to selected wold be super useful in the flowchart view
- being able to rename/edit things in teh flowchart view would be great
- Having an AI embedded in the tool itself so you did't have to manually round trip and copy/paste with claude code would be super useful
- It might be worth trying moving the comments panel to the right hand side of the screen. Very similar to google docs, word and other document tools. Makes the visual chart front-and-center and makes the comments separate from the simulate step
It’s interesting eh, it’s a wonderfully straightforward tool to use, but it’s scary.
My theory is that those courses aren’t selling you on how to use obsidian, but are instead selling “how do I organise knowledge and information. Oh btw we’re using obsidian”
They aren’t marketed like that, but I think that is what they’re really doing
It’s like taking a course of office organisation. I mean filing cabinets are easy right, it’s just putting labels on folders and putting them places.
Except I would absolutely be terrible at that job and would pay nearly anything to be good at it.
I found all the themes interesting, but "the rigor has to go somewhere" and "the enterprise reality check" resonated.
I was thinking about how my build of software has changed in the past 25 years, and while it feels there's only been small shifts with a great increase in my general grumpiness at stack complexity, the reality is before AI there had been a huge shift in my day to day focus.
When I started out, writing and reviewing code with a focus on managing memory, performance optimisation, tackling crossplatform compatibility were significant chunks of each day. If you didn't do those things, it was unlikely you would be able to sell in the market, because your competitors were faster or better. Then computers got faster, you needed to think about those things less, and you could instead afford focus more on features and getting to market faster.
Those were distant concerns for most of the things I was working on around 2020. The concerns where instead overall system design, distributed systems concerns, and business processes. If you didn't do those things, your product couldn't compete with all those other ones that did those things well (i.e. multi user systems, scaling to thousands of concurrent users etc etc)
If the AI trajectory continues, code as we know it today will become like memory management or hand rolled assembly from the 1990's, just not something you think about anywhere near as much (right up until the point it becomes a problem). You just couldn't afford not to. The focus and rigor will be in how well have we captured and delivered on the business requirements, how well are we responding to changing requirements, how well are we integrating with other systems. There will be some people who will need work on the low level things things, but the majority of of the sector will be working on these bigger picture problems.
Yes, it will create big balls of spaghetti code, unmaintainable monorepos, and everything today we consider bad, messy and wrong. But when the cost of regenerating said code is drastically reduced, you get to focus instead really close to delivering on user requirements. The focus and rigor will shift to verification, i.e. making sure what we're selling does what it's supposed to. Which If we are honest with ourselves that is exactly what we've been trying to do forever, but we just couldn't afford to do it as well as we would have liked. And honestly it was because building things was more fun and more necessary than testing things. That started to shift 15 years ago, and really shift 5 years ago, and now I think its' about to shift even more.
One could argue much of this doesn't fit under the purview of software engineering, but I think it does. For me, software engineering was the process of capturing value and knowledge in a system that could run on a computer, that we did it using coding, and that many things required highly specialised skills was an implementation detail. It will shift in a way that building architecture did - moving away from the raw technical ability to draft plans, and instead be able to understand a customers requirements, understand the legislation that the buildings exist in, and be able to oversee the project to see it completed that it fits all those things.
All true, but also depends on jurisdiction the product is operating in
For example, in Australia any consumer has rights around products and services they purchased regardless of the terms agreed to during sale. If a business offered 99% uptime in their marketing, then they are required to provide that or, something equivalent, or a refund, even if it was never mentioned or some lower number was mentioned in the terms and conditions.
Enforcing that however, particularly with companies that are renowned for having no human staff, is tricky.
So yes, definitely agree - builders have to be aware of their dependencies and work with the realities of what they provide, not the theoretical
I’m confused - is it the actual source code, or minified/bundled code? I don’t think those two are the same thing - unless of course you write your code minified. That would be really impressive.
One of the things I miss most about the Amiga workbench is variable size icons.
I love them, and miss them
That giant battletech icon before you play that fantastic turn based hexagonal game, or the Amos basic icon, there was just so much opportunity for fun.
Ever since then I occasionally try and make it happen on vanilla OS’s, without success.
Them I just realised I’ve been a dev forever, and various desktop environments on Linux have been open forever, it might be time for me to try one last time. It may never take off, but I would love to see it :D
Thank you for writing and sharing that. It's one of the simplest and sane explanations I've seen. How did discussions go with accountants separating the debits/credits into being a presentation issue?
Accounts (in the accounting sense) are unitless, and refer to whatever meaning we ascribe to them, so we can transfer value from $ to shares, or USD to GBP or whatever.
Lalit describes this I think really well in his article
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.
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.
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 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?
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?