melreams.com

Nerrrrd

“Show me what you build, and I will tell you who you are.”

I think this talk by Eric Meyer is really interesting and worth watching. Be warned, he does discuss his daughter Rebecca’s death of brain cancer (not in detail), so maybe you don’t want to watch this one at work.

Aside from the crushingly sad part, he has some really interesting stuff to say about how the way we build the tools we do (social media like twitter, facebook, linkedin, for example) reflects our values and how that will shape the next generation’s view of what’s normal on the internet. Like he says in the talk, “Show me what you build, and I will tell you who you are.”

When is it done?

“Done” is a surprisingly ambiguous word in software development. Back when I was in college I thought an assignment was “done” if it compiled and produced more or less the result I was expecting. Then I got a job in the industry :)

It turns out “it compiles” doesn’t mean much when you need to ship software that handles edge cases correctly and works in more than one browser and doesn’t throw exceptions when it’s used just slightly differently from the way I assumed it would be when I built it.

Another complication is that people use the word “done” to mean a lot of different things. I’ve heard people say “it’s done, I just need to test it” and “it’s done, I just need to integrate it” and “it’s done, it just needs to go through QA” and “it’s done, I just need to fix a couple of bugs.” It’s certainly useful to know what stage of development a feature is in, but none of those are done.

To me the only meaningful definition of “done” is “ready for production.” That is, is when the developer has tested the feature, QA has passed it, it’s been merged onto the production branch and any regression testing that needed to happen is done. When it’s ready to be deployed it’s done and not before.

That may seem overly picky but imagine how far off the rails things go when one person thinks done means “ready for QA” and someone else on the team thinks done means “ready for production.” If your feature (or project or report) isn’t actually done, your team lead needs to know that whatever other task they give you might get bumped if your original task comes back from QA with bugs. Obviously you should aim for bug free features but in reality things don’t always go according to plan. That’s why we have a QA department in the first place.

And to go on a bit of a rant, that example above of “it’s done, I just need to integrate it” is not even slightly done and is almost always a terrible idea. If you’ve developed something outside of the system it’s going to be a part of, you’ve exposed yourself to an enormous risk of terrible surprises. Sure, you’ll be fine if you just happen to have a perfect understanding of every little quirk of the larger system, but let’s be honest; you do not. Unless it takes a truly intolerable amount of time to compile the main system, you will actually save time in the long run by building your feature directly where it’s going to be used and just getting up for a drink of water or something while your project compiles. You’re almost guaranteed to have to compile repeatedly while you get your feature integrated anyway, so you’re really not saving any time by developing in isolation. Now, the plural of anecdote is not data and other people have probably had different experiences, but I have personally never seen that turn out well and strongly advise against it. Okay, rant over.

We like to pretend software development is perfectly logical and unambiguous, but you’ll actually run into issues like different definitions of done all the time. Even if you feel dumb doing it, it’s often really helpful to ask teammates exactly what they mean. A surprising number of the problems you’ll run into developing software are just miscommunications that could have been cleared up with a five minute conversation at the beginning of the project. Interfaces between client and server code in particular can be tricky. I’ve personally had to throw out work because I misunderstood what the client team actually needed and built something that was pretty close but not quite right.

Just because you think you know what your teammates mean when they say something as simple as “done” doesn’t mean you actually do. I’d love it if we could all agree what done actually means, but until then you can save yourself a lot of trouble by asking questions.

Why your QA department is smarter than you

Something that’s baffled me for a long time is the animosity some programmers have for the QA department. It’s incredibly frustrating to try to get a feature out and have QA find bugs over and over, but that’s not the QA department being jerks, that’s them doing their jobs properly. QA people actually do a lot of awesome things for us developers. They protect us from releasing a broken product and looking like dumb jerks who don’t care about doing good work. They give us bug reports that actually make sense and can be reproduced. They protect us from the wrath of the thousands of angry people who just wanted to be able to use the thing we released.

QA just wants the project to work when it comes out, which is the exact same thing I want. I don’t want end users to have to wonder whether I’m terrible at my job or whether I just don’t care. Personally I’m a terrible tester, but if a product comes out broken there’s no way for end users to tell a dev who tries really hard but isn’t good at testing from one who counted the minutes until they could go home. I don’t want to look like a fuckup. QA protects me from that, which is basically the nicest thing they could possibly do for me.

