NIH, Developer Infantilization, and Motivations

I recently read about the new face of NIH syndrome, and after sharing and discussing it with some coworkers (Hi, John!) I had some thoughts about how NIH (or what Freeman calls NPF) comes to be, and what it means about an organization.

For the uninitiated, NIH stands for “Not Invented Here,” and refers to the inclination of some development organizations to avoid third party tools at all costs, because there’s some sort of vague FUD (fear, uncertainty, doubt) around using anything that our developers haven’t written. Maybe it won’t work, maybe it won’t work *well*, maybe it will stop being supported, etc, etc. Freeman argues that the software industry has, by and large, rid itself of NIH syndrome, but it has done so mostly through word policing and social mores, and developers still do roughly the same thing, only in the form of what he calls NPF: Not a Perfect Fit syndrome. The symptoms are the same, more or less: sure, this software works, but we realllly need X feature, and no one else does that. Or, yea, that works, but do we really want to deploy a JVM on our wiki box? why not just write our own? Or, etc. Same symptoms, same cause, different name — because saying “we can’t use that, we didn’t write it” doesn’t work anymore, you need a plausible-sounding justification, however thin it may turn out to be.

So I was reflecting on all this and chatting with John, who is a wonderful sounding board and generally a thoughtful person, and I mentioned that I have basically no vulnerability to NIH, at which he looked slightly surprised. Upon further thought I have come to think it is because I don’t find all that much joy in writing code. Sometimes it’s fun, and certainly the feeling of solving interesting problems is always rewarding, but I am much more motivated by delivering value to customers than by just the raw act of implementing things. I’m currently really excited about an upcoming project at work because I had spent a while worrying that it would turn out to be frustrating and difficult for customers to use, but after some recent discussion I realized that we have the opportunity to turn it into something that customers will really like. That is so much better of a motivator for me that I can’t imagine slowing down the time to get that feature out to customers by banging out a proprietary form validator or whatever.

And so now I come to my main point: many developers in many companies are basically not permitted to have the kinds of motivations that I have, the ones that supersede the mere technical challenges. Many organizations silo off their development teams, both from the business and, often, even from each other. They are handed feature requests from the business, largely devoid of context, with little idea who they benefit or what the underlying goal is. I consider this a form of infantilization, honestly: the only reason to do this is because you think developers need insulation from the scary business types that poor nerdy coders can never figure out how to interact with effectively. They can play in their little sandbox while the adults gather requirements and decide what to have them do. In this environment — and, actually, I have worked in conditions like this, although not for long — it’s easy to see why someone would develop NIH syndrome. If your job is to do context-free drudge work updating some winforms or CRUD app or whatever day in and day out, and you don’t see customers loving it or understand why anyone would need it, of course you’d make up any excuse to do more interesting work. If the only motivation you’re allowed to have is “for the love of the code,” then the best you can do to keep yourself interested is to work on more interesting code, since you’re not allowed to help solve more interesting business-related problems. Given that the only tool I have for working on an interesting problem is telling someone who wants me to work on a boring problem that there are important prerequisites to it, and that none of the existing solutions to those prerequisites will work for our special snowflake case, I am going to use that tool constantly. If my choices are “write a Django clone” or “write an intranet CRUD app in Django,” I’m going to choose the former every single time.

I am lucky enough that those are not my choices. First of all, no one I work with would dream of letting me write a Django clone, thank god. Secondly, and more importantly, my choices are more like “work on this feature to help customer X” or “work on another feature to help customer Y.” I’d rather do either of those things than write a Django clone! I’ve talked to our customers, I know the pain they feel, and I know the value they can get out of using our product, and helping them is great. Creating a product that I can feel good about giving to customers is a much better feeling that knowing I’m capable of writing some tricky library from scratch.

(Hopefully unnecessary disclaimer: some developers are more motivated by the writing of tricky libraries than the helping of customers. This is totally fine and I don’t mean to deride it in any way. I’m talking about the developers who are like me but not given the freedom to work on projects that would be interesting to them)

There are obviously other reasons an NIH mentality can take over a dev team. “Job security” is a shitty reason people might do this, a feeling of fear that we either can’t implement what we need to or don’t know what we need to implement is a much-less-shitty reason. But I think this explanation explains a lot of the organizations that get taken over by NIH syndrome, and I think it’s a particularly pernicious reason.

It’s pernicious for two main reasons. The obvious one being that you’re wasting your developers’ time, or rather letting them talk you into wasting their own time. That’s just an unnecessary inefficiency in your organization: you would literally be better off firing them.* The second one is that this kind of environment is only appealing to developers who are happy just hacking out code without caring about the business. Engineers who do have any interest in being an active part of helping your customers are going to be frustrated and leave, and the only ones left will be incompetents who can’t find another job and ones who only care about technical chops and have no qualms about crying NIH constantly in order to scratch that itch.

Do you really want that? I mean, empirically, the answer is yes, a lot of companies do want that, because they choose to infantilize their engineers. But you can do so much better! You can get feedback from intelligent, knowledgeable parties, constantly. You can motivate engineers by introducing them to the customers they’re going to solve problems for. You get everyone more involved and more motivated! And you don’t have to constantly fight with your developers if you treat them as grown ups; they won’t constantly scramble to justify NIH tendencies because they’re engaged in their work, and they’ll get more done, and they won’t be incentivized to bullshit you about what can or will get done, and everything is just so much nicer.


In the end, my point is basically just “treat everyone in your company like an adult,” which seems like it should not be controversial enough to say nor rampant enough to break down into sub-categories of infantilization. Unfortunately we do not live in the best of all possible worlds.


