How you speak reflects how you think

My good friend Audra pointed me to this list of “20 programming jargons” that is just full of awfulness. First of all—and this is the easy, facile complaint—I’ve never heard any of these terms (at least, with these definitions) used in the wild. Maybe it’s because I’ve generally worked for reasonably grown-up companies where we attempted to act like professionals, but who can say? I don’t quite know why these terms are so foreign to me, but some of them are just bad.

First, the good… or, at least, neutral:

Baklava/Lasagne Code

Okay, this one’s actually kind of good. Lasagne code evokes a particular variety of spaghetti code that got that way by adhering a little too closely to old “enterprise” techniques of organising class responsibilities, and by applying code patterns for the sake of applying code patterns. I’m hesitant to use baklava to describe this phenomenon because (a) baklava’s delicious, (b) there’s too good of a parallel to spaghetti code with lasagne, and (c) it feels like it’s making fun of Muslims, and I just don’t go in for that.

Banana Banana Banana

I’ve never heard of this, that I can recall. As an actor, I’m definitely familiar with rhubarb rhubarb rhubarb, the chorus equivalent of making it look like you’re having a conversation onstage without actually saying anything particularly coherent, that would pull focus.

Claustrocodeia

Can’t say I’m familiar with this term. Granted, I don’t like moving away from my nice 24” screen at the office, and working on my laptop screen, but it’s not like it’s anything more than a minor inconvenience. Get over it. Or buy yourself a big screen and expense it.

Stringly Typed

Again, this one’s pretty good. I’ve seen code like this, and it’s always much more of a headache than it could possibly be worth.

There’s Already A Word For This

Bugfoot

Over here, where the professionals work, we call this an “intermittent bug”. Could be environmental, could be infrastructure, could be code. But while we can’t replicate it, we don’t want to dismiss it out-of-hand, because this also means we can’t gauge its impact on the end user.

Jenga Code

Also known as “tightly coupled”. If you don’t already know this, or for some reason refuse to use this industry standard terminology, I frankly worry for the quality of your code.

Shrug Report

The bug report with insufficient detail. This is just a bad bug report, and should get sent back to the reporter for more details.

Unicorny

Otherwise known as “the business’s problem”. Unless you’re being called in to provide swag work estimates. I’ve also heard this as a “future project”.

Your Professionalism Is Showing

Counterbug

Code review isn’t supposed to be an adversarial process. When another programmer is reviewing your code, this is supposed to be about everyone’s professional development. Your reviewer may learn techniques they weren’t previously familiar with, and will gain exposure to more areas of the codebase, and that’s always a good thing. And by the same token, you’ll have the opportunity to learn techniques you weren’t previously familiar with, because your reviewed may be able to suggest a better (or even just different) way of solving the problem at hand. By saying, “yeah, well, you did this wrong”, you aren’t helping anyone (beyond exposing additional bugs to be fixed).

That said, getting used to code review as a collaborative process, and no longer hearing their comments as a personal attack, takes a conscious effort at first. But it’s effort that’s worth it. So when a reviewer points out an error, you should first bite your tongue, then think about what you can do better the next time around.

Duck

The business is not your enemy. Distracting their attention away from one particular area of the software is staggeringly unprofessional. It suggests that either you didn’t do your job properly there, or you think you know better what the business, or customer, wants. You might. You probably don’t; the business holds all the cards, and knows things they haven’t bothered to tell you, because they didn’t consider it germane to the feature request. If you have an issue with their ideas, the best thing to do is to take it up with them. In the event that they didn’t consider your alternative approach, then you might get them to reconsider their approach, and create an ultimately better product.

Refactoring

There’s a great maxim about how to write software: write code as though the next maintainer is an axe-wielding psychopath who knows where you live. Vivid, I know, and pretty violent, but I think it kind of gets the point across. Another, less aggressive version, describes the next maintainer as someone less capable than you with no context. If you’re writing code, or refactoring, and you don’t leave it in such a state that any developer could read it and know immediately what it does, you’re doing it wrong.

I know, I know; I’ve written before about self-documenting code being a lie. That doesn’t mean your code should be incomprehensible; it’s about not eschewing documenting your classes at a high level, simply because another developer need only read the code to understand it. Being a nice person to the next person is what self-documenting code is supposed to be about.

Smug Report

