If your codebase were an automobile, what kind would it be?
A sports car? Minivan? Pickup?
Regardless, if you let complexity sneak into your codebase, you're driving with one foot on the gas, one on the brake. The more complex, the harder you're pushing.
Take your foot off the brake! Simplify!
Bumping for visibility, since I posted this at an obscene hour.
"Red, green, refactor" promotes premature abstraction.
Ward Cunningham on convincing management to refactor: "I don't. Two estimates—make room for the feature, then add it."
Do structural refactor before the next story, not after this one.
What I do instead: the.codegardener.com/red-green-pr...
Not where I am. But Cisco is huge.
We hold all code submitted to our repo to the same standard, regardless of who or what wrote the code. AI can totally get there. So we’d likely push back on the PM.
Are you a builder who prioritizes shipping software? Or are you a craftsperson who prioritizes well designed code?
It’s a false choice.
You get more done with well designed code and tests than you do without. Craftspeople move faster than Builders who eventually grind to a tech debt induced halt.
Totally! False confidence.
Bugs can still sneak in with 100% line & branch coverage. But, without 100% coverage, you cannot refactor code with full confidence. It's not about bugs. It's about moving fast and keeping your design malleable!
Have you ever been told by an executive that test coverage past 80% produces diminishing returns?
Have you asked them which 20% you should not test?
Have they ever given you an answer?
Come ready to share your experience with disagreement. Come ready to receive the wisdom of the room. And leave with a framework for breaking through disagreements and making decisions together.
We'll cover why persuasion fails, how to facilitate a decision-making process that actually works, and the role psychological safety plays in all of it — skills that can be applied to any human relationship.
There are two words that can change all of that. They're disarming, vulnerable, and surprisingly hard to say. This workshop is built around those words — and everything that has to be true for them to work.
Every experienced engineering team has been here: a decision needs to be made, everyone has a favorite solution, and the harder people push, the more entrenched people get. Persuasion—our default tool for resolving disagreements—doesn't just fail in these situations. It can actively damage the team.
I'm working on an idea for a workshop at #RubyConf. I'm wondering if you would find this a valuable use of your time at a technical conference. Please comment to register your vote. Here's the title:
You're Right! Going from Disagreement to Decision without Damaging Your Team
Abstract in 🧵
😅
But it’s a dry heat…
Same. I felt seen by her talk. I, too, started programming in the 1900’s.
In an era filled with tech dipshits who never developed emotionally past the age of 13 & use their wealth to become odious monsters ...
... listen to Steve Wozniak.
Saw you at the conference. Didn't get a chance to chat. Glad you enjoyed SF!
Which talk should I absolutely not miss when the video comes out?
Enjoyed the article!
I gave up and wrote my own definition for vision:
A vision statement is an inspirational postcard from an aspirational future. It should be brief. It should paint a picture. And it should make you wish you were there.
the.codegardener.com/vision-missi...
XKCD drawing of two stick figures watching a sunset, with the text: What are you doing? Lenthening the sunset Pushing back the night Giving me a little more time Here with you.
A love letter by XKCD:
What are you doing?
Lenthening the sunset
Pushing back the night
Giving me a little more time
Here with you.
youtu.be/U8F7UNK9jco
TIL: Wubular
github.com/RubyElders/wubular
> Wubular is a modern re-imagining of Rubular, built with Ruby compiled to WebAssembly.
> It lets you compose and test Ruby regular expressions directly in your browser — no backend server required.
Excellent suggestions.
One other challenge: what happens when the OPUR is unavailable or leaves the organization? Is there backup? Would it not make more sense for there to be a team instead of one person?
In other words, as the OPUR, I am empowered but don’t have time. The people on the rotation have time but don’t feel empowered because there is an OPUR. I do not see that as a healthy dynamic.
I’m thinking about changing the run book for the process to make updating the run book part of the process.
“Could you make that change for me so the next person in the rotation can benefit from your learnings?” usually works.
Rather than update the docs or work on the backlog of tickets to further automate the process, they tell the coordinator (me) that changes need to be made. But I am just one person. By making me the OPUR, nothing is happening to improve the system. So I turn it around on them.
We have a gated deployment process that requires a human to push buttons and check dashboards as a build goes through automated end-to-end tests in staging and canary before being promoted to production. We have a rotation of engineers who run the process. They have downtime while tests run.
Hot take: Developers who are happy to complain about friction within a process, generally don't lift a finger to resolve it.
Hot take: Developers will complain about other people's flaky tests but defer dealing with their own for as long as possible.
Hot take: Developers will complain about a build that takes two minutes longer than they think it should, but will gladly spend two days gold plating something.