As you learn to code and learn new programming languages you’ll often hear that different languages are good for different things. Technically you can do just about anything in any language, so for a long time that never meant much to me. Once you get past basic conditionals and loops, there actually are pretty major differences in how easy it is to do different things in different languages.

Here’s a handy example: the other day I wanted to figure out how much I spend on average each month so I could figure out how much I can reliably throw into my RRSP. Okay, use mint, you say. Not so fast there! I only wanted to know about my expenses NOT including RRSP and TFSA contributions, and I wanted to leave out the month I got married because it’s a huge outlier and screws up my average :) If you can get mint to do that, I’d love to hear how.

What I ended up doing was downloading my transaction history as a csv from my bank and manually removing the stuff I didn’t want to include. Then I needed to create monthly totals (so I could see if those looked reasonable) and an overall average somehow. I was hoping I could do that with a simple formula in a spreadsheet, but after fiddling with it for a bit I decided I’d rather poke myself in the eye than stick with that idea.

Python to the rescue! Not so long ago I was a mentor at a Ladies Learning Code workshop about data processing with Python. At the end of that workshop we ended up with a little script that read in a csv, did some processing, and output the results, which is exactly what I needed. I started with that script and ended up with this:

Then I started thinking, that was weirdly easy considering that since college I’ve touched Python twice – once while preparing for that Ladies Learning Code workshop and once while actually mentoring at the workshop. That made me wonder how Java, the language I’ve used just about every day at work for the last nine years, would compare. So I ported my Python script to Java and this is what I ended up with:

In a word, ugh. File processing scripts are not even slightly what Java is good at. Everything I needed for the Python script was part of the Python language. For the Java version, I had to go hunt down a library and add it to my project, which required knowing that there probably was a library, knowing how to add it to my build path, and figuring out how to use it.

Even the least terrible csv library I was able to find for Java inside of five minutes of googling (Apache Commons CSV, if you’re curious) was much harder to use as Python’s builtin csv handling. Java’s date parsing also requires way more steps than Python’s does. And to run this in Java you have to know about main methods and all the boilerplate around them. Even if you just let your IDE generate that for you, you still need to know it exists and what it’s for.

Basically you have to fight Java to do something like my average monthly spending script. You can still do it, but it’s much more work than it has to be. Java is great for big enterprisey systems with APIs and multiple programmers working on different pieces, but it’s kind of painful for little scripts to parse a csv and do some processing. Python, on the other hand, rocks at stuff like that. I hope this helps you understand what people actually mean when they say different languages are good for different things.

It’s pretty common to hear developers joke about how they get paid to Google things. Fun fact: we’re only kind of kidding. An enormous part of my job is Googling stuff.

Tech changes so quickly it’s just not possible to know everything. It’s definitely not possible to keep up with everything, and it’s especially not possible to know the entire tech stack a new job uses. No two company’s tech stacks are the same (we use AWS, play, Java, Ember, javascript, and bootstrap, just to name a few of the languages and frameworks in our app. At my last job we used spring, jetty/tomcat depending on the app, an internal front end framework, Facebook’s hideous sdk, and Flash (AS3) and Unity on the front end), and even if you did magically know all of those technologies before you started, given a few months it wouldn’t matter. No matter what you use right now, things are going to change. You’ll try out a new front-end framework, integrate with a new system, be asked to build a feature that requires a new library, something will happen that means you’ll need to learn something new.

This is why developers spend so much time Googling. We have to learn new stuff constantly. Don’t feel bad about not knowing everything, no one else does either.

Even if your tech stack didn’t change, you would still get asked to build new stuff all the time and honestly, your problem is probably not unique. Even if you already have a plan, it’s not going to hurt to do a quick search and see if someone else has a better way to solve your problem. If you don’t already know how to solve it, Google is here for you. Why reinvent the wheel? You could call that laziness but honestly it’s inefficient to fight with a problem for hours when you could just ask Google for a hint. Work is not an exam, you’re getting graded on how much you produce and how solid it is, not the intellectual purity of your solution. Plus, next time you have to solve a similar problem you’ll remember what you did last time.

Now, you do need to make sure you actually understand the code you found (and that you’re not violating any licences or anything), but if you’re a professional you’re doing that anyway, right? If you don’t understand your code you’re just going to end up wasting time chasing down weird bugs. Don’t forget that software is at least 90% maintenance, you will touch that code again and you need to understand it when you do.

Of course, I’m being a little bit flippant when I say I Google things professionally. A big part of being a professional is knowing how to search, what to search for, and how to tell useful results from dead ends. Learning how to look stuff up is a real skill and it’s one that takes practice. You also need a bit of a knowledge base to tell good results from bad ones. That is, the more you know about, say, Java, the easier it is to tell a good solution from a bad one. A combination of having a feel for the way Java does things and knowing what good Java looks like makes it much easier for me to tell whether that Stack Overflow result is actually a clever solution or whether it’s a filthy hack. Sometimes you do need to use the filthy hack but you should at least know that’s what you’re doing and add a comment about it.

Software development is at least as much about knowing how to learn as it is about knowing stuff in the first place. If you can learn how to search effectively and are willing to brute force (seriously, a huge amount of my college education was banging my head against java until it started to make sense) the conceptual framework that lets you make sense of the results you’ll get when you search, you can be a programmer. It’s not all Google but honestly if you’re good at Googling and are weird enough to actually enjoy programming, you can do it professionally. We like to pretend we’re wizards but it’s mostly Google :)

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

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

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 :)

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.

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 :)

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.

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?

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:

Show up

Try to be friendly

Don’t be a dick

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.