I’ll be the first to admit that I’m guilty of having this reaction to an external bug report that suggests that the reporter knows more about what’s going on than the developer. I’ll also cop to the reality that I’ve probably filed a few of these bug reports, as well. However, instead of going into adversarial mode, or trying to belittle the reporter, acknowledge something: you probably have a particularly technically competent reporter on your hands. If they’re outside your organisation, then you basically have someone who will do free testing for you! Make use of this reality, because you have someone on your level, who you probably wouldn’t have to work very hard to convince to do black-box testing. These reporters are gifts in human form.

Unfortunately, there are some that betray an awful interpersonal culture. Presented in no particular order, and certainly not the original order:

Being A Good Person: You’re Doing It Wrong

Jimmy

This, frankly, reads more like an in-joke at one particular organisation. Probably Jimmy was a wet-behind-the-ears recent graduate who managed to get past the interview, only to flail wildly until he was put out of the rest of the team’s misery. It happens sometimes. It’s unfortunate for Jimmy that no one on his team was willing to mentor him into a good programmer, but if the rest of the list was written at the same company, there probably weren’t many qualified candidates.

Not to say that professionals don’t turn colleagues’ names into in-jokes. Never mind that at the foosball table, I can think of at least four developers whose names are used to describe particular moves, one of our developers was, due to a fluke of seating assignments, regularly forgotten to be pulled into impromptu meetings. He’s now a verb, used when something (or, more typically, someone) is carelessly forgotten. However, this is done (a) in jest, and (b) is aimed squarely at the forgetter, not the forgettee. Poor guy just got it named after him after we did it so often that we started using his name as a shorthand for “we forgot him!’

So why is it unfair to call the clueless newbie a Jimmy? Because it pokes fun at the clueless newbie for being just that. Instead of mocking the new kid, they should be welcomed with open arms and guided into being a better developer.

Chug/Drug Report

Yes, suggest that the bug reporter was, at best, in an altered mental state when they wrote the report. This seems fair. Or, you could be working with a language barrier. Perhaps two, depending on when you, as the reader of the bug report, learned the language it’s written in. Assume that the reporter did their best to convey what they encountered, and give them the benefit of the doubt.

Mad Girlfriend Bug

First of all, this kind of bug is pretty much any bug that isn’t completely straightforward. Second of all, this is an idiotic gender stereotype. If you aren’t willing to try to communicate with your signficant other when you’re having an argument, your miserable relationship is your own problem. Finally, reinforcing idiotic gender stereotypes in the workplace is just one of the reasons that the gender balance both in the workforce and in school is so completely out to lunch. It’s one of the reasons that twice as many women as men exit programming as a profession. It creates a hostile work environment for your peers. Don’t do this.

Barack Obama

This one feels vaguely racist, and the fact that it’s the editors’s favourite, of everything on the list, gives a certain amount of credence to my worry in this regard. I want this to be a joke about Healthcare.gov, or about how a lot of liberal people had a lot of hope which has been repeatedly dashed, but the bit about “which would not otherwise get approval” bears a pretty strong suggestion that African Americans only voted for Obama because of the colour of his skin… and that just a reference of questionable future usefulness into a racist joke.

Ghetto Code

While I was simply wondering if the Obama project account was racist, this one pretty obviously is. Inelegant code is just that. Inelegant, perhaps sloppy. Tightly coupled. Not cohesive. Spaghetti code. With so many descriptors for code that isn’t elegant available… why on Earth would you go for the one that takes advantage of a marginalised group of people? Other than the obvious explanation that you almost certainly grew up in a life of privilege, with no idea of what it’s like to live in a ghetto. Bear in mind that the word ghetto was first used to refer to the quarters of the European cities where Jews were effectively obligated to live, because the Christians in power viewed the Jews as something less than themselves. Ghettos are areas of both crippling poverty and, at least once (if not still), systematic oppression. Your inelegant code is not described by this. Just stop using this word entirely.

As a profession, we get a lot of flak for how we treat people who don’t look like us… and I can’t say it isn’t well-earned. By adopting, using, and promoting language like this, all we’re doing is saying that we think it’s okay to do exactly that. It isn’t. So other than the two phrases up at the top… this stuff all has to go. The writers and editors at EFY Times who wrote and approved this list should give some serious consideration to what they’re really saying when they publish lists like this.

An unfit culture

Yesterday afternoon, Nitasha Tiku published a piece on Valleywag, entitled This Is Why There Aren’t Enough Women In Tech. It’s eye-opening reading, even for me (and I consider myself at least somewhat awake to the terrible ways in which women are treated in this industry). Go ahead, read it. I’ll be here. I’ve got a Scotch to keep me company. Read Shanley Kane’s February article and Ciara Byrne’s followup interview with Kane, while you’re there.

