Amitai Schleier
@schmonz@schmonz.com
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.
Given a completed test run
When it included all possible tests in the project
And all of them ran green
Then a particular file’s timestamp gets updated
Easy peasy! Let’s teach every test framework to do this.
If you run #JUnit 5 tests on pre-commit, here’s your bonus: https://schmonz.com/software/greencently
(Pays off on day 1.)
For other frameworks, help wanted! #tdd #xp
(Something short and sweet and stepwise, akin to #TDD's "Red, Green, Refactor", would be amazing.)
Expect to learn more, plan a little less.
An even older USB printer staying useful.
https://schmonz.com/2024/06/07/small-arms/
