I'm giving up maintainership of the #Subsurface dive log package on #Flathub. There is a too wide gap between how it is developed and what Flathub/Flatpak expects, and I still can't use the Flathub version with my own dive computer because there are Bluetooth issues I have no idea how to debug.
I cannot justify investing more time on an application I use at most three times a year. Especially when the official #AppImage just works.
I have a #GitHub question (I am a GitHub newbie, but familiar with other repos like SVN):
I’d like to see others’ code on GitHub but I feel weird about [edit:] downloading code belonging [/edit] to people I don’t know.
Is there any etiquette around this?
For context: I’m autistic and this is the kind of thing I’ll screw up IF there are unwritten rules! But a lecturer on my masters course recommended I explore others’ coding solutions on GitHub. I just feel so weird actually doing this!
Ok, I admit it; I've got one eye on the weekend…
I'm thinking about what I'll do to protect my wellbeing over the next few days when I have more control over my time...
This weekend I'll be:
Eating out with friends Spending quality time with family Playing squash and doing a gym workout Spending some quiet time reading my kindle
https://lwn.net/Articles/1013776/
A really interesting article about using open source in the government. In this case it's Mexico. Nice to see that good things are also happening. Congratulations to González Waite for pushing open source software in the government!
It's crazy that when you stop using a proprietary software product you get called by the U.S. embassy with threats. Obviously it is free economy /s
The new CPSA®-Foundation Level curriculum is here! 
@gernotstarke and Alexander Lorz share key insights into the updates, including a more logical structure and improved progression to better equip architects for current and future challenges. 
Learn more: https://t1p.de/lsbux
3 daily habits that will improve your sleep…
I previously mentioned 3 fundamentals for getting great sleep based on your mattress, pillow and duvet…
These 3 daily habits will compound the effects of those fundamentals…
Do some form of daily exercise. Just be careful not to do it too close to bedtime, as your increased core body temperature will likely keep you awake.
Leanpub book LAUNCH 
Real World Agility: Backed by evidence, built for results by Nicolas Brown https://youtu.be/g7K-joUICFM #books #ebooks #Agile #ProductManagement #Leanpub #Leadership #EvidencedBased #SoftwareDevelopment
Conway’s Law and the challenge of building software in government
There’s an old truism in software engineering called Conway’s Law. It goes like this:
“Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.”
In other words, how a team—or a government agency—is structured shows up in the way it builds (or buys) software.
Anyone who has spent time building or working with software in a government setting has likely encountered the effects of Conway’s Law, even if they didn’t know it by name. Fractured services. Complex handoffs. Disconnected user experiences. Often, these are not the result of bad intentions or even bad code. They’re a result of organizational structure.
In the private sector, a common strategy to mitigate the effects of Conway’s Law is to restructure teams around user needs or product outcomes (often referred to as a Reverse Conway Maneuver). Change the organization, and you can change the way software is delivered. But in government, pulling off a Reverse Conway Maneuver is much easier said than done.
While the structure of government agencies can seem baroque and overly complex, they’re usually designed intentionally to fulfill legal mandates. Federal and state statutes define agency missions, outline specific responsibilities, and enforce a separation of duties across different offices. These divisions are designed to support transparency, avoid conflicts of interest, and maintain accountability. In many cases, the structure of an agency is baked into federal or state statute, and can’t be quickly or easily changed.
Budgets also play a defining role in how agencies are organized. Funding is often tied to specific programs or outcomes, and agencies are organized around how dollars are allocated. That financial structure shapes how teams are staffed, which systems get developed, and how contracts are awarded.
Contracts, too, reflect these constraints. While a software contract that spans multiple organizational silos might make sense from a technical perspective, it may not comply with procurement rules or statutory authorities. A contract that looks suboptimal in terms of software delivery might make perfect sense in terms of law, oversight, or available funding.
Conway’s Law isn’t a problem that can easily be solved in government, but it is a dynamic that teams developing software in government must acknowledge. In government, changing the structure of an organization to improve software isn’t always feasible. Instead, teams may have to work with the structure they have—navigating silos, building bridges between responsibilities, and designing systems that account for the way an agency is structured.
Changing the way that government agencies are structured or overhauling existing contracts may be difficult, but the real work of government digital modernization is finding ways to work within these constraints. This doesn’t mean that a Reverse Conway is impossible, just that it’s a lot harder (and slower) to do than it is in the private sector. And it can’t be our only tool in the toolbox.
This is what makes implementing tech technology solutions inside government so challenging, and so rewarding.
"You can replace tech writers with an LLM, perhaps supervised by engineers, and watch the world burn. Nothing prevents you from doing that. All the temporary gains in efficiency and speed would bring something far worse on their back: the loss of the understanding that turns knowledge into a conversation. Tech writers are interpreters who understand the tech and the humans trying to use it. They’re accountable for their work in ways that machines can’t be.
The future of technical documentation isn’t replacing humans with AI but giving human writers AI-powered tools that augment their capabilities. Let LLMs deal with the tedious work at the margins and keep the humans where they matter most: at the helm of strategy, tending to the architecture, bringing the empathy that turns information into understanding. In the end, docs aren’t just about facts: they’re about trust. And trust is still something only humans can build."
"Since 3.5-sonnet, we have been monitoring AI model announcements, and trying pretty much every major new release that claims some sort of improvement. Unexpectedly by me, aside from a minor bump with 3.6 and an even smaller bump with 3.7, literally none of the new models we've tried have made a significant difference on either our internal benchmarks or in our developers' ability to find new bugs. This includes the new test-time OpenAI models.
At first, I was nervous to report this publicly because I thought it might reflect badly on us as a team. Our scanner has improved a lot since August, but because of regular engineering, not model improvements. It could've been a problem with the architecture that we had designed, that we weren't getting more milage as the SWE-Bench scores went up.
But in recent months I've spoken to other YC founders doing AI application startups and most of them have had the same anecdotal experiences: 1. o99-pro-ultra announced, 2. Benchmarks look good, 3. Evaluated performance mediocre. This is despite the fact that we work in different industries, on different problem sets. Sometimes the founder will apply a cope to the narrative ("We just don't have any PhD level questions to ask"), but the narrative is there.
I have read the studies. I have seen the numbers. Maybe LLMs are becoming more fun to talk to, maybe they're performing better on controlled exams. But I would nevertheless like to submit, based off of internal benchmarks, and my own and colleagues' perceptions using these models, that whatever gains these companies are reporting to the public, they are not reflective of economic usefulness or generality."
Everyone else seems to be crushing it…
Those engineers you think are "crushing it" may still need your support.
Just because you think they are crushing it, doesn’t mean they are coping.
Excellent performance doesn’t mean an absence of:
Stress Self-doubt Burnout.
They probably don’t feel like they are crushing it…
"Build-measure-learn" - the premise of Big Tech development teams - is an ideology of waste. In reality it's "build, build, build" and all the stuff after that is an afterthought.
This week's issue covers UX designers who are finding ways to start with "learn" instead of starting with waste.
#UXDesign #UX #UserResearch #ProductManagement #softwaredevelopment
Sigh, I think I might have to switch away from #VisusalStudioCode. Seems the only stuff they work on is #AI, to the detriment of everything else.
Shall I move back to #vim? Or rather #neovim. Do I still have the patience to configure that just the way I like it?
I could also try out that newfangled #zed editor that is getting all the hype these days.
One must-have feature is it having good vim keybindings though, I'm lost without them.
#SoftwareDevelopment #golang #rustlang #rust
Many software engineers struggle to FOCUS.
They feel constantly distracted by...
Social media. People & notifications. What others are doing. New languages and frameworks. The grass being greener elsewhere.
Do you want to feel more FOCUSED...
On the day ahead? On your wellbeing? On the task at hand? On your career progression?
#developers #coding #softwaredevelopment #softwareengineering #wellbeing #mindset #mentalhealth
I just posted a rant about behaviour in the open-source community with an emphasis on user entitlement.
"My current conclusion, though preliminary in this rapidly evolving field, is that not only can seasoned developers benefit from this technology — they are actually in the optimal position to harness its power.
Here’s the fascinating part: The very experience and accumulated know-how in software engineering and project management — which might seem obsolete in the age of AI — are precisely what enable the most effective use of these tools.
While I haven’t found the perfect metaphor for these LLM-based programming agents in an AI-assisted coding setup, I currently think of them as “an absolute senior when it comes to programming knowledge, but an absolute junior when it comes to architectural oversight in your specific context.”
This means that it takes some strategic effort to make them save you a tremendous amount of work.
And who better to invest that effort in the right way than a senior software engineer?
As we’ll see, while we’re dealing with cutting-edge technology, it’s the time-tested, traditional practices and tools that enable us to wield this new capability most effectively."
The best way to build confidence in your solution…
…Is to get early feedback.
Discuss your ideas before implementing them. Get someone to eyeball your solution as early as possible. Deploy something and let people have a play as soon as you can.
Too often, I've found myself tucked away working on a feature, going deeper and deeper down that rabbit hole...
So, for anyone not in dotnetland, MediatR is a library which is commonly implementing a design pattern known as CQRS, one of the many completely pointless "design pattern for the sake of design patterns" found within OOP and which I have been trying dearly to make people stop using.
2 months ago its lead developer posted in a comment to a reddit thread 'You can print it on a shirt “I will never commercialize MediatR”. And I will sign it.', only for that lead developer to, two months later, make it closed source...
Jimmy, you have no idea how much of a favour you are doing for me
https://www.reddit.com/r/dotnet/comments/1iamrqd/comment/m9e36u2/
