bgribble

The direction Audacity has been heading now is ok, but it's not for me. I really miss the days when it was just an editor for audio files. I have a DAW already, thanks, but I do still need to just quickly pop open a sample file to trim, normalize, maybe stretch it. I don't want to create a "project" or save really anything other than the edited audio.

I guess I don't really have an opinion about that. Certainly an exact representation of decimal numbers was essential, and was something we needed to implement at the time, but going to a fully rational numeric stack was arguably overkill.

The current value of held assets in another currency isn't really "counting" any more, it's a prediction of the outcome of some future transaction that hasn't happened. So I'm less concerned about exactly computing it than I am in never making a mistake in assets that I am counting, i.e. keeping in one account and only incrementing and decrementing the amount when a transaction occurs.

I seem to remember that we were aware that fractional commodities were going away, but exact rational values would still be important to be able to represent historical holdings and transactions.

I committed to the GnuCash codebase pretty regularly in the 1999-2002 era... I think maybe I actually implemented the fractional representation that the article discusses? Not sure, it was a long time ago! I definitely remember receiving some very heated emails about how this was total nonsense and there was no reason to do anything other than a decimal representation. The phrase "a superhighway of abstraction, leading nowhere" has stuck with me for lo these many years :) good times

One thing I think is missing is an understanding of why there is such a top-down push for timelines: because saying "we aren't sure when this feature will be delivered" makes sales people look like they don't know what they are talking about. Which.... well.

They would much rather confidently repeat a date that is totally unfounded rubbish which will have to be rolled back later, because then they can blame the engineering team for not delivering to their estimate.

As it turns out, the magic sauce that makes everything taste better is just ketchup.

It's good (maybe even indispensable) for some things. Please don't go "ketchup native" on my ice cream.

How else are you going to liquidity-stalk that company you left with some options or even shares?

I take my first cup of coffee with a little tea-leaf reading based on the activity of the CEO and my former coworkers. If you ever see more than 5 connections reacting/liking the same thing you know that HR or marketing sent out an email about it.

I feel some genuine grief about what GTK has become.

It started out as a toolkit for application development and leaned heavily into the needs of the C developer who was writing an application with a GUI. It was really a breath of fresh air to us crusties who started out with Xaw and Motif. That's the GTK I want to remember.

What it is now is (IMO) mostly a product of the economics of free software development. There's not a lot of bread out there to build a great, free, developer experience for Linux apps. Paid GTK development is just in service of improving the desktop platform that the big vendors ship. This leads to more abstraction breaks between the toolkit, the desktop, and the theme, because nobody cares as long as all the core desktop apps work. "Third party" app developers, who used to be the only audience for GTK, are a distant second place. The third party DX is only good if you follow a cookie-cutter app template.

I switched my long-term personal projects from GTK2 to Dear ImGui, which IMO is the only UI toolkit going that actually prioritizes developer experience. Porting from GTK2 to GTK3 would have been almost as much work since I depended on Clutter (which was at one point a key element of the platform, but got dropped/deprecated -- maybe its corporate sponsor folded? not sure).

I am still skeptical about the value of LLM as coding helper in 2025. I have not dedicated myself to an "AI first" workflow so maybe I am just doing it wrong.

The most positive metaphor I have heard about why LLM coding assistance is so great is that it's like having a hard-working junior dev that does whatever you want and doesn't waste time reading HN. You still have to check the work, there will be some bad decisions in there, the code maybe isn't that great, but you can tell it to generate tests so you know it is functional.

OK, let's say I accept that 100% (I personally haven't seen evidence that LLM assistance is really even up to that level, but for the sake of argument). My experience as a senior dev is that adding juniors to a team slows down progress and makes the outcome worse. You only do it because that's how you train and mentor juniors to be able to work independently. You are investing in the team every time you review a junior's code, give them advice, answer their questions about what is going on.

With an LLM coding assistant, all the instruction and review you give it is just wasted effort. It makes you slower overall and you spend a lot of time explaining code and managing/directing something that not only doesn't care but doesn't even have the ability to remember what you said for the next project. And the code you get out, in my experience at least, is pretty crap.

I get that it's a different and, to some, interesting way of programming-by-specification, but as far as I can tell the hype about how much faster and better you can code with an AI sidekick is just that -- hype. Maybe that will be wrong next year, maybe it's wrong now with state-of-the-art tools, but I still can't help thinking that the fundamental problem, that all the effort you spend on "mentoring" an LLM is just flushed down the toilet, means that your long term team health will suffer.'

I don't know that the hardware is dead yet. They got a cash infusion last year and there are occasional hardware updates in their Discord. It's just a slow process with 1-2 engineers total working on the many different hardware and software and firmware elements of the overall product.

There's no hurt feelings like the hurt feelings of a junior engineer, who has spent the last year kvetching about how much they hate working on legacy junk, hearing someone else refer to one of THEIR projects as "legacy junk".

Any code that's old enough to have its first birthday party is "legacy", which means that "legacy" is a completely useless category. Anyone calling anything "legacy" is generally just showing their own lack of experience.

I ran face-first into this effect at a successful startup where I started as employee number 9.

When everyone can sit around one big table, you don't have to consciously polish your "brand" all the time -- most people have direct experience with you and base their opinions on that. You do good work and you will have a good reputation. If you have a conflict with someone who is a jackass or have a project that fails to launch, people know enough about the context to judge pretty fairly.

When there are hundreds of people on the engineering team, especially in a remote-heavy workforce, most people don't have direct experience with you and can only base their opinion of you on what they hear from others, i.e. your reputation. This goes for peers as much as leadership.

You have to be aware of how an org changes over time, and how things that were once not important are now essential skills for success.. and decide if any new essentials are skills that you are interested in developing.

You can still buy bikes like that. There are plenty of people still making frame sets that will work with standard drive train components, standard sized stems, and plain ol handlebars in a variety of shapes. And they will build a bike for you.

I bought a Rivendell about 10 years ago and it's probably my last bike. Is a steel frame heavier than carbon? Yes, a bit, but I don't have to throw it away after a crash, it rides like a dream, and the weight difference is less than the extra "water bottles" I carry around my midsection. Most of the weight of the bike+rider (which is what you have to haul around) is the rider, not the bike, and the frame is just a fraction of the weight of the bike!

Even though new bikes are getting more and more proprietary, I don't foresee a time when I can't buy a new Shimano cassette or other replaceable parts.

I worked for an Intel spinoff whose CEO was a former high-level Intel exec from the 1990-2010 era. Internal goss attributed much of Intel's decision to stay out of the iPhone to him... there was a supposed quote that went something like "we make chips for computers, not g*d** telephones!"

As the tale went, he was sent out to this doomed-from-birth spinoff as a "sunset cruise" to basically force him into retirement (for this bad decision) without the bad publicity of a public head-chopping.

I love the developer experience of Dear ImGUI, even though I use it through Python wrappers that confuse things sometimes. It just slices like a sword through several layers of often-pointless abstraction and puts the control over the main loop right in your hands.

And when you need to read the source to figure something out, it's just a few files of pretty self-evident C-ish code.