Amitai Schleier
@schmonz@schmonz.com
If your business makes software, I might be good for your business.
In the same message: "Is this a bug in acceptutils or did I make a configuration mistake?" A bug, and now I'm freshly motivated to fix!
When designing a project, do you always prioritize closing the feedback loop of ROI (or lack thereof) as early as possible?
Might you ever choose to defer closing that loop because you need something else sooner? If so, what kind of something could that be?
(1) Collective ownership and incremental shared learning over the absolute quality of today’s code
or
(2) The other way around
or
(3) Both, somehow
?
I imagine there are workplaces wishing for this. But first, more time for more reflection.
Last time I saw @Soulcraftswoman was only slightly less long ago. Any minute now!
einfach = simple
vielfach = complicated
nullfach = impossible
(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.
History
![[?]](https://schmonz.com/snac/schmonz/s/506a4e5be3c4eba4d0539c833aea957a.jpg)