The Honest Troubleshooting Code of Conduct

I think every organization above a certain size necessarily ends up with informal (or sometimes formal) groups of "adults in the room" that handle important things in good faith, as a coordinated team. It's inherently discriminatory against a certain type of employee (one who would rather metagame the organization itself rather than address the market/customers/ops) but quite necessary.

I have been fortunate enough to land in a part of my employer's technical culture governed -- roughly -- by this sort of idea, albeit not one that's written down anywhere. The people in the Slack channels (IRC, back in the day, but time marches on...) that I frequent are the ones who provide some of the backchannel cross-team communication and technical analysis that make our company work.

I like this article a lot; if I were trying to replicate the community I've got now, I'd probably start with this.

One real issue here is Slack being used for a RFC rather than something like a github issue.

Slack is a great medium for realtime chatting but someone jumping into a conversation without context is exactly where it falls down. "Ubuntu is doomed" is exactly the sort of comment someone skimming to catch up will fixate on and jump to a conclusion - even with a code of conduct...

You need a place for conversations to exist that promotes asynchronous communication. A github issue is a nice starting point since someone can create a summary at the top. The summary can be continuously updated. And an intentionally slower/more thought out discussion can follow.

"RFC: Company$ moving away from ubuntu" is exactly the sort of productive GH issue I've seen at past companies.

Of course GH issues regularly devolve - lots of examples dropped into HN over the years where people get angry/inappropriate at some poor open source maintainer, but it is still an improvement over slack.

I obviously don't know all the details here, as this is, by definition, just one person's version of events. That said, I'm always highly skeptical of any account that essentially paints many/most others in the org as the source of the dysfunction, and if only they implemented my brilliant idea would things get fixed.

All large organizations have varying degrees of dysfunction, some more than others. Sometimes that dysfunction is toxic, but other times it's just a result of people being human with different opinions of how best to do things. Coming in to a new organization and making an announcement that is some version of "you're doing it wrong", unless you're very high up in the org, is rarely successful.

Most of us in software engineering have, at some point, encountered someone who does not see a difference between technical criticisms of a system and personal attacks on its designers and authors. This is an understandable error in a junior engineer, an irritating bad habit in a mid-tier engineer, and a problem in a senior person. In all cases, the answer often winds up being finding a way around them, much as this describes.

I've been places where such people have found their way to technical leadership. Finding ways to improve things can rapidly become exceptionally difficult.

At this point my only way forward is to have a personal blocklist of people whose technical leadership decisions I refuse to ever be subject to again. It's a shame, because some of them are also brilliant engineers.

i kind of agree with much of this stuff, but:

* i saw in one project shitting only on commits of a certain person, only on a technical basis, even if other commits were worse. i know this because of a real crappy testcommit i did. i did not get the shit the other person got.

* i still think, some swearings even for code are over the line, like linus torvalds retroactive abort of code, for example. We code and build things. many people poor their soul into this. and then other people come around and shit on it.

* people who shit are often very agressive and competent people. so less competent people may on the receiving end quite a bit, for example the guys who built the ubuntu base in that example. is their work doomed or shit? does this mean that they did not work well? are they bad workers or do generate bad results? should they be fired because their workresults do not perform well? can that be a general rule? and this line is not cut through by on-subject-shitters because "be an adult". and this in turn might create toxic culture. just as well as the toxic positivity which only comes more often because it's better understandable by non-it-guys from HR.

but i admit, at least it's another approach. we need more approaches and studies about them.

Im not sure but i think the only place to have that "we're here to work, not play soap opera at work" environment may be open warfare.

I like that, but it probably won't work, as the people that jump in, out of context, are the same ones that scroll to the bottom of the Ts&Cs, and bang on "ACCEPT." That's OK. I've learned the benefit of building a community by example, as opposed to fiat. The people that follow it will be the ones that don't need to read it, and they will provide the example.

I'm an "older" engineer (just turned 59. I really don't give a damn what people think of it. That's one of the benefits of being my age). I have about 40 years of experience in tech; the vast majority, writing software. Sometimes, quite badly.

Also, almost my entire career has been in "shipping" software; not just "writing" it. This has meant that I've always been pretty damn close to the end-user; sometimes, to the point of receiving personal...erm...feedback. Let's call it "feedback." I've also been responsible for delivering complete product, with polish and support. It wasn't "someone else's job" to clean things up. It was my job (it still is -even more so, these days).

I've watched (and caused) some real Jurassic-scale disasters, over the years.

That's one of the reasons I write damn good software, these days. Nothing like being given a bag and a stick, and told to clean up the mess (even if it was someone else's mess), to teach humility and caution.

So, that means that I'm often the guy that says things like "Are you sure you want to do that? I did it once, and it did not end well."

In today's "cargo" culture, that's considered "being negative," or "being timid, and only the bold survive," etc. ad nauseam.

I'm told that I'm "not a team player," or that I'm "harshing the vibe" (I actually made up the second one, but you get the picture).

This is funny, because my entire life has been ferociously dedicated to making difficult things happen. Precisely the opposite of being "too cautious to leave the starting gate." I've always been about "That's a difficult thing, and here are some of the things that might go wrong, along with a bunch we can't foresee. Let's figure out how to do it, anyway. We just need to be careful and circumspect."

That's pretty typical with experienced folks in any profession; not just tech. We often have a lot of callous and scar tissue.

Yes, we can be so timid, that we are too gun-shy to try difficult things, but we are also fairly likely to actually make it happen, if we take on the job.

For myself, I tend to look for "dreamers," who have ideas, and then help them to actually realize their dreams, as opposed to some of these Krakatoa-level explosions that we see happen, because the execution of a perfectly good idea was flawed and ill-considered.

That's what "engineering" is to me.