*They would probably be better off if you fired them, too! Imagine a person who develops an internal bug-tracking tool because Jira is “not a perfect fit.” Now imagine that person works full time on this Not-Jira, or, say, full time for 3 months and then ~20hrs/wk indefinitely. Let’s say you don’t fire them: you’re wasting ~half of this dev’s salary (half of their salary – a monthly Jira subscription), and this dev is wasting half their time on non-transferable skills that will get them nowhere in their career and severely limit their job opportunities moving forward. Or don’t imagine it: I have seen this exact situation transpire, maybe you have too.

Posted in software | Leave a comment

Users and Accounts in Swift

(This will eventually be published on the SwiftStack blog)

Preface: I am a developer at SwiftStack, where we work with Swift, which is in this context an open source distributed object storage engine, not the Apple language of the same name (which is also pretty cool, tbh, even if the compiler was a piece of shit when I was playing with it). Anyway, people who interact with Swift frequently run into trouble understanding the distinction between users and accounts (and for good reason; it’s quite confusing for the neophyte); so frequently, in fact, that I wrote up this blog post in order to have something to point people to.

This is written from the perspective of a SwiftStack developer to a SwiftStack customer, so it will sound somewhat odd appearing on this blog. When reading, I advise you to imagine yourself as a SwiftStack customer.

On a welcome rainy day not so long ago, I was sitting in the SwiftStack office and ruminating over how best to communicate with one of our valued customers about a feature said customer was interested in us implementing. In the course of coming to a more complete understanding of what was needed to fulfill this customer’s desires, I realized that I was having communication troubles as a result of the confusion between Users and Accounts in Swift. In addition to this already difficult terminology — people are often used to saying “user account” in the context of other software, which leads them to (not irrationally!) misunderstand the crucial distinction inside of Swift — there is also the extra level of indirection of the fact that you yourself are a SwiftStack user!

Note: I will be using bold text for User and Account throughout when they refer to the concepts in Swift. If you see either term unbolded, it is being used to some other purpose.

So to start off with, I am going to indulge in some unbearable pedantry in the form of terminology.

  • Swift UserSwift has a concept of users which are tied to authentication and authorization. A Swift User does not, on its own, provide any access to the storage engine. Instead, it is a way to take credentials from a client and allow Swift to recognize that, yes, indeed, I am aware of this user, and if they continue to make other requests, I have the means to authorize (or refuse to authorize) those requests.
  • Swift Account — An Account, on the other hand, is simply the top-level namespace for storage inside Swift. An Account may have many Containers, each of which may have many Objects, as you are no doubt aware. However, an Account is not necessarily tied to a Swift User.
  • SwiftStack User — This is your identity on the SwiftStack Controller, which is in no way connected to your or anyone else’s Swift user (or Account, of course!)

Smashing MonitorThe last of these is fairly easy to understand as separate from the others, and is generally confusing because of sloppy terminology when speaking about it (in particular, the fact that our auth system for Swift is called SwiftStack Auth, thus necessitating at times the phrase “SwiftStack Auth Swift User” to wholly disambiguate from a SwiftStack Controller user). I thought it was worth calling out explicitly if only to explain that I’m not going to be discussing what a SwiftStack user is.

On the surface, the concepts of User and Account seem fairly easy to distinguish between: a User represents a human (or maybe an automated service), who “logs in” to Swift and then has permissions to see various things. An Account is sort of like a folder, in that you can put Containers in it and then Objects in those Containers. So what’s the problem?

Well, I think the problem comes from a few things. The primary two are:

  1. Simple bad pedagogy and sloppy language on the part of Swift experts, and
  2. The fact that Accounts are, in many auth middlewares, auto-vivified per user.

Problem 1 is something that I myself am guilty of. When talking with other developers and people immersed in Swift, if I slip up and say “user account” when I mean “user” or similar, my colleagues have no difficulty in translating it within context to whatever I actually meant. However, in letting such imprecise language slip into conversations where I’m trying to understand a problem a customer is having, I only create more confusion for both of us.

Cause 2, however, is not something I can label a problem on its own. It’s actually quite a convenient thing! It would be more difficult to get started using a Swift cluster if you had to not only create a User, but then also explicitly create an Account for that User (or perhaps give them permissions to create their own Account). However, people often just start using Swift without ever being taught about the distinction between Users and Accounts, and so the lines get blurry because, in many people’s experiences, there’s a tight one-to-one correspondence between Users and Accounts.

So let’s talk first about the way many people interact with Swift, which leads to most of the confusion, and then we’ll get into other aspects of Accounts in general. When you authenticate with Swift using your username and password, you get back a response that includes, among other things, a Storage URL. This Storage URL is nothing but a link to the default Account that your User has access to. For example, in SwiftStack Auth (our auth system for Swift, not for the SwiftStack Controller), if you authenticate as User “Alexander”, you’d get back a storage URL that looks like That last bit, the AUTH_Alexander, is the name of my Account! In this case, it was automatically created for me by SwiftStack Auth, which by default creates an account for each User, and gives that User full ownership of the Account. Now, if I make a request to that Storage URL, I get back a fairly bland response; I have no objects and no Containers. But I am free to change that – this is my Account, after all!

On the other hand, what if I try to request a similar URL, but with a different final segment; that is, try to access a different Account? Well, when I try to access the account AUTH_Brenda, I get back a 403 Forbidden error response, because I do not have access to Brenda’s data.

