July 2013 Archives

When asked to fill out the 'Sex' box in web-forms I always wish for an "It's complicated" option. Because for me it is, and has been since I was 17. On the one hand, 17 years of unquestioned masculinity gives me some damned good passing privilege for "M" (and my government identity documents having the "M" box checked off makes it even better). On the other hand, socially I'm a lot more adept with women, and that's where my source of self-image is based these days. I get ma'amed by shop-staff 3 out of 4 times, so my passing privilege for "F" is good-enough.

I haven't felt strongly enough about this whole "F" thing to push me into a full transition. And really, there are three transitions:

  1. Social, which impacts anyone who interacts with me.
  2. Physical, which impacts mostly me, but also includes intimate partners and medical people.
  3. Legal, which impacts mostly me. And with recent legal changes, soon that will be 'only me'.

That's a lot of work, you see. For the longest time I figured I'd have to present further down the F spectrum than I'd rather present just to pull it off (social transition, but neither of the others). And I'm lazy. And cautious (geez, I must be a sysadmin). Can't I just kind of hang around part way somewhere?

Well, yes. These days I can. It's no longer all or nothing, more of a 'some' or 'none of the above'. This is the realm of the genderqueer, and I am one.

I've been one for years, I just haven't made it part of my public persona. Waves

How does 'genderqueer' differ from 'transgender', which I have seen used?

A tricky question, with a tricky answer. The scope of 'transgender' includes a wide variety of people. The term 'genderqueer' has a narrower scope, which is largely (though not completely) overlapping with 'transgender'. Also, genderqueer is newer, and seems to include people who:

  • Aren't transitioning to anything, they're just playing with gender presentation (social transition, sort of).
  • Are transitioning, just to something like "none of the above" (social and maybe physical transition).
  • Could transition to something widely recognizable, but not just yet (social transition to something non-binary).

As I said, tricky. For more on this, see a handy page I made.

Does this mean I should change what pronoun I use for you?

Only if you want. I'm deprecating 'he', but I haven't removed it from usage yet. But 'she' will continue to work. I promise I won't get upset for misgendering me. Really.

What about 'they'?

I tried it on, didn't like it. I'm not so much 'non-binary' as 'weirdly binary'.

Are you going to legally transition to F?

That'd be nice, but that's a lot of work. The states that even have a legislated policy to change that marker on drivers-licenses all require at least one note from a physician declaring this that and the other thing (evidence of physical transition of some kind), and several require proof of surgery (evidence of physical transition of a specific kind, not happening here). Birth-certificates are another matter, and things are usually more complicated.

The physician/surgeon requirement can be gamed, or so I've heard. Get two sympathetic surgeons to look you over, say "good enough" and sign the papers without actually rearranging bits. The state that issued my birth-certificate requires more than just attestation over the 'appropriate surgery', it defines the surgery so... may have to wait until that state joins the 21st century before trying that. It may be another decade, I'm not in a hurry.

Of course, laws may change. Some nations have a third option for gender already. Some states may move to simple personal attestation. When that happens, yay.

Also, it's not like anyone other than the TSA and emergency medical professionals really look at that marker. Getting an F means I get to have a pregnancy test before emergency medical treatment, and the nice TSA staffer checking my bording-pass won't look at me with official non-expression if my presentation doesn't match the marker.

Are you changing your name?

Nope, I'm keeping sysadmin1138.

No, your wallet name.

Oh. Um, maybe. Need to pick a name first, though. Hard to do that without something to change it to you know?

If I go there, I'll be sure to let the people who care about that know.

[Update 10/2015] Yes, I did. To something nicely ambiguous as to what my 'true' gender is.

Would this whole thing have something to do with why you're the only ServerFault moderator who doesn't have their wallet name on their profile?

Yes, yes it is. I prefer the undefined-presumed-male image on SF. Yes, I'm aware that this blog post will change that. Oh, darn.

Still not putting my name up there, though.

Does this mean you're going to start blogging about gender issues now?

I don't see blog content changing much, honestly. This is a technical blog after all, not a social-issues one. While I definitely do have opinions in that regard, I won't be sharing them here.

Did you always know about this?

Hah, no. The swift upside the head arrived when a friend was crying on my shoulder about how devastatingly gorgeous a mutual friend was and how I couldn't possibly understand how good looking he was. And I realized that, actually, I did. Um, crap.

The introspection from that event triggered the line of questions that brought me to questioning my gender identity. On reflection there were a few signs and portents before that event which should have been a clue that I had an unconventional gender, I just didn't notice.

Wait, did you just come out as gay?

No, bi. By that point I'd been leering (discretely) at girls for at least four years. Having that happen just gave me more people to have trouble talking around, damn it.

