melreams.com

Nerrrrd

Degrees aren’t everything

A common worry I see in self-taught developers is that not having a degree means that you’re not a good programmer and no one will hire you. I’m not going to lie, having a degree does make it easier to get an interview, but it in no way guarantees that everyone with a degree is a better programmer than everyone without.

Here’s a fun fact about hiring developers: having a degree tells interviewers so little about whether you can code that people came up with the idea of asking candidates to code a very, very simple math “game” called fizzbuzz to figure out if you can write a for loop all by yourself. I’m completely serious, in the mid-late 2000’s fizzbuzz was all over the programmer blogosphere. If you poke around online you will likely find a bunch of criticism about how fizzbuzz is too simple to tell you anything interesting about a junior programmer candidate, which I think is true but is not the point of this post.

Three women of colour having a meeting in a boardroom
Photo provided by WOCInTechChat under a CC Attribution-ShareAlike License

Back at my point, it sounds completely ridiculous that you would need to ask a new college/university grad to prove they can write a for loop and a couple of conditionals. How could someone graduate and not be able to code? That question really deserves its own blog post, but part of it is that memorizing facts for a test is a very different skill than writing code on the spot to solve a problem.

Ridiculous or not, people started asking developers to code fizzbuzz for a reason and it’s not because hiring without it worked so well. Fizzbuzz exists as a programming concept because interviewers needed a quick way to weed out people who simply couldn’t program at all.

If you don’t have a degree, don’t feel bad. If you can program at all, then you’re already ahead of the game. You’re probably just as good a coder as anyone who does have one. In a lot of ways being self-taught is more impressive because once you make the decision to go to college/university you’re essentially locked in. Aside from feeling like you have to get your money’s worth once you’ve started paying for a degree, there’s a massive amount of social pressure not to drop out and feel like you’ve disappointed your family and friends.

If you study something on your own time, on the other hand, then it’s much easier to just stop when you’re bored or it’s hard or you’d rather go have a pint with some friends. When nobody will know or necessarily care that you stopped, it’s a lot harder to keep going.

To be fair, having a degree/diploma/certificate from a bootcamp/etc does open doors, and you can end up with really frustrating gaps in your knowledge if you’re self-taught. My husband is a sysadmin but he grudgingly does a little bit of programming when he has to (he’s weird and thinks setting up servers is more fun than writing code). Not so long ago I had to tell him about maps/associative arrays/dictionaries because the last programming class he took was in high school and the language they used didn’t have maps. Turns out there was a point to all the time my teachers spent hammering datatypes into our heads in college after all :)

A degree or a diploma doesn’t mean anyone is special or a better programmer than you are. It really just means they had the good luck and inclination to pick up a degree and some ability to follow through, at least when a large amount of money and the prospect of their parents being disappointed is on the line. Who knows, maybe you’ll be the one asking new grads to code fizzbuzz one day.

Different languages are good for different things

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:

# Import the csv library
import csv
import datetime

# Open the statement file
statement_file = open('./statement.csv')

# Convert it to a csv_data structure
statement_data = csv.DictReader(statement_file)
current_month = -1
current_year = -1
months = 0
grand_total = 0.0
running_total = 0
# Loop through each of the rows
for transaction in statement_data:
    # deposits have a blank in the withdrawal field, we only want withdrawals
    if transaction['withdrawal'] is not '':
        #convert the string date to a date object so we can get the month
        date = datetime.datetime.strptime(transaction["date"], '%d-%b-%Y')
        #every time we hit a row where the month doesn't match the month from
        #the last row we know it's a new month and we need to update current
        # month & year and increment the month count
        if date.month != current_month:
            if current_month > -1:
                months += 1
                #print current_month instead of date.month because date.month
                #is the new month
                print(str(current_month) + "-" + str(current_year)
                      + " monthly total: " + str(running_total))
            current_month = date.month
            current_year = date.year
            running_total = 0
        running_total += float(transaction["withdrawal"])
        grand_total += float(transaction["withdrawal"])

# one more print statement for the last month in the file
print(str(current_month) + "-" + str(current_year) + " monthly total: "
      + str(running_total))

average = grand_total / months
print("avg: " + str(average) + " over " + str(months) + " months")

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:

import java.io.FileReader;
import java.io.IOException;
import java.io.Reader;
import java.text.DateFormat;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;

import org.apache.commons.csv.CSVFormat;
import org.apache.commons.csv.CSVRecord;

public class Calc {
    public static void main(String[] args) {
        try {
            int monthCount = 0;
            int currentMonth = -1;
            int currentYear = -1;
            float grandTotal = 0;
            float runningTotal = 0;
            // open the statement csv
            Reader in = new FileReader("statement.csv");
            // parse it into CSVRecords so we can get values out more easily
            // unlike python this CSV library doesn't seem to automagically
            // figure out what a header row is so I had to add the headers
            // manually
            Iterable<CSVRecord> records = CSVFormat.DEFAULT.withHeader(
                    "account", "date", "desc", "num", "withdrawal", "deposit",
                    "balance").parse(in);
            // loop through each of the rows
            for (CSVRecord record : records) {
                String dateStr = record.get("date");
                String withdrawalStr = record.get("withdrawal");
                // deposits have a blank in the withdrawal field, we only want
                // withdrawals
                if (withdrawalStr != null && !withdrawalStr.equals("")) {
                    // java requires a lot of boilerplate around parsing a
                    // string into a date that we can get a month out of
                    DateFormat df = new SimpleDateFormat("d-MMM-yyyy");
                    Date transactionDate = df.parse(dateStr);
                    Calendar cal = Calendar.getInstance();
                    cal.setTime(transactionDate);
                    // every time we hit a row where the month doesn't match 
                    // the month from the last row we know it's a new month 
                    // and we need to update the current month and increment 
                    // the month count. technically we can get the month 
                    // using transactionDate.getMonth() but that method is 
                    // deprecated and I'm trying to set a good example
                    if (cal.get(Calendar.MONTH) != currentMonth) {
                        monthCount++;
                        if (currentMonth > -1) {
                            // in java months start from 0, add 1 so we get
                            // nicer looking output
                            System.out.println((currentMonth + 1) + "-"
                                    + currentYear + " monthly total: "
                                    + runningTotal);
                        }
                        currentMonth = cal.get(Calendar.MONTH);
                        currentYear = cal.get(Calendar.YEAR);
                        runningTotal = 0;
                    }

                    float withdrawal = Float.parseFloat(withdrawalStr);
                    grandTotal += withdrawal;
                    runningTotal += withdrawal;
                }
            }
            // one more print statement for the last month in the file
            System.out.println((currentMonth + 1) + "-" + currentYear
                    + " monthly total: " + runningTotal);
            float average = grandTotal / monthCount;
            // the one convenient thing java does here is 'autoboxing' - it
            // automatically converts non-strings into strings when you try to
            // add them to a string
            System.out.println("avg: " + average + " over " + monthCount
                    + " months");
        } catch (IOException | ParseException e) {
            e.printStackTrace();
        }
    }
}

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.

I Google things professionally

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.

two women of colour working together at an Apple laptop
Photo provided by WOCInTechChat under a CC Attribution-ShareAlike License

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

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