Superman LegoNow let’s briefly talk about superusers. If you’re using SwiftStack Auth to create Swift Users, you’ll notice there is a checkbox for making a user a superuser. A superuser has access to all data inside the Swift cluster. If I created a new User named Superman for my cluster, and had Superman set up and authenticated as a superuser, I would be able to see I would be able to see all of Alexander’s or Brenda’s data.

In fact, I can go ahead and outright delete Alexander and Brenda’s Swift Users, so that it is no longer possible to authenticate using their credentials, and Superman will still be able to see and act upon any data that either of them had put in the cluster!

Superusers are not the only way to access Accounts other than the one your User implicitly has ownership of; you can also set up what are called Access Control Lists (ACLs) on Accounts and Containers, for example. This post is already quite long enough without going into detail on other ways to divorce Users and Accounts, though!

I hope this helped you understand a little bit better the difference between Users and Accounts in Swift. The takeaway is that the two are not closely tied together except by convention and for your convenience.

Posted in pedantry, software | Leave a comment

An Intuition On Why Teaching Is Hard

There are some things that are very difficult to teach. For example, nobody has really figured out how to teach programming yet. Many people are pretty good at teaching calculus, but nobody has a 100% success rate, and it’s never easy. Etc, etc.

Some things are not difficult to teach, of course: it is relatively easy to teach someone facts: water weighs 1 g/ml, John Lennon was born in 1940, the sky is blue.

What’s the difference? Well, I think the major difference is that teaching static facts is easy, while teaching things that require some sort of integration is hard. For example, teaching someone the straightforward formula: \frac{d}{dx}x^{n} = nx^{n-1} is actually not very hard, assuming they have a decent understand of algebra. Getting someone to understand what the derivative is, in a general sense, is very hard. Similarly, we have things like Codecademy, which do the equivalent of teaching you formulae and no integration, because it’s not hard to tell someone to copy some text, but it is hard to teach someone how to write programs.

The intuition I had about this the other day is that you cannot transfer knowledge via language; you can only transfer serialized forms of knowledge. Facts like “John Lennon was born in 1940” serialize very well. Integrations between ideas, understanding processes, etc – these things serialize poorly. Have you ever tried to get directions from someone who has lived in the same place their whole life? Their brain understands the terrain at too deep a level to serialize it, and since they rarely need to communicate that issue in language, they have no intermediate forms to serialize for you. They literally cannot advise you as well as someone who is still learning the territory, because that person still has ready access to all the serialized forms of knowledge (“go a mile down First street”, etc).


This might be obvious or well-known, but I thought it was interesting, anyway!

Posted in language, pedantry | Leave a comment

Why I Don’t Care About Bernie Sanders

Two main reasons I don’t care about Sanders:


  1. He’s not going to win the election. He’s not even going to win the primary. And he’s not doing a great job, from what I can see, of forcing the candidates who might win the primary into taking his issues more seriously.
  2. I have long been cynical about politics. I understand why politicians lie, why political progress is slow, why extremism or idealism in a leader won’t get us anywhere (and probably wouldn’t be a net positive anyway); it’s not a cynicism borne of thinking they should do better, it’s about knowing they can’t and not falling for it. I got duped, once: I bought into the whole Obama idea, the hope he was selling, etc. And he — of course, and inevitably — did not bring that to bear. Not that McCain would have been better: he probably would have been worse. But, I think that it’s intellectually dishonest to think both “all politicians are [perhaps necessarily] liars or double-talkers” and “Bernie Sanders has morals and ideals and would stick to them if elected president.”
Posted in politics | Leave a comment

All Security Is Security Theatre

In light of the Ashley Madison leak, I wanted to tell, or perhaps remind, you that all security is bullshit. This applies to physical (e.g. home) security as well as digital security. The moral of this post will be: please do the bare minimum, or slightly above it, required for “reasonable” security; do not worry about going beyond that because you basically can’t.

Physical Security

Physical security, like home security or how to be safe when going somewhere, is mostly about not doing the stupidest possible thing. As long as you’re not doing the stupidest possible thing, you’re getting most of what you can out of security.

Consider home security. Presumably, you don’t want people breaking into your house. You don’t want them to hurt you or steal your possessions. So you try to prevent them from doing so: you close your door, you lock it, maybe you even deadbolt it; you close your windows, maybe you take the time to lock them too, usually. This is all you need to do.

I’m going to make up some numbers here, but they should be fairly representative. Let’s say 100 people walk by your house: how many of them are going to break in and steal your jewelry?

  • If the door is open, maybe 5 people will be tempted by how easy it is
  • If the door is closed, but unlocked, maybe 1 or 2 people will try it, at worst
  • If the door is locked, we’re way below 1%; you’d expect maybe 1 in 1000 people, at worst, to try a number of doors, find them locked, and then look for further ways of entry.

At this point, you’re basically protected from crimes of opportunity. Everything past this point is only protecting you against people who are willing to, both psychologically and physically, expend nontrivial amounts of resources breaking into your home. They can’t just break in right then, because you could come home at any minute, and that’s an extraordinarily high risk. So they have to case the joint, which requires coming back at least a few times, and then they have to scout around for vulnerabilities: an unlocked window, a lock that’s easy to jimmy, etc.

So let’s consider that you now have a small number of people who see your house, which has an appropriate “not-extremely-stupid” level of security, and decide that it still looks worth robbing. Let’s say 100 people reach this stage:

  • If all your windows are locked, that will prevent maybe half of them
  • If all your doors are deadbolted, that will prevent many more
  • If all your doors have difficult-to-pick locks, that will prevent a few more (no lock is that hard to pick)

To get any further than this, you have to start doing things like barring your windows (which makes your day to day life less pleasant and reduces property values), installing alarm systems (which are of dubious effectiveness), build a moat, etc.

