Amitai Schleier
@schmonz@schmonz.com
If your business makes software, I might be good for your business.
(It’s foundational to my coaching practice that I not be the expert. As usual, working as intended.)
On the other hand (the hand I often manage to continue on to), I was able to make the trip, am already booked for the next one, and can easily imagine it’ll go better.
1. Not your code, but can break your code
2. Will one day dictate your schedule
3. Will own you more superlinearly the more you defer dealing with it
I’m almost never sure of any specific next move.
AND
I’m almost always sure of my general skill at coming up with next moves.
When would you? When wouldn’t you? Either way, how do you mitigate the risk of your choice?
What are some of the key factors that go into each such decision?
All else equal, what’s your preference?
What do your teams think you’re more expert at?
What do they think they’re more expert at?
Where do you mean to position yourself in relation to them?
Where do they perceive you?
What else have you tried? On what grounds do you prefer your current approach?
Sometimes we’re pouring code into different containers.
Sometimes we’re optimizing the shape of the current container.
When do you focus on which, and why?
How to work the Campsite Rule to your advantage?
🧵 https://octodon.social/@schmonz/111162007959878626
a. Be quiet
b. Stop
#SoftwareEngineering #CognitiveLoad
Got no slack time? Defer something, then pick a cost to reduce.
1. Push straight to main
2. If that doesn't feel like a good idea, change everything about how we work until it does
(To be clear, implementing this takes more than two steps.)
#ContinuousDelivery #ContinuousImprovement
It's unmanaged duplication that creates risk.
- See and fix any remaining ones
- Recompose parts to add functionality
- Adjust to meet people's real needs
Messy code is a competitive disadvantage. #refactoring
If not, oops, we fix it.
If yes, we can ask more of it.
I hadn't been aiming that far ahead; I'd been looking for a foothold to climb out of a persistent hole.
A bit more about that: https://www.linkedin.com/posts/jack-hannah_by-default-i-wasnt-effective-in-a-business-activity-7221620343000477696-3jI8
(For long-winded personal reasons I run and develop @notqmail instead of using Postfix. https://schmonz.com/2017/03/27/automation-for-mail-hosting/ says more in terms that might appeal to your XP feelings, but I cannot yet honestly recommend notqmail to folks who aren't already running qmail. Someday.)
(Developers at every level can be thinking about how well the two are correlated. A good way to acquire seasoning.)
1. It feels good
2. It invests company money wisely
When I get carried away with #refactoring, they both turn false. Same when I haven’t been doing nearly enough of it.
Upon our return there today I made sure to say it.
*by age, size, and frequency and obviousness of communications with other dimensions
Now, instead of
$ nb boot ubuntu 24 arm64
I can just type
$ nb boot ubuntu
to bring up the latest version matching the host's arch.
https://github.com/schmonz/nbvm/commit/a1a3a363552f24549e458ecad203d40af75cb4b1
When we trust ourselves later, we can do less now.
When we do less now, later gets easier.