Aren't you afraid that this'll hurt your employment chances? You're kinda coming out as "weirdo", and companies don't like hiring weirdos.

The way to think of this is me applying a bozo-filter to companies I work for. Yes it will hurt my employment chances, but odds are I wouldn't like working for that kind of company anyway. Plenty of companies hire weirdos, and even advertise that fact.

More and more states are adding explicit employment protections for gender-presentation, but that really doesn't mean much in the tech-hiring market where hiring for 'cultural fit' is so endemic. And do you really want to sue your way into a job?

[Update 10/2015] Two job-hunts later, and it turns out that having highly sought after skills, and shopping for jobs in very talent-tight markets, means employers didn't even blink. Not a problem.

Does this mean you'll be in a dress for LISA?

Hah. No. Though you may see me in a kilt (A/C and weather permitting; LISA being a late Autumn convention doesn't improve your chances).

Remember that bit about me not going for a full transition because I thought I'd have to go too far towards F than I wanted to go? I still don't see myself in a dress. Just a mite too fem.

That said, if they decide to do another Formal Night, I just might reach for the other side of the closet; last year's suit was about as alien as a dress would be. We'll see.

If you have more questions relating to the transing of Gender, I wrote up a quick gender-thingies 1001 page which should help a bit.

This is a goal that many sysadmins aspire to. On a new person's first day on the job, they have a computing asset upon which they can work, and all of their accounts are accessible and configured so they can do their work. No friction start. Awesome.

How this worked at WWU when I was there:

  1. HR flagged a new employee record as Active.
  2. Nightly batch process notices the state-change for this user and kicks off a Create Accounts event.
  3. CreateAccounts kicks off system-specific account-create events, setting up group memberships based on account type (Student/Faculty/Staff).
    1. Active Directory
    2. Blackboard
    3. Banner
    4. If student: Live@EDU.
    5. Others.
  4. User shows up. Supervisor takes them to the Account Activation page.
  5. User Activates their account, setting a password and security questions.
  6. Automation propegates the password into all connected systems.
  7. User starts their day.

It worked. There was that activation step, but it was just the one, and once that was done they're all in.

This worked because the systems we were trying to connect all had either explicit single-sign-on support, or were sufficiently scriptable that we could write our own.

I'm now working for a scrappy startup that is very fond of web-applications, since it means we don't have to maintain the infrastructure ourselves. The above workflow... doesn't exist. It's not even possible. Very roughly, and with the details filed off:

  1. Invite user to join Google Apps domain.
  2. Wait for user to accept invite and log in.
  3. Send invites from 3 separate web-applications that we use daily.
  4. Wait for user to accept all the invites, create accounts, and suchlike.
  5. Add the new accounts to app-internal groups.
  6. Send invites from the 2 web-applications with short "email verification" windows when the user is in the office and can get them.
  7. Add the new accounts to other app-internal groups.

The side-effect of all of this is that the user has an account before their official start-date, they don't get all of their accounts until well after 8am, and admin users have to do things by hand. Of those 5 web-apps, only 2 of them have anything even remotely looking like an SSO hook.

There is an alternate workflow here, but it has its own problems. That workflow:

  1. Hard create the new user in Google Apps and put into in the 2-factor authentication bypass group. Write down the password assigned to the user.
  2. Login as that user to Google Apps.
  3. Invite the user to the 5 web-applications.
  4. Accept the invites and create users.
  5. Add the new account to whatever groups inside those web-apps.
  6. New user shows up.
  7. Give user the username and password set in step 1.
  8. Give user the username and password for everything created in step 4.
  9. Walk the user through installing a Password Manager in their browser of choice.
  10. Walk the user through changing their passwords on everything set in steps 1 and 4.
  11. Walk the user through setting up 2-factor.
  12. Take user out of 2-factor bypass group.

This second flow is much more acceptable to an admin since setup can be done in one sitting, and final setup can be done once the user shows up. However, it does involve written down passwords. In the case of a remote-user, it'll involve passwords passed through IM, SMS, or maybe even email

That one "Account Activation" page we had at WWU? Pipe-dream.

At some point we'll hit the inflection point between "Scrappy Startup" and "Maturing Market Leader" and the overhead of onboarding new users (and offboarding the old ones) will become onerous enough that we'll spend serious engineering resources coming up with ways to streamline the process. That may mean migrating to web-apps that have SSO hooks.

You know what would make my life a lot easier now?

If more web-apps supported either OpenID or Google Login.

It's one fewer authentication domain I have to manage, and that's always good.

Inspired from this Computerworld article on whether or not anyone in IT truly relaxes on vacation. It quotes a survey where 67% of senior IT professionals say they're expected to be available even when on vacation. As such these days, this is relevant to my interests.

Due to the loose relationship my office has with being in the office to do work, we frequently get people working full time from their Parent's house for a couple days. It's a way to make two weeks out of the office only seem like three days, and reduces the disruption because of it. Our customer-facing people follow the same habits as described in the article.

Yeah, when I'm going on vacation and I expect I'll be away from my phone for significant periods of time I am sure to mention this before I leave. I have gotten calls, urgent ones even, while on the vacation calendar. Sometimes I really am the only person who can rapidly fix a critical problem.

Not so helpful when I'm on, say, a cruise ship in the middle of the Atlantic.

Is this an expectation of availability like the article describes, or merely guilt-induced availability through office culture? In my case it's the latter; everyone is assumed to be available, unless explicitly declared otherwise. Being on the vacation calendar just means they'll allow more time between call and getting impatient with the reply.

In my defense, I figured out a while ago that the best way for me to feel like I've actually been on vacation is to actually check work email a few times while I'm out there. It stitches the radically different reality of vacation in with my normal work-a-day reality, so when I come back I don't get that "Arg, it's like I never left, I need a vacation" feeling.

My first experience with Markdown was on ServerFault, where the markup language for posting is Markdown. The SF community is kind of down on Markdown, which is plain to see by the tags on the main chat-room.


The tags have been in the same theme for a couple of years now.

And yet, Markdown is getting lots of love in non-Sysadmin spaces. Github's documentation format is Markdown. MovableType, what I use for a blog-engine, has a Markdown plugin. Heck, there is a move in the indy publishing world to only accept manuscripts in Markdown, throwing over the previous standard of MS Word.

Why is Markdown getting the love?

Markdown is a syntax for specifying text formatting using just text. It is far, far, far from the first such format to attempt this. And yet, love. My theory is that it's winning for two main reasons:

  1. The syntax doesn't bother with the shift-key as much as other formats (unlike HTML), which makes it easier to produce.
  2. The marked-up text is comprehensible all by itself to non-fluent readers (unlike LaTeX).

Why is Markdown earning the hate?

There are a couple of reasons for this.

  1. It is far, far, far from the first such format to attempt this, and reinventing the wheel just to invent something gets old. The other stuff worked just fine, by the way, we don't need yet another markup language. Oh wait.
  2. Each implementation seems to be subtly different, so you can't always be certain if one markup format will completely render through another engine.

My View

I can see why manuscripts would benefit from Markdown. It's a format that is very simple and very light in formatting (tables are deeply problematical to render, but bolding, italics, quotes, and indents need to be perfect), and the same Markdown file can be used to render the reader-copy as well as the typeset copy by adjusting the defaults for how to render paragraph breaks for instance.

Overall I think it does what it set out to do, and allow rich formatting of text using a relatively easy to access markup method. I can accomplish the same kind of thing through raw HTML, but marking up for markdown is definitely easier then that. Yes, we've had these kinds of things before, and I'll probably have to learn a new markup language in 10 years time; but that's how the tech industry works.

Confidence vs. Competence

| 1 Comment

Tech Competence: How good you actually are at whatever it is that you're doing.
Tech Confidence: How good you think you are at whatever it is that you're doing.

This post is inspired by a recent article that made a lot of very good points relating to the grass-roots of Open Source projects. As it happens, the same points also apply to closed source products (such as what I do for a living) and to the Systems Administration community as a whole.

For the tl;dr crowd, a bulleted list of key points:

  • Building a culture of elitism (also known as a robust meritocracy) means:
    • You risk not being able to replace retiring gurus with fresh ones.
    • You risk not being able to grow the community as a whole due to the barriers in place to keep out the non-elite.
    • Efforts to change up the diversity in the community will largely fail due to those same barriers.
  • Communities defined by tech competence are more often actually based around tech confidence.
    • Building barriers based on competence therefore do more harm than good in sustaining that community.
    • To grow such communities, it is far more effective to focus on building new member confidence.

For fully volunteer efforts like an Open Source project, these are very key things to keep in mind. If a project gets too cliquey it risks dying from lack of investment. Such projects live and die by their community.

For professional efforts like what I do for a living (we get paid for this so we kind of have to work together) you can get away with not doing this kind of thing, but it's still a bad idea. For one, new-hires will have to be shoe-horned in somehow and if the going gets rough they'll just jump ship to a less difficult company. As always, office culture matters quite a lot.

For outreach efforts advocating for a specific community it also matters quite a lot. For instance, LOPSA is such an advocate for the Systems Administration community as a whole and has faced significant headwinds in part from Systems Administrators generally being perceived as an elitist bunch of assholes (the dragon in the datacenter; do not poke unnecessarily, or your User Picture will be turned into smoking boots ). Changing an entire profession is a very hard problem.

Now for some specifics.

Other Blogs

My Other Stuff

Monthly Archives