Paul Cantrell
I endorse this post @rubenerd:
https://bsd.network/@rubenerd/112264116393309434
…and I endorse it in its more general form: “Just don’t have that problem” is one of the most unhelpful, snitty, arrogant, obnoxious, and demoralizing things you can say to somebody who is in a place of frustration.
1/2
Paul Cantrell
This is a tricky one, because “let’s choose not to have that problem” can •also• be one of the most powerful thoughts in engineering.
For it to be so, three things are •strictly• necessary:
1. A good understanding of the problem, including the other person’s (a) goals, (b) constraints, and (c) tradeoffs.
2. An understanding of the problem’s history, including options they’ve already considered.
3. A social relationship with the other person where such advice is appropriate and welcome.
2/
Paul Cantrell
I’d also tentatively add:
4. The interpersonal understanding and communication skill to offer the advice in a way that the other person can truly hear and receive well. (Not •strictly• necessary because some people are really good at receiving ill-communicated advice, but…it sure increases the odds of success.)
3/
Paul Cantrell
I’ve had to learn all of these things through the experience, sometimes bitter experience, of screwing every one of them up. I offer the list above in the hope that it helps accelerate that learning for someone else.
People new to or entirely outside of software dev / tech / engineering look at me funny when I go on about how software is all people, but…software is all people. People all the way down.
/end
Jeremy Kahn
Someone in trouble with a challenging technical task needs
1/ the tools to change a bad situation
2/ the grit to tolerate or grind through what cannot be changed about that situation
3/ the wisdom to know the difference
a lot of techies approach less techie people assuming that they want 1/ — tools to fix it
when often they want 2/ — support in getting through a bad situation
And the techies themselves are lacking in 3/ — they often can't tell the difference
2/fin
Jeremy Kahn
I love this thread
And I want to jump off in a tangential direction, that has to do with what just today I dubbed "the Serenity Prayer for tech support"
1/2
Paul Cantrell
@trochee Well said.
Paul Cantrell
(This again: https://hachyderm.io/@inthehands/110040888687644329)
Paul Cantrell
@trochee @donaldball
See this an subsequent: https://hachyderm.io/@inthehands/111387994270423293
Jeremy Kahn
Indeed there are plenty of cases where the engineers' solution is _worse_ , because they've added a technical problem — the maintenance and configuration of a tool — to what was previously a business problem
("Now you have two problems")
Many technologies fit in this antipattern. I've seen it peak multiple times
regex 1999
XML 2003
"big data" 2007
"machine learning" 2010
"put a neural net on it" 2012
"Blockchain" 2013
"put a chatbot on it" 2016
GPTs 2022?
Donald Ball
@trochee @inthehands There's a trap I've seen very experienced engineers fall into — I've probably fallen into it myself! — whereby after mastering some morass of complexity, they — we — become endeared to the technical difficulties of the puzzle and resist efforts to reduce or eliminate the incidental complexity, or to seek out simpler solutions to the business problem.
Jeremy Kahn
So now I'm revisiting the tool improvement work, but specifically seeking insider "champions" from my less technical peers — people who (3) know the difference and can speak to the good reasons to (1) use tools.
IOW I'm no longer certain that the techies are the repository of (3)-style wisdom, and I'm going back to find my peers who _are_ more informed on that discernment
(3/fin)
Jeremy Kahn
In the last few months, I realized that some large fraction of my peers have entangled their professional identity with (2) the grit and grind, and were quietly resisting tooling improvements (!), which increased _my_ work frustration substantially ("why won't you let me help you!")
(2/3)
Jeremy Kahn
In my own professional life right now, my less-technical teammates have been given very few tools (1) and had to rely on difficult and tedious manual review (2 - grit and grind).
In my own rush to help them, I've often rushed to offer them tools to not grind so hard — pointing them to @AlSweigart's https://automatetheboringstuff.com/ , writing custom tools, etc — but without doing a very clear job of discerning (3) what _they_ felt was needed
(1 of 3ish)
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.