,
8 tweets,
2 min read
Read on Twitter
This laundry list isn't meant to shame anyone, btw. Even high performing teams will manifest a symptom or three, because context and tradeoffs.
But the more list items apply to you, the more confident I am that your release process is *seriously* dragging you down.
But the more list items apply to you, the more confident I am that your release process is *seriously* dragging you down.
Yes: it happens when leadership equates shipping product & features with progress and profit, and everything else is seen as a "cost center."
It is hard to recognize and evaluate the true impact of costs that are amortized over time.
It is hard to recognize and evaluate the true impact of costs that are amortized over time.
Also, depressingly, most engineers have never worked on a high performing team where they *weren't* rowing the boat uphill thru a viscous stream of molasses
🌪🌧They think this is just how building software feels.🌧🌪
🌪🌧They think this is just how building software feels.🌧🌪
To be clear, it is totally possible to *over* invest in your pipeline. Usually like this:
"we abstractly know it's important, so we are going to let some engineers go off for months and write a lot of software that doesn't actually connect to any real need, but does sound cool"
"we abstractly know it's important, so we are going to let some engineers go off for months and write a lot of software that doesn't actually connect to any real need, but does sound cool"
There may be legit cases of genuinely over architecting and building out too far before your needs... maybe?
The return on investment is just astronomically high if you get people deploying faster with more confidence. The sooner the better. It's like AAPL stock circa y2k.
The return on investment is just astronomically high if you get people deploying faster with more confidence. The sooner the better. It's like AAPL stock circa y2k.
And bad habits are hard to break, entrenched fear is hard to cure. If you have code to deploy, you should invest in your process.
Lastly, some super subjective observations on great release engineers and effective release engineering. (Warning: my sample size is not large.)
Lastly, some super subjective observations on great release engineers and effective release engineering. (Warning: my sample size is not large.)
A good releng looks for low hanging fruit (trust me, you have some) and knocks out a stream of incremental improvements, each hours or days-long. No starting from scratch, no ambitious designs.
They are instrumentation obsessed. If they looked at it, they left it instrumented,
They are instrumentation obsessed. If they looked at it, they left it instrumented,
Tbqh some of the best releng I know are pretty weak as software engineers, who write new software reluctantly as a last resort. So if they are writing code, you know it was god damn necessary.
(but this describes my attitude towards new code too, so perhaps a bias 😉)
(but this describes my attitude towards new code too, so perhaps a bias 😉)
