Just as I was finishing my last post, I decided to turn in an application to the Montana Code School to see what happened. Once I submitted the short, online application (which was handled by Submittable – a Missoula tech company!), I went back and took another look around the Montana Code School website and realized that they had a part-time bootcamp scheduled to begin right away, as in the following week! Within a half-day of submitting the application I received a phone call from the school director wanting to set up an interview. So I went in for the interview on Friday and heard later that day that I’d been accepted to the part-time program.
While I’d been thinking of doing some kind of coding bootcamp, I wasn’t exactly prepared to act on the idea quite so quickly. I decided to jump on the opportunity for several reasons. For one, the price, while still significant, was much better than the online course I was considering. The timing also was good—I’d get to start on it right away and since it was part-time I could work on other projects at the same time. Possibly more importantly I’d be able to work with local classmates and get the support of the local tech sector through networking and other events. Since I’m only freelancing and doing odd jobs at the moment, I haven’t been as connected to the Missoula professional scene as I have wanted to be. I’m hoping that doing the code school will help in this regard.
The class meets regularly in a room at MonTEC (Montana Technology Enterprise Center), an office building which houses a number of local tech companies and startups. There are about 11 students in the class, many working full-time already and doing the boot-camp on the side. The first part of class was spent both on introductions and on going over some of the productivity methods that get used frequently in web development and that we’ll be using in the class, such as Kanban and Agile. We were then given a stack of sticky notes and asked to write down our “goals” “values” and “resources” as they related to the bootcamp. It was clear from some of the responses, especially for “values” and “resources,” that people were both excited and anxious about the learning ahead. A number of the “goals” that people stated were to be expected: earn more money, have a more meaningful work life, be creative. Others’ reasons were a bit more surprising initially, but made sense. One person mentioned the desire to combine tech with social justice. Amita, the school director, then mentioned that this was a reason more women are getting into tech. As an aside: I think this is actually key. If more people think first of what kinds of questions they can solve or explore through programming, they might be more interested in seeing coding not as an end in itself but as a means to other ends.
Our assignment for Thursday was to start creating a website with the HTML and CSS we had learned so far.
Austin, our instructor, introduced GitHub, the command line and then had us continue work on our basic websites. I’ve known about the command line (Terminal on macs) for a while, but it’s always been super intimidating and I’ve been convinced I’m going to break something or lose something if I use it. Apparently there are a lot of advantages to getting used to the command line though, such as saving time when navigating through your folders and files. It’s also how Austin wants us to “push” our work to GitHub. I’m still scared of the command line, but now that I know a few commands it’s a bit more accessible. One thing you probably don’t want to do from a command line is to remove something. Unlike dragging it to the trash on your desktop, removing a file in the terminal will probably delete it permanently—as in forever. Scary.
I’d played around with GitHub for a short time before the class started, but found the workflow hard to grasp. Basically, GitHub is an online repository for coding projects. That is, it’s a kind of cloud storage for your project files, but also serves as a version control platform. Every time you make changes to your files on your home computer and then “commit” and “push” those changes to the repository in GitHub, it stores a version of those changes that you (or others) can later access. It’s useful if you make a change that results in your code “breaking” (a.k.a “not working”). You can go back to an earlier version to help identify which changes were responsible for the code breaking. It’s going to take me some time to get used to GitHub, but I can see where it can be super useful, especially for collaboration.