We need a role model

So Notch (along with all the other founders, it seems) has resigned his position from Mojang, and publicly distanced himself from anything to do with Minecraft, now that he's personally worth in excess of $1B USD.

Why? The screed he left is a bit rambly, but seems to boil down to not wanting the responsibility for the overall Minecraft community. Some other of his writings definitely convey that he’s got pretty sick and tired of dealing with managing Mojang and all the extra issues that come with it. But he doesn’t want to have anything to do with Minecraft any more. He says, at the end, “Thank you for turning Minecraft into what it has become, but there are too many of you, and I can’t be responsible for something this big.”

I’m sorry, Notch, but you don’t have that choice. You are responsible for something as big as Minecraft, because you made it, and you put your name on it. You’re responsible for a one-hundred-million-strong user base, which means over the course of the last five years, you are invariably responsible for inspiring more than a couple of people to become programmers. I don’t think Star Trek had an audience that big when it was in production, and it’s only too easy to find stories of the actors—not even Gene Roddenberry, but James Doohan and Nichelle Nichols—talking about how fans approached them, repeatedly, at conventions, telling them that the show had changed their lives and given them a career (and in one case I can recall, Doohan saved a young woman considering suicide).

You’ve established a subculture within gaming, Notch, and it’s one that seems to have a level playing field amongst genders and ages. Your game does what no other game does, and considering the fucking shit show that is gaming culture right now, you owe it to the world to show that, in fact, some gamers can treat people with mutual respect. You are a role model, and this is the time, of all times, to act like one.

Minecraft’s great. I have the Pocket Edition demo on my iPad, and I pop it up every now and then. I’ve been considering shelling out the $7 to be able to play it properly. But if you’re going to act like this… you know, maybe I don’t want to.

Come back to Minecraft, Notch. Your audience needs you.

I am not an engineer, and neither are you

I’m called a Software Engineer. It says so when you look me up in my employer’s global address list: “Matthew Coe, Software Engineer.”

I am not a software engineer.

The most obvious place to begin is the fact that I don’t hold an undergraduate engineering degree from a board-accredited program. While I’ve been working at my current job for just over four years now (and have otherwise been in the field for an additional three years before that), I’ve never worked for a year under a licensed professional engineer, nor have I attempted, let alone passed, the Professional Practice Exam.

I don’t even satisfy the basic requirements of education and experience in order to be an engineer.

But let’s say I had worked under a licensed professional engineer. It’s not quite completely outside of the realm of possibility, since the guy who hired me into my current job is an engineering graduate from McGill… though also not a licensed professional engineer. But let’s pretend he is. There’s four years of what we call “engineering”, one of which would have been spent under an engineer. If we could pretend that my Bachelor of Computer Science is an engineering degree (and PEO does provide means to finagle exactly that, but I’d have to prove that I can engineer software to an interview board, among other things), then I’d be all set to take the exam.

Right?

There’s a hitch: what I do in this field that so many people call “software engineering”… isn’t engineering.

So what is engineering?

The Professional Engineers Act of Ontario states that the practice of professional engineering is

any act of planning, designing, composing, evaluating, advising, reporting, directing or supervising that requires the application of engineering principles and concerns the safeguarding of life, health, property, economic interests, the public welfare or the environment, or the managing of any such act.

There are very few places where writing software, on its own, falls within this definition. In fact, in 2008, PEO began recognising software engineering as a discipline of professional engineering, and in 2013 they published a practice guideline in which they set three criteria that a given software engineering project has to meet, in order to be considered professional engineering:

• Where the software is used in a product that already falls within the practice of engineering (e.g. elevator controls, nuclear reactor controls, medical equipment such as gamma-ray cameras, etc.), and
• Where the use of the software poses a risk to life, health, property or the public welfare, and
• Where the design or analysis requires the application of engineering principles within the software (e.g. does engineering calculations), meets a requirement of engineering practice (e.g. a fail-safe system), or requires the application of the principles of engineering in its development.

Making a website to help people sell their stuff doesn’t qualify. I’m sorry, it doesn’t. To the best of my knowledge, nothing I’ve ever done has ever been part of an engineered system. Because I miss the first criterion, it’s clear that I’ve never really practised software engineering. The second doesn’t even seem particularly close. While I’ve written and maintained an expert system that once singlehandedly DOS’d a primary database, but that doesn’t really pose a risk to life, health, property, or the public welfare.

The only thing that might be left to even quasi-justify calling software development “engineering” would be if, by and large, we applied engineering principles and disciplines to our work. Some shops certainly do. However, in the wider community, we’re still having arguments about ifwhen we should write unit tests! Many experienced developers who haven’t tried TDD decry it as being a waste of time (hint: it’s not). There’s been recent discussion in the software development blogosphere on the early death of test-driven development, whether it’s something that should be considered a stepping stone, or disposed of altogether.

This certainly isn’t the first time I’ve seen a practice receive such vitriolic hatred within only a few years of its wide public adoption. TDD got its start as a practice within Extreme Programming, in 1999, and fifteen years later, here we are, saying it’s borderline useless. For contrast, the HAZOP (hazard and operability study) engineering process was first implemented in 1963, formally defined in 1974, and named HAZOP in 1983. It’s still taught today in university as a fairly fundamental engineering practice. While I appreciate that the advancement of the software development field moves a lot faster than, say, chemical engineering, I only heard about TDD five or six years into my professional practice. It just seems a little hasty to be roundly rejecting something that not everybody even knows about.

I’m not trying to suggest that we don’t ever debate the processes that we use to write software, or that TDD is the be-all, end-all greatest testing method ever for all projects. If we consider that software developers come from a wide variety of backgrounds, and the projects that we work on are equally varied, then trying to say that thus-and-such a practice is no good, ever, is as foolish as promoting it as the One True Way. The truth is somewhere in the middle: Test-driven development is one practice among many that can be used during software development to ensure quality from the ground up. I happen to think it’s a very good practice, and I’m working to get back on the horse, but if for whatever reason it doesn’t make sense for your project, then by all means, don’t use it. Find and use the practices that best suit your project’s requirements. Professional engineers are just as choosy about what processes are relevant for what projects and what environments. Just because it isn’t relevant to you, now, doesn’t make it completely worthless to everyone, everywhere.

It’s not a competition

The debate around test-driven development reflects a deeper issue within software development: we engage in holy wars all the time, and about frivolous shit. Editors. Operating systems. Languages. Task management methods. Testing. Delivery mechanisms. You name it, I guarantee two developers have fought about it until they were blue in the face. There’s a reason, and it’s not a particularly good one, that people say “when two programmers agree, they hold a majority”. There’s so much of the software development culture that encourages us to be fiercely independent. While office planners have been moving to open-plan space, and long lines of desk, most of us would probably much rather work in a quiet cubicle or office, or at least get some good headphones on, filled with, in my case, Skrillex and Jean-Michel Jarré. Tune out all distractions, and just get to the business of writing software.

