Paul Cantrell
Re this important thread from @grimalkina:
https://mastodon.social/@grimalkina/111972810596703896
I just gave a little soapbox to my Software Design and Development students that I give every time I teach the class, and I’ll give it here on Mastodon.
Software development is an intensely social discipline.
1/
Paul Cantrell
@grimalkina Software is made by humans for humans.
Most software is made by teams. All software involves interacting with other people. When you use a tool, a programming language, you’re interacting with the people who made it; when people use your software, they’re interacting with you. When software works or doesn’t work, that’s the decisions of others, the work of others that you’re experiencing. It’s people all the way down.
2/
Paul Cantrell
Most software is made by teams, and software development is an •intensely• social activity. Software projects stand and fall on the relationships between the humans who create it: whether they understand each other, whether they collaborate well, how they make each other feel.
Computers don’t fill in the gaps and misunderstandings for us with common sense; when we don’t understand each other, we •codify• that misunderstanding in our code, fix it in place and turn it loose.
3/
Paul Cantrell
The best software tester I’ve ever know once said to me, “Whenever I start at a new place, I find out which teams hate each other. Where their systems interface with each other is the first place I look for bugs — because they’re not talking to each other.”
Software projects stand and fall on the relationships between the humans who create them. (A corollary to Conway’s Law.)
4/
Paul Cantrell
Now please don’t misunderstand me (and here imagine me looking earnestly to the students): when I say it’s “intensely social,” I don’t mean that you have to be a social butterfly to write software.
You can be the world’s biggest introvert and make great software.
You can be socially clumsy (I am!) and make great software.
You can be autistic and make great software.
You can be chatty and charming, or silly, or dry and serious, or linear, or or or…and make great software.
5/
Paul Cantrell
What you can’t be is misanthropic. When you write software, you are in relationship with other people. And if you don’t care about people, if you just •hate• people, if you can’t care about healthy relationships, if you cannot be bothered to communicate or to listen or to just give a ground-level shit about other people, DO NOT get into software. You’ll crash and burn — and you’ll cause terrible harm as you go down. Find some other discipline to go torment.
The rest of you…come on in.
/end
Yeshaya Lazarevich
@inthehands
I just want to say—this person sounds amazing to work with. I always say, a good relationship with the testers is my best asset as a developer
Paul Cantrell
@alter_kaker It’s so true. I actually have my classes practice saying out loud, “Nice bug! Thanks!”
Paul Cantrell
@helplessduck
Sean sounds like a real one.
helplessduck
I had a professor/mentor in college that frequently gave a speech pretty similar to this, but for art:
- It's about two way communication with another human,
- Tools (brushes, pencils &c.) and media are the paths to this connection,
- Art for art sake is bullshit, enrich your life and the life of the consumer,
- Otherwise, you will be very bad at this and,
- If you're in this class to become a rich and famous artist get the fuck out.
Surly old Irish man. I loved Sean.
Paul Cantrell
You know, if I say “be decent to other people and try to understand them” and your response is basically “bureaucracy stifles innovation,” I really don’t know what to tell you.
https://fedi.keinpfusch.net/objects/1d3d44ad-0070-43ca-abec-2d8b6bd253b3
Paul Cantrell
@mrcompletely @Wikisteff I love the word “reify,” and wish it has a less jargon-y taste so that I could use it in more casual conversation. It’s a great idea.
Alberto Brandolini has a remark I love: It’s developer (mis)understanding, not the experts’ knowledge, that’s released in production.
Mr. Completely
@Wikisteff @inthehands I say that too (really! It's nice to see the same thought out in the wild) and usually the response is "is reify a real word?" (yes, it's the essence of software)
Steffen Christensen
@inthehands I sometimes say that software reifies particular ideas into code, because in code, it's a real measurable thing in the world, whereas before code, it was an idea that floated in the use and communication of the concept between people and their society.
Paul Cantrell
@Steveg58 @raven667 Rigid specifications, blocked communication, and CYA-first thinking all go hand in hand. It’s a tough hole for an org to crawl out of.
At best, a spec is a tool of communication, a light to shine misunderstandings and hidden assumptions into sharp relief. At worst, it’s a legal prop.
Steveg58
@raven667 @inthehands
The downstream contractor was raising the faults. The policy of Big Mining Company was that subcontractors should never be allowed to talk to each other and preferably never even know of each others existence.
The behaviour in question was our system responding to an error condition and that did not happen frequently. We repeatedly told them it was expected behaviour but the other subcontractor wanted a lot of money to re-write sections of their system. We tried to put mitigation in place but without knowing why it was a problem we were a bit hamstrung.
Raven667
> "It took a couple of years of to-ing and fro-ing before they called a formal fault resolution meeting and the existence of the unsupported interface specification came to light."
_Years?_ ... UuuuughhhaaaaAAAAARRRRGG!!!....<screaming continues silently>
Steveg58
@inthehands
Yeah ... and that is why Traditional Configuration Management has Interface Control Working Groups so that someone can make sure they talk and crack some heads together if they don't play nicely.
The worst SNAFU I saw was when our customer (a very big mining firm) wrote their own description of the interface to our software and consulted neither the software documentation or ourselves and gave it to another contractor to build a big downstream system. A year or so later our system did something that is completely acceptable but wasn't in their specification and they tried to raise a defect notice against us. It took a couple of years of to-ing and fro-ing before they called a formal fault resolution meeting and the existence of the unsupported interface specification came to light.
Paul Cantrell
@raven667 @Lehmanator There’s also a lot of nuance to dickheadedness. It’s a weird thing to say, but it’s true. Some people are brusque but also caring; others are socially appropriate but socially toxic. Layers and layers.
Sam Lehman :nixos:
@inthehands This thread contains a lot of wisdom, especially the bit about looking for friction between teams.
Effective communication is hard, but so so so important. Failures can manifest in subtle ways & often compound.
It's easy to conceptualize the immediate effects of your speech, but much harder to understand the emergent effects brought about by communication patterns.
Sam Lehman :nixos:
Software types put way too much respect on the "super technically competent dickhead" archetype.
Yeah, they might be a beast at stomping out bugs or churning out features, but how many bugs were missed or features poorly written because no one wants to ask this guy questions. If no one wants to talk to you, your effectiveness is limited to your individual capabilities, whereas better communicators multiply their expertise, even if their individual capacity is less.
Raven667
@Lehmanator @inthehands this may be more or less true in different cultures depending on what values parents reinforce in their children and what children pick up from the media, but it is definitely something seen in the US not only with tech bros and nerds but with doctors/surgeons, actors/musicians/artists, sports players/coaches, politicians, etc. You might find example in those fields who _you_ find distasteful for their dickheadedness, but they _are_ famous so plenty of others adore them
Paul Cantrell
@Lehmanator I do an exercise in one of my classes where we spend an hour looking at why Atari failed.
Note “mythology of developer as wizard” showing up deep in the causal chain:
https://hachyderm.io/@inthehands/109378162951221547
Paul Cantrell
@RealFinoxy The trick is that strict definition doesn’t do a damned thing if it doesn’t function as a nexus for communication. It can be a way of throwing things over the wall, a CYA “don’t blame me” tool. But when done well, it can be a thing that exposes hidden assumptions and misunderstandings before they become crises.
RealFinoxy
@inthehands I completely agree your view. I feel it very strange not defining interface data strict way.
#MDR #interface
Paul Cantrell
@pygoscelis_papua Replaced the link with a screenshot in case you’re curious.
pygoscelis_papua
@inthehands I can't load the post, but I can guess I'm not missing out.
Paul Cantrell
@forthy42 Agreed, but I’ll just speak for my own discipline. Maybe there’s a special place in this world for assholes too?
Bernd Paysan R.I.P Natenom 🕯️
@inthehands I'm not convinced that this kind of people can do a good job anywhere else, either.
Paul Cantrell
@Liophora Yup. A hotshot coder who can’t communicate is just a tech debt factory: didn’t do what stakeholders really wanted, and now nobody can modify or maintain it.
Liophora 🐀🏳️⚧️ θ∆
@inthehands this all fits very nicely in with my firm belief that the most important skill that should make a developer more senior than another is their ability to share knowledge effectively and frequently :)
If you can clearly and simply explain complex things at a high level to execs as well as help other devs understand the little details, and actively try to find ways to share things you learn and better ways of doing stuff with other people as part of your regular work, you're far more valuable imo than a hotshot coder
Paul Cantrell
@Lehmanator
If nothing else, it’s a fantastic episode of a fantastic show.
Sam Lehman :nixos:
Sounds like a thought-provoking lesson!
I like to think I'm a *good* communicator, but this discussion thread makes me suspect there are things I fail to consider that might sabotage my intentions.
I'll give that podcast ep a listen.
ZanaGB
@inthehands Sometimes, even if you want to do your best, you're dictated to do things a certain will by the higher ups, against your will. Ending in things like never ending bugs, development being 26 months ahead of production with no deployment on sight, competing efforts from external teams for features planned if the developers WERE ALLOWED TO HAVE TIME not to chase the whims of the higher ups, etc...
Your hands are tied and even if you know better, you just can't act on it.
Paul Cantrell
@zanagb
It’s true. Good communication and positive social relationships are not just a product of individuals; they are a product of whole systems, whole organizations.
Paul Cantrell
@ni_nad Indeed! One of my Paulisms is that a bug is a mismatch between expectation and actual behavior, and there are thus no bugs unless there are expectations.
(Among other things, this helps explain why unchanged code can acquire new bugs, why “bit rot” is real: even if code doesn’t change, context does.)
Ninad Pundalik
@inthehands when I wrote up an internal note at work about troubleshooting bugs a while ago, I described it as the ability to reason about what the author of the code intended vs what the code written actually does. Your thread makes me realise that intent cannot be guessed without understanding people!
Paul Cantrell
@DenialShown @grimalkina I think it’s something all of us who’ve been around the software project block are itching to share.
Denial 🐔 Shown
We're having something like this conversation tomorrow in csci 5030 principles of software development as we dive into the final day of "storming: who" and talk about collaboration. To be fair, though,this is a recurring theme in the class. Actually, this is a drum i beat constantly to all my students in all my classes.
Paul Cantrell
Dammit, I can’t take it anymore, I’m fixing the typo in the 4th post even if everyone does get notified
Paul Cantrell
@polotek
Thanks, and much respect to a fellow Noticer.
Marco Rogers
@inthehands I just want you to know that I did notice the edit. I did go find out what changed. It was a little tedious. But also I'm completely fine with it. It's okay to fix nagging things.
Paul Cantrell
@ToniE Yeah, remembering a bit harder, I think his original statement was actually “which teams don’t get along,” which is less eye-catching but encompasses a bit more, disconnection as well as dislike.
Toni Erdmann
So true but not only if they hate each other.
Also true if you separate them geographically.
Do not underestimate the value of a coffee-corner/kitchen with free and good coffee/tea.
Paul Cantrell
@cestith Well, glad it hits home, and sorry for the chaff I normally dump out!
Christopher E. Stith
@inthehands in case you ever wonder, this thread is why I'm following you.
Antiqueight
@inthehands that is genius
Ben Ford :grinchsmile:
@inthehands I find that this is true with community engagement too. Some of our biggest and dumbest bugs got released when we didn’t take user advice first.
Paul Cantrell
@jevidl @pfriedma
Indeed, very much so. All human system are systems of care (or non-care).
JevidL
@inthehands @pfriedma It seems obvious, but do you think it’s fair to say business processes are the same?
I think this probably applies to most any system in which you have two people involved.
Paul Cantrell
@SmartmanApps
Who knows! It’s entirely plausible.
💡𝚂𝗆𝖺𝗋𝗍𝗆𝖺𝗇 𝙰𝗉𝗉𝗌📱
@inthehands
So does this explain the failure of that NASA mission where one team was using Imperial and the rest were using Metric? 😂
Esteban Borai
@inthehands @grimalkina Very interesting!
Paul Cantrell
@estebanborai
Always happy when people know about Conway’s Law.
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.