Let’s assume my numbers are vaguely right: locking your doors and closing your windows stops >99% of all robbery attempts. At that point, you have to start trading off the cost of implementing further security with the actual effectiveness. Locking your windows every day is annoying and easy to forget, and prevents, based on our givens, less than 1% of all robberies. Probably much less. Is it worth it? Is it worth barring your windows? Certainly not.

Even if you do go through these steps, anyone who really wants to get in is not going to be stopped. If someone wants to hurt you and is willing to take the risks (or, perhaps, wants to hurt you and is the government), they will get in. Most doors I’ve seen in my life would be trivial to break down with a solid kick. Most of the rest would take maybe 30 seconds with a sledgehammer. After that you’re getting into concrete doors, and you don’t want to live that kind of life. These attempts, obviously, expose the perpetrator to much greater risk of consequences, but who cares? their goal is to get in and hurt you: you cannot stop someone from doing that if it’s important enough to them. Kings and presidents have been assassinated, you’ll recall: you do not have half the ability to protect yourself that they do.

Lesson: Lock your doors, close your ground floor windows, and accept that you’ll get robbed if anyone really wants to rob you. They probably don’t: one of your neighbors will forget to lock their door one day, and that’s all you need.

We can also consider personal physical security. Do you need to go to the store? Do it during the daytime if you can. If you can’t, avoid bad neighborhoods on your way to the store. If you can’t do that, stay in well lighted areas as much as possible. Walk upright, don’t have headphones in, don’t play on your smartphone. Bam, you’re golden. Nobody who’s out for easy opportunities to rob or hurt someone is going to fuck with you. Only people who are much more dedicated to their crimes will, and the steps to prevent those people from doing so are as likely to backfire as not: carrying a knife or a gun is likely to end up escalating things and getting you hurt worse.

Online Security

Online security is also mostly about not doing the stupidest possible thing, although I think people are less educated as to what the stupidest possible thing is when it comes to digital, rather than physical, security.

For reference, the stupidest possible things in digital security are: using the same password for your email as everywhere else; clicking on links from strangers without observing where they point to; entering sensitive information (passwords, SSNs, etc) into any website that is not over HTTPS, and, of course, giving out your passwords.

What do you want digital security for? The main thing you have to protect against is what we often call “identity fraud,” which is usually in the form of someone grabbing your credit card information and making some purchases with it. This actually usually doesn’t matter; it’s happened to me two or three times and the remediation in all cases has been calling my bank, explaining that, no, I did not order $3,000 worth of audio equipment shipped to Ohio, can you cancel those charges, please? Okay, thanks! and then having to wait a few days for a new bank card. It could, of course, end up worse than that, but your bank takes these things very seriously, so it’s likely to be fine.

What is actually much worse is someone getting into your email account. Your email account is, to a stunningly large degree, who you are online. If I can log into your email, I am you for all intents and purposes. I can intercept all your personal and professional correspondence, obviously, which is horrifying to think about and potentially damaging to one’s career or reputation if, for example, you have otherwise-hideable medical conditions, or you are into wacky sex things, or having an affair, you say mean things about your boss/friends in confidence, or whatever. Beyond that, though, I can sign you up for anything I want, I get all your bank information, I get complete access to all your accounts. I can go reset your password on everything. I can transfer $500 from your bank account to mine, acknowledge it, and delete the email. I can blackmail you by holding hostage those sexy pictures you sent your SO.

That is why you do not, I repeat do not use the same password for your email as for anything else. Find an email provider with a reasonable history of security, always navigate directly to their website when you need to sign in, and use a different password everywhere else.

You can use the same password everywhere else, depending on how much you care. Remembering (or using something like 1password to store) a zillion different passwords sucks, and most of the services you sign up for are hilariously badly secured already, so it’s not like you’re protecting anything. If you use password A at service S, and password B at service T, you’re insulated against S getting hacked and leaking your password for T. But if anyone bothers to hack T, they probably won’t have any real trouble doing it, anyway, so it’s not like you’re buying a whole lot of security. And, anyway, S is hopefully using a salted cryptographic hash for storing your password, so even if you use the same one at both services, it’s unlikely to tip anyone off.

Beyond using at least a couple different passwords and making sure that you only ever sign into things either (a) with one-off credentials not tied to your other accounts or (b) that are HTTPS secured, you’re pretty much set.

You can do things like disabling javascript to prevent clickjacking attempts, using randomly-generated, high-entropy passwords to insulate yourself from rainbow table attacks, encrypting your hard drive, etc, but the cost of those to your daily experience using your computer is pretty high, and buys you very little.

Let’s imagine a situation to put a point on this. Let’s say you’re extremely paranoid: you log out of everything every time you use it; you keep all your passwords in an encrypted password vault which requires you enter your memorized, long, high entropy password every time you use it; you disable javascript in your browser; you never install software except from trusted sources, over HTTPS, and you check the md5sum of each of them; etc. How can I attack you?

Well, if I’m just me, I don’t have a ton of easy options. You’re safe from me. But you already were!

Let’s say I’m a dedicated blackhat hacker. You’re slightly insulated from me, but how hard would it be for me to set up a MITM attack on you? If you’re already afraid of me, fairly. But what if I just invite you over for dinner one night, and contrive to get you to connect to my wifi network?

So say you’re terrified of me; you know I’m an attacker. What if I make friends with your dad, and one day I tell him about a security update he needs to install for his home router? I say I’ll do it for him; it’s easy to mess it up, and I’m pretty well versed in these things. Oops, you’re out of luck.