After all, most of the biggest names within software development, who created some of the most important tools, got where they are because of work they did mostly, if not entirely, by themselves. Theo de Raadt created OpenBSD. Guido van Rossum: Python. Bjarne Stroustrup: C++. John Carmack: iD. Mark Zuckerberg. Enough said. Even C and Unix are well understood to have been written by two or three men, each. Large, collaborative teams are seen as the spawning sites of baroque monstrosities like your bank’s back-office software, or Windows ME, or even obviously committee-designed languages like ADA and COBOL. It’s as though there’s an unwritten rule that if you want to make something cool, then you have to work alone. And there’s also the Open Source credo that if you want a software package to do something it doesn’t, you add that feature in. And if the maintainer doesn’t want to merge it, then you can fork it, and go it alone. Lone wolf development is almost expected.

However, this kind of behaviour is really what sets software development apart from professional engineering. Engineers join professional associations and sit on standards committees in order to improve the state of the field. In fact, some engineering standards are even part of legal regulations—to a limited extent, engineers are occasionally able to set the minimums that all engineers in that field and jurisdiction must abide by. Software development standards, on the other hand, occasionally get viewed as hindrances, and other than the Sarbannes-Oxley Act, I can’t think of anything off the top of my head that becomes legally binding on a software developer.

By contrast, we collaborate only when we have to. In fact, the only things I’ve seen developers resist more than test-driven development are code review and paired programming. Professional engineers have peer review and teamwork whipped into them in university, to the extent that trying to go it alone is basically anathema. The field of engineering, like software development, is so vast that no individual can possibly know everything, so you work with other people to cover the gaps in what you know, and to get other people looking at your output before it goes out the door. I’m not just referring to testers here. This applies to design, too. I’d imagine most engineering firms don’t let a plan leave the building with only one engineer having seen it, even if only one put their seal on it.

Who else famously worked alone? Linus Torvalds, who also quite famously said, “given enough eyeballs, all bugs are shallow.” If that isn’t a ringing endorsement of peer review and cooperation among software developers, then I don’t know what is. I know how adversarial code review can feel at first; it’s a hell of a mental hurdle to clear. But if everyone recognises that this is for the sake of improving the product first, and then for improving the team, and if you can keep that in mind when you’re reading your reviews, then your own work will improve significantly, because you’ll be learning from each other.

It’s about continuous improvement

Continuous improvement is another one of those things that professional engineering emphasises. I don’t mean trying out the latest toys, and trying to keep on top of the latest literature, though the latter is certainly part of it. As a team, you have to constantly reflect back on your work and your processes, to see what’s working well for you and what isn’t. You can apply this to yourself as well; this is why most larger companies have a self-assessment aspect of your yearly review. This is also precisely why Scrum includes an end-of-sprint retrospective meeting, where the team discusses what’s going well, and what needs to change. I’ve seen a lot of developers resist retrospectives as a waste of time. If no one acts on the agreed-upon changes to the process, then yeah, retrospectives are a waste of time, but if you want to act like engineers, then you’ll do it. Debriefing meetings shouldn’t only held when things go wrong (which is why I don’t like calling them post-mortems); they should happen after wildly successful projects, too. You can discuss what was learned while working on the project, and how that can be used to make things even better in the future. This is the purpose of Scrum’s retrospective.

But software developers resist meetings. Meetings take away from our time in front of our keyboards, and disrupt our flow. Product owners are widely regarded as having meetings for the sake of having meetings. But those planning meetings, properly prepared for, can be incredibly valuable, because you can ask the product owners your questions about the upcoming work well before it shows up in your to-be-worked-on hopper. Then, instead of panicking because the copy isn’t localised for all the languages you’re required to support, or hastily trying to mash it in before the release cutoff, the story can include everything that’s needed for the developers to their work up front, and go in front of the product owners in a fairly complete state. And, as an added bonus, you won’t get surprised, halfway through a sprint, when a story turns out to be way more work than you originally thought, based on the summary.

These aren’t easy habits to change, and I’ll certainly be the first person to admit it. We’ve all been socialised within this field to perform in a certain way, and when you’re around colleagues who also act this way, then there’s also a great deal of peer pressure to continue do it. But, as they say, change comes from within, so if you want to apply engineering principles and practices to your own work, then you can and should do it, to whatever extent is available within your particular working environment. A great place to start is with the Association for Computing Machinery’s Code of Ethics. It’s fairly consistent with most engineering codes of ethics, within the context of software development, so you can at least use it as a stepping stone to introduce other engineering principles to your work. If you work in a Scrum, or Lean, or Kanban shop, go study the literature of the entire process, and make sure that when you sit down to work, that you completely understand what it is that’s required of you.

The problem of nomenclature

Even if you were to do that, and absorb and adopt every relevant practice guideline that PEO requires of professional engineers, this still doesn’t magically make you a software engineer. Not only are there semi-legally binding guidelines about what’s considered software engineering, there are also regulations about who can use the title “engineer”. The same Act that gives PEO the authority to establish standards of practice for professional engineers also clearly establish penalties for inappropriate uses of the title “engineer”. Specifically,

every person who is not a holder of a licence or a temporary licence and who,
(a) uses the title “professional engineer” or “ingénieur” or an abbreviation or variation thereof as an occupational or business designation;
(a.1) uses the title “engineer” or an abbreviation of that title in a manner that will lead to the belief that the person may engage in the practice of professional engineering;
(b) uses a term, title or description that will lead to the belief that the person may engage in the practice of professional engineering; or
(c) uses a seal that will lead to the belief that the person is a professional engineer,
is guilty of an offence and on conviction is liable for the first offence to a fine of not more than $10 000 and for each subsequent offence to a fine of not more than $25 000.

Since we know that PEO recognises software engineering within engineering projects, it’s not unreasonable to suggest that having the phrase “software engineer” on your business card could lead to the belief that you may engage in the practice of professional engineering. But if you don’t have your license (or at least work under the direct supervision of someone who does), that simply isn’t true.

Like I said up top, I’m called a Software Engineer by my employer. But when I give you my business card, you’ll see it says “software developer”.

I am not a software engineer.

Women don't join this industry to fulfil your fantasies

It’s been another bad day week for men in the technology industry being complete and total shitheads to women.

Admit it, guys, we didn’t have very far to fall to hit that particular point. But last Friday uncovered a few particularly horrible examples of just how poorly some men can regard women, and how quickly others will come valiantly leaping to their defense.

My day opened up with being pointed to codebabes.com (no link, because fuck that). Describing itself as a portal to “learn coding and web development the fun way” CodeBabes pairs video tutorials with scantily-clad women, and the further you progress in a particular technology, the progressively less and less the instructors are wearing. As if software development wasn’t already enough of a boys’ club that has used busty women to get people to buy things (whether it’s the latest technology at an expo, or the latest video game), now somebody’s had the brilliant idea of having PHP and CSS taught by women in lingerie.