Another great thing the QA department does is produce usable bug reports. If you don’t appreciate good bug reports, you haven’t worked in the industry for very long. I have had to try to work with terrible bug reports that had none of the details I needed, were not reproducible, were duplicates, and even reports of totally predictable problems caused by continuing to work with a broken account. A good bug report is a thing of beauty and you should appreciate it! Having a clear set of steps that reliably reproduce a bug saves you so much work. So much! This is extra true of game development where the lack of a single linear path through the product produces some truly weird bugs.

Aside from protecting me from looking like I’m bad at my job, QA also protects the whole team from the many angry people who will flood your customer service and social media with rants about how your product is junk and you should be ashamed of yourselves and they want a refund yesterday. Nobody wants to disappoint their customers, and no one wants to deal with that kind of PR nightmare. You might think that a few angry people are no big deal, but they can really hurt your business and they can hurt your whole industry’s reputation. Toward the end of 2014 so many big-budget AAA games shipped broken that it shook customer’s confidence in the entire industry. Obviously no-one’s releasing numbers about how doing a bad job hurt their sales, but it only makes sense that there is now a huge pool of people who simply will not buy a game until they hear from other players that it actually works.

Given all the great stuff QA does, why don’t they get more respect as a group? Well, in general the tech industry has a problem with fixating on developers to the exclusion of basically every other job title. It’s also not unusual for project managers and team leads to see QA as an obstacle to release the features that upper management is pressuring them for, which leads to nobody else on the team giving QA the respect they deserve.

QA is not just important, they want the exact same thing you do: to put out a good product. But if the rest of this post didn’t convince you, read How to lose $172,222 a second for 45 minutes and then tell me QA isn’t important :)

Get out there and vote!

If you didn’t already vote in the advance polls, get out there and vote! Remember, if you don’t vote you don’t get to complain about the government ;)

If you’re not sure who to vote for, have a look at these 25 reasons Harper is bad for Canada, or Harper Watch, or shit harper did. Or just look at the news lately. If that’s not a reason to vote Anyone But Conservative, what is?

But wait, there’s more! In terms of reasons to vote for anyone else, Harper is the gift that keeps on giving:

Harper’s “old stock Canadians” line is downright racist and xenophobic

Harper: Niqabs ‘Rooted In A Culture That Is Anti-Women’

A detailed timeline of Stephen Harper’s weird, racially divided vision of Canada

The day Canada’s white supremacists saluted Stephen Harper

Harper’s proposed terrorism travel ban borders on racism: Toronto activist

Harper’s new Australian spin doctor is a raging anti-immigrant racist

Stephen Harper’s War On Women

Stephen Harper’s comments on missing, murdered aboriginal women show ‘lack of respect’

Canada’s Prime Minister Refuses To Take Additional Refugees After Backlash Over Drowned Syrian Boy

Premiers Say Ottawa Cutting Health Funding By $36 Billion Over 10 Years

C-51 will remake Canada in Harper’s paranoid image

It’s official – second class citizenship goes into effect

Harper Named World’s ‘Worst Climate Villain’ After Damning Report

Thanks to the All the Canadian Politics tumblr for that list of links.

Obviously you have the right to make up your own mind, but those are some pretty compelling arguments to vote Harper out. I am not going to pretend every political party is equally good for Canada when that is just not true. If you agree that anyone but Harper would be better, votetogether.ca will tell you which candidate in your riding has the best chance of beating the conservative candidate.

The mythical man month

In the programming field, it’s pretty rare to find a book that’s still relevant even five years after it was published. The Mythical Man-Month is still useful forty years after it was first published, which is either amazing or depressing depending on how you look at it.

What depresses me about how useful the book still is so long after it was written is that in the forty years since, we clearly haven’t learned that much about how to run projects. I first tried to read The Mythical Man-Month ages ago, and I got so frustrated about how little we’ve learned since it was published that I had to set it down. Then I completely forgot about it for a few years because I’m just that organized :) I finally finished it this year, and it’s just as relevant as ever. By all rights everything in that book should be totally obvious and taken as a given by every project manager out there, but sadly it’s not. It is, however, kind of comforting to know that other people have run into the same problems I have.