Or maybe I break into your house and do it from there. That’s not gonna be too hard, either.

Or, like, I pay someone $5000 to sleep with you and steal your laptop while you’re asleep.

Point being, if I have specifically targeted you, and I have any reasonable amount of resources at my disposal, you’re fucked.

There’s also a few more things to consider: It is unreasonable to assume that the NSA does not have full access to all of your information sent over the web, at this point; any credentials or information you sent over the web before the Heartbleed bug was discovered should be considered compromised; anything you send over any website that you cannot guarantee has patched Heartbleed is still getting compromised. And of course there’s probably a thousand more zero-days compromising all your data all the time.

Using a few different passwords, etc, gets you to that >99% security threshold; after that everything else is painful at best and folly at worst.

All this is to say: if there is anything you wish to communicate that you absolutely cannot tolerate having someone else finding out about, don’t say it online. There is no privacy, there is no security, there isn’t even anonymity.

Posted in pedantry, software | Leave a comment

Patricide is a good word

pat·ri·cide: noun

  1. the killing of one’s father.

Patricide is a noun that describes an action. It is also, of course, the name one can give to a person who has killed their own father. In general, when we refer to people based on their actions, we use the active -er form of the word: one who programs is not a “program” (verb: to write computer programs), they are a programmer. And yet, you would never think to call one who has murdered their father a “patricider,” they are simply a patricide.

This is a wonderful grammatical oddity, which is quite enough for me to love the word all on its own. It is also, of course, a subtle linguistic hint that, after killing one’s father, that fact becomes one’s whole identity. There is nothing left of you: you are no longer Alexander, who is a programmer, you are simply Alexander the patricide. Or, in a culture that wishes to basically expunge you from history, just “Patricide,” although that might get complicated if there is a father-killing spree in your town.

So that’s great too. I mean, I actually hate language that boxes people in and represents them as less than their whole selves, but it’s a very powerful idea. I think we should do it with more words. Take the verb form of your occupation and describe yourself as that. Alexander, the program. Embrace your job as your whole identity; it’s what the industry wants!

Note: the word “engineer” already follows this mold, which is hilarious and didn’t occur to me until after i had written this post and was proofreading it.

Posted in language | Leave a comment

Words That I Know Exist But Don’t Know The Meaning Of: A List

  • obverse
  • the difference between exaltation and exultation
  • the difference between assume and presume (ass/presuming there is one)
  • sanguine
  • Other words like sanguine that I can’t think of right now but regularly run into and only partially decode based on context clues
  • pansexuality
  • pantheism
  • basically any word starting with “pan”
  • lief (??)
  • counterfactual. i could probably give you something approaching a definition but i have no fucking clue what it really means when people use it.
  • Ionian, Corithian(?) and Dorian columns, the differences between
  • alligator and crocodile (as referents, not references)
  • “referent,” unless I used it correctly in the last sentence, in which case I at least sort-of know what it means
  • option select, apparently, because every time anyone (inc. me) uses it someone else says they’re wrong


this list is incomplete. in case you were wondering. i know a lot more words that i dont know what they mean.

Posted in language | Leave a comment

If Reid Duke Were Your Boyfriend

Inspired by The Toast’s series

If Reid Duke were your boyfriend, you would tousle his long hair when he stretched in the mornings, and he would sheepishly say, “It’s getting too long. I really need to make time to get a haircut,” and you would smile indulgently at him even though you love how boyish he looks with it longer.

If Reid Duke were your boyfriend, you’d sometimes pretend not to know how to do simple things like loading the dishwasher, even though you obviously do know, and he would know that you know how to do it but he’d explain it to you gently and patiently with no hint of condescension, and you’d both know that hearing him explain it was the only reason you’d asked, but you’d never admit it and he wouldn’t want you to feel bad about it.

If Reid Duke were your boyfriend, the two of you would compete viciously at everything: who is better at board games, who picks up the check at dinner, who makes better sandwiches. The competitive spirit would only bring you closer together, though; after all, every victory for either of you is a victory for the relationship.

If Reid Duke were your boyfriend, when he went to Pro Tour Journey into Nyx, he would have been wearing underwear you had written “You’re always top 8 in my heart” on when he went on stage to claim his first Pro Tour top 8.

If Reid Duke were your boyfriend, you could tell your parents you were dating a writer, your journalist friends that you were dating a prolific content creator, and your nerd friends from high school that you were dating a professional gamer, and they would all be true, and no one would question your taste in partners any longer. Reid Duke would be happy to introduce himself as each of these things to the appropriate groups, not just for your sake, and not because he’s ashamed of any of it, but because he’s equally proud of all his accomplishments and is comfortable accepting kudos for any of them.

Posted in dating, fanfic, jokes | Leave a comment

Secure, But Not Encrypted

I’ve been going to the doctor a lot lately (knee problem, boring story), and I had to sign a consent-to-being-emailed form. On this form, which I regrettably forgot to nab a copy of to post here, it was explained to me, the patient, that the practice’s use of email is “secure, but not encrypted.” They labored to assure me that their computers are protected by passwords, but that no content is going to be encrypted.

I, of course, am a software developer and understand what this means: namely, that the information is not secure. Further, I’m not even sure what they’re trying to reassure me about, understanding what I do about computers and security. I’m safe against the other doctors in the practice learning my medical history? Or perhaps the assistants and administrative employees? Those people almost certainly could get access if they wanted it, and I don’t care, because it is their job to know enough to help me.

