Iain M. Banks wrote one of my favorite sci fi series (Culture Series) about what society would be like in an abundant future. One of the ideas that stands out is that even if people don’t strictly need a job, they will still want mastery, stories, to build, and to feel useful to others. In the society he imagines, the hard problems are no longer allocation problems, but are instead about values (what’s good, beautiful) and identity. The scarce resources become trust, attention, and, for institutions, claims to legitimacy. Values, not resources, drive differences in cultures. Societies choose different aesthetics, morals, and attitudes towards risk. Banks’ world offers infinite comfort, and some people basically opt into endless pleasure. But the books focus on the people who crave intensity, put themselves in danger, chase purpose in hard environments, and want friction and consequence. In the books, “the Minds” are basically benevolent, well-aligned ASIs who solve all our problems and run everything. Even if that’s where we are headed, it’s fun to imagine what we will still care deeply about. Banks is amazing at thinking through what that might mean. I highly recommend them.

This is incredible

Italian narrow roads? How can Tesla FSD handle them???😉

Congratulations to the England women’s rugby team! Fantastic game played by both 🇨🇦 and 🏴󠁧󠁢󠁥󠁮󠁧󠁿

We’ve moved fast to integrate Anthropic’s Claude Opus 4.1 into your GitHub Copilot Chat model picker. This new version brings a major boost in performance, giving you a smarter, more capable partner. Now go put it to the test. github.blog/changelog/2025-0…

Most impressive #MSBuild in my 7 years of working at the company (and sub divisions) GitHub Copilot SWE agent is epic, Copilot foundry looks amazing for enhancing my own models; and Windows with MCP! This is so awesome. Just to name a few!

Does everyone really need to know what the CAP theorem is?

Not often the bosses boss gets in on an announcement. GitHub Copilot Free announced today by Satya.

I'm tired of seeing the typical list of books recommended over and over again for software engineers. This is my list of great books (free & paid) and Youtube content creators that you should read / follow. Featuring: @Lethain , @neoeno, @munificentbob , @shiffman, @chacon, @aarondfrancis, @3blue1brown, @ArtemKRSV and many many more who I cannot tag here

Another question for the day. Is industry becoming even less empathetic to the human condition?

Another spicy opinion piece. GraphQL is terrible.

Hot take. Passkeys have made things worse. User Pass MFA device I can get on board with. Passkeys not so much, since enabling passkeys, I have to reauth every device every time I go to it, and I have so many passkeys I am loosing track of what I have authenticated where. It is a nightmare to do a personal audit on and the user experience is terrible. Who else thinks passkeys are shite?

Facinating, anyone got any more detail on these laws that they want to share?

What an absolute legend!

I didn’t know John Cena was this wise. That was a beautiful speech about purpose ❤️

I need an emotional support vehicle.

Nice; swag for my part of GitHub Gives 2024!

I’m messing around with Ruby on Rails 7 having not touched rails in a decade (despite using Ruby a lot a few years back) Y’all why it got such a bad rap. Rails is awesome.

The Toyota Production System (TPS, usually called "Lean" in the West) defines three sorts of difficulties, all of which apply to software development: Muri, Mura, and Muda. They're all worth thinking about. Muri is long-term overburdening of the entire production system (e.g., too much work for the people at hand). That's not waste so much as creating a system incapapable of doing the work. To my mind, Muri also encompasses inappropriate organization architectures, where the management structure is fighting against working in effective—all too common in larger corporations, but you see it everywhere. Mura is variation in the work to do. The biggest cause is usually random show-stopper bugs in the drop-everything-and-fix-this category. Variation can also happen at a macro level, for example, tax-related software that's used only once a year, so all the bugs surface over a couple of weeks rather than continuously throughout the year. In general, the more variation you have, the more buffering and slack time you need in your schedule to absorb it. In the Muda category, TPS defines eight categories of waste (all of which apply to software). I use the acronym DOWNTIME to remember them: * Defects (of all sorts, but bugs and technical debt). * Overproduction (is related to Inventory. Producing software we can't sell—often because we're not validating products before we build them) *Waiting (all sorts of dependencies cause waiting, as do processes that mandate lots of meetings and the like). * unused taleNt (punnishing people as "unproductive" instead of training them is a big one here.) * Transportation (when the work needs to move from one place to another—from product to dev or dev to test, for example—you have delays). * Inventory (work done that has not been released to customers. Money spent without a balancing revenue.) * Motion (too much process. too many meetings. Lots of motion, but no progress). * Extra Processing (building more software than you need. futureproofing). Of course, all this is just the tip of the waste iceberg, but it's a good start.

Please share this far and wide. As far and wide as you can. NIST Password Guidelines for 2024 are in the process of being updated. This is a HUGE pet-peeve of mine (when vendors in particular are still operating like its 2017 and keep changing passwords every 60 days, STOP DOING THIS, it's outdated and has been shown to put you MORE at risk than less -- NIST explains why it does in this document, meticulously outlining user behavior**) so I'm sharing this in the hopes all of you will pass it along to your bosses. The Special Publication series governing passwords is SP 800-63 "Digital Identity Guidelines". The 2024 version is 800-63-4. Here: pages.nist.gov/800-63-4/ The companion docs are also on that link. They are 800-63A, 800-63B and 800-63C. These are different documents for different scenarios in play at your org. The previous update was in2020. The changes in the 2020 version from the 2017 version were numerous but one of them was that the password verification method should NO LONGER require passwords be changed at specific intervals (i.e. every 60 days) but in the following circumstances instead: 1. After a breach/compromise 2. User request 2024 repeats this and adds a bunch more guidlines but here is a screenshot of page 13 of the new 800-63-4 (note the # 4 after it) which outlines how your systems should now and moving forward, be handling passwords. This goes for Active Directory, too. All your systems which have passwords should align with these guidelines provided there isn't another standard or framework you must adhere to which overrules this. Most frameworks, however, have moved away from arbitrary password resets and complexity rules. **We cybersec researchers and hackers use wordlists from breaches in a variety of different ways. Hackers use them in tooling to crack passwords whereas researchers use breach dumps to see the kinds of passwords users are creating and the psychology behind them. Using complexity rules gets you the user psychology of: Password1 Password2 and so on Use phrasing instead and allow for spaces, which is important. Humans type phrases with spaces. They also mention phish-resistant methods and most vendors are on-board with MS going to be turning off all Legacy Auth next month, across all free accounts and tenancies. I'm so excited for the new changes! Ok I'm off my soapbox. Share the love! Thank you!