Why we started a dev boot camp for women in Utah

Troy Leland Shields
Weave Lab
Published in
9 min readNov 28, 2018

For a long time I daydreamed about teaching software development as a side project, so when my wife expressed an interest in enrolling in a code bootcamp we decided to start our own instead: Parallel Learning, a software development bootcamp for women in Utah.

I had had some experience teaching at a bootcamp before, but we wanted to try something new. Specifically, we wanted a very small class size, and we wanted to use Go to teach programming instead of focusing mostly on front-end web development.

Weave, fortunately, was extremely supportive of this side-project from the very beginning and even offered to let us use the office for class space.

I spent a few months preparing lesson material in my spare time. We then convinced three of our friends to give up their weeknights to be guinea pigs in our first class. Andrea the school teacher, Holly the graphic designer, Buffy the recent college grad.

Our pilot program spanned the entire Summer; we met three nights per week and I did my best to teach four women with little-to-no background in software how to be developers. It was a smashing success, probably!

Our philosophy at Parallel Learning is that successful developers are self-taught anyways, even if they have a four-year CS degree. Technology is changing so fast and so often that someone who can learn only in a classroom will unfortunately be pretty helpless in the real-world of software development.

So the goal is not necessarily to create developers, it’s to get them to a point where they can teach themselves to be developers if they really want to. Whether or not we are successful at that remains to be seen, but in the meantime we can answer a few questions that we often get about Parallel Learning.

Why Women?

A surprising number of people ask us this question when we talk about Parallel Learning. They seem to think we’ve cracked the code on how to help women learn to code, but that the method is unfortunately ineffective on men.

The real reasons are far simpler than that. We started Parallel Learning for women because we believe the following things:

  1. There is a distinct lack of diversity in tech (especially in Utah), and there is value in changing that
  2. Being a software developer often comes with a lot of flexibility, making it an attractive career choice for women who also want to raise a family or have raised a family
  3. Many women will simply feel more comfortable and open in a group of exclusively women
  4. A larger proportion of women than men self-selected out of a technical degree back when they were in school

That fourth point is important.

Many bootcamps cast a wide net to help teach as many graduates as they can; we feel this has the unfortunate side-effect of giving a bad reputation to the dev bootcamp model in general. We wanted our approach to be a bit different: small class sizes, allowing us to look for a very specific type of student.

Our student is someone that should have chosen to get a 4-year technical degree when they were in college, but did not because they either (1) didn’t know it was an option or (2) they looked at the field and recognized they didn’t fit the typical mold. While this certainly describes some men, it’s likely that a higher proportion of women got cheated out of their opportunity to become software developers simply because of demographics.

If you doubt the efficacy of that then I will point to my own experience in college as a white male. I nearly chose not to pursue software for this exact reason. I had incorrectly assumed that to be a developer you had to start learning how to code when you were an early teen, so I figured it wasn’t for me. If even I can feel some tinge of being an outsider, imagine how much worse it could feel for someone going into tech in Utah who is not a white male.

Why Not Frontend?

The prevailing wisdom from most dev bootcamps is to teach web-dev, starting with the front-end. This means tackling HTML and CSS before any “real” programming is taught.

There are at least two big benefits here: (1) students get visual feedback while they are learning—which will be important when they start learning JavaScript — and (2) students can deploy these static assets to the Web via Github Pages. This means they now need to learn HTML, CSS, and Git before they even hear the word “variable.”

This, in our opinion, is a lot of time that could be spent more valuably. Students expend a lot of effort working through the frustration and nuances of web design. That frustration is very real and deserved, but it is not a blocker for people to self-teach programming; meaning, most new developers can use online resources to successfully teach themselves HTML and CSS, in our opinion.

Our philosophy at Parallel Learning is that if it’s not a blocker to self-learning then it’s not worth spending energy on in our short time together. That means HTML and CSS are out — at least in the beginning. Instead, we teach our students Go.

It’s hard to argue, however, that there is value in having visual feedback when first programming. For that reason, we lean heavily on goplay.space; a browser-based playground for executing Go.

This fantastic tool comes complete with a Turtle Graphics mode where an adorable gopher executes your program to draw a picture. Students get to play with variables, functions, loops and if-statements, all before installing Git or Go on their laptops.

True art

