Monday, 30 December 2013

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.
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

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.
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

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.
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.
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

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, 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.

No comments:

Post a Comment