Sending information unencrypted over email is just letting anyone have it. Sending it through an encrypted protocol is giving it away only to the practice’s email provider, the receiver’s email provider, and (obviously) the NSA. Since you’re a doctor’s office, I have no reason to believe you have spent a single minute thinking about your technological infrastructure, and thus no reason to trust your email provider. I use gmail, and I have good reason not to trust Google. So you’re sending my medical information to at least two parties I don’t trust.

I don’t care about this at all. My perspective on security is that all security is security theatre and if someone wants to break into my house or my email or anything else badly enough, they will succeed. But I know this. I don’t care because I am (somewhat) informed. I know that assuming my data is secure is simply incorrect, so I assume that the entire world can see it instead, and make choices accordingly.

I do, however, care pretty deeply that to an uninformed reader of that consent form, who understands the everyday meaning of the word “secure” and has more or less zero understanding of encryption, or email transport, or anything else related to computer security, it sounds like the practice is taking meaningful precautions. I don’t know if it would stand up in court — I believe there are laws saying that when one party is drastically misleading the other party who is direly uninformed on the material, that isn’t valid — but it still pisses me off. I don’t even think the practice knows they’re misleading their patients. They probably don’t know anything about computer security either. But it’s just all so wrong and sad.

Posted in pedantry, security, software | 1 Comment

How To Write A Resume* Worth Reading

I have recently taken on a bunch of hiring at work. In particular, I am now spending a substantial amount of my time at work reading resumes. These are for new grads and intern candidates for software development positions. I have some thoughts on how to write your resume, and since most new grads are not fortunate enough to have access to people who will be reading their resumes, I thought I would write up these thoughts.


I know that writing your resume is hard. There’s a number of competing goals, and it’s difficult to balance them. In addition, many computer science students do not receive adequate training in technical writing, and their only resource is often a harried student resources administrator who would like very much for your resume to be wonderful, but can’t write it for you without most of your information, in the week you have left to apply for jobs.

It’s still important to do a good job. I personally do not grade resumes very harshly, for many reasons. Most of what I am looking for is something like 4 bullet points out of a possible 10, since it’s next to impossible for a new grad or intern candidate to have accomplished anything meaningful. Not everyone is going to be as lenient as me, though, and the less of your resume I have to ignore, the happier I’m going to be, which, unfortunately, will affect my objectivity no matter how hard I try not to let it. If I am the person who reviews your resume, and it lists something like a Bachelor’s degree, the word “Python” somewhere, and a project or two that you seem to have completed (even class projects count in many cases!), I’m not going to turn you down because the rest of your resume is bad, but that doesn’t mean you should try to get away with it!

What a Resume Should Do

The ultimate goal of your resume is to land an interview at the company you send it to. It is not to impress your mother, or make yourself sound good, or “get you a job.” The duty of the resume ends when the person you send it to agrees to give you a phone call. This informs some decisions about what to put on your resume; namely, some amount of “acronym soup”1 is tolerated, and it is actually reasonable to plop down a long list of dubiously useful buzzwords to get someone to notice you or to get past HR. If you knew for a fact that a software hiring manager was going to be the first person to see your resume, you would not list information as desperately as you must when that might not be the case: I have found myself with a skills section that says absurd things like “SQL, MySQL” just because I do not know if I will have to have “SQL” as a separate buzzword. You have to make some odd decisions to play it safe because a resume is not, fundamentally, a representation of the talents you’ll ultimately bring to a company, it is a plea for someone to call you back.

So “land an interview” is not an actionable goal. What sort of subgoals does your resume need to accomplish to fuel the greater effort? The major things to do are:

  • Present enough conventionally mandated boilerplate to not have your resume thrown out
  • Present some relevant achievements
  • Explain what relevant skills you have (indirectly)
  • Explain what your interests are (indirectly)
  • Make you stand out in some way

And the complements to the two indirect ones, of course: leave out anything irrelevant, even if it is an achievement or skill of some sort, don’t mention important skills that you don’t have (either in positive or negative: it should go without saying not to lie here, but also don’t list something like “Worked with a front-end engineer because I don’t know JavaScript”), and don’t make your resume seem like you’re interested in a field or job that is not, in fact, something you want to do.

 Rapid Fire Don’ts

Here are a number of things not to do when sending out a resume for a software development position. Most of these are actually relevant to any resume, but I can’t pretend I know how resumes are evaluated in other industries, and some of these are fairly specific.

  • Do not list skills that I don’t care about, such as:
    • Microsoft Office suite tools
    • Notepad (seriously, I’ve seen this)
    • Any text editor, actually
    • Any productivity software whatsoever, with the exception of tools directly related to the software development process (that would mean you can list git, but you can’t list Trello: Trello is external to the development itself, while git or another VCS is deeply ingrained in how developers work).
    • Things that are wildly outside the ken, such as martial arts, or acting, etc
  • Do not list achievements that are irrelevant to development work, such as:
    • Being an Eagle Scout/Gold Award recipient
    • Employee of the Month at your high school job
    • …your high school job, at all, in general
    • Anything about your minor/second major beyond the fact that you obtained it. This can be bent if you, say, wrote software in the course of research in that field, but in general I don’t care that you took a few Math electives or play the trumpet or whatever.
  • Do not provide your course list. It is not very different from anyone else’s course list, and beyond that, I actually don’t care what courses you’ve taken. If there’s anything extraordinary and unusual, you can find somewhere to squeeze it in.
  • Do not list redundant qualifications. I see a number of resumes where a GPA of 3.8+ is provided, and “Dean’s List” is also somewhere on the resume. I do not need both pieces of information.
  • Do not attempt to quantify your own skills. Tell me in what contexts you’ve used them and what you’ve done by leveraging your skillset, but emphatically do not tell me you are an “expert in Python” or a “JavaScript guru.” I know a lot more about Python than basically any fresh grad2, and if I do interview you I’m going to make you prove you’re an expert, at which point it will come out that you are either a) lying on your resume or b) simply delusional about your own abilities, neither of which reflect well on you.
  • Do not list any skills or technologies that you are not willing to talk about in an interview. If you haven’t used Visual Source Safe in 5 years and you don’t remember how it works, that means it’s time to take it off.
  • Do not misspell technologies you claim to be versed in. It does not speak well for you that you’ve spent 4 years studying it and still think it’s spelled “JAVA.” It’s not. It’s “Java.” Please stop doing this one, people. It hurts me every time.
  • Do not have huge proofreading errors in general. I don’t care about a typo here and there or “it’s” in place of “its,” or whatever, but eventually these things add up and I just start to assume you’re not going to be able to communicate well in the workplace.
  • Do not list frameworks, operating systems, libaries, databases, or anything else that is not a programming language under programming languages. Do not list HTML or XML or CSS under programming languages, even if you shorten it to just “languages.” Seeming like you don’t know the difference between a programming language, a markup languages, and a library is not a good look.
  • And this is perhaps actually the most important one: Do not give me a resume that’s over a page long!