The project doesn’t even pretend to have any particularly noble purpose in mind. Above the fold on their site, the copy reads, “The internet: great for learning to code [and] checking out babes separately, until now.”

The mind boggles.

First of all—even if we were going to ignore everything about how socially backwards this idea is—is just isn’t an effective way to accomplish anything semi-productive. Did they not learn anything from trying to get off, playing video game strip blackjack? Or any other game where the further you progress, the more you see of a nude or semi-nude woman? Because this idea is clearly derived from those. The problem with those games is that in order to reveal the picture you want, you have to concentrate on the challenge you’re presented, but the more you concentrate on the challenge, the less aroused you are. The aims are in complete opposition to each other. If you’re trying to make learning a new technology a game, make sure that the technology is the aim, and the game is an extrinsic motivator. If you’re trying to look at naked girls… well, there are lots of opportunities to do that on the web.

But this problem is so much bigger than just being an unproductive way of trying to do two things at once.

What’s the catchphrase, again? “The internet: great for learning to code [and] checking out babes separately, until now.” These two things are implied to be mutually exclusive—that outside of the site, beautiful women and learning to write software have nothing to do with each other. That, were it not for these videos, beautiful women who look good in lingerie would have nothing to do with writing software.

So, if beautiful women who look good in lingerie would other have nothing to do with writing software, we can further assume that the creators are implying—and equally importantly, that their users will infer—that women know shit about computers (if I may coin a phrase).

Now, that being said, I’s quite sure that the women who are presenting these videos actually know what they’re talking about. There’s nothing more difficult than trying to convincingly explain something you don’t understand, unless you’re a particularly talented actor with a good script (see: every use of technobabble in the last thirty years of science fiction television). And I’m not trying to suggest that they should be accused of damaging the cause of feminism in technology. Why? Because there is nothing about this site that suggests to me that the idea was conceived of by women. The whole premise itself is simply so sophomoric that I can’t come to any conclusion other than that it was invented by men, particularly when the site’s official Twitter account follows The Playboy Blog, Playboy, three Playboy Playmates… and three men.

Software development, in most English-speaking countries, suffers from a huge gender gap, both in terms of staffing and salary. Sites like this will not do anything to close that gap, because all this says to a new generation of developers is that a woman’s role is to help a man on his way to success, and to be an object of sexual desire in the process—their “philosophy” flatly encourages viewers to masturbate to the videos.

What makes it that little bit worse (Yep, it actually does get worse) is that, on reading their “philosophy”, the creators also make it quite clear that they recognise that what they’re doing will offend people, and they don’t care. They say, “try not to take us too seriously”, and “if we’ve offended anyone, that's really not our goal, we hope there are bigger problems in the world for people to worry about.” Where have I seen these arguments before? Ahh, yes, from sexist men who are trying to shut down criticism of their sexist bullshit. The next thing I expect to see is them crying “censorship”. I’m not trying to prevent them from saying their repugnant shit. I would, however, like to try to educate them about why it’s hurtful, and why it’s something that they should know better than to think in the first place.

As for the rest of us, we need to make it clear that there’s no room for these attitudes in today’s software industry. That when somebody suggests visiting sites like this, they get called out for promoting sexist points of view. That when someone posits that a woman only got an interview, or even her job, because of her anatomy, that they get called out for thinking that she isn’t fully qualified to be there. If this industry has any hope at escaping the embarrassing reputation that it’s earned, we have to do better. We have to have to the guts to say, “that shit’s not cool,” to anyone who deserves it. Stand up for what you believe in.

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.

E3, or, Seventy-two hours of misogyny

After lunch most days, before returning to work, I typically take a few minutes’ break to catch up with Reddit and Twitter, to see if any of my friends have said anything funny or interesting today, or maybe there’s an programming-related article I can share with my colleagues. However, today, my Twitter feed had this waiting for me, courtesy of a retweet from @lindsaybieda:

Holy shit. Female 343 games producer walks on the Microsoft stage and a man *seriously* wolf whistled at her. Fuck you.

— brandon sheffield (@necrosofty) June 10, 2013

My immediate reaction was not unlike Gollum’s, when Sméagol tells him in the film of The Two Towers, “Master looks after us now. We don’t need you any more.”… what?

Now, I knew going into this that E3 is a ridiculous three-day-long display of sexism, objectification, and misogyny (oh, and something about video games, too). Last year, Scott R Kurtz had a character deliver a webcast from “either E3, or the world’s largest Hooters.” I have privately, among my friends, and probably publicly, too, lamented every marketing department’s decision to hire booth babes for a conference—to use women as little more than decoration and furniture— and I’ve written before about the technology industry’s rampant misogyny. It's not as though I didn’t at least somewhat expect the result of what I did next.

I ran a Twitter search for “#E3 Bonnie Ross”—just that—and was promptly given a feed full of complaints about the new Halo, pleas for 343 Industries not to mess it up… and a litany of tweets about Bonnie Ross: how good she looks, how inept she (apparently) was as a presenter, and multiple people explaining in sometimes graphic details that they want to have sex with her. In particular, @Boogie2988’s gem (since, it seems, deleted):

£429 do we get a complimentary blow job off Bonnie Ross with that?"

— Boogie2988 (@Boogie2988) June 10, 2013

I can’t believe that I have to ask this, but where the fuck do these guys get off, thinking that this shit is okay to suggest, let alone think?! Bonnie Ross is not the studio head of 343 Industries for you to cat-call, or to ask for sexual favours from. She is there to do a job, and judging by the Halo sales, she seems to be doing a pretty good one at that. If you think she’s a dull presenter, fine (during the BB10 launch, I described BlackBerry CEO Thorsten Hiens as having “all the personality of a wet dishrag”), but for God’s sake, can a woman, for once, show up at E3 and be treated with some basic human respect? Is that so hard, guys? Maybe, you know, not call her a MILF. Perhaps not suggest that “that bitch had to have skipped speech class.”

I went on a bit of a tear on Twitter, quote-tweeting and retweeting some of the more egregious offenders, because you know what? I am sick to death of the way that men in my industry talk about women, whether they’re presenting for their favourite console, or the speaker’s colleagues and peers. I would really like to think that, in this day and age, we were raised better than that, but, clearly, this isn’t the case:

@mgpcoe do you want to fight?

— goodsmell (@G__REX) June 10, 2013

@mgpcoe Oh sorry, didn’t realize I was being monitored. That FEMALE must have skipped speech class.

— sinrin. (@SannyRanny) June 10, 2013

@sannyranny @mgpcoe mgpcoe is the definition of a floppy wet turd. #E3 #goofball #letscaremorethanweshould

— Lawrence Fidelis (@HeyFiddy777) June 10, 2013

@mgpcoe It’s my opinion and I will freely state it anywhere I want. Your judgement means shit

— Vel (@God_Damn_Vel) June 10, 2013

