Scott Galloway

I mentioned one of my “down the pub” software development opinions to James Lewis at EventCentric. He suggested that I mention it to Kent Beck and so, while I remember. But definitely, the tone here, is “crazy talk over a pint.” ———- XP optimises software development for folks with ADHD. The Extreme Tuesday Club is likely a hotbed of ADHD diagnoses. TDD, CI, Small Releases: we need those rewards to keep coming in regular doses. Pair Programming: “Stay on target, stay on target” Refactoring, Boy Scout Rule: “Ooh, while I am here, I should fix that as well. Now where was I? Oh the test list.” Sustainable Pace: We can only focus so long in one stretch, even with the above. Planning Game: one story at a time, don’t get distracted by other things. Business value, not “shiny thing.” Small stories because we get bored easily. Whole team working so that we can get to that shiny story faster. Osmotic Communication: Quick, let me blurt out my idea before I get distracted and forget I wonder if there is a correlation between XP teams achieving flow, and XP teams filled with neurodivergent people who have figured a coping mechanism for productivity.

311

67 Comments

If Teams were written in a highly fault-tolerant language like Erlang, would it actually work well, or is there some non-technical reason that it is inherently unreliable?

Managing developers isn’t about checking in every five minutes... It’s about giving them the right environment to do their best work. Here’s what that actually means: 🔷Be crystal clear on what needs doing - outcomes, not tasks 🔷Give proper context - the why behind the work 🔷Remove blockers - don’t be one 🔷Let them get on with it - deep work needs space 🔷Trust them to find better ways of doing things Developers aren’t looking for micromanagement. They want autonomy, purpose, and a team that knows how to deliver without chaos. If they’re constantly waiting on approvals, chasing clarity, or stuck in meetings... They won’t stick around for long. Lead with clarity. Support with trust. And manage based on results, not noise. Simple, but often missed we are djr 🔵 ⚪

7

5 Comments

A single feature idea can trigger hours of planning, debate and architectural decisions before a single line of code is written. That's not inefficiency. That's how good software gets built. The teams that skip this part are the ones firefighting six months later. #TechCulture #SoftwareTeams #UKTechIndustry

5