The amazing part of The Mythical Man-Month is how clearly it shows that the actual programming is the easiest part. Code is simple compared to trying to coordinate a large team and hit a deadline, but as programmers we seem to get hung up on the easy part and largely ignore the hard part. One of the many terrible ironies of programming is that a field that attracts introverts who just want to be left alone to code actually requires huge amounts of communication if you want to get anything meaningful done. For me and probably for most other programmers the code is the fun part, so it’s understandable that we’re not as good at communication as we should be but eventually we’ll grow up as an industry, right?

As sarcastic as that sounds, I think a large part of what we need to do as an industry is accept that things just aren’t as easy as we wish they were and learn to work around it. It’s pretty similar to the way children grow up and understand that the world isn’t as simple as they thought and learn to work around it. I and every other programmer ever have massively underestimated how long something was going to take, and no doubt  we’ll all keep doing that. But understanding that underestimating tasks is common allows you to leave extra space in the schedule and/or prioritize features so you know what can be cut if you aren’t going to hit your deadline.

Basically we just need to learn to account for human nature. Should be easy :)

You don’t have to be a developer

This is a follow up to my post about digital literacy and learning to code. I want to be clear that while I believe everyone should have the opportunity to learn to code and the basics should be taught in school, not everyone has to be a developer or even any good at coding or feel like they need to pour hours and hours into it when they hate it. People seem to get the idea that learn to code initiatives mean everyone! must! learn! to! code! which is not even slightly the case. We just want everyone to be able to make a choice about whether or not they’re interested instead of assuming they’re not welcome.

If you try out, say, a Ladies Learning Code workshop and you come out of it thinking you’d rather have spent the day digging a ditch, great! I started college with a few people who went to all the trouble of applying, getting into the program, and going to class for weeks or months before deciding it wasn’t for them. If you can skip all that hassle and find out in a single day and a measly $50 that code isn’t for you, that’s honestly fantastic. Now you can focus on something you actually like doing instead of something that makes you miserable.

Before you decide code is definitely not your thing, I do have some advice. First of all, learning to code is hard. You’re learning a whole different way of thinking, it takes time to get good at that. Don’t feel bad if you’re not good at it right away. People have different learning styles too. Plenty of my classmates disagreed about which teacher’s explanation of a given concept was clearer. If coding just doesn’t make sense to you, it could be because your teacher isn’t explaining things in a way that makes sense to you.

Or maybe you’re just not in a good headspace to learn a really intense new skill right now. Honestly, if you’re a new parent I don’t recommend trying to force yourself to learn to code. Looking after a tiny human is quite enough stress to put on yourself. If you’re excited about code by all means give it a shot, but if you feel stupid all the time it’s absolutely not because you are stupid, it’s because you’re brutally sleep deprived and stressed out and operating at a huge handicap. Code can wait until you start sleeping regularly again.

All that said, if you understand code just fine but you’d rather watch paint dry, or don’t understand code and would still rather watch paint dry, go do something you actually like! Code is not the only worthwhile thing you can do. Have you ever seen an interface a programmer designed? It was awful, wasn’t it. If you like tech but not programming, you could be a UI designer, an artist, a marketer, a community manager, a tester, a customer service rep, a graphic designer, a copy writer, an admin, a game designer (the easiest way to get to design games is to build your own but that’s not the only way), an animator, an office manager, a level designer, the list goes on and on and on.

If you want to code, great! If you would rather do anything else, great! Don’t ever feel like programming is something you have to do whether you like it or not.

Digital Literacy

One of a number of places I volunteer is Ladies Learning Code’s Victoria chapter (you can also find them on Facebook, Meetup, and Twitter). What we’re all about in the Victoria chapter is digital literacy for everyone.

To make sure we’re all on the same page, I’m defining digital literacy as the ability to find your way around and get things done on desktops, laptops, tablets, smartphones, and to be able to find your way around on the internet in terms of being able to find and share a link, send and receive email, post and reply to posts on social media, search for the information you need, and recognize blatant scams.

Considering how many of our jobs involve computers, if only for a little word processing and email, it’s pretty clear why digital literacy is important. What might be less obvious is how important it is that everyone get the opportunity to learn a little bit of code, which is the more in-depth form of digital literacy.

