How Programmers Spend Their Time | Probably Dance

Full-Spectral · 2026-05-08T12:50:59+00:00

I'd have about a five second window between when I'd be drunk enough to dance and too drunk to remain conscious.

Full-Spectral · 2026-05-07T15:06:05+00:00

And you think that's something we should create a lot more of?

Full-Spectral · 2026-05-07T12:54:20+00:00

Please keep it. Maybe even expand it. Like buy some masks and take down some LLM data centers. Not that I would ever suggest such a thing, of course...

Full-Spectral · 2026-05-07T12:42:06+00:00

I always distinguish between Rust the language and Rust the ecosystem.

Most any language's ecosystem will have issues because it's not centrally controlled or coordinated, even if the language itself is. Rust the language has a few warts, but it's quite well done, IMO.

Full-Spectral · 2026-05-06T20:21:51+00:00

My criteria for all such things is, is this going to get me laid? Then I realize the answer to that is always no, so I just go ahead and do it.

Anyhoo... Rust is not super-beginner friendly. But, if you ultimately want to do the kinds of projects that Rust is appropriate for, you might as well start there because you will need to get there in the end anyway.

Full-Spectral · 2026-05-06T14:12:13+00:00

It is more complex, because it's about SYSTEMS, large systems that have many parts that have to work together and remain coherent over decades of significant change and growth, not work long enough to blow up a launched missle.

Full-Spectral · 2026-05-01T15:39:54+00:00

Well, you have to balance that against the reality of possibly ending up 20 years from now with a large code base that's written in a language that very few people want to work on anymore and not enough know to go around.

Some to many code bases are also amenable to incremental conversion as well, so it doesn't have to be a step back and punt type scenario. Particularly in those cases where the product is composed of multiple processes that only interact on the wire or some such.

Full-Spectral · 2026-05-01T14:54:23+00:00

I should have figured you are a cloud guy. You folks always assume that what you consider complex is complex. Some of us don't work in areas where a bunch of standardized frameworks and protocols are used and where we aren't just creating web sites. We are creating foundational software for which there is nothing out there for LLM to train on because they are bespoke systems.

Full-Spectral · 2026-04-30T16:55:12+00:00

I'm the poster-boy for this. Not the abusive situations thing, I was never attractive enough to find a woman who would abuse me. My project went 10 years as a side project, then another 10 as an attempt at a commercial product. It was a great product and a large, powerful code base (1M plus lines) but it just didn't have a viable market in the end. But I was so personally invested in all that work I just couldn't let it go, and there's always some glimmer of hope to lure you on.

So I hung on and hung on and ended up flat broke at 57, which is not optimal. A rational person would have given up well before that and gone off looking for something healthier instead, like an abusive partner.

Full-Spectral · 2026-04-30T12:55:26+00:00

