So, this post may be “counter productive” in that it’s essentially a list of complaints. On the other hand, having made the rounds and soliciting opinions, This List of Complaints probably would’ve been helpful to have had in the first week so I’d be better prepared for the challenges ahead.
Since it’s a drag to get caught up in the negative there are some cutesy analogies that have helped me better articulate ‘the drag’. NOTE: If you don’t like negativity, don’t read this – as a student it may give you new things to be paranoid about. If you helped design some of the labs well… I hope I don’t offend you and that maybe you can keep in mind some of this stuff when creating or fixing new labs.
The “IT WAS ALL JUST A DREAM” lab… this is the kind of lab that takes you by (unwarranted) surprise. You complete a bunch of lessons that seem to be adding up… only to discover… NOPE! Something only tangentially covered is the focus of the lab. This is very similar to the MONSTER JUMPS OUT OF A CLOSET lab, where what you have to do seems either completely unrelated, or so cursorily explained that you feel ambushed.
The fix that seems to work for me in these two situations is to jump to the solution; check out the official solution and forked solutions of students that have come before me and play the INDIANA JONES GAME: deciphering and refactoring code until I know exactly what’s happening. This is a big help because as opposed to spending 2 hours on Google mentally exhausting myself (and not even knowing what I’m looking for) I’ll end up spending 2 hours going over solutions that work and refactoring until something breaks to test the limits of what works and what doesn’t. It goes without saying that playing INDIANA JONES GAME makes Googling a heck of a lot easier and more productive – allowing you to dive deep into the alternate ways of coding ||= in Ruby as opposed to guessing at the ether until you discover a concept like ||= on your own. Another aspect of the INDIANA JONES GAME is clicking the ‘Ask a Question’ button and getting a Socratic walkthrough of the thing you didn’t understand.
Then there are the HANSEL AND GRETEL and HACKING THROUGH A JUNGLE WITH A MACHETE labs. This complaint is about the built-in RSPEC tests. If you were to say: build a music library from scratch… you would probably diagram out what the the music library is supposed to do. Then do pseudocode or write out some tests. Designing your program as you would in the real world would enable you to keep track of what does what. However, when the RSPEC tests are already all written out for you, and your understanding of how a music library might work is poor (or slightly different) than what the designer of the RSPEC tests planned… you are basically diving into the equivalent of legacy code, with each test serving as its own unique puzzle.
The HANSEL AND GRETEL analogy describes the kind of a lab where the RSPEC test failures serve as breadcrumbs to guide you through the woods… but, you know, deep down: that if those tests weren’t there, then you might code the lab differently. The following breadcrumbs could also apply to Googling; especially if you don’t know what you should be Googling; where each Search brings you only slightly closer (you hope) to the answer you seek. The alternate analogy: “HACKING THROUGH A JUNGLE WITH A MACHETE” lab is the notion that you might be able to ‘hack’ your way through difficult coding puzzles and come out the other end a ‘winner’. BUT, if you look back or stop for too long then you will lose perspective and orientation. The INDIANA JONES GAME sorta solves this, in allowing you to get through the lab, but you’re not a better designer for it.
Another complaint comes from a quote by one of my favorite authors/thinkers: Eli Goldratt
“Tell me how you measure me and I will tell you how I will behave. If you measure me in an illogical way… do not complain about illogical behavior…” –Eli Goldratt
To keep with the theme of this post, I’ll call this one MAKING THE EMPEROR NEW CLOTHES lab, y’know… because making clothes require tailoring and tailoring requires measuring. Though this is true of all online learning, and really education in general: the system of learning-advancement being tied to passing labs (or some other metric) creates an unintentional atmosphere of gamification where you want to see how fast you can go. And not only that, but it also creates the illusion that all you need to learn is all that was required to pass the lab. You sometimes get a list of alternate resources, and if you follow them through you’ll discover that a series of labs which you passed in a collective 2 or 3 hours might be covered in a 500 page book somewhere else (I’m thinking of Regular Expressions – and YES, I bought the book). The solution to the MAKING THE EMPEROR NEW CLOTHES is what I’ve come to call BLAST SELF OUT OF A CANNON and MEASURE WHAT MATTERS.
There’s actually a book by that same title (Measure What Matters) by John Doerr and it’s all about objectives and key results. Quick aside: John Doerr is a legendary Sand Hill road investor who worked with Bill Campbell. Bill Campbell is a guy that worked with CEOS ranging from the Google guys to Jeff Bezos and Steve Jobs. It’s the OKR method described in that book. ANYWAYS. If I become conscious of the fact that I may be manufacturing imaginary clothes in an imaginary sweatshop… then I will attempt to blast myself out of a cannon, attempting to consciously trade “depth” (I put depth in quotes because: if the depth were ‘Real’ and not just an endless shallow swamp – then I wouldn’t have to do all this other stuff); thus attempting to consciously trade “depth” for speed and perspective, attempt to get passed the HANSEL AND GRETEL, HACKING THROUGH A JUNGLE, IT WAS ALL JUST A DREAM, or MONSTER JUMPS OUT OF A CLOSET labs, keeping close track of WHAT was covered though not necessarily HOW, that I might faster arrive at the section project to gain a better understanding of how I can perform (and then measure it – hence MEASURE WHAT MATTERS). And at the same time, gain some headway in the course that I can (hopefully) double my understanding through practice on some side project. The side project to be determined by the ‘checklist of what I should know’.
In truth, I didn’t have the courage to do this while struggling through my first 50ish days, nor did I have the foresight to do this. It’s only now with some greater perspective that I wish I had taken this approach from the beginning – also because, as I’m nearing the CLI project: I realize I have a lot of disjoint information that I probably couldn’t assemble without RSPEC tests. So, this Whiny Post is as much the articulation of a forward looking plan – as much as it is a whiny retrospective.
One other semi-related complaint (because this is the whiny post) is what I call CROSSWORD PUZZLE MASTER. There’s a lot of noise about the various code dojos etc… but so often the solutions ranked highest are also clever solutions that having asked around (have discovered) are rare to see in production code. While there are gems of knowledge, and people obviously get value out of this… I have the personal concern that mastering code challenges is akin to someone who wants to be a novelist writing only clever sentences. In other words, it’s a skill that doesn’t necessarily add up. If I were preparing for a coding interview then I would assume there would be more value in doing puzzles… but anyways… yeah… the amount of time I might spend hacking out clever solutions in some code dungeon might be better spent building technical projects that I can either showcase or incorporate into a showcase.
THE SILVER LINING…
The instructors are AWESOME and so is the Flatiron Brand. And whenever I cringe at my monthly bill, I remind myself that were I searching all this stuff on Google using Udemy or Coursera as a guide… well, I wouldn’t have access to the Ask a Question Button, nor the inspiring (and knowledgable) instructors that serve as mentors… nor would I have access to the virbant community/alumni network of students whom I’m able to learn as much from as the actual course.