There’s been plenty of debate over whether everyone should learn to code or if everyone should be taught to code in school, which frankly is pretty boring. Code is important for the exact same reason science is important: “Because the world is not magic.” Just like everyone deserves to know that the physical world is not magic, everyone deserves to know that the digital world is not magic either. Computers are not magic, code is not magic, software in general is not magic, and the internet is not magic (printers, on the other hand, are infernal machines that feed on human misery). When these things are all such important parts of our daily lives, it’s absolutely necessary that all of us have a basic understanding of how they work.

It’s not that everyone should be experts who are able to develop an entire app on their own, but to quote @alicemazzy: huge diff btwn not knowing how to use a hammer well and not knowing a hammer is a tool that exists that solves a certain class of problems. Everyone should be taught what kind of problems are solvable with code and what sort of problems are created with code. You don’t need to be an amazing developer to understand that analyzing a spreadsheet of registrant data to figure out which events had the most attendees is a problem you can solve with code and that spam is a problem someone else created for you using code. So is terrible software (Ashley Madison, I’m looking at you. Ethical issues aside, if you charge a premium for security your service should actually be secure).

The same way you deserve to know that if a diet or a deal sounds to good to be true it most certainly is, you deserve to know that a Nigerian prince is most certainly not in need of your help and that bankofmontreeal.com is not a site where you should enter your password. If you’ve gone to a single html/css workshop like the ones Ladies Learning Code offers, then you understand how easy it is to build a totally convincing looking website. It’s not magic, it’s just a bit of html and some tedious css pixel pushing.

If you’re going to spend any time on the internet, you need to and have the right to understand the basics of how it all actually works. If you don’t, then you’re stuck with the internet equivalent of hoping that salesguy down at the used car lot is honest. Do I really need to tell you that’s a bad place to be?

Showing up is my secret superpower

Or, networking for misanthropic nerds.

I’m shy, awkward around people I don’t know well, and honestly kind of a dork. So how is that I got three of the four jobs I’ve had since college by knowing people? I show up. That’s seriously it. Physically show up to events, make a minimal effort to be friendly, and you will get to know people who will either introduce you to someone who will offer you a job or offer you a job directly.

So let’s get into details. When I say “events” what am I actually talking about? User groups, code camps, meetups, developer get-togethers, conferences, etc. Victoria is not a large city and we still have a wealth of meetups, your city almost certainly has some too. Google is your friend here, as is twitter and other social media. I found out about whiskydev because a friend tweeted about it. At whiskydev I met a friend who introduced me to my new boss, and now I work at an awesome startup.

If you’re particularly shy, I recommend user groups or meetups where someone gives a talk. How do you know the group is having someone give a talk? They’ll usually announce the speaker and topic ahead of time because they’re excited about having an actual speaker (depending on the group’s topic, it can be a huge pain to find someone to speak so organizers are usually pretty stoked about finding someone) and so that people who either don’t care about or love that topic can make plans accordingly. Talks are easier for shy people because a) you can spend most of your time at the meeting quietly taking notes, and b) afterwards you can ask people how they liked the talk instead of agonizing over how to start a conversation. Not that I’ve ever done that.

Another tip for shy people or for people who are really serious about networking is to volunteer. I volunteer with a number of organizations and I speak from experience when I say there is no such thing as too many volunteers. Come early and help set up, stay late and help clean up, or ask the organizers if they need volunteers for anything. The answer will almost certainly be yes, and now you’ll have a defined job to do which makes it way easier to talk to people.

It’s great if you can be friendly and talk to people, but the first step is just physically showing up. Start there and you’ll be fine.

But to be fair, I have to mention that it is possible for showing up to backfire horribly. If you show up and act like an asshole, word will spread. Victoria in particular is a very small town when it comes to tech. The person you’re a jerk to today could easily be friends with the team lead who’ll be interviewing you tomorrow. On the upside, you kind of have to work at it to be enough of a jerk that someone would tell a friend not to hire you. People are generally pretty forgiving and we all know what it’s like to put our foot in our mouths. Just don’t be a dick and you’ll be fine. That doesn’t mean you can’t have opinions, just that you should phrase them as opinions. For example “I hate working with javascript” is just an opinion, but “javascript sucks and only shitty programmers use it” is going to make you look like a jerk.

And one more tip, particularly for students: class counts as networking. Your professors have probably had students before you, and certainly know people in the industry. Those former students may be the ones interviewing you or asking your professor about you. People your former classmates work with might also ask them what you were like as a classmate. Think about what you want them to say before you show up late and blow off assignments. This applies to your current job as well – just like you aren’t going to stay in one place for your entire career, neither are your coworkers. If you interview somewhere a former coworker now works, what are they going to say about you if the interviewer asks them?