Read them? Good.

Assuming you’re a cis man… still feel good about yourself, and the developer culture in the office you work in? I hope not. Because if you’ve ever sat an interview, and were asked afterward about “cultural fit”, you’ve been on the edge of this problem. And the problem, as Kane puts it so eloquently over at Pretty Little State Machine, is that cultural fit is “a loosely coordinated social policy to ensure homogeneity in our workforce.” Cultural fit is a catch-all way of rejecting otherwise perfectly suitable job applicants, without having to flat out say that it’s because they don’t have a similar cultural background.

This also introduces design problems in your product. No, seriously. Hiring with a view to cultural fit ensures that your entire development team thinks similarly—and approaches problems similarly, allowing for slight differences in experience with the tools in use and with others. You could get an entire team of programmers who would write, structurally, almost the same code, just with different variable names. You might say, "great minds think alike," but I would suggest that fools seldom differ. Then. if you hire one person who is eminently qualified, and is largely unlike the rest of your staff (e.g. outspoken about what’s shit code and will just fix it, as opposed to the various forms of introversion you stereotypically see in programmers), you see not only significant structural differences in coding styles, but this also helps your entire team evolve as programmers. Instead of everyone already writing according to an unspoken code style, there’s discourse, improvement, and a gradual winnowing away of the chaff.

But enough about how cultural fit damages your codebase.

Cultural fit damages developer culture, and society as a whole. Reading through the anecdotes in Valleywag, I’ve seen hints of this attitude in virtually every office I’ve worked in, since I started working. My computer science program was, as in so many others, overwhelmingly dominated by men. The few women who started, and made it through the three years that I was there full-time, were either as naturally talented as some of the men, or struggled every day with it. And I can’t imagine it was made easy for any of them by the men, who alternately accused them of following their boyfriends into the program or buying answers, and incessantly hit on them.

I’ve said it before, and I’ll say it again, because it seems like every week I see another example of it: the tech industry, by and large, is an industry made up of little boys who were hurt over and over again, and never learned anything but how to hurt. They were rejected and hurt by their peers growing up, formed a tribe of comrade rejects, and grew to fear outside interest. When they were young, outsiders becoming interested in them led to pain, but now they have the means to reject and hurt those who rejected and hurt them. The bullied have become the bullies.

These hurting little boys grew up in a society of intense white male privilege. One where, even in 2003 when I began my degree, there were jokes that the women taking B.Comm. were really just being there for their “MRS”. One where the University of Waterloo was “jokingly” called the University of Waterwoo, on account of the high concentration of Asian students in the Math and Computer Science programs—almost as though they were displacing the rightful seats of (might I add, white) Ontario-raised students. A culture where, I hate to admit, I participated in jokes about final exams being either the perpetrators or victims of rape.

So these little boys, already distrustful of new people becoming interested in their interests, were raised to further distrust the motives of those others. And now that they’re creating tech companies, and doing the hiring, they’re applying that distrust to their staffing procedures, and keeping out everyone who doesn’t already think like them.

I’ve heard stories from colleagues—women who were interested in computers but hadn’t had the opportunity to try programming until they entered university—of being disregarded by the men in their program who had grown up in front of a keyboard and a CRT. That they were somehow inferior because, for whatever reason, they didn’t have the same opportunities growing up. The same men who, invariably, would describe developer culture as a welcoming meritocracy, where intelligence is fostered and output alone determines your worth. The same men who, on Slashdot (and later, Reddit) would, after receiving comments of “STFU, n00b” from their elders for asking naïve questions, would turn around and do the same to those who had naïve questions for them. A welcoming meritocracy, my ass.

Cultural fit is little more than code for “were you bullied as a kid for like computers and D&D,” when you get down it. It’s shorthand for decades of similar experiences of pain, and a similar unconscious desire to mete it out on the new kids. And it has to stop. We have to begin the difficult process of evolving past the pain and refusing to inflict it on others. Instead of demanding that people fit into our culture, we have to extend the olive branch to other cultures, and modes of thinking, and creating a brave new world where the meritocracy that we claim to exist is actually present. In private, we used to assure ourselves that, when we got older, the bullies would be working for us in the new knowledge economy. That knowledge economy seems to be here, but all the old rules of proving who’s got the bigger dick seem to still in force.

So to anyone and everyone reading who sits an interview, I call you to reject cultural fit, and reject old ways of thinking, and help create the meritocracy and the culture we all wanted our community to be.