“You can maintain and sustain the hard-earned psychological safety of your team by doing these five things.” https://www.reflectionpoint.org/post/how-to-build-psychological-safety-not-destroy-it
“Drucker revolutionised management thinking in the 1950s by considering businesses and corporations not just as economic systems, but social systems too, and much of that insight was directly inspired by Mary Parker Follett.” https://psychsafety.co.uk/psychological-safety-74-power/
Replying to @mweagle
Sounds a bit like Map/Reduce.
Trust your fleet.
Ferry now departing to the Isle of Pasta https://twitter.com/zillowgonewild/status/1565371498931621891
“But what are companies actually looking for in senior leaders? What skills should you work on, what should you avoid?”
https://staysaasy.com/leadership/2022/08/15/how-to-break-into-senior-management.html
“This is why Alyson emphasized…that subject matter experts shouldn’t be the incident commander. Good incident response shouldn’t be about “getting lucky” and having the expert on call, but establishing learning and processes that help anyone solve issues. https://www.blameless.com/sre/sre-from-theory-to-practice-whats-difficult-about-incident-command
Replying to @mweagle
This explains our finding that highability college graduates exit STEM occupations earlier in their careers.”
https://academic.oup.com/qje/article/135/4/1965/5858010 via @this_hits_home on https://preaccidentpodcast.podbean.com/e/papod-406-ryan-kitchens-and-poeple-and-systems-part-2/
“If workers with high academic ability are faster learners, the relative return to ability will be higher in careers that change less, because learning gains can accumulate more over time…”
Replying to @mweagle
The churn is real.
“The fastest-growing software skills between 2007 and 2019 include Python, R, Apache Hadoop, and Revit. Software that was relatively common in 2007 but obsolete by 2019 includes QuarkXpress, Adobe Flash, ActionScript, Solaris, and IBM Websphere.”
“Working with graphs, we can completely lighten the programming, export, and overall graph and execute it partially or completely only when needed.” https://towardsdatascience.com/pythonflow-from-eager-to-graph-python-programming-6ee51fb9779f
MTBWR: Mean Time Between Wire Rage
https://arstechnica.com/gadgets/2022/09/usb-c-naming-to-somehow-get-worse-with-usb4-version-2-0/
RT @kohidave: @WilliamCaryHall @JonathanMHenson @rchrdbyd @pinskinator This isn’t reflective of my l8 (she’s really cool and open) or ya’ll…
“Agile doesn’t specify exact rules to follow because you were meant to learn and improve as you went and work out the most effective way to work based on feedback. It acknowledges there are no best ways because each project is unique.” https://itnext.io/agile-projects-have-become-waterfall-projects-with-sprints-536141801856
Replying to @catehstn
Thank you for writing it. 😀
Lots on interesting findings in this paper.
https://www.usenix.org/system/files/osdi22-lou-demystifying.pdf
Replying to @mweagle
“Surprisingly, we find only less than one third (32%) of our studied failures violate relatively new semantics, while 68% of them violate old semantics.“
“But by my arithmetic, in its AWS life Ruler has been invoked on the order of 10^16 times, including lots of millions of times while you’ve been reading this.” https://www.tbray.org/ongoing/When/202x/2022/09/02/Hello-Ruler
Risk McMahon
PNW fall. Choose all:
Replying to @petrillic
Arachnotourism board is too powerful.
They’re everywhere and they are disturbingly quick.
“Among several common bug types, concurrency bugs are the most difficult to fix correctly: 39% of concurrency bug fixes are incorrect.”
https://pages.cs.wisc.edu/~laksh/research/fse11-bugs.pdf
Replying to @mweagle
“A fundamental reason for developers to make mistakes during bug fixing is that they do not know all the potential impacts of the newly fixed code...
Replying to @mweagle
If all such potential “influenced code” (either through control- or data- dependency) is clearly presented to developers, they may have better chances to detect the errors.”
Back from time in Iceland. Beautiful landscapes. Recommended if you like being outside and exploring side roads.
Replying to @nconnaughton
Yeah, the scale was overwhelming (in a good way).
RT @jeffsonstein: <sigh/>
AI *is* software. just because it will be able to write itself will not make it any the less software. just as s…
“We can extend self-awareness and critical thinking to all decisions made within an organization. We just have to consider every decision’s second-order effects.”(via @Pocket) https://pocket.co/xpwe7s
“Managers who do not work with this understanding of systems think that management is purely about doing stuff…”
(via @Pocket) https://pocket.co/xpwe72
“The more we depend on technology and push it to its limits, the more we need highly-skilled, well-trained, well-practised people to make systems resilient, acting as the last line of defence against the failures that will inevitably occur.”
http://johnrooksby.org/papers/ECCE2012_baxter_ironies.pdf
Replying to @mweagle
“The real problems only surfaced when the system failed after the developer left the company…The situation was further exacerbated by the lack of documentation, and the fact that all of the critical information needed to access the services was stored on the developer’s laptop.”
Replying to @FarrahC32 and @ASchwam
Congratulations! 🎉👏
RT @dpp: I’ve got room for 2 folks in my car going to @monktoberfest
I’ll be leaving Providence at around noon Oct 5
I can pick up from…
Howdy C++ <its::been<aminute > >
“Go’s tooling reduces noise in your results by only surfacing vulnerabilities in functions that your code is actually calling.” https://go.dev/blog/vuln
“Simplicity is often complicated...The solution for complication is simplification. The solution for complexity...is transparency. Make those couplings understandable.”
https://preaccidentpodcast.podbean.com/e/safety-moment-simplification-sounds-good-bun-not-in-a-complex-system/
“It’s a system of developing hypotheses, setting and committing to a disciplined set of outcome-based success criteria and holding yourself accountable to the results achieved to inform further bets, and decisions to pivot, preserve or stop…”
https://barryoreilly.com/explore/blog/value-engineering-for-outcome-based-bets/
Replying to @mweagle
“As the software development industry continues to mature, we now have an opportunity to leverage improved capabilities such as Continuous Design and Delivery to maximize our potential to learn quickly what works and what does not.”
https://barryoreilly.com/explore/blog/how-to-implement-hypothesis-driven-development/
This is a very clear and helpful overview of the differences between Safety-I and Safety-II.
Underpinning that distinction are Worldview-I and Worldview-II.
https://www.skybrary.aero/sites/default/files/bookshelf/2437.pdf
Replying to @mweagle
These were probably never “accurate”, but given the lower tempo and interconnectedness than today, were considered useful.
Replying to @mweagle
Worldview-I is Newtonian, decomposable, causal, predictable and binary. Things either `work` or they don’t.
“The foundation of Safety-I represents the assumptions about the nature of the world, so to speak, that are necessary and sufficient for the mechanisms to work.”
Replying to @mweagle
Since we can’t (or could never) fully describe our systems, specifying what an operator should do in *every* circumstance isn’t possible. Embrace the inherent variability and leverage/expand operator adaptability, organizational capacity.
Replying to @mweagle
Increased load and tempo jeopardizes the usefulness of those assumptions:“The bottom line of these developments is that the world as we know it…is a world where few things or issues are independent of each other… We must accept that systems today are increasingly intractable.”
Replying to @mweagle
Worldview-II is constructivist, complex systems, socio-technical.
Replying to @mweagle
Worldview-II drops the Jane Austen omniscient point of view (Work as Imagined) in favor of Work-as-Done.
“We should acknowledge that things go right because people are able to adjust their work to the conditions rather than because they work as imagined.”
Replying to @mweagle
Operators sustain and complete the system. There is no point at which the system became independent & correct, only to be (in hindsight) destabilized by “operator error”. Operator actions aren’t explanatory if they are as associated with successful/non-events as outliers.
Replying to @mweagle
I’m probably doing a disservice to this paper, but it’s Twitter and I need to eat breakfast.
On a practical level, there Safety-II makes strong arguments for I&D (more perspectives, greater capacity to handle variability) and observability (make complexity transparent).
Replying to @mweagle
Worldview-II acknowledges that operators create safety. Invest in understanding how things usually go right, to expand the capability envelope that was escaped when something went wrong: “Focusing on the lack of safety does not show us which direction to take to improve safety.”
Replying to @mweagle
My TL;DR; Safety I is Newtonian/Tayloristic. Safety II is Complex Systems/Pragmaticism.
Disclaimer: I still need to eat breakfast.
Replying to @mweagle
It also reminds me of one my favorite stories: Funes the Memorious
Replying to @turgon
Agree & I do the same. Plans are necessary, but they aren’t perfect predictions that people “fail” to execute against.
Replying to @cmeik
IME it only gets more wild. You might like these...
* https://par.nsf.gov/servlets/purl/10189069 * https://proceedings.neurips.cc/paper/2015/file/86df7dcfd896fcaf2674f757a2463eba-Paper.pdf