Bad Software Advice: Three Interesting Links #5
On building software that survives
I see a similar dichotomy with software projects. Certain technology decisions lead to projects that are warm-blooded: everything is great when there’s constant motion on the project, generating heat. But put warm-blooded software in the freezer, and you’ll pull out a corpse six months later.
This article is easy to poke holes into, but it is a useful metaphor. It makes you think about software that can ship with its dependencies and the power of choosing boring things that you think will be around years from now.
Deanna and Deepak are basically in agreement with Oscar: there’s no evidence of a system health issue. To them, and to Oscar, it’s not really clear how strong a signal Sylvain has. It could just be a coincidence that these three reports all arrived in a row. The engineers on the call are thinking, I guess we’ll keep poking at this, but we’re not even sure this is a real issue. We need more information.
Great analysis with examples that feel very real. There are many things unsaid in an incident call. Driving to precise details is great advice, as is his advice on debugging as a team and finding and keeping common ground.
Never attempt to attack theoretical work as not considering constants, as unrelated to real computer systems, or as requiring too much sophisticated mathematics. (The intended victim is likely to smile and thank you for the flattery.)
I’m no academic, but enjoyed it greatly: How To Criticize Computer Scientists or Avoiding Ineffective Deprecation And Making Insults More Pointed
I have been watching a show called The Physical 100, which is a sort of much kinder-spirited Korean American Gladiators. Incredibly strong people compete in events to see who has the “best physique”. I’ve noticed that most of the events don’t come down to who is stronger, but down to who can last the longest, and who makes the fewest mistakes. For example, the penultimate challenge was essentially won by those who never tripped and who put the ropes where they were supposed to every time.
The competitors that avoided blundering won. Experience is specific know-how, and knowing how to stay calm, but it also sometimes just knowing what not to do.
Unsolicited Book Recommendation
I have been debugging myself recently1 and found some interesting resources from the technology space:
Unlocking Leadership Mindtraps: How to Thrive in Complexity
I have mentioned this book before when discussing The Danger of Ego. This entire book is a deep dive into 4 leadership anti-patterns that all center around YOU. What you want to do rather than what you should do and what your ego drives you to do are wrong. General lessons abound.
Reboot: Leadership and the Art of Growing Up
This book introduced me to the terms Shadow and The Irrational Other, which have led to some real self-insights.
The Shadow is all the things you have been talked out of or avoided because you needed to survive childhood:
The shadow is everything about ourselves that we do not know or refuse to know, both dark and light. It is the sum total of the positive and negative traits, feelings, beliefs, and potentials we refuse to identify as our own. The shadow is that part of us that is incompatible with who we think we are or are supposed to be.
The Irrational Other is essentially people who drive you crazy, either because they are just like you (and expose your faults) or do the things you think you can’t do (and make you feel insecure). They bother you because they expose your shadow.
we all have a choice in the experience of the Other. We can remain stuck. Or we can allow the Irrational Other to provoke us, to wake us up to the repetition of painful habits and-with love and understanding for ourselves and an embrace of the ghosts in the machine-we can move past any fear or shame and take a step on the path of awakening.
Apart from personal value, these two books provide solid advice about working on yourself and your character to improve your leadership. Building software is about technology, but it turns out it is used by and built for people, and debugging and learning about them provides a great return on investment.
This is code for therapy; it’s like a long-term code review of yourself and your dependencies.