This post touches on week three but mostly covers my thoughts on the bootcamp experience thus far. At this point, my cohort has finished three weeks out of our twelve weeks at DevMountain.
I apologize that this took me so long to get posted. I simply wasn’t happy with my first several drafts and so I kept refactoring it. I’m still not happy with it, but class tonight starts our fourth week, so I should call this good enough.
Week Three
We started the week by finishing up our study of JavaScript and then we made an abrupt switch to touch on jQuery.
We have not the time to take our time.
Monday and Tuesday, we covered objects in JavaScript. This meant we started to touch on JavaScript that was challenging, unfortunately we never really had a chance to discuss or explore the challenging aspects (e.g., the scope of .this, and addressing .this scope in callbacks). There is a difference between rushing through a topic and outright bypassing it. This was a definite bypass.
Our assignment post-Wednesday class and pre-Thursday class (i.e., a 21 hour period during which most after-hours students have existing work and sleep obligations) was a 3-hour Code School course on jQuery. Needless to say, most students didn’t complete this, including myself, and our ability to complete the jQuery project was correspondingly hindered.
I would have much preferred to (a) have had the Code School material assigned as prerequisite work, (b) spend a full week on the advanced JavaScript topics, and (b) spend another full week on jQuery. I know the DevMountain crew is constantly tweaking the program, and I hope they implement this for future cohorts.
The DevMountain Bootcamp Experience thus far
Why I’m at DevMountain
I’ve got a lot of grips this week. So, I want to put them in the context of why I’m doing a bootcamp in the first place; the main reasons are: squirrel-blocking, integration, focus, and networking.
Squirrel-blocking
There are a lot of things happening in the JavaScript world and a lot of interrelated elements to get an application up and running. For someone really wanting to dive in, this diversity can result in analysis paralysis, squirrel chasing, or utter hopelessness. In my case, I spent a fair bit of time evaluating various frameworks, but had settled on learning the MEAN stack - i.e. analysis paralysis averted *wipes brow*. But then it came time to actually start learning, and the flood of information necessary to be productive made me feel like a dachshund in a field full of squirrels. I couldn’t catch any one squirrel before another one caught my attention! Surely there is a set of basics in each area that will help me (a) become productive and (b) prioritize subsequent squirrels. I was really hoping DevMountain would let me put on a pair of blinders while learning the basics, i.e., focus on a single squirrel at a time. On the one hand, the speed at which we’re moving prevents a fair bit of squirrel chasing. On the other hand, so many of our questions have been met with something along the lines of, “Oh, you’ll need to study X, Y, and Z outside of class”, in other words, go chase even more squirrels. While a certain amount of squirrel-chasing comes with the field, I really was hoping it would be minimized in this environment. So, squirrel-blocking has and hasn’t happened.
Integration
Many of the things we’re doing, e.g., online readings, watching videos, and completing online tutorials, we could do without being in a boot camp. In fact, I’ve done many of these things, but tying the disparate pieces together seems to be a skill in and of itself. For me there are two specific aspects of putting the disparate pieces together: technical and best-practices.
An example of the technical is when something can be done in either jQuery or CSS; which should you use and why? So far, when students have asked precise technical questions, the instructors and mentors have done an admirable job of answering these question.
An example of the best-practices is using Git; and not just using Git to pull starter code, but also to push regular updates. While we use Git to pull starter code, and are occasionally reminded that we should push our code, it isn’t systemically reinforced. Likewise, our exercises are presented in prose format. As such they are prone to misinterpretation or incomplete implementation. The first few weeks we weren’t at the point of being able to do proper Test-Driven Development (TDD) or Behavior-Driven Development ourselves. However, we could have been given assignments in a more TDD fashion; and I think we should have tackled TDD before moving onto jQuery and Angular. More importantly, I genuinely believe that that our assignments should be done in a TDD environment, both to reinforce proper best-practices, but also to ensure we’re actually completing assignments correctly and completely.
I don’t know how many actual military veterans are among the DevMountain students, but as a Marine Corps veteran (aka a “Corps Vet”), this is the area that strikes me as one of the biggest fails thus far. In Marine Corps bootcamp the basics are drummed into recruits so fast, so hard, and so often that they become second nature very quickly. For example, most recruits weren’t used to wearing “covers” (civilian translation: hats). In the Marine Corps, covers are to be worn when in uniform and outdoors but are not to be worn indoors (with a few notable exceptions). By our third week, short of forgetting to grab a cover on the way out of the barracks or training room, there wasn’t a recruit in our platoon who consciously thought about whether to put on or take off their cover, it was completely second nature; by our third week it was genuinely as thought-free as breathing. I was really expecting a similar, systemic reinforcement of best-practices in the DevMountain bootcamp, in particular use of version control and TDD.
I’d also like a range of problem sizes. We’ve been given really small problem sets (e.g., JS Fiddles) and large problem sets (e.g., the war card game and twitter clone), but we haven’t had many projects in the middle range.
Focus
Related to squirrel-chasing is my need to simply spend enough time developing myself as a developer. I’ve got a salaried job (i.e., >40 hours a week), with an hour commute each direction, and have had activities many nights and weekends. So finding time to learn on my own has been a challenge. Doing a bootcamp has allowed me to reset my friends’ and family members’ expectations. They know that I am focused on this through January. There have been quite a few questions like ‘are you really sure you want to do this’ and comments about ‘taking care of yourself’. The fact that I’ve shelled out a non-petty amount of money, and I’ve been very clear that this is for a limited - albeit multiple months - amount of time, they’ve all come to understand and respect that I’ve made this a priority and are being supportive. I don’t think I could have gotten such support if I was just trying to focus on it without attending a bootcamp. In addition, because I’ve been able to get my friends and family’s support, I feel much more comfortable spending every free moment studying JavaScript. So, this has been an total win.
Networking
When studying by myself, I’ve frequently run into silly problems (e.g., basic syntax errors that debuggers don’t really highlight) or more complex, but opinionated questions (e.g., should I use approach A or approach B for this problem). My current job isn’t related to JavaScript in any way, so I don’t have work colleagues that I can ask to review my code, and my questions tend to be either too rudimentary or opinionated for sites like StackOverflow. Not to mention, I want to make a career shift and need to be making contacts in local JavaScript community. Attending UtahJS meetups and founding the SLC JS Learners meetup group, has allowed me to tap into the community and occasionally have support, but it still wasn’t quite enough. Working through many problems with other learners has provided me an immense amount of support and is helping me debug my own code more effectively. Having instructors and mentors to ask opinionated questions of, and to discuss the local job market with, has also been absolutely wonderful. So, this is also a total win!
Instructors and Mentors
While there are many unavoidable differences, the difference that pains me the most is the difference in mentoring hours; i.e. 480 for immersive versus 160 for after-hours. This strikes me as a difference that can and absolutely should be drastically minimized, simply by having more mentors on site during more class hours.
We’ve had five instructors thus far. I’ve really enjoyed the presentational style of three of the instructors. The other two felt unprepared and hurried. While I didn’t have any personal mentoring experiences with the latter two instructors, I did overhear one helping some other students, and he was much better at mentoring specific problems than he was presenting topics to the class as a whole.
My feelings about the mentors and mentor-mentee relationship has fluctuated a lot over the last few weeks. I was originally assigned to one mentor, then the day before boot-camp started I was reassigned to a different mentor. Because of our respective schedules, I really didn’t have any interaction with him until Saturday of the second week, i.e. 1/6th of the way through the program.
Each Saturday, one of the last things we do is break into groups with our mentors. My mentor wasn’t there the first Saturday, so his students were told to work with another mentor (ironically, my original mentor). I felt like we were taking time away from that mentor’s mentees; there were definitely too many of us for this one person to truly assist. The second week our mentor was present but my original mentor wasn’t, so again, we had too large of a group for effective mentorship. I was grateful that I got some one-on-one time with my mentor, and he was able to help me over a conceptual speedbump. Today was the first day that my group was actually just my group with our mentor, and I was amazingly relieved! Even though I didn’t have any specific problems that I needed assistance with, I could actually hear all the conversations he had with group members, and when something was relevant, we could all gather around the respective laptop and go over it. I was also able to talk to him about the .this related to callback readings, and he pointed out some things that I should pay attention to the next time I read those articles.
While the Saturday mentor groups can be useful, I’d really like to see more mentors available during class periods. I find that I’m one of the students who tend to be ahead of most of the other students, and when there aren’t enough mentors, we spend a significant amount of time helping our classmates. I certainly don’t mind this - to a degree! First and foremost, I genuinely like helping people. Second, having to read and troubleshoot another student’s code is - in and of itself - a useful exercise. And lastly, articulating a problem or helping a fellow student work through the logic of a correct solution is - in and of itself - a useful exercise. So, I really don’t mind helping my fellow students. But there are two distinct problems when there aren’t enough mentors available during class periods. First, when a student spends a significant period of time helping other students it means they’re not spending a significant period of time coding. Second, when the more advanced students run into problems of their own, there aren’t enough experienced individuals to help them in a timely fashion.
Cahlan posted a blog entry this week touching on the differences between the immersive and after-hours programs. While there are many unavoidable differences, the difference that pains me the most is the difference in mentoring hours; i.e. 480 for immersive versus 160 for after-hours. This strikes me as a difference that can and absolutely should be drastically minimized, simply by having more mentors on site during more class hours. Heck, having two to three mentors available the full length of each class would double or triple the mentoring hours.
So, I really like the mentoring when it’s available.
Related to mentoring - I’d like to send out a special thanks out to Amy-Kate for running an unofficial Monday night study group!
Flipped Classroom
DevMountain claims to use a “Flipped Classroom” approach, but in fact it isn’t a completely flipped model - we’ve had traditional lectures every class day.
We were expected to have completed a fair amount of prerequisite work before the course even began. And we’re regularly assigned a significant amount of homework; homework of the type that is in alignment with a flipped model.
In large part, because the prerequisite and homework is appropriate for a flipped classroom, most of the classes’ benefit isn’t coming from the lectures - rather it’s coming from the hands on practice with peers, and assistance from instructors and mentors when they’re available. I’d really prefer a fully “flipped classroom”, e.g., (a) no lectures, (b) a period of time at the beginning of each class to discuss the previous assignment/s, (c) some quick class exercises (specifically a step above ‘clickers‘, but exercises that make it really obvious if a student doesn’t grasp a topic) and (d) preferably projects, in a range of sizes, that reinforce the use of Git and TDD.