So, Then, Do You Have Any Positive Advice?

Of course! There’s a number of easy things to do to make your resume better. I’m gonna go through them in the order from above.

Present enough conventionally mandated boilerplate to not have your resume thrown out

So I need your name, phone number, and education information. I would prefer that this take up approximately 3 lines of text, because it is some of the least relevant information. Yes, even for a new grad, your education information doesn’t matter much to me: you have a BS in Computer Science from some school, that’s great, but I don’t care about your course listing or your honors program or basically anything else except: I went here from dates X to Y and got my diploma. Many places will insist that you include your GPA, which, again, I don’t personally care about but which it is sensible to include anyway.

Aside: I don’t care about your GPA partially because it’s just not a measure of anything except diligence and partially because my own GPA was merely alright, due to hating school passionately. I seem to be doing okay, though, so I have personal experience of why it’s not particularly relevant.

Beyond that, the rest of what’s conventionally required is actually there for you to use to sell yourself, and so I can’t in good conscience call it boilerplate.

Present some relevant achievements

I want to know every interesting project you’ve done. Any side projects (even pretty small side projects are worth including: if you wrote a Blackjack bot, that’s plenty substantial enough to mention), and any major class projects. A good barometer for whether or not a class project is worth including is, “did everyone else in my class also write this program?” If the answer is yes, it’s not interesting. If the answer is no, mention it.

I also want to know anything cool you’ve done in the software development universe that isn’t a project. Did you go to PyCon? Did you get the Grace Hopper award? Did you do an independent research project with a professor? Those are all awesome and I want to hear about them. Include these.

Finally, I of course would expect to see any relevant work experience here. If you had a prior internship or part time job or something, list it and mention what you accomplished there.

Explain what relevant skills you have (indirectly)

Now, there is a place on your resume for a blunt listing of skills. I’ll cover that a little later on, when I mention some things about formatting. But in general, just seeing something listed on your resume is not a strong signal that you actually have any particular expertise in it. This is unfortunate but true: I have interviewed people who have things listed on their resume that they cannot talk about coherently. Thus I cannot trust a list of technologies without any further evidence of competence.

So, on any projects you list (personal, school, or work), figure out a way to work in the technologies you leveraged to build them. For example:

  • Built a web app in Django to collate TPS reports, including an interactive frontend using jQuery for AJAX requests

That tells me an awful lot more than two disconnected pieces of information, one of which lists Django, jQuery, and AJAX, and other of which merely states “Built a web app to collate TPS reports, including an interactive frontend.” In the first one, I know that you’ve built a project using those technologies. In the disconnected example, I might assume that all your web projects were in Ruby, and Django is only listed because you ran through the tutorial one weekend.

Use this as a general pattern for demonstrating your experience with anything you want to call attention to! You could say, for example,

  • Constructed requirements document for a greenfield TPS reports engine, delineated tasks into User Stories, and got our team set up to work in an Agile way.

Note: I don’t give a shit about anything demonstrated in that last one (except that you gathered requirements, that’s quite relevant), and most of it isn’t something a new grad or intern will have any exposure to, but the point is it’s a fairly flexible template. Most bullet points in your resume should look like:

  • ${created something} ${in a way that demonstrates some knowledge} for ${reason that explains or at least hints at its value} ${and maybe some followup explanation}.

Maybe what you created was improved performance. In that case, you could say:

  • Parallelized TPS report process using Hadoop, decreasing running time by 42%, which allowed our business analysts to have access to their data up to a full business day sooner.

Explain what your interests are (indirectly)

If you’re applying for a web development job, call attention to any web development work you’ve done. If I’m reviewing resumes for a web dev position and I see a lot of bullet points about Android and NLP, I’m going to assume you don’t want to work here. Maybe you actually really like web dev, and it’s a historical accident that most of your work has been in other areas. That’s totally fine! As a new grad, “most of your work” is 0 of your expected lifetime output to many significant figures, and if you just think web apps are awesome, find a way to show me. “Built a toy site in Django to see what the excitement was about” is a huge selling point that you might enjoy the work you’re ostensibly applying for.

Another great way of doing this is a link to a portfolio or your github/bitbucket account. These things are wildly not required for you to get a callback, but if you have them, they’re a great way to demonstrate what you work on when you’re free to choose. This is probably the best way to signal that you have interest in what the company is doing outside of having prior experience in that field.

