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.

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.

The only limitation has been in your mind

A few days ago, Infinity Ward announced that the upcoming Call Of Duty: Ghosts would provide an option for players to inhabit the online mode of the game either male or female characters. Finally! About 14% of US Army personnel are women, and women are further underrepresented in Xbox and PlayStation users at 10%, and Infinite Ward has joined the ranks of enlightened game publishers, like BioWare, who recognise that they ought to reach out to all their customer demographics, not just the biggest one, because it's the right thing to do, even if they are a bit late to the party (2013, guys).

Right?

I want to believe that, really I do. The only problem is that producer Mark Rubin has gone on record explaining that the reason that CoD has never before offered women as playable characters was a technical limitation in the engine. Memory and processing requirements have, until now, been far too significant to provide players with the option of using multiple meshes in online play.

I might be able to believe that, if this were, I don't know... 1996. If I'd never played Quake 3 Arena on a sub-1-GHz system, which comes stock with a wide variety of meshes, and provdes players with the option of installing their own meshes, which would be seen by all players in the arena, all over the world. If I didn't own a copy of Halo 2, which allows players to appear on Xbox Live as either a Spartan or a Covenant Elite. If there wasn't a wealth of evidence supporting the fact that the technology has been out there to do exactly that for almost two decades.

Mark, if your engine can't handle showing characters with two different meshes in this day and age, on modern hardware, you are simply using the wrong engine, or you are abhorrently misusing it. But I find that hard to believe; if your engine was as shitty as it would have to be for your excuse to be realistic, then the Call of Duty franchise wouldn't be remotely as popular as it is.

Just admit it, Infinity Ward. You haven't offered women as playable characters because you didn't consider them a sufficient demographic to justify the expense of creating a second mesh (which, incidentally, would have been... What? 10K? 20? And what's your budget on these games?). You'll feel better, because you can also admit that you've been doing the wrong thing, and you want to make it up to the devoted women who play your games. That you want to encourage more women to play your games (because why wouldn't you? At 51% of the population, it's a huge market). That women deserve a hell of a lot better than the shit they receive from both the gaming industry and community, each and every day they play the games they love to play.

Anything other than the most bullshit copout to (dis)grace my screen in the last several months.