It's that time again! I've got a talk up this year that started out as a discussion in a DigiLocal CIO session about the best ways of talking to young people about testing the code you've written and led to me writing a basic testing framework in Scratch and seeing how feasible TDD was in that environment. The talk is called "Testing from Scratch" and if that sounds in any way interesting I'd really appreciate any votes to get it into the programme, but there are loads of great talks on offer (in particular, I'm curious to see what both Lorraine Pearce and Michael Luke are talking about) so do have a scroll and see all the wonderful things on offer

8

1 Comment

"The more tools we give developers, the better off they’ll be.” - Joshua Markham In conversation with Joshua about the challenge of developers contacting support, wanting to share code they’ve written, and asking, “Why isn’t this working?” Of course, we’d love to help every developer debug their API integration code, but that doesn’t scale. Investing in the developer experience and tools around our APIs scales, which is what APIMatic and Verizon are doing together. #TechSupport #API #DevX #DeveloperExperience #DX #SDK

7

It's not just meetings that destroy the productivity of your developers, but they don't help. Learn some ways to improve your #DeveloperExperience in this blog post.

1

And now for some readings of user level RCU .. and a landmark paper that led to the implementation of liburcu - the user space RCU library, a Christmas Day evening read .. Why RCU is difficult in user space ? RCU, particularly its high-performance Quiescent-State-Based Reclamation (QSBR) variant, is easier in kernel mode because the kernel scheduler automatically detects quiescent states whenever a CPU context-switches, enters user mode, or idles, allowing grace-period tracking without any explicit cooperation from kernel code. In user mode, applications lack this built-in mechanism, so threads must explicitly register and periodically report quiescent states (e.g., by calling specific functions), imposing invasive global constraints on the entire application. These requirements make user-level RCU harder to adopt broadly, as they complicate library design and require modifications to all potentially reading threads, which is impractical in many user-space programs. User level implementations of RCU : This paper contributes to user-level RCU by formally describing efficient and flexible implementations that overcome the limitations of prior approaches, which either imposed high read-side overhead or severely restricted application design. It presents multiple classes of RCU (including QSBR, memory-barrier, signal-based, and bullet-proof variants) with detailed algorithms, performance analysis, and comparisons to locking, directly forming the foundational basis for the liburcu library's core flavors and enabling its widespread adoption in user-space applications.

73

3 Comments

Explore the future of API testing with Tom Akehurst, Co-Founder of WireMock, as he chats about bridging front and back end development gaps in our latest episode. Tune in for expert insights and tips: https://lnkd.in/eDEmKkTF

7

There’s a tonne of vibe coding going on at the moment, it gets something working, to see if it feels right and then worry about the structure later. That can be genuinely useful early on. It’s also how you can lock yourself into decisions you didn’t really mean to make. I ran into this building Nota. Until a few days back, transcript templates were just typed structures in code. Clean, simple, and quite tempting just to leave as they were, because they worked so there was no immediate pressure to change anything. The more I thought about where it all might go, the more that “simple” choice started to feel brittle. Versioning would be a faff, editing would mean shipping code and anything beyond the original use case would feel bodged in rather than designed. It would have been easy to keep going and tell myself I’d migrate later. Sometimes that’s fine, but sometimes it just stores up work you know you’re going to have to do anyway (aka tech debt). That’s where I’ve found it useful to slow down and be a bit more honest with myself. Not “does this work today?” but “what does this turn into if people actually use it?”. I’ll often sanity check that with an AI as well, not for code, but to call out where I’m making optimistic assumptions. Vibe coding gets you moving... but at some point though you need a more brutally honest review, whether that comes from a person, an AI or just taking the time to properly challenge your own decisions. The tempting feature is always speed. The harder decision is knowing when to pause and fix something while it’s still cheap to do so. #nota #vibecoding #decisions #techdebt #legaltech

20

3 Comments

The UK Share Code API is going to be adding a lot of features in the coming weeks. The first one we've added this week is to include gov.uk check details in the API response for both work and rent checks. This means that you can now reference the right to work/rent check that you carried out by grabbing the reference number out of the response! We've got some really big features and updates to share in the coming weeks, follow our page to keep up to date 👀

1

I'm finding it fascinating how tactics for working well with GenAI coding tools seem to be quite familiar - a lot of what I'm using comes straight from classic XP practices, Test Driven Development, and just a pile of my personal development practices and preferences. It makes sense - a common comment about these tools is "It's like having a lightning-fast junior developer who reads a lot but has no long-term memory or wisdom" - so in a lot of ways, I'm treating the AI like I'd treat a fast, clever, but naive developer. In D&D terms they have high INT but poor WIS. They need lots of guidelines and guard rails, and definitely don't let them go write an entire application unsupervised! XP practices especially were designed to help people write high quality software fast, with a focus on small safe iterative steps, and not needing to retain a lot of context - ideal for working with GenAI. See also Ian Cooper's post on XP and ADHD: https://lnkd.in/eTWQc5JH At a minimum I'm always making them work iteratively. "Generate a checklist of tasks that you will do, and let me check it. Then implement each step in turn, and let me review the changes and course-correct before you start the next step." This honestly reminds me of a really productive ThoughtWorks team I ran once, where for every story the devs would write an index card with a checklist of "TODOs" on the card, that they ticked off as they worked. That team was doing regular pair swapping, so lacked a lot of long-term memory - the checklist was very handy. This is also the best defence against "vibe coding" - at least as it was originally defined. Would you "vibe code" with a team of high-INT low-WIS developers with no strategic knowledge and no long-term memory to write code unsupervised? I'm having more success following what Pete Hodgson calls "Chain of Vibes": https://lnkd.in/eeU_xWnz (I love this naming, which is why I keep referring to his blog) - use the tools in lots of small, incremental steps, and you can get some great results. (I really should put more about this on my blog. When time permits. (and I know, the internet is flooded right now with "this is my cunning AI tooling approach" posts))

19

1 Comment

We’ve built salary sacrifice schemes for pensions, bikes, and electric vehicles. Why not housing? As a Software Engineering Manager, I spend my days architecting resilient systems. But outside work, I’m navigating a mortgage landscape that feels anything but resilient, with volatile rates, rising costs, and no structural support for working families. Here’s the gap: Mortgage payments often are our largest monthly expense, which must be made from post-tax income. Yet other long-term assets benefit from salary sacrifice. Why not allow capped pre-tax contributions toward our primary residence mortgage? Imagine being able to salary-sacrifice £500–£1,000/month toward your mortgage: 🔹 Hundreds of pounds/month in tax savings 🔹 Reduced housing stress and improved retention 🔹 Fairer treatment for mid-career professionals balancing family and financial growth It’s time to rethink housing support not just through subsidies, but through structural fairness. If we can salary sacrifice for pensions, bikes, and electric vehicles, why not housing? What’s stopping us?

15

8 Comments