On October 30, I completed the Web Development Immersive at General Assembly in San Francisco. As a self-taught web developer with a BA in Art, with an emphasis in graphic design, I have done a lot of great work I am proud about, including my work at The Online 401(k) and Cooper. I learned so much in each position and feel fortunate to have had those experiences.
As I started interviewing for new jobs this past spring, it became apparent to me that the time had arrived for me to learn these skills in order to advance to the next level. I had great interviews, people were impressed by my work, but I wasn’t quite where they needed me to be for a Senior Developer role. Fair enough, so I made a big decision to resign from Cooper without first finding a new job. I decided to put my job search on hold for a few months to fill in some of these gaps, and ended up enrolling in the Web Development Intensive (Full Stack) at General Assembly. It was a course I had my eyes on for a few years, so I was excited to finally have the opportunity to take it.
The course, as advertised, was intense. We started from the bottom up with object-oriented programming, learning Ruby in all of 3 weeks. Since I had learned Python at Cooper, I was able to get going pretty quick with Ruby. It is a very similar language with a clean syntax and some nice perks I warmed right up to. We learned about variables, arrays, objects, loops, methods, blocks and procs. Ruby is pretty lean out of the box, but you can add additional capabilities by including modules or through the use of gems, which are essentially plugins to expand what Ruby can do. Another really nice thing about Ruby is its documentation.
Project One happened during week six. The expectations of Project One were somewhat unrealistic, given that we had not made it to Ruby on Rails yet. Because I spend a bit of leisure time on a Beards bulletin board that seems seriously out-of-date in appearance and function—I’m a beard nerd, and have the beard to prove it—I decided to build a bulletin board app. The easiest part for me was setting up my data models. I understood I needed Users, Forums, Posts, and Comments, and understood how they needed to cross-reference each other in join tables, but I had trouble understanding Object-Relational Mappings (ORM). The amount of time spent writing routes to work in Rack was overwhelming to the point that I barely got my first level of views working on time. For most of the cohort, Project One was mostly a flop, a discouraging outcome that weighed heavily on the cohort for the remaining six weeks of the course.
After surviving that experience, we were introduced to Ruby on Rails. This would have usually happened before the first project, but our group had a different curriculum than previous cohorts. All the same, we were thrilled to discover that in two short lines of code, “
rails new app” and “
rails s“, we skipped past all the aggravating work of the past 3 weeks in Rack to have a bare-bones app running on a Rack server that needed zero configuration. It just worked. Rails streamlines routing and is a solid MVC framework. It is really well-documented, and supported by a huge community of programmers all around the world. That said, it’s not the easiest thing in the world to grasp. Though you can use scaffolds to generate entire MVC apps, scaffolds only build the essential RESTful operations. Scaffolds are frowned upon in the real world because one-size-fits-all solutions are rarely the right solution to the problems presented in a project. If you need to do other things, such as user authentication, you need to know how to hand code these things. So this is a lot of what we did, writing routes, controllers, and views. Models were handled by another nice feature of Ruby on Rails called Active Record, the ORM built into Rails that serves as the translator between PostgreSQL and Ruby, allowing access to the database using Ruby object syntax and RESTful processes.
Ultimately, we learned enough in weeks seven and eight to be ready for Project Two during week nine. Project Two is a group project, by assignment. Our cohort was half the size of most cohorts, so we worked in pairs. The course is advertised as a ground-up course, but by this point in time some of the members of my cohort who had no previous programming experience were struggling. As it turned out, groups were assigned in a way that balanced the strengths and weaknesses of the pair so that each pair had a decent chance of producing a nice project. I was paired with a man named John Hoopes. Before General Assembly, he was in the insurance industry, but he decided to take up a career in tech and was doing really well in the course.
As it turned out, John and I were well-matched. We decided to build a Rails app using Google Maps and Instagram APIs to allow users to find a spot on the map anywhere in the world, and find Instagrams in a one week time-frame determined by the user. It was the week after Outside Lands, so we used that as the model for our user story about an event spanning a weekend or so that somebody might have been unable to attend, but wanted to experience using our app. We set up our git configurations to properly use Github to collaborate without overwriting each other’s code. We got off to a strong start and in the first day had the basics of our app working. We even figured out how to request user permission to determine their current position to center the map relative to the user’s location. As it turns out, geolocation is really easy to do, but it was new to us, and exciting to make it work since it added that extra touch to our app that made it feel special. At the end of the day, we were amazed by our quick progress, and our confidence soared.
In the second day, while John fine-tuned and refactored our work from the first day, I got seriously bogged down trying to figure out OAuth using OmniAuth, a heavy-lifter that allows you to configure users to log in with the social network of their choice. You see this all over the web. It turned out to be too heavy for us to figure out in the time we had to work on it. With the guidance of one of our instructors, we found a Sinatra OAuth app for Instagram. We had not learned Sinatra, but we had learned enough about routing to understand what we needed to take from the Sinatra app in order to build out Instagram OAuth in our Rails app. At the end of the day, we were able to log in using Instagram, which created a session. It took us only a few minutes to realize that to log the user out, we just needed to delete the session when they clicked log out, which was almost too simple. Again, we were so excited by how far we had come, and we actually left early that day, feeling a little sheepish as we told our classmates, “See you tomorrow!”
The fourth day, I wrote some custom CSS and added a Google Font as we buffed and polished our app. We reviewed it with one of our instructors. There were a few project requirements we realized we had not implemented, but they didn’t work with what we were doing. Our instructor agreed there was no need to build things that did nothing for our app, and he was really pleased by what we had done. Our last step was to deploy it to Heroku, a process that had caused some trouble for the other pairs. In our case, it was a smooth deployment. Everything just worked. We left early again that day, a bit less sheepish than on day two.
The next day, we presented our app, Instamap, and enjoyed seeing what everybody else turned in. Not every project was where each pair wanted it to be, but there was such a huge improvement from project one that everybody was really pleased. The class had a renewed sense of optimism, and that was exactly what we needed from project two. We also, for the most part, had good experiences in pair programming. This was something I particularly enjoyed since in my previous jobs I had either worked alone or with remote team members. There is just a synergy that happens in pair programming, and John and I produced a higher quality project together than we would have as individuals. Going forward in my career, I’ll be most interested in collaborative team environments such as pair programming.
Suddenly, it was week ten and the realization set in that there were only two more weeks of instruction followed by the Final Project. Tension levels went through the roof. During week ten, we learned AngularJS, which is a front-end MVW framework. The W stands for whatever, since you can handle controllers directly in Angular. I found it so confusing in class that I went home and started the Code School course, Shaping Up with Angular.js. I didn’t do the homework this week, instead working on Code School to make sense of Angular. It was not a perfect match since in class we were learning how to make Ruby on Rails and Angular play nice using Angular Resource, but it was enough that I was able to keep up during class for the most part. I was starting to feel like I was getting it as we ended week ten, and hoped we would continue with Angular in week eleven.
Instead, in week eleven, we got back-to-back crash courses on Sass, customizing Shell, sorting and recursion, and were introduced to RSpec one day followed by a somewhat infuriating Code Retreat debacle the entire next day that largely resulted in a meltdown for the cohort. This week is where I believe my cohort really suffered as a result of the excessive time spent learning Rack at such a granular level during weeks four, five and six. It was more material in one week than any of us could absorb, following a challenging week learning AngularJS, and ended the instructive part of the course on a sour note, resulting in an uncomfortable all-cohort discussion with the program producer and her boss. To their credit, they responded professionally, and while we worked on our final projects in week twelve, they worked on solutions to the concerns we brought to their attention in that meeting.
For my Final Project, I decided to revisit my unfinished, unremarkable Project One to rebuild it properly from scratch using Rails. I did some research and discovered a bulletin board app built in Rails called Discourse. I knew I wouldn’t be able to build anything so fully resolved, but it served as a good mental model for a basic app I was certain I could build in a week. After I set up the basic Rails app, I realized the most important thing I needed to do was set up user authentication. John and I hadn’t needed to do this in Project Two because our users had to log in with Instagram in order for it to work. Wrapping my head around authentication, understanding that it involved not just users with unknown passwords, but also sessions, took up my first day and a half. With the help of one of my instructors, I finally figured it out, but the process was so spread out, I decided to document it for the future as my first Gist.
Next, I wrote my routes, and generated models, views and controllers. This is when I ran into the biggest problem I experienced during the project, how to nest everything properly so that Topics only belonged to one Forum, Posts only belonged to one Topic, Comments only belonged to one Post, and Users related to all three. This is when I learned about nested shallow resources. It was another point of frontal lobe expansion because it resulted in unusual ORM references, instance variables referencing parent objects in child controllers, and view files that were also layered in unusual ways . This took me another day and a half to sort out, but I finally got it all working with simple data input and output and all CRUD functions working properly.
So three days had passed getting everything on the back end to work properly, but the front end was not looking good at all. Since I had worked in Bootstrap in Project Two, I decided to use Foundation framework in this project. I had some previous exposure to Foundation during a Project at The Online 401(k), but hadn’t looked at it in several years. In my opinion, it is easier to use. It requires less junk markup, and its classes are plain English. That doesn’t mean it takes any less time, though. So I started plugging away at it. Here it was Thursday, and I would be presenting the project in less than 24 hours. It was also Game 7 of the World Series and my native hometown Kansas City Royals were playing my adopted hometown San Francisco Giants in a game that went right up to the last out of inning 9. It had been a huge distraction all week that didn’t end well for my Royals, but I also worked 16 and 19 hours a day through the week, which I do not recommend.
As it turned out, I didn’t get all of my views finished before it was time to present. It was fine, though, because I was able to demonstrate that everything in TalkAmongst actually worked. I was able to present my code and talk about where I got stuck, what I did to get unstuck, and say what I was going to do next . Over the next week, I finished writing my views, debugged some trouble with Foundation icons in Heroku, used the Gravatar API to display user gravatars without requiring any additional information, and added CKEditor to enable basic text formatting in each of my posts. I am still working on integration of Amazon Web Services S3 so that users can upload images to posts. I’m also planning on taking another look at how I can integrate AngularJS into the project, and writing some custom CSS to make it more visually appealing.
At this point, my cohort entered its final phase at General Assembly, working with the Outcomes team to find jobs, which is the point of the whole thing, after all! I worked closely with the Outcomes team to prepare my résumé, business cards, cover letter, and General Assembly alumni profile in preparation for our Meet-n-Hire event. Before the event, I was already being contacted for interviews. The event itself ended up being a great success. It was held at General Assembly’s beautiful new location at 225 Bush Street, and attended by more than 200 employers. I had good conversations with 10 or 12 companies working on a broad range of innovative products. I have followed up with several, and coming out of the course I have a lot of momentum.
As I started writing this article, I wasn’t sure what my answer would be. As I come to an ending, though, the answer is clear. In the above 3400 words, I have told you about, and clarified for myself, all the things I learned how to do in just 12 weeks. The reality is I’ve been struggling in self-instruction to learn a few of these things for many years. Did I come away with everything I wanted to? No, but General Assembly has responded with follow-up solutions to help me fill in the gaps. I do believe they really are invested in my success, and that their investment in my success has not stopped even after the Meet-n-Hire event. I have good, no, GREAT employers reaching out to me directly, without recruiters, to schedule interviews. And the fact of the matter is, I am by leaps and bounds a much better programmer in the middle of November than I was at the start of August.
I would not recommend this Web Development Immersive to just anybody, though. You can’t just be “interested” in tech. You can’t just want to make the salary all the techies make so you can keep living in San Francisco. None of that is enough. You have to really want to learn this material. You have to be obsessed by your desire to learn and improve your skills to the point you are compelled to turn your life inside out for 12 or more weeks, because that really is what it takes. I’m not saying this as a critique of the course. I’m saying it because in writing this article, I am finally able to see how I did it, and why I’ll continue to be successful. I am glad I took the course. It was the most intense experience of my professional life, but, in my opinion, it was worth it.
Thanks to everybody at General Assembly for a program that was certainly challenging, but ultimately rewarding.