Blog: July 2021

Most of these posts were originally posted somewhere else and link to the originals. While this blog is not set up for comments, the original locations generally are, and I welcome comments there. Sorry for the inconvenience.

New VP of community at Stack Exchange, prognosis unknown

Stack Exchange recently promoted someone to VP of Community, and he posted on Meta asking what to change and what is inviolate. It's too soon to tell if these are just empty words, as is the norm with Stack Exchange leaders in recent years, or if he intends to and will be allowed to work with the community. Someone pointed all this out to me, so I figured, hey, I'd log in for the first time in many months and accept his invitation (posted yesterday afternoon):


Today is Tisha b'Av, the date the ancient Jewish temple was destroyed. (I promise this is relevant.) According to our tradition, the second temple was destroyed because of baseless hatred, sinat chinam. Among all the problems of the time, one incident stood out as the precipitating event:

A wealthy man held a party and sent his servant to invite his friend Kamtza. The servant misunderstood and made the invitation to Bar Kamtza, whom the host hated. Bar Kamtza, thinking the man was offering an olive branch, attended. The host was furious and ordered him to leave. Bar Kamtza, trying to save face, repeatedly tried to make peace, offered to pay for his food, and even offered to pay for half the party. But the host expeled him in front of all his other guests, none of whom objected, setting in motion a chain of events that led to the destruction.

The host hated Bar Kamtza so much that he no longer saw him as a fellow human being deserving of basic decency and dignity. Presented with the results of a misunderstanding, the man in power escalated instead of de-escalating, harming everybody present (and, according to the account in the Talmud, the whole nation).

Philippe, your predecessors didn't destroy a whole people or a national treasure, but there has been a lot of baseless hatred and harm and pain to lots of people over the last few years. Some of that can never be repaired, but some still can be, even at this late date. What has been missing is not the ability to correct errors but the will.

What should you change as quickly as possible? This ongoing failure to make what amends and repairs can be made. It's the ethical thing to do, and -- to speak to the company's business-driven interests -- it would show the people who build Stack Overflow and the SE network that you're willing and able to correct mistakes. Everybody makes mistakes; we learn a lot about people and institutions by seeing how they handle their effects. Yes you have the power of the wealthy party host, but is that the kind of person you want to be?

What should you never touch? The community's goodwill. You have the potential for awesome partners in growth, people who still want to see Stack Overflow succeed despite it all, people who know a lot about how to do that on the community side. You've got lots of professional experience but you're new to SE and SE jettisoned decades of its CM expertise in January 2020. The previous people at upper levels not only didn't engage with the communities but shunned them. By coming to Meta and starting this conversation you've taken an important step. Keep that up and follow through: engage with the community, participate on some of the 170 communities, ask for feedback regularly, carefully listen to feedback (which is not the same as "do what we say"), don't spring disruptive changes on people -- treat the community as partners not enemies.

(I realize much of the previous paragraph belongs in the "what should I change" paragraph, because what needs to change is the corporate attitude, but the reason it needs to change is that somehow you still have a community here that cares, and you should work hard to maintain a good relationship with it.)


I was asked in a comment some time later if anybody from the company had contacted me. On 2021-09-27 I updated the post to say that I have not been contacted.

Considerations in remodeling

When choosing a floor tile, it's important to consider contrasts with key components:

light floor, dark cat

Hiring dark pattern

We're hiring, so I've had recent occasion to see a hiring "dark pattern". I don't know how widespread this is outside of the tech industry, but I see it a lot in tech and it needs to stop.

The pattern: asking for "number of years of experience in (insert tool, language, or skill here)".

Jobs are multi-faceted. I'm seeing people who don't know how to choose a number, and just as I see the ones that overshot, I know there must be ones who undershot and were filtered out. I saw a resume recently from someone with a broad role, who listed "N years experience" in something where N was the length of the job, even though the job involved many other things and wasn't primarily about that skill. That's "N years of experience" in the same way that I have "20 years of Java experience". Spoiler alert: I don't.

Recruiters and hiring managers put people in this position: we have this checklist, tell us how many years of each, and we need a number not an explanation. Maybe we're making you fill out a web form and you can't even add a comment or ask questions. In the absence of guidance about primary and secondary skills, people will apply different weighting factors. It's a mess.

I often don't know how to answer either. In the last four years I've gained four years of tech-writing experience, the focus of my job, and four years of git experience, meaning I have all the basics and can untangle a merge conflict (but I've never rebased successfully). Those "four"s don't mean the same thing; I don't spend all day using git. Tech writing is fundamental to my role and I'd have no qualms about fully claiming those four years, but for git I would want to say that I've used it as part of my job for four years. That's different. I don't have the same knowledge that an infrastructure person whose job revolves around maintaining git servers and stuff for the same amount of time has. "How many years of experience?" questions don't allow for that nuance.

People who are trying to be thoughtful and honest run the risk of getting filtered out, and people who count "everything" get filtered in. I wonder how the success rate (meaning "acceptable hire", since you'll never know if you got the "best hire") of this exercise compares to recruiters just not filtering on skill-specific numbers at all (just general experience) and having the hiring team evaluate more people. I'm fortunate enough to be sufficiently "long in the tooth" that I don't need to worry about this gatekeeping -- either you're looking for a top-notch tech writer with all that implies, or you aren't -- but this hurts early-career people where the difference between "2" and "4" can make or break a deal.

As for the Java: I spent years documenting and helping to design Java APIs, wrote some examples, but haven't written anything deep and complicated. Someone with a year or two of full-time actual Java development experience beats me. Would the recruiter be able to tell?


The source post on Dreamwidth has a number of thoughtful comments.