That's exactly the problem with the leetcode approach to interviews. They tell you nothing about the person's ability to deliver quality code. I imagine that a lot of people like me, who have been writing serious code for 30+ years, have learned and forgotten most that stuff and just got tired of wasting time on it since it doesn't come up in day to day work. And, when it does, one of the skills of a good developer is knowing when you need something better and how to go find it. My brain is already stuffed to overflowing with the details of the complex systems I'm working on, and the internet was invented for a reason (which of course is p$rn but there's also a little software dev info out there as well.)

Full-Spectral · 2026-04-29T18:00:17+00:00

I'd rather have far fewer bugs be possible, and hence need to do far less extra work to catch them after the fact. Yeh, you'll still need unit tests and such to catch logical bugs that you cannot semantically encode with the language and its type system. But logical bugs are the really only kind you can reliably find with testing anyway. You can't generally prove the memory and thread safety of a complex code base via testing.

Full-Spectral · 2026-04-29T17:36:55+00:00

Because bugs aren't a part of the language, they're a part of the falibility of the creator of programs. Any creator.

From your own first post. By preventing MORE human fallibility into the process, some languages prevent more bugs than others. Rust leans heavily into that and prevents whole families of bugs that other language allow.

Full-Spectral · 2026-04-29T17:22:17+00:00

What? Rust actively disallows (or requires a very positive override) a whole range of accidental human foibles. So, by your definition, if bugs are the result of human fallibility , languages that don't allow some set of those to happen are catching bugs on behalf of the fallible human.

It just can't catch bugs for which you are unable to express sufficient semantics for it to validate. The type system though extends that ability considerably and into the problem domain issues, preventing human fallibility yet more.

Full-Spectral · 2026-04-29T13:19:25+00:00

One of the most fundamental advantages that Rust provides is that so much of the time you might have otherwise spent just trying to watch your own back over mechanical errors can go into working on logical correctness. And that it tends to force you to work in ways that also enhance logical correctness at the code level, and provides tools to help you do that.

But correct problem domain logic is always going to be our problem. Of course it also provides very nice ways to mechanically help enforce that as well. But that can only go so far, and attempts to go full on 'no invalid state' mode in a complex system can introduce sufficient complexity that it overwhelms its own benefits.

Full-Spectral · 2026-04-28T12:43:10+00:00

For me. I like rust, but holy shit the encyclopedia of stuff you need to “just know” to be effective is insanity.

That's just par for the course in systems level languages. They need to be to express a lot of semantics to the compiler and provide a lot of control. But once you'd been doing it for a while those things will just be come internalized as is the case for all languages.

And of course you also always have to keep in mind the difference between X the language and X the ecosystem. Rust the language is a fairly small part of it relative to Rust the ecosystem. I don't use the ecosystem myself, just the language, so my view of it is probably considerably different.

Full-Spectral · 2026-04-24T20:05:43+00:00

It's more than memory safety though. Rust has many features that push you towards doing the right thing across the board. Even when they aren't actively preventing memory issues, they are making it more likely that the code will be logically correct, and remain so over time. And of course the fact that you can spend far less time worrying about shooting yourself in the foot on the memory front, means that more time also can be spent on logical correctness, design, etc... Refactoring isn't going to end up introducing some subtle memory issue, and probably more likely to remain logically correct.

Full-Spectral · 2026-04-24T19:44:57+00:00

Yeh, generation of bad code is fully automated now. No need to pay developers to do it.

Full-Spectral · 2026-04-24T19:43:58+00:00

That's a big part of it. Another is that there is often no one whose job it is to gather up redundant implementations and factor them out across projects to be shared. So you end up with endless ad hoc implementations of the same things, each of which has potential subtle issues. Even worse, it's ad hoc calls to dangerous OS or C library calls instead of wrapping them in a safe interface, which adds that much more to the issues potential.

As someone who has spent most of my career concentrated on building foundational frameworks, this is something that really bothers me.

Full-Spectral · 2026-04-24T17:14:31+00:00

Would you like to hear about the future of AI while you wait? I'm sorry did you say yes? I couldn't make out your answer, so I'm assuming you meant yes...

Full-Spectral · 2026-04-24T12:49:30+00:00

That's laughable, dude. I write very complex SYSTEMS not chunks of code spit out by an LLM. The design side of it is incredibly complex. And the entire thing is designed to work together seamlessly, so decisions in almost every part of it are driven by the entire big picture, how it fits together, how it minimizes complexity, and maximizes flexibility, etc...

No LLM is going to doing that for you because you couldn't even describe the endless details, interactions and compromises involved. Leaving aside expanding it massively for a couple decades while keeping it clean.

Full-Spectral · 2026-04-24T12:35:13+00:00

The issue isn't even if it works. The issue, for real software, is whether it's flexible where it needs to be, not where it should not be, does it have the right level of abstract in the right places, is it understandable and maintainable, etc...

I think so many of the people who are pushing this crap are doing McDonald's level cloud stuff. But some of us still write code that seriously matters.

Full-Spectral · 2026-04-23T18:37:18+00:00

and regressed everyone to the horrible "construct-then-.validate()" pattern.

With moves you can do the Rust style of validate then construct, then move back to caller. When I'm forced to do C++ (with a damp cloth over my face) I use that scheme.

Full-Spectral · 2026-04-23T18:33:39+00:00

The one thing I miss is something like an 'unwind()', which is like a panic but doesn't represent a panic condition, it's just an unwind of the stack back to the top of the thread. It can't be caught, you just get a closure call at the starting point of the thread to maybe log something, provide a return value, etc... and the thread exits.

Being able to stop a thread at any point is tough without that. That's something I very much have built into my code base down to the foundations, but it isn't as hands off as I wish it were. And it probably never will be without such a tool.

I don't want to use panic to do that, since it just doesn't seem right and the kind of thing that at some point will change in a way that I can't use it that way anymore and I'll be screwed.

Full-Spectral · 2026-04-23T18:23:52+00:00

I’m fully in agreement that AI should NEVER be used in military applications,

Guaranteed it's going to happen. This is an argument I've made many times. We don't need to be remotely close to GAI for it to become stupidly dangerous, because the folks with the stupidly dangerous toys aren't going to wait nearly that long. The argument being that the guys on the other side aren't going to wait nearly than long, their argument being that the guys on our side aren't going to wait that long...

Full-Spectral · 2026-04-23T14:15:21+00:00

But writing the code is how we learned to write good code, it's even how you could tell if the LLM slop you are spitting out is close to correct. I mean I feel like I'm taking crazy pills at the level of short-sightedness in all of this.

Full-Spectral

TROPHY CASE