To summarize, my tips for networking are:

  1. Show up
    1. Try to be friendly
  2. Don’t be a dick
  3. For extra credit, volunteer

That’s all you need to do to make contacts who might one day help you find a job. “Networking” can sound like something only slimy salesdroids do, but it’s really just showing up and trying to be friendly.

How javascript is like a board game

Javascript is much more like a board game than you might think. Let me tell you a story to explain what I mean.

I used to be convinced I just didn’t like board games. I’d played the usual Snakes and Ladders, Sorry, Risk and Monopoly as a kid, and I could happily go without playing any of them ever again. Especially Monopoly. At least the other ones had an end in sight, even in Risk there was the hope of a quick and merciful rout, but Monopoly always seemed to end with people forfeiting just to get the game over with.

Then friends of mine started introducing me to board games that didn’t suck. Games like Clue and Red November and Space Alert and Ticket to Ride. It turns out I like board games after all, I just don’t like shitty board games.

Javascript, as it turns out, is remarkably similar. I used to think javascript just sucked, then I started working with ember. It turns out I don’t hate javascript after all, I just hate shitty javascript. All of the javascript I’d worked with pre-ember was a totally structureless mess – which I freely admit was partially my own fault. The vast majority of my programming experience is in java using frameworks like struts and spring which enforce a lot of structure. Server devs, myself included, don’t always know what to do without a framework enforcing some structure on our code.

Ember is an extremely opinionated framework, which as a veteran of rigid java frameworks I find comforting and familiar :) It also takes quite a few architecture decisions out of the developer’s hands, which is tremendously helpful if you’re a server dev with no interest in reinventing the wheel. Ember certainly isn’t the right choice for every single project, but it works very well in the context I’ve used it in and lets me get my front end tasks done quickly so I can go back to the server side development I prefer.

The moral of the story, in case you haven’t been paying attention, is that before you decide something sucks make sure you’re not just using it wrong.

The most important word a project manager can ever learn

There is an amazing, near magical word that can save projects, hit deadlines, prevent burnout, and gain the respect of your team. Sadly, few project managers seem to know it. What’s this magical word? “No.”

Really, it’s that simple. Just saying no (respectfully, in the right situation) can do all of the amazing stuff I listed. It’s not a guarantee of success, but it will give you a fighting chance.

How does “No” save projects? If you don’t commit to more than your team can actually do, your project’s odds of success skyrocket (this isn’t news, is it?). If you say “No” when someone tries to add features without taking other features out or pushing out the deadline, again, that can only be good for your odds of success. If someone tries to change a feature repeatedly, say no until they figure out what they actually want.

How does “No” hit deadlines? If you have too much work for the time you have left, say no to some of it or say no to the deadline. Developers are not magicians, we can’t fit infinite amounts of work into a fixed time period. Say no to some features planned for the next release if you know they aren’t going to fit. Say no if you can only hit the deadline if everything goes perfectly.

How does “No” prevent burnout? One of the biggest causes of burnout is working excessive hours. If you say no to unreasonable deadlines, like magic your team will be able to get everything done on time without living at their desks. They’ll also be happier because they’re being treated like people instead of cogs that can be replaced when they wear out.

How does “No” gain you the respect of your team? Developers actually aren’t idiots. We can tell when you’re sacrificing our time to make yourself look good or because you’re scared to stand up to your boss. We can also tell when you got us the best deal you could in the face of political pressure to manage the project incorrectly, and we will respect you for that.

So if “No” is so awesome, why won’t people say it? Because they want to be nice, because they want to be seen as a go-getter, not a downer, because they’re afraid they’ll never get promoted if they say no, because they’re afraid to stand up to their boss, etc etc. Those are all compelling reasons, but here’s the problem: refusing to say no doesn’t work.

Sure, you look good in the moment, but when it’s time to deliver and the product is buggy or doesn’t have all the features everyone was expecting, you’re in much bigger trouble than you would have been if you had just said no in the first place. If you do that repeatedly, all you get is a reputation for not delivering. If you don’t want people to trust you that’s your call, but you’d better be amazingly charming (or related to the CEO) if you can’t actually get things done.