schmonz.com is a Fediverse instance that uses the ActivityPub protocol. In other words, users at this host can communicate with people that use software like Mastodon, Pleroma, Friendica, etc. all around the world.
This server runs the snac software and there is no automatic sign-up process.
On 𝐅𝐫𝐢𝐝𝐚𝐲, 𝐌𝐚𝐫𝐜𝐡 27, I’ll be presenting "𝐞𝐗𝐭𝐫𝐞𝐦𝐞 𝐏𝐫𝐨𝐠𝐫𝐚𝐦𝐦𝐢𝐧𝐠 – 𝐓𝐡𝐞 𝐊𝐧𝐨𝐰𝐥𝐞𝐝𝐠𝐞 𝐖𝐞 𝐋𝐨𝐬𝐭” at 𝐝𝐞𝐯𝐂𝐨𝐧𝐟 2026. This talk is a deep dive into the origins and core practices of XP, and why these ideas are still very relevant today. Let’s reconnect with the principles that shaped modern technical practices.
🔗 More info & registration: https://devconf.nl/
Looking forward to seeing you there!
#XP #ExtremeProgramming #Agile
The following excerpt comes from “All I Really Need to Know About Pair Programming I Learned in Kindergarten”, an article written by Laurie Williams and Robert Kessler. This article got published in May 2000, but is still highly relevant today.
That’s your clue: refactor first.
(Special case of the general KFB wisdom “First make the change easy, then make the easy change.”)
Scientific research discovered that human brains “sync up” when we collaborate. Co-creation patterns in software development do really work. These new findings add to the existing pile of research that others like Laurie Williams have already done regarding pair / ensemble programming.
Collaborative rule learning promotes interbrain information alignment:
https://journals.plos.org/plosbiology/article?id=10.1371/journal.pbio.3003479
#extremeprogramming #xp #pairprogramming #ensembleprogramming
Hit up your network before applying. If you’re reading this, I’m in your network.
But if a supposed #ExtremeProgramming expert doesn’t grok this, such remarkably deep failure of understanding indicates ignorance AND profound obstinacy.
For the same reasons, some published authors are better at describing than at enacting.
Maybe an author really knows, in context, under stress, how to do the thing. Maybe not.
1. Become Director of Engineering
2. Tell org and stakeholders that XP will fix longstanding problems
3. Regularly interfere with devs’ learning
4. Design projects to delay ROI
5. Find scapegoats
Maybe they’ll blame #XP.
Maybe in your case it’ll be what it sounds like. I hope so. But beware. https://schmonz.com/snac/schmonz/p/1757721641.814818
If the only bits of #ExtremeProgramming you’ve mastered are the technical ones, you’re not an XP expert. Especially if you’re sure you are.
If you’re still sure of your understanding, regardless of cost to you and others… clownshoes.
If you do this while claiming to be an #XP expert, that’s clownshoes.
Leaders are not obligated to value such feedback.
But if they don’t, they oughtn’t claim to value #ExtremeProgramming. They value something incompatible.
If influential developers of the highest caliber keep not meeting your expectations, you have much more to learn about #EngineeringLeadership.
Not all “XP” jobs, authors, experts, or leaders are what they claim. Before applying, ask around your network.
- Less principled, coherent, systemic
- More expedient, forgetful, surprising
In short: even riskier.
If there were such a thing as expertise in managing software risks, you’d want that, right?!