I assume this goes without saying, but don’t tell me about your non-professional interests. Maybe we’ll get along great and go play ball on the weekend or see concerts together or whatever. But I don’t care, and including such things is bound to hurt you: either I think your interests are bullshit and I subconsciously give you a demerit (I swear, I try very hard not to do anything like this, but it is unreasonably difficult for humans to maintain true objectivity, and you should not risk it), or I think your interests are awesome and I give you a thumbs up, which is a) discriminatory in the hiring process and b) liable to set off alarms that I need to be more objective, and is just as likely to cause me to wildly overcompensate as it is to end up in your favour.

Don’t mention personal things on your resume. It’s a terrible, terrible idea.

Make you stand out in some way

This one is really hard. Most new grads are substantially the same. There are some obvious ways to do this: prior internships or work history, open source contributions, a personal github, and various other harder-to-achieve things like winning well known awards for CS students or having a strong portfolio. It is advisable to do any or all of these things, because the world is a cold and harsh place, but it is not for me to categorically dismiss all those who don’t.

Perhaps the easiest way to make your resume stand out is to not clog it up with bullshit that doesn’t matter. If you went through your resume according to my list of Don’ts, you’re probably looking at somewhere around half a page of content. If you have more than that, congratulations on your upcoming offer from Google; you can stop reading now.

It is a truth universally acknowledged that a resume must be no more than one page, and not much less than one page. But, it is a truth that I, at least, avow, that much of the text on the average resume is of negative value, and should be removed.

So here’s what you do: Take all those bullet points about the projects you’ve done and go into a little more detail. Make them sound cooler. Try not to stretch things too much — I’d much rather a sparse resume than one where it sounds like you have no confidence and have to reach really hard to make anything sound good — but just elaborate a little.

Then, do some reformatting. Make your section titles bigger, or use a bigger font. Make your name on its own line and bigger than necessary. Include some extra line breaks. Now your resume is much more pleasant to read, and is also the magic size.

Try to avoid the temptation to make your resume stand out by getting fancy with the design. If you are really a strong designer, then you might get away with it, but it’s mostly just a distraction. If you’re applying for a design job (or even a front-end developer job, potentially), it might be appropriate to add some flair, but for a normal SWE job it’s not a good idea: you probably won’t do a good job, and the person reading it will at best not care even if you do.

Some Structural Tips

Many people present their skills poorly. I’ve seen a number of ways of formatting your skills presentation, and there’s several ways of doing it that are appropriate depending on your goals. My own resume has a very short skills section, mostly as a result of the places I apply to. I generally apply to small startups, where I have a reasonable assumption that a technical person is going to be the first person to see my resume, so I mostly just list some things to get them out of the way and leave space for talking about what I’ve actually done with the rest of the page. If you’re applying to larger companies where you’re worried about a semi-automated HR screen, you should list many more skills (as above, it might make sense to list several flavours of SQL just in case someone has a checkbox that says “T-SQL” that won’t get checked if you don’t have that string on your resume). And there are other considerations, too: perhaps you would like to fill some more room on the page because you listened to my advice and now have blank space you feel compelled to fill. In that case, choose a more elaborate format for listing your skills!

The general ways of breaking down your skills section are

  • By category: Languages, Databases, Web Technologies, Tools, maybe a catchall, etc. Whatever grouping makes sense for your background.
  • By skill level: Proficient, Comfortable, Exposed To, something like that. Proficient is a reasonable word to use here for the languages or technologies you’re best at; it’s a sort of code word that means “proficient compared to the other categories,” whereas using a word like “Expert” is, as mentioned above, a bad idea. You’re a new grad, you’re not an expert in anything. And if you were an expert in something, you wouldn’t have a whole section for it, because you’re damn sure not an expert in multiple things.

You can mix and match, you can use a crazy table, whatever. But those are the standard ways of doing it, and you don’t want to deviate too much. For example, you could have something like the following:

  • Languages: Java (proficient), Scheme (comfortable), Python (beginner)

or on the other side:

  • Proficient: Java, Ruby | Django, MySQL | HTML, CSS

or, say you want to mix and match across categories to save some space or preserve context. Maybe you do something like:

  • Web Technologies: Python (with Django and Twisted), PHP (CodeIgniter), JavaScript (jQuery, backbone.js)

But, for the love of god, don’t delineate a category and then include examples in it that don’t belong!


If you are listing personal projects and you are able to link to their source, you should. This is a great place to include links to your github, because it means I don’t have to sort through your repos list and try to figure out which ones are worth looking at, and it allows you to link it without making it intrusive or having to find room for it somewhere else.

An aside about github: if your github is all trivial exercises and forks of popular projects that you haven’t actually contributed to, consider leaving it out. If there’s nothing of meat in there it doesn’t help you at all, and if there’s only 1 or 2 projects nestled amongst a background of noise, try to link directly to what is worth looking at. Using github as a place to manage a bunch of things that aren’t really for interviewers to see but that you want to keep track of is great, but if that’s how you’re using it then don’t try to show it off.

Wrapping Up

Hopefully this advice will help you craft a resume that gets looked at. It should help you make your resume punchier and more to the point, and avoid some novice foibles. I can’t guarantee you’ll get callbacks from this, but it will at least lower your false negative rate.


*Résumé. Whatever.

1. “Acronym soup” is a term to refer to long lists of acronyms detailing technologies that you have experience with; think “XML HTML SQL SVN ANT….”

2. I am not an “expert in Python” and I would never claim to be, much less on my resume. This isn’t intended as bragging; it’s intended to drive home how poor people are at evaluating their own skill level.

Posted in hiring | Leave a comment