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/
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/
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/
The best software tester I’ve ever known 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/
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 an extroverted social butterfly.
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 chaotic, or or or…and make great software.
5/
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
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.
[Edit: switched to screenshot of post]
It's the only way!
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.
Yeah, he didn't mince words. Brilliant painter. Awesome instructor. Later, I'd come to find out awesome boss. He just happens to be one of those people that really should have come with documentation. A quick start guide, at the very least. LOL
Invariably, by the second or third meeting, only one or two of the truly interested students who weren't in our program would remain.
@helplessduck @Gaolaitch @inthehands It's the same way in music, too. The music may be gorgeous, and it might be satisfying, invigorating, absolutely wonderful to play, but when I perform in front of others, I'm hoping that I can add what they need to their lives 
Some people need encouragement. Others need invigoration, while yet others need soothing. I've had the pleasure of making people dance, making them cry, and rarely, sooth the broken-hearted 
At the end of the day, all of our thousands of hours of practice are in the hope that, in those key moments when a person truly needs our music, we'll be skilled enough to share it with them in the way they need it 
@OctaviaConAmore @helplessduck @Gaolaitch This musician agrees. You can’t always meet people where they’re at, but you do have to reach toward them. Much the same with teaching as well.
I’m also a big defender of making music for one’s own self, and not feeling like it doesn’t matter or doesn’t count because it’s a private pursuit, a secret garden. Meeting people where they’re at includes one’s self.
@inthehands @OctaviaConAmore @helplessduck I have serious amounts of baggage in this area. My training toxified the idea of audience by demanding that I aim for perfection, and so imagine the listener as a critic with the perfect ear who will know if I fall short of perfect. I’ve spent many years trying to disempower my hyper-criticism; it’s only lately that I find I can play to a real audience, whose opinions I believe and trust. Rather than failing at the impossible, again.
Imagining a real human being as my ideal audience sort of crowds out the hyper-critical one, I find. Or at least gives me an alternative to play to. Little steps.
@Gaolaitch @OctaviaConAmore @helplessduck So sorry you went through that ordeal!
Cello is wonderful. Piano’s my thing, but I were going to seriously learn a second instrument, cello would be it.
@jagthedrummer @Gaolaitch @inthehands @OctaviaConAmore
And they science and the arts are two opposite worlds!!!
BAHH! Charlatans! 😂
>> All software involves interacting with other people.
ah, so that’s why I can’t do it. makes sense now. ty
@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.
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.
I make a point to avoid being short with others, even when annoyed, for this reason.
If you can't receive information that upsets you without making people uncomfortable, people will simply not share information to avoid the negative reaction.
I see a lot of parents who make this mistake.
For sure.
All communication is relative to a myriad of factors like context, preferences, and social norms.
There are things that you'd feel comfortable saying to your friends that you'd worry about saying to a colleague because you don't know how it would be received.
Not to mention people have different tastes. One man's dickhead is another man's frank.
@raven667 @inthehands Definitely. It's certainly not limited to just software people.
Makes me wonder if there is any relationship between self-perceived aptitude in a given field and proclivity towards hostile responses to people. I don't know how you could measure this and control for cultural norms, but I'd imagine that people who feel like they're exceptionally good at their job are more willing to be a dick because they know they aren't risking job security.
@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
Attached: 1 image Fascinating to look at those deep causes the students identified in the Atari story (look at the far left of the diagram), and compare those to the situation unfolding at Musks’s Twitter:
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.
@inthehands I fought so many times against the "user is stupid" narrative. Every bug report tells a story. Every misunderstanding can inform design. Every "PEBKAC" contains valuable data.
A team might choose not to change something in response, but blaming a user for _being_ _a_ _user_ is paradoxical.
@NegativeK Yeah, the “user is stupid” thing is funny for 30 seconds and then deadly for a project lifetime.
I mean, to be fair, users •are• stupid, because they are humans — but my dear fellow devs, I have some bad news about the people creating the software….
@inthehands Agreed, but I'd add a corollary: If you're not good at the social stuff, then bone up on professional standards instead.
Even if you have trouble creating human connections, behaving professionally simulates it well enough to get the job done right and become an indispensable part of a team.
@inthehands That's not "being social" though.
I'm intensely *anti*social. I'm also not a dickhead (I hope). This isn't "being social" it's "not being a dickhead". There's a /huge/ difference.
@inthehands solo development is a niche though. you don’t necessarily need to get employed by a company nor collaborate with other people to do software development. there are plenty of popular software projects that are written by a single developer
there are some situations where you might need to interact with other humans, but many of them are possible to outsource
> "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 @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.
When I was an international troubleshooter I had a similar experience. The vast majority of issues were at the interface between responsibilities. These were smart people, but DB, OS, application and network people tend to live in their own delineated world.
Only in the limit, in that a software package used by zero customers and developed by zero developers has no meaningful bugs
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
Daniel Haran
Marco Rogers
the roamer
helplessduck
Octavia Con Amore 
Succubard's Library
Jody Hughes
Jeremy Green
Idris Elbow Macaroni
Jim Spath
Sam Lehman 
Raven667
canteen
Negative Kelvin
Louis Ingenthron
Frost, wolf of winter 🐺🎄
LambdaDuck
Marc Trius
Cassidy Curtis
Steveg58
David Penfold 
Aaron Turner
Matt Campbell
Jeremy Kahn
RealFinoxy
Christopher E. Stith
BakersRelay
Toni Erdmann