We later transition to writing CLI programs that will draw an image in-memory using this drawing library and save it to a file on disk instead. The students first got to watch the program play out in real-time, but now that we’ve gone offline they have to think mentally about how the program executes. They still get to see the result visually, though. Eventually we remove the visual component entirely to build more and more complex applications.

Why Go?

Weave is a huge believer in Go and the value it brings as our backend language. There are many great reasons to choose Go for your company, and while there is some overlap, those are not the reasons we chose to teach Go at Parallel Learning.

There’s actually at least one big reason not to choose Go for students: compared to JavaScript or Python, there really are not a lot of great, beginner-friendly resources online. Most Go tutorials that I’ve seen assume you are coming from another language, which is completely useless to a brand new student.

While that’s too bad, there are still enough good reasons that make it worth using Go as a student’s first language, even if they never pick it up after leaving our bootcamp. Again, the goal is not to create Go developers, it’s to enable self-learning.

Go values simplicity

Clear is better than clever.

Go Proverb

Go strives for simplicity in all things. The language is small and lacks many sexy, useful, or just convenient features that other languages have — all in the name of keeping the language simple. What’s even better is that Go developers have really adopted this philosophy as well. Just ask the redditor who made this comment when debating the idea of adding map/reduce functionality to Go:

Go code is simple, that’s what we love about Go, it is one of Go’s major selling points. — /u/Paradiesstaub

While I personally would love to have the ability to map each value in an array in Go, there is a ton of value in knowing that our students aren’t going to come across some syntactic sugar that obscures the way a program works before they are ready.

The language is imperative to a fault (if you don’t believe me, look at error handling in Go). This is exactly what you want when teaching new students, because there is no magic and there is usually one, idiomatic way to do something.

Go values stability

It is intended that programs written to the Go 1 specification will continue to compile and run correctly, unchanged, over the lifetime of that specification

Go docs

I went to a JavaScript meetup recently after having been away from the JS world for some time. After listening to the presentation I had the distinct feeling, “Wow, I thought I at least kind of knew JavaScript but apparently I was wrong.”

There were so many new features and tools shown that it just didn’t look or feel like the language that I had used before. While it’s nice that JavaScript developers can constantly enjoy new and interesting features, it’s not great that students might feel completely lost between code written last night and code written two years ago.

That is guaranteed not to happen with Go, because the language designers are extremely hesitant to change anything. Developers can go look at code from the standard library that has been around since Go 1.0, and it is going to look and feel just like code written today for Go 1.11.

Go comes with tooling

I promise this is my final criticism of JavaScript, but holy cow the story about tooling is a nightmare. There are so many tools that do the same or close to the same thing and they are constantly trying to replace each other.

:face_palm:

Furthermore, there are plenty of opinions about how to lint and format your code, but many text editors are not configured to handle this for you by default. So, students end up writing code that never gets automatically formatted and it’s a huge mess. Then they ask me for help on an issue and I have to deal with the anxiety of looking at code like the example below while trying to answer their question.

function doSomething(param1,param2 ) {  var x= 5;  

if (!param1)
{
param1 = "w/e"
}
return param1 +param2}

When you install Go, you also install the go CLI tool, which comes complete with things like go fmt (the one true formatter), go build, go test, and more. There is no confusion caused from installing four or five third-party tools and there is no tedious configuration needed to get your environment in a state where you can build some project, hopefully.

Go is statically typed

We believe that learning a statically typed language first helps students think correctly about data types. The Go compiler will force students to avoid bad habits and help keep them from making many simple mistakes.

Later, moving to a dynamically-typed language will be much easier than trying to make the opposite migration.

Any effort our students spend during their first few weeks not practicing programming is a huge waste of valuable time in our opinion. Go minimizes the amount of set up and maximizes the time spent writing code. We can get students started with code before even the first day by using web-based tools like goplay.space.

What’s next?

Well, with our pilot program being such a smashing success, we need to go back and iterate on our curriculum and then find another group of students that are willing to give up their weeknights to come learn software development at Weave. Soon, we will need to figure out how we can offer classes at affordable prices while keeping our efforts sustainable. We’re excited about what the future might hold and we hope we can continue working on this project.

Please clap.

If you know any women trying to learn software development, please direct them to us. We are actively looking for new students that are willing to go on this journey with us!

--

--