This blog is more of a reflection on the process. What went wrong, what went right.
SOME BACKGROUND CONTEXT: When I completed my CLI project, I felt as if I had to relearn many of the lessons and labs. It got me thinking if so much had to be relearned, might I have a better learning experience if I raced through the course material in order to spend more time on a bigger project that would really force the learning in a Do Or Die way.
A general problem I have is that I find it hard to internalize information that is out of context, or with limited context. In some ways this makes learning very difficult for me because unanswered questions really nag at my subconscious making it nearly impossible to focus on what’s in front of me. If I don’t know “why” seeing the “how” is often meaningless to me. Strangely, I was not aware of this until I began learning to code.
Regrettably, and even recently, I would criticize the labs and lessons as being insufficient in the surveys. It is only with much reflection and thought that I realize and embrace that I am the one FULLY at fault. Looking back to my time in college, when I was studying screenwriting, I’d find it difficult to try a new technique if it was only in the context of a single scene. Though more time consuming in some ways, I wouldn’t really be able to “get it” unless I employed the technique into the larger context of a fuller project. On the flipside, it helped me with employing techniques in contexts I didn’t expect. Likewise, after college when I was doing outside sales, I’d learn a technique at a seminar and then obssessively try it in cold calls, or attempt to rehearse and memorize it before I felt I understood it. Imaginary rehearsals about what could go wrong made it easier when things went wrong in real life (and all due to greater context).
Going back further, when I was in high school studying lines for a school play, or studying lines for an independent film, I would never be able to internalize the lines without The Motivation. Strangely, I had always thought the actor’s question of “what’s my motivation” was ridiculous – the motivation was (to me) TO KNOW THE LINE. However, on a deeper or maybe simpler level: it’s all about The Why in Context. Or at least I think it is now. I don’t know if this is a general rule that applies to everyone, or if it’s something that only applies to me. Whatever the case, I realize it’s something I need to compensate for.
Back to the opening point: racing through the labs to get the larger context being the approach I took during the Sinatra section…
I felt if the process turned out to be a total disaster, my consolation was “better to have tried this while learning Sinatra than while learning Rails or JavaScript.” Thus I had started thinking about my portfolio project that moment I began Sinatra coursework. The thing I did not think about (very stupidly) was “what” (from the lessons and labs) did I reaaally need to pay attention to. Essentially, I “hacked” my way through the course treating code almost as if magical incantations, repeating where necessary. Using RSPEC tests and AAQ and the Forums to guide my way. Often I’d have to look at the official solution code just to make heads or tails of what was going on. In tandem, I would often attempt to refactor solution code – usually into lousier code than what was provided – until I get a sense of what was happening. More often than not, I did not really understand why any of it was working. I often could not tell the difference between what was actual Ruby Syntax versus what was just a naming convention. This was much to my detriment when I began the project – for it truly was a relearn.
In hindsight, I wish I had written down the project requirements and kept them on a post-it next to my computer monitor that I might’ve always had “in mind” what to focus on. I probably would’ve also liked to have a plain text file with headings of “THIS IS HOW YOU DO SUCH AND SUCH A THING” with corresponding code examples pasted below, as well as in depth commentary for what was happening AND WHY. I think that would’ve saved me a lot of time in terms of guessing and asking and guessing some more and asking about guesses and well… it was often a nightmare. I’d be on AAQ asking a coach about some thing that I thought was a problem only to discover it was something else.
When it came time to plan the project, I knew what I wanted to do but not exactly how to do it. I thought I could watch the instructional tutorials and figure it out from there. This did not work very well, other than setting up Corneal and doing the “git stuff” because my project was not a one to one in any meaningful sense. I had seen other students take much time going through the course and spending little time on the projects, only to later have remorse about not fully understanding what they were doing in later sections. Given my problem of not being able to really understand stuff without the larger context, I knew that any temptations to scale back my project to “just move on” would result in a much more epic failure for me later on.
Because I had planned to spend more time on the project (I had budgeted approximately 1 month for it), I did a detailed PDF mock up that I sent to the instructors and advanced students, and anyone willing to look, to get a sense of what people thought. If it seemed to make sense to them, then I felt I was on “solid enough ground” to move on and tackle it. If someone said “that’s impossible with the information you’re supposed to know” then I would’ve had to rethink what I intended to do.
All went well, so there I was. And now here I am on February 9th. Project buggy but essentially complete. I checked Slack and it is literally about a month to the day. I believe I started making the PDF mock up the weekend before the 11th (though perhaps it was the same weekend); I sent it out on the 11th. I finished all relevant code on February 8th. Had things gone terribly wrong (which I’m grateful they didn’t in thanks to many instructors and students) during the process, I had planned to do a very simple tutorial MVC. I’m glad it worked out.
Some thoughts about why it worked out. Well, I wouldn’t have been able to do this without access to the Flatiron Community and the people that make it great. The other thing that made this possible was a design approach over a syntax approach to the project. To reframe and rephrase: I feel there are two problems I’ve been encountering over and over during the course… one is a matter of syntax (I don’t know the code to do this) and the other is a matter of design (how might I solve this problem). While these are closely intertwined, I’ve found they are indeed different. If attempt to “code” my way through a design problem, the process can take two or three or even five times as long. If I attempt to keep designing when I should really be coding, then that also leads to a FAIL.
To make that point clear, and give an example from my project. I spent HOURS following the tutorials and thinking maybe I could swap enough details to get to the end. After much time was wasted, and very little progress made on my project I felt that I had no sense of how big my project actually was nor any closer to completing it. I just had a lot of messy code that didn’t work the way I hoped. I was treating the issue as a syntax/coding problem. The first HUGE leap I made was in some ways a leap of faith. I thought maybe I could just write all the GET routes that I would ever need for the project, along with corresponding views with some dummy content (a line of what should be there and how it should work) – basically the HTML/Sinatra version of the PDF mockup I created. I felt that if I could click from page to page, even if nothing was working that I would at least be able to measure my success (or lack thereof) against how much of the project was completed. Though it was time consuming and tedious, borderline mindless work to recreate the PDF document, it was very rewarding to be able to see “the entire flow” of the project, the scaffold of what should be, in a way that a wireframe written out on paper is not. I could click through EVERYTHING despite nothing working. But it felt like a huge victory. The project was done, only it didn’t work right (talk about putting a happy face on something).
That (small) victory solidified what was mentioned above as the difference between coding VS design problems. Had I not designed it all out, I reflect that I would not have been able to complete the project. I’d have gotten lost in the code.
There was another example I want to share here that was a victory of the same kind, and of greater magnitude. I was having an incredibly difficult time with control flow. I thought it was a syntax problem. Only after I posed the problem as one of syntax to some students that were nearly done, and received their enlightening answers did I realize it was in fact a design problem. As scary as it was to realize the problem was beyond my ability, it was also liberating to IDENTIFY the nature of it. And thus it became solvable. From there I was able to solve the problem; I doubt my code is as efficient as it could be, but it seems to work, and for the learning experience I’m grateful for that – and grateful for all that I’ll learn from refactoring later on.
I’m now looking forward to my project review to see all that is wrong and hopefully some that is right. There are elements of the review that I dread, especially since I have great difficulty producing “syntax” (though not so much difficulty recognizing when something is wrong), but also elements of the review that I expect to be exhilirating: knowing what is wrong so I CAN grow and be a better help to others along the way. As much as they have been a help to me.
And in a way, that’s what my project Ariadne is all about – solving problems. It was a process that I developed over time using pen and paper, notecards, or even two plain text editors side by side. It would help me prioritize the order that I might tackle the tasks, something greatly helpful even in the development of this project. To do what is quick and easy first, or quick and time consuming. Follow that with what is difficult and quick, followed by what is difficult and time consuming, Do what is necessary followed by what is optional. And if something is ambiguoius, attempt to do the aforementioned things first that you have enough context to fill in the gaps… As much as I wanted this project for myself (even in its buggy form)… I wanted it to be available to other students, that they might also reap the rewards of saving time when tackling and planning difficult projects.
SPECIAL THANKS TO: Steven Crouse, Guy Bryant, Meg Gutshall for doing a Code Talk session yesterday which was a “dress rehearsal” for my project review. Prepping for a dress rehearsal helped give me the motivation to finish the project on time – just when I was running out of steam – and also thanks again to all of the above, plus instructors Ayana Zaire and Dustin Anderson, and students Daniel Dawson, Aurangzaib Danial Liaqat Khan, Abiodun Ajagunna, for helping me with code – and also thanks to past instructors Beth Schofield and Howard DeVennish, for encouragement and confidence. Thanks to everyone on AAQ, and also the nested forms videos done by Sophie DeBenedetto which I wish I had watched and understood before I even began.