A Way to Learn As a Flatiron School Student

I began my journey as a FS Web Development student in the first week of April. I am a quarter of the way through the curriculum and would like to share some patterns that I have noticed in my learning in hopes that it will be of some help to any other beginning FS student.

What I have learned about my learning:

  • Get comfortable with being uncomfortable with broken code.  In fact, get comfortable with breaking and redoing or refactoring code to higher efficiency. In a phrase, think in drafts. Writing code is not unlike writing a paper that is too wordy, uses overused terms, or is poorly formatted.  Working code is not necessarily "good" code.  All of this is part of the ongoing process of programming.  Think: Less is more. Simplest or abstract code is the good code.  Although, I grant that for beginners that the "efficient" is relative to our experience and what little we know.  So be patient with yourself.
  • Read test specs carefully and plan accordingly.  As great as it is to have pre-written test specs, don't make the test specs a crutch.  Remember this is a learning environment intended to simulate and teach; that is, to train as you fight, figuratively speaking. This is to say, you need to learn the way a programmer is expected to program in the real world or learn  by doing as programmers do. However, Learn.co is still a teaching environment and not the real world.  Therefore, plan and think, as opposed to slipping into autopilot--because it is possible up until a big challenge comes along and appears wholly unfamiliar on top of whatever labs are supposed to be challenging all their own. Don't get me wrong! These lessons and labs are scaffolded to comprehensively challenge you.  But this does not rule out the personal responsibility to review, take some notes, and make connections to prior knowledge; assimilating knowledge, while consistently taking in entirely new experiences.
  • Strategize, strategize, strategize!  Object-oriented ruby, for example, will begin to introduce you to more realistic interaction with code, where you will code in one file while having to pause work on that file to accomplish some working code in another to enable the prior file to work.  The implied task is that you will need to understand what to code in some necessary order.  This makes the previous steps crucial.
  • Think about your thinking and approach. For example, when you make an error, and whether you are able to resolve it quickly or not, take a moment to understand how you got to that point, whether your code is passing or failing the tests specs.  In terms of a failing spec, think:  What am I missing in this method/class/lab?  What does the test spec say?  Does my code address every facet of what the spec requires? (On the latter, all but a missing piece of code could be causing an error to be thrown, demonstrating while you have to think both with and beyond the given test specs! Stated inversely, all your code is set to work if one piece of code weren't missing.)  So you kind of have to be a Sherlock who must really observe your code to embrace the possible problem that just isn't popping out at you despite having run yourself through several loops to figure out why your code is not working.  And in terms of a passing spec, ask yourself:  How did I accomplish this?  Do I know and understand what I did to achieve this success?  Implied task:  Take time to evaluate your learning, even if you are a high-speed FS student with previous experience.
  • Evaluate and document (summarize in your own words) what is being asked of you to  accomplish a particular specification(s). Although Learn.co has built-in tests for you, you still have to do the work of thinking. As you progress through the curriculum the tests will become less and less specific. There will be gaps in the logic of the test specs that require you to fill in the blanks for how you get from one end of a problem to its expected outcome or output. 
  • Remember that computer programming's technical and essential purpose:  To solve real-world problems.  You should be excited by the presentation of a problem to solve, as opposed to feeling bothered by problems.  So to further break a broken record, learn to love problems so that you can get to the place to appreciate how your work as a programmer can improve people's daily lives, because that is what it's all about at the end of the day.

Dig deep. Think. Code. Evaluate. Adapt. Keep going. :)

Originally published at http://wayofthecode.com/.