I’m a little proud of eliciting “let’s care more than we should” as a hashtag; it really demonstrates the work that still needs to be done. And I have to say, I haven’t been challenged to a fight since Grade 9, so well done over there, too. However, one of the guys I quote-tweeted (the one who made the crack about speech class) got back to me and we had this conversation. It’s too long to embed without messing around with Storify, but I broke it down for this guy that, basically, what you say on Twitter is open for public critique (and I was just criticising his statement, not his character) but his closing statement, “I was in a casual context, speaking with kids just out of high school who couldn’t care less about semantics,” really reminded me, despite all the fucked-up things that have happened this year, that kids today still need to be taught this.

I’m sure he and his friends couldn’t care less about the semantics of what they’re saying, but the reality of the situation is that we need them to. Just as we, as adults and parents and nurturers and teachers, need to teach them to care. We need to carefully teach the younger generations about respect, and about the hidden messages they may not realise they’re delivering when they use certain words. We need to not only self-correct, and demonstrate the right behaviour; we need to call out the wrong behaviour in others. They may not realise what they’re doing, but that doesn’t mean they shouldn’t be taken to task for it. After all, not knowing that, in this particular jurisdiction, you can’t turn right on a red light doesn’t mean the traffic police are going to let you off the hook.

To make this abundantly clear, if you were one of the guys who decided to judge Bonnie Ross’ ability or competence based on her appearance or gender, or you made—or laughed at—jokes about her, using language specifically reserved for insulting women, you are part of the problem. You are holding back the human race from evolving beyond prejudice, beyond hatred, and beyond unwarranted fear. And I refuse to stand idly by and watch you do it.

On the definitions of terms

This morning, on my walk to work, saw a tweet in my feed mentioning a new service built on BitTorrent, called BitTorrent Sync. Fully encrypted, the blogger in question called it “Dropbox without the cloud”.

I just about tripped over my own feet.

The term “cloud” has very specific semantics in networking and computing, and it annoys me more every time I see it misused to sell something. There couldn’t possibly be a more cloud-like implementation of cloud storage than by using BitTorrent. By distributing the data all across the cloud, you really are just dropping your bits on the cloud, and picking them up later.

The Cloud, quite simply, any and all of the networks you connect to, but don’t control. Most often, network cut sheets use a cloud to represent the Internet as a whole. It’s an opaque region of the ether that may have your systems on the other side, or it might just be used to represent the source of incoming requests to your services. It may also be used to represent the networks between you and a network API with a specific, known endpoint (like, for example, Dropbox!).

Any x-As-A-Service service is fundamentally a cloud service, because it operates on on a network outside of your control. Dropbox is a cloud service. Netflix is, and you’d better believe BitTorrent is, too. Dropbox exists on a readily quantifiable set of servers, but this BitTorrent Sync product isn’t nearly so measurable—your data could literally be anywhere within the cloud.

For the sake of comparison and clarification, what would be a “Dropbox without the cloud”? A local server within your network that provides similar data mirroring. This would likely only ever be useful in an office environment full of thin clients (or tablets) where no one necessarily has the same desk from day to day. This, however, largely doesn’t exist in most office environments. I have a laptop computer at Kijiji that I bring with me when I need to work in a different room, or if I need to travel. And if, for any reason, I can’t bring the computer with me, I can access it through SSH, anywhere within the corporate network. “Dropbox without the cloud”, in our ecosystem of cheap, portable devices is fundamentally meaningless.

So please, if you&rsquo&re selling something, and want to refer to The Cloud, use the term correctly. This industry is one based on precision of language, and “cloud services” is vague enough already, without being used as its own antonym!

The bullied have become the bullies

I’m willing to give SendGrid a pass in this fiasco. A small pass, only, but Daily Dot is reporting that their hand was forced. Beyond the DDOS attack that they, and Richards’ blog, were suffering, Anonymous is/was threatening the utter destruction of the company if she wasn’t removed, and publicly.

I knew there was something strange about publicly firing her, if even just to try to pacify the trolls.

The threat from the Internet’s favourite band of vandals and vigilantes includes the following details of the plan:

“You [sic] client list has … been obtained by Anonymous. They have already begun harassing your customers. These include obnoxious phone calls, emails, denial of service attacks, online vandalism and defamation, and even real-life harassment.”

“Your financial backers have also been targeted for the same harassment. …If any of your backers have something embarrassing or illegal to hide (sexual misconduct, tax fraud, etc), Anonymous WILL find it (they are good at doing this) and make it public.”

“Real life harassment is an escalation that comes into play based on how long this situation is allowed to play out. It is not affected by the effectiveness of the previous forms of harassment. Even if your customers and financial backers are dropping like flies (or the opposite, entirely unaffected), this will still happen if Anonymous still maintains an interest in this situation. …If some of the more talented members of Anonymous take an interest into [doxing], every employee of Sendgrid becomes a target, starting at the top. For your reference, this is already happening to Ms. Richards as per standard protocol. There are also some interesting information about her dentist that was dug up in the process.”

“However, you do have a choice to make at this point: Do nothing, or publicly announce that Ms. Richards will be fired. The opportunity to stop this growing mob in its tracks before it tries to tear Sendgrid apart is as simple as publicly announcing Ms. Richards' firing. Now, you also have the opportunity to be sneaky about it and just publicly announcing the firing but not actually do it. But if Anonymous ever finds out, they will bring the full fury on you and your company. To put it in perspective, not even secure government websites are safe. If you believe you can tough it out, by all means, do nothing.”

I think it’s safe to say that Sendgrid didn’t have a choice in the matter.

They did, however, have a choice in what words to use when they announced Richards’ dismissal, which means that despite the reality that they had to sever their relationship with her, writing the following in their public blog continues to send much of the same message that I decried earlier:

“A SendGrid developer evangelist’s responsibility is to build and strengthen our Developer Community across the globe. In light of the events over the last 48+ hours, it has become obvious that her actions have strongly divided the same community she was supposed to unite. As a result, she can no longer be effective in her role at SendGrid.”

I don’t believe for a minute that Adria Richards divided the developer community. The developer community is already divided, because large numbers of men think nothing of making sexually suggestive jokes in a crowded conference hall. Large numbers of men think that a person who’s been offended by sexually suggestive commentary at a professional event should discuss the issue quietly, and not make a fuss. Large numbers of men believe that Human Resources department policies regarding indirect sexual harassment in a professional setting are stranglings of their free speech.

The software developer community is rife with sexist comments, and sexist thinking. Richards didn’t create a divide, her actions exposed it. The CEO of SendGrid “supports the right to report inappropriate behavior, whenever and wherever it occurs”… but clearly, only as long as it’s kept quiet.

To say that the Internet has exploded with hatred really doesn’t quite do the reality justice.

Let’s review:

1. A woman—a woman of colour, at that—embarrasses a man for making sexually suggestive comments in a professional setting.
2. The man is chastised, and apologises, presumably in earnest.
3. His employer fires him for making these comments.
4. The public isn’t told specifically why (perhaps this wasn’t his first offense, perhaps it was, we’ll never know, and his employer isn’t accountable to any of us), but he publicly accuses his accuser of getting him fired.
5. Men across the Internet rally around his cause, and begin attacking her for daring to publicly call out inappropriate comments made in public. Every terrible word you can think of to describe women, and women of colour, is used.
6. /b/ hears about it, and begins a campaign of harassment, demanding that she be fired in retribution for, ultimately, an HR policy violation firing.
7. Vigilantes get in on the campaign, and attempt to destroy the woman’s employer, and everyone associated with them, unless she is fired.

This is not the behaviour of an inclusive, welcoming group.

This is the behaviour of a group of misogynists, who are frightened by the thought that the power relationship that they have historically always enjoyed over women (and over people of colour—the English-speaking software development community is not only overwhelmingly male, but overwhelmingly white) is in jeopardy.

I don’t recall where I originally encountered the thought, but it’s becoming more and more clear how true it is, the longer I look around—the nerd community wasn’t born out of a spirit of inclusivity. The community was born in an effort to exclude those who had previously excluded its members—a spirit of “fuck you, now we’re the cool kids.” The community at large claims to be more evolved than the cool kids who rejected them, but that simply isn’t true.

We’re a tribe of hurt little boys, who only ever learned to hurt. When we were overwhelmingly in the minority, it was a support group, and there was no one to hurt. But we never got over the pain of rejection, and we never learned how to rise above the hatred that forged the community.

But now we’re a pop culture, and we don’t know how to deal with that, other than the only way we know how—by lashing out at those who say they don’t like what we’re doing. And those who are most inclined to lash out have the means to do much more damage than a playground fistfight.

This week has dealt a huge blow to the feminist cause in IT, because the public perception of developers being misogynists, and of the community being a boys’ club, has been dramatically reinforced. I’ve seen all kinds of comments confirming that the comments made at PyCon are by no means unusual, or that Richards is alone in finding them highly inappropriate. But for men to demand that women interested in STEM fields simply accept that ribald comments are just part of the environment only serves to keep highly talented women out, because they don’t think having to put up with their colleagues’ shit is worth it.

Regardless of what you think of Adria Richards, or of the picture she tweeted, I would like to think that we can all agree the technical community as a whole needs to stop the cycle of revenge.

This is not a meritocracy

UPDATE

An hour ago, SendGrid publicly announced Adria Richards’ termination. They say,

While we generally are sensitive and confidential with respect to employee matters, the situation has taken on a public nature. We have taken action that we believe is in the overall best interests of SendGrid, its employees, and our customers.

In other words, they heard the thousands, if not millions, of people calling for Richards’ termination, and delivered. In an effort to do… what? Save their customer base? This is a hell of a message to send—if you embarrass a man for making tasteless jokes at a technical conference, and he gets fired and complains about it, we’ll throw you to the wolves.

The joker’s behaviour at the conference earned him disciplinary action (whether or not he should have been fired or given sensitivity training is academic)—he was acting as a representative of his company, at an event they had sponsored. Necessarily, he should have been on his best behaviour. Richards was probably representing SendGrid as well, insofar as SendGrid probably paid her to be there, and it was probably all over her nametags—and she may have been wearing company gear too. However, what was Richards’ offense? Saying “that’s not cool” loudly, really.

Rather than go to bat for Richards, and say, “we believe that the software industry is best served by a culture of universal respect, and we don’t condone anyone making inappropriate sexual commentary in the workplace or at a technical conference,” SendGrid has sent the message that they don’t have their employees’ backs. That they either don’t believe that the industry is rife with misogyny, or perhaps that they don’t think it’s a bad thing, or maybe just that it can’t be fixed.

I don’t hold with any of this. I believe that the misogyny that pervades this industry must be confronted head-on. New hire sensitivity training that says little more than, “don’t make dirty jokes around girls” is staggeringly insufficient, and if Human Resources requires this training, then everything that company does in public must reflect the beliefs that that training espouses.

SendGrid has told the world that they believe offensive jokes are okay in the workplace, and that if you call it out, you will be silenced.

Is my calendar right? Is it 2013, or 1963?

---

This week is a bad week for how I feel about my gender.

We got an early start on Sunday with shockingly insufficient sentences for a pair of teenage rapists, followed up by horrifying apologia from, well, all the major news outlets, CNN included. I’m not going to comment on it here, but I will suggest that you read I Am Not Your Wife, Sister or Daughter, a fantastic article (that my wife Anne wrote) that’s getting a fantastic amount of coverage. She’s absolutely spot-on when she points out that we, as a society, really need to stop trying to humanise rape victims to rape apologists by suggesting, what if it was your wife? Your sister? Your daughter?. It’s not just objectifying, but it also reinforces your audience’s misogynist worldview.

I could really get into it, because it makes me mad… but the way that the professional software community is treating Adria Richards—and, by extension, every woman in the industry, has got me so upset I can hardly see straight.

You probably know where I’m going with this, but let’s review the facts, shall we?

Richards publicly shamed two attendees for cracking sexual jokes about, among other things, “forking his repo” after a suggestion that forking is the highest form of flattery. I understand the pair of them were going on for quite some time, and the PyCon organiser dealt with the situation privately, and the guys were chastised for their behaviour, and that seemed to be the end of it.

Until when they got back to work, when at least one of the pair of jokers was fired. He then posted a strange apology that suggests that he believes Richards was trying to make that happen. Richards sent her own public apology to him and urged his employer to reconsider their decision.

Regardless of this, the male developer community has worked itself into a mouth-foaming rage. People are specifically calling for her dismissal, and there was at least one suggestion that the guy who was fired should sue her. There’s a whole host of men insisting that “dick jokes aren’t harassment”, as though sexual harassment can only occur through individually-directed comments. I’ve lost count of how many people are suggesting that Richards’ fragile female sensibilities caused her to overreact to a “private joke” (one, I’ll point out, was told in a crowded conference hall, and thus is anything but private, unless it was whispered directly into the other person’s ear).

Virtually every comment I read on the thread following the non-apology is coming to his support, and attacks Richards.

Virtually every commenter seems to believe that a man’s desire to make offensive jokes in a public space, while representing his employer, somehow trumps every other person’s basic right to be in a room without being made to feel uncomfortable because of their race, gender, religion, sexual preference, or even no reason at all. That bad jokes are somehow sacrosanct, and that people who are offended by them should simply “grow up and get over it.”

Look, this isn’t the way adults, and professionals, are supposed to talk to each other. This isn’t the way the developer community constantly tries to describe itself to outsiders. We insist, adamantly, that everyone is considered equal, and that the developer community is a meritocracy above all else.

This is, unfortunately, not the reality. Women have never been afforded the respect they deserve within this industry. RADM Grace Hopper invented the compiler, and assembly language, in order to make programming that little bit easier than having to remember and decipher opcodes, and her male peers couldn’t possibly have taken her less seriously… but because of her, I don’t have to have any idea what the x86 instruction set looks like in order to do my work.

And yet marketers at computing events like CES and E3 continue to hire booth babes—in other words, human furniture to make their booth look good. I’ve read of women who have produced games, who later staffed the conference booth for the game, and tech reporters asked her to get the producer, or technical director, as though the idea of a woman being responsible for creating something as complex as a video game was a foreign concept.

I’ve worked in a variety of companies, some larger and some smaller. But the reality is that I’ve worked with far more men in technical roles than I have with women, and that, invariably, when there haven’t been women in the technical group, it’s turned into a boys’ club.

This is unacceptable. The current software developer community is openly hostile to women asking to be treated like human beings, and this shit has to stop. You wouldn’t make racist jokes at a conference (or would you?), so what makes it magically okay to make jokes that objectify sex, and women?

Right, nothing does, because it’s not okay.

It’s not okay to compare an object to a person’s body. It’s not okay to compare a development process to sex. It’s not remotely okay to tell someone who says, “I’m offended”, that nothing offensive happened, and that they’re overreacting.

And it isn’t fucking okay to make death threats against a person who called out inappropriate jokes. Yes, this happened. Yes, the post has been deleted. Yes, I hope YCombinator does the right thing and assists the police in any investigation that might occur, and yes, I hope that investigation happens.

Finally, it’s not even a little bit okay to attack someone for acting on having been offended. That someone got fired for making inappropriate comments while representing his company at a conference shouldn’t be remotely surprising.

Technologists really need to start showing each other a lot more respect, because right now, it really feels like we don’t show each other any.

Your Encapsulation Is Bad, And You Should Feel Bad

Pass-by-reference is a fantastically powerful tool in object-oriented languages. In Java’s case, it ensures that no argument on a stack frame is longer than a processor word, by only passing along copies of primitives, and the heap locations of objects. It reduces your memory footprint fantastically, because it’s always there, unlike in C, where you had to specifically indicate that this argument is actually a pointer. Java does the same with return values as well—anything that you return from a method that isn’t a primitive is passed by its location on the heap.

And thus are a whole host of encapsulation and coupling issues born—particularly when you work with Collections.

Let’s say, for the sake of a specious example, I run a rental car agency. My agency is represented by an object Location:

public class Location { private Address address; private Place city; private Place province; private ArrayList<Vehicle> vehicles; ... public ArrayList<Vehicle> getVehicles() { return vehicles; } }

According to the Rules and Standards of JavaBeans, I’ve done encapsulation right… until I decide to process a series of updates to my stock in this boneheaded way:

public class Updater { ... public void doUpdates() { Location myLocation = LocationDao.getLocation(1); ArrayList<Vehicle> vehiclesToUpdate = myLocation.getVehicles(); scheduleWashes(vehiclesToUpdate); } public void scheduleWashes(List<Vehicle> vehiclesToUpdate) { for(Vehicle vehicle:vehiclesToUpdate) { if(vehicle.getLastWashed().add(DAY, 7).after(Calendar.getInstance()) { vehiclesToUpdate.remove(vehicle); } } updateScheduler.schedule(vehiclesToUpdate); } }

If, at any point after that for loop, I want to work with the list of vehicles, I’ll only have access to those vehicles that haven’t been washed in a week—I removed them from the same List that my Location object refers to.

Like I say, it’s a pretty specious example, but it shows what kind of unintended consequences can crop up when you pass mutable objects around by reference. Fortunately this doesn’t happen with Strings and Numbers (because they create new objects on the heap just about every time you assign a new value), but as soon as you start doing the same thing with more complex objects, you risk loss of data integrity. My Updater needs to know how my Location stores, and returns, the list of Vehicles in order to prevent problems, when it probably shouldn’t. The encapsulation here is bad, because it permits side-effects.

So what’s the fix? Replace the body of Location.getVehicles() with this: return new ArrayList(vehicles); and keep on going as-is. While each individual Vehicle that the lists are backed on will probably point to the same place on the heap (and this may, itself, have attendant problems, depending on what you’re doing, at least you know, for a fact, that whatever changes you make to the list you got back will be self-contained.

This gets even worse when you start throwing around DTOs for different serialisation methods. Because various annotations used by persistence architectures may not necessarily be compatible, often times you need to create three different DTOs for each of your database, XML, and JSON representations. These DTOs should only exist long enough to prepare your problem domain object for serialisation, or to deserialise something into your problem domain.

Say you created an amazing Web service that’s backed on SOAP (I know, I know, JSON geeks. It’s just an example). When I call your Java API’s method to getThing(), I shouldn’t be aware of the SOAP Body. I shouldn’t have to call, say, thing.getAttr(“thing”) to get something that’s an XML attribute, and then thing.getOtherThing().getValue() to get the String value of something that’s stored as an XML element. As a consumer of your API, I shouldn’t be aware of this; it means two things:

1. You can’t easily move your service away from SOAP, without either...
   1. Forcing all your customers to update their code to use a new API, or
   2. Internally converting your new serialisation into something that can be expressed as a SOAP call,
2. and you’ve told the world that your service is backed on SOAP.

Whether or not you’re proud of the fact that you’re using SOAP is irrelevant; it’s an implementation detail that I, as a consumer of your API, don’t care about. For all I know or care, you could be using a proprietary binary format, or even passing messages around by carrier pigeon. From my application’s perspective, this is all irrelevant. The encapsulation here is bad, because it exposes implementation details.

So, what’s the take-away from all this? Two things:

1. Don’t return references to your member collections and arrays. It’s bad for coupling. Return copies, instead.
2. When designing your API, give the consumers of it a paradigm that makes sense from the problem domain, instead of just blindly representing your storage format.

LinkedIn, you're fired.

Let’s be clear about something, LinkedIn. You’ve done good work. This has nothing to do with your performance as a professional social network. But your attitude about your job—the lackadaisical attitude toward data security, the fact that your communication with users who have question can take weeks, and your constant suggestions that your customers are mistaken about plain and simple facts—just can’t go on anymore. Your services won’t be required anymore. Someone will pack up your things.

Yup, I’m firing LinkedIn. I almost called this, “LinkedIn, I quit”, until I remembered that they are providing me with a service, so the firing metaphor is more apt. Particularly considering they’re really all about getting people jobs.

And it’s not as though LinkedIn has been totally useless to me. I’ve found a job through LinkedIn, coincidentally interviewing with a former classmate. My long-time tagline, “Minor PHP deity/aspiring system administrator/technorenaissance man” was referred to by my hiring manager at my current job as part of why he hired me. Whether it was because it demonstrated my sense of humour or my confidence, or even just a joke, I’ll probably never know. But the point is, LinkedIn has its uses.

The problem is in their customer service—more accurately, their almost-total lack of customer service. First of all, when you have a problem, you are functionally prevented from submitting a question to their help desk without first making a cursory look in their knowledge base. Seems sort of fair, until you remember that, sometimes, you know going into it that your issue isn’t covered by a question: there are problems that come up that quite simply need a human being to resolve. So there’s a barrier to getting the help you need, and when you consider it a little further, implies that they don’t have enough staff working their help desk. This point, in fact, gets demonstrated later on.

The second barrier to getting help, once you’ve actually made it to their “Contact Us” page, is that, once you’ve typed out your question, a modal dialog pops up, where it performs a keyword search in its knowledge base for you, presumably based on your summary of your issue. JavaScript sets the browser caret on the button labelled “I Found My Answer”, which redirects away from the page. When you click the Back button in your browser, your question is gone. This is yet another attempt to obstruct users from getting the help they need, and another vivid illustration of just how understaffed their help desk is. To describe it as “poor user experience” is a bit insufficient.

So, just in order to get to the point where you have successfully asked a question, LinkedIn has done everything they can to prevent you from doing so. During the most recent occasion when I had to submit a ticket, I actually muttered at the website, “I hate you so much, I wish I could hate you to death.” I know, I know, it’s not really my line, but Goddamn if it isn’t evocative of the particular type of impotent rage you feel when you’re already mad at something that you can’t really take out your anger on, and it thwarts you.

Now, all that being said… what are the problems I’ve had so far with LinkedIn? Leaving out their comically bad response to the infamous Gawker Media password crack—resetting everyone’s password—there have been three:

1. Recommending connections to contacts from my email
2. Continuing to send Groups emails to an email address I (thought I had) removed from my account
3. Automatically connecting me to someone hours after they requested a connection

These are, in my opinion, huge problems in terms of data security. What made them all even worse was the fact that, in every case, the help desk agent flatly contradicted that the problem existed. Because I don’t particularly feel like trying to sum them up, I’m just going to copy and paste the ticket contents, and let LinkedIn speak for themselves. I apologise in advance for my language, and I haven’t changed the agent’s declared names. I see no benefit in protected the guilty.

---

Support History » Why is LinkedIn accessing my email account?!

Your Question 04/26/2010 23:42
I just received my weekly LinkedIn network update, letting me know that a person I regularly email has just joined LinkedIn.. which seems somewhat strange to begin with, since this person has little reason, that I know of, to use LinkedIn.

What really set off a flag for me, though, is the fact that LinkedIn *knew that I know this person*. I have *never* instructed LinkedIn to import my contacts from my webmail services, and never intend to. So why is it that LinkedIn is suggesting that I add people from my Google Mail contact list to my LinkedIn network?

Before this event, I have been particularly satisfied with LinkedIn’s service; I’ve been able to keep in touch with colleagues, make new connections with recruiters, and in one instance I was able to secure a job because of it. It’s quite valuable to me, but if the service can’t do something simple like respect my privacy, I may have to leave the service and tell everyone I know that uses it precisely why I left.

The contact in question’s email address is [REDACTED]

Thank you. I hope to hear from someone promptly regarding this matter.

LinkedIn Response 05/01/2010 11:21
Dear Matthew,

Thank you for contacting LinkedIn Customer Support.

Please be assured that LinkedIn would never access your address book or import contacts without your permission. Our policies require all members to enter a password any time an address book is imported or other actions are taken on the account. My records show that you have imported some contacts into your LinkedIn account at some point in time. One of those contacts is the one in question. You can see the contacts you have imported if you log into your account and click on “imported Contacts” under “Contacts”. Please know that you can delete imported contacts at any time by selecting contacts and clicking on the "Delete selected contacts" button.

If you have further questions, please feel free to reply to this message.

Roberta
LinkedIn Customer Support

---

Support History » Remove secondary email

Your Question 01/23/2012 23:47
I attempted to remove [REDACTED] as an email associated with my LinkedIn account a couple of months, preferring [REDACTED] as my email address, due to a brief security compromise of my Google Mail account.

I’ve noticed over the last little while that I’m still receiving email from LinkedIn at the old address. Nowhere in my settings does it indicate that you’re storing the other address, until I came in here to contact you and I found it as a secondary email address.

Remove this address from my account immediately. If this cannot be done, then it must be exposed as my alternate email address within my account settings, so that I might change it to another alternate email address.

LinkedIn Response 01/24/2012 01:06
Hi Matthew,

Thanks for your email letting me know that you still receiving emails to your old email address and I understand how concerned you must be about this matter.

I’m able to locate the account and see that there’s only one associated email address [REDACTED] which have 166 connections. I’ve tried to locate the account with the email address [REDACTED] mentioned, but I couldn't find any account on our records.

[I continue to receive LinkedIn Groups emails at the old address to this day. –ed.]

However, if you want me add your old email address to our “Do Not Contact List” in order to stop receiving emails in future. Please reply to my message so that I’ll be glad to proceed with your request further.

Matthew, I await for your response.

Regards,

Susheel
LinkedIn Customer Service.

---

Support History » Unauthorized connection

Your Question 11/07/2012 20:44
At 7 November 2012, 12:34 AM EST, I received an email notification from LinkedIn, informing me that “[REDACTED]” would like to connect with me. I received another email at 1:51 AM EST, suggesting that I see what [REDACTED] has been up to, because we had now become connected.

I did not authorize this action. In point of fact, I did not know of either email until I woke up this morning and checked my email. I can only assume that either some device in my house performed the authorization on my behalf, or that this authorization was committed fraudulently. Accordingly, I insist that you divulge all the logs you have respecting this authorization, and with the original request made by [REDACTED] that the two of us connect, so that I can verify that the request did not come from any device in my possession.

Please note that this is not the first problem I have had with LinkedIn. As you can surely see from my support case history, I also have reason to believe that some process of yours gained access to my Google Mail account without my permission. Despite the support representative's insistence that I must have kicked it off myself, the fact is, I disagree with such “helpful” services on general principle and would never have done so. I have also had no end of difficulty purging my other email address from systems. I continue to receive LinkedIn Group notifications at my past email address, despite a support rep’s insistence that the old email address has been purged from your systems.

Your Response 11/13/2012 14:38
And now I’ve just discovered I had apparently followed PwC Consulting?! What the fuck, guys. This shit has to stop.

LinkedIn Response 11/20/2012 14:29
Hi Matthew,

There are a couple of scenarios that could explain the possibility of unauthorized access to a LinkedIn account:

1. If you’ve recently logged into your account from a public computer and didn’t completely sign out of your account, the next person to access the site on that computer may have unintentionally logged into your account.
2. If you share a computer with another person either at your workplace or home and didn’t completely sign out of your account, the next person to access the site on that computer may have unintentionally logged into your account.
3. Your account has been compromised by someone with malicious intent.

In order to secure your account, we have taken the following actions:

1. We signed you out of your account from every computer it has ever been accessed on. This will now prompt a new login for your account.
2. We sent a password reset link to the primary email address listed on your account.

We also like to recommend these best practices for your online privacy:

1. Always completely sign out of your LinkedIn account each time you leave a computer.
2. Don’t use the same password on multiple websites. If fraudsters identify your password, they can use it to access your other accounts.
3. Select passwords that can't easily be guessed. Create one that includes 10 or more characters. Hint: Think of a meaningful phrase or quote and turn it into a complex password using the first letter of each word in the sentence and add more complexity by adding capital letters, punctuation and symbols.
4. Never give your password to others or write it down.

If you continue to see anything suspicious, please report it to us immediately.

Regards,

Andrea
LinkedIn Trust & Safety

---

Two canned responses! It’s like they aren’t even trying. You can see that I didn’t bother responding to any of the tickets; there was demonstrably no point, since they weren’t putting forth any effort to resolve the issue in the first place. But then, maybe that’s what they’re trained to do.

Like I said above, I’m firing LinkedIn. Exactly what form that will take on LinkedIn’s servers, I have yet to decide. I want to leave a link to this article there, so that anyone who looks me up can read about my awful experience, but I also want to retain the maximum possible visibility—which would mean maintaining all my connections and job history. Decisions, decisions.

LinkedIn, consider this your two weeks’ notice.

In which a scale is found tipping

There’s a certain aphorism that I’ve been thinking about lately: “there are twenty-four useful hours in every day” I don’t recall where I heard it first—as I recall, the version I heard growing up was “you’ve got the same amount of time in the day as the rest of us”—but I’ve realised two things about that first saying:

1. There are decidedly not twenty-four useful hours in every day. Depending on your particularly sleep needs, there are eighteen and, say, fifteen waking hours in every day. Then when you factor in time spent in transit between work/school and home, and mealtimes, along with basic hygiene needs, your time-per-day number drops considerably. I”d estimate around twelve. Your mileage may vary, depending on, well, the mileage between home and what you do to make a living.
2. I need more. I think this is why I’m reminded if my father’s different, truer version of the saying.

There are people in this industry, in this city, who love the freelancing life; people who love seeking out the Next Big Contract, and who get off on working late into the night to make a higher paycheque than the next guy. I’m not one of those people, as I’ve been discovering this year.

Don’t get me wrong. I like networking, and I like making things happens, and I like being able to say, “you know that thing that you use? I made that.” It’s a great feeling. But for the past few months, I’ve really felt like I’ve had at least twenty-four hours of work to do, every single day. So I perpetually feel like I’m behind. And that’s a pretty crappy feeling.

I read a book a few years back called The Hacker Ethic. It discusses the Protestant work ethic, which I think is a huge influence, in this city, of why people will willingly put in ten- or twelve-hour working days, five or six days a week. I don’t get that. I’ve been doing that for months, and it’s awful. All you’re thinking about is what you have to do. Your main focus is making more money. But why? So you can buy more things?

Seriously, everybody should read that book. I got into computers professionally because I love using them, and bending them to my will. But I also love my wife, and it’s important to find that work/life balance that keeps you sane and healthy.

This is becoming a bit of a rant, so I think I’d best cut it off. Too much work to do, anyway.

In which software that wasn't properly engineered is shown to have killed people... again.

My wife showed me an article in today’s online New York Times (yesterday’s print edition) that got my blood boiling—a radiation therapy machine manufactured and programmed by Varian Medical Systems wound up massively overdosing and killing two patients in 2005, just like Therac-25 did back in the eighties. The bad part is that Therac-25 is a standard case study for CS students throughout the continent (and probably worldwide), so this shouldn’t have happened in the first place. The worst is that Varian Medical Systems said it was pilot error. Now, as a software developer and a computer scientist, incidents like these are particularly poignant, as they demonstrate the urgent need for a cultural sea change within the industry.

A quick backgrounder: Therac-25 was involved in six known massive overdoses of radiation, at various sites, that killed two patients. A careful study of the machines and their operating circumstances was conducted and it was ultimately revealed that the control software was designed so poorly that it allowed almost precisely the same problem outlined in the Times’ article. In Therac-25’s case, a higher-powered beam was able to be activated without a beam spreader in place to disperse the radiation, much like how the Varian Medical Systems machine allowed the collimator to be left wide open during therapy. Furthermore, the Therac-25 user interface, like the Varian interface, was found to occasionally show a different configuration to the operator than was active in the machine, as the article mentions: “when the computer kept crashing, …the medical physicist did not realize that her instructions for the collimator had not been saved.” The same issue occurred with Therac-25, where operator instructions never arrived at the therapy machine. Finally, both interfaces failed to prevent potentially lethal configurations without some kind of unmistakable warning of the danger to the operator.

The Therac-25 incident quickly became a standard case study in computer science and software engineering programs throughout Canadian and American universities, so the fact that this problem was able to happen again is shocking, as is the fact that Varian Medical Systems and the hospitals in question deflected the blame onto the operators. The fact of the matter is that Varian’s machine is one that, when it fails to operate correctly, can maim or even kill people. In such a system, there is simply no room for operator error and it must be safeguarded against. Unfortunately, in shifting the blame, Varian Medical Systems has denied their responsibility in untold more tragedies.

Had a professional engineer been overseeing the machine’s design, these deaths could have been prevented. Unfortunately, most professional engineering societies do not yet recognise the discipline of software engineering, primarily because it is exceedingly difficult to define exactly what software engineering entails. For decades, software systems have been in positions where life and death are held in the balance of their proper operation, and it is critical, in these cases, that professional engineers be involved in their design. These tragedies underscore the need for engineering societies to begin licensing and regulating the proper engineering of such software. By comparison, an aerospace engineer certifies that an airplane’s design is sound, and when an airframe fails, those certified plans typically reveal that the construction of (or more often, later repairs to) the plane did not adhere to the design. Correspondingly, in computer-controlled systems that can fail catastrophically, as Varian’s has, it is imperative that a professional engineer certify that the design—and in a computer program’s case, the implementation—is sound.

Varian Medical Systems’ response—to merely send warning letters reminding “users to be especially careful when using their equipment”—is appallingly insufficient. Varian Medical Systems is responsible for these injuries and deaths, due to their software’s faulty design and implementation, and I urge them to admit their fault. I recognise that it would be bad for their business, but it is their business practices that have cost lives and livelihoods. I think the least they could do is offer a mea culpa with a clear plan for how they will redesign their systems to prevent these incidents in the future.

The IEEE, the ACM, and professional engineering societies need to sit up and take notice of incidents such as this. That they are still happening, even with the careful studies that have been performed of similar tragedies, is undeniable proof that software engineers are necessary in our ever more technologically dependent society, and that software companies must, without exception, be willing to accept the blame when their poor designs cause such incidents. Medical therapy technology must be properly engineered, or we will certainly see history continue to repeat itself.

If this reads like a submission to the Op-Ed page, there’s a very good reason for that! It was, but they decided not to publish it. Oh well.