Amitai Schleier
@schmonz@schmonz.com
If your business makes software, I might be good for your business.
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.
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.
@schmonz I am almost never satisfied with neither "my", nor "others'" code. That's why I insist on the code to be maintained relentlessly (TDD, refactoring and CI above all) and that's what I expect from others. Because currently most of the others act as if the code they write is perfect (the write once mentality and the notion that the code can be "done" which it never is).
Lastly, there should be no such thing as my and your code.
I appreciate the reminder to consider systemic factors that push people to make such choices. The systemic factors suck. But also people who make any part of others' lives miserable suck.
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 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.
What does this feedback reveal about the giver? Would you expect them to be a skilled leader or manager?
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.
Alt...
Ocean view from our table
Alt...
Whole Spelt K’nockers
![[?]](https://schmonz.com/snac/schmonz/s/506a4e5be3c4eba4d0539c833aea957a.jpg)
![[?]](https://sw-development-is.social/system/accounts/avatars/113/504/811/663/933/476/original/67d0a12eabfb5e30.jpg)
![[?]](https://social.mikutter.hachune.net/system/accounts/avatars/000/000/427/original/fc94b536e3a273de.png)
![[?]](https://social.notqmail.org/notqmail/s/0d5728c5aea4d6c6a2405eb736aea730.png)
debian/ packaging automation alongside code, but not accustomed to seeing upstreams ship BSD packaging automation. As a packager, my experience of pkg_create is indirect. Very cool that you wrestled it into submission. Have you seen folks use your supplemental BSD package repositories?(I intend in the fullness of time to package nosh, and to figure out what to do with djbwares -- possibly treat it as the new upstream for all its constituent packages. But @notqmail@social.notqmail.org is also in dire need of a fresh batch of my attention.)
My fault assuming the existence of a published 1.5 tarball meant it was fully cooked. (I also saw FreeBSD Ports using it, so my fault accepting social proof as sufficient, too.) But also it's generally troublesome for packagers when published tarballs change size/checksum/etc. in place. Better to not publish until the URL contents can be stable, and/or publish new changes under new URLs.
Also, I was surprised to see your build wanting to know how to generate its own binary package. I guess that's typical for Debian and others, but unusual for pkgsrc and I imagine other ports-style trees. No harm done, of course, but I've given pkgsrc that part of the job.
Progress on getting shairport-sync cross-built, but not there yet.
I'd prefer #NetBSD: https://schmonz.com/2024/06/07/small-arms/
Staged latest shairport-sync for #pkgsrc. Builds on NetBSD, #macOS. Normally I'd commit, wait for evbearmv6hf-el binary package, forget.
Trying something new today: https://cdn.netbsd.org/pub/pkgsrc/current/pkgsrc/doc/HOWTO-use-crosscompile