My Two MOST IMPORTANT Hours as a Coder

This is a repost of content originally written while at Flatiron School on February 26th 2020

“When the student is ready the teacher appears. When the student is truly ready the teacher disappears” Lao Tzu

Meet Mark Daniel Delgado. He began the Online Self Paced section on September 14th and completed it on January 14th. He completed the entire curriculum not only FASTER than what is expected of students in the typical self paced 10-15 month cycle, but FASTER THAN students in the full time live coding cohort. He did not attend many study groups, nor was he frequently seen on the Slack channels (although I do remember reading a brief note on Slack about how fast he finished, and what was possible, in response to someone’s question).

So how did I meet him in order to experience what I consider the two most important hours of my coding journey? It goes back to the first half of the Lao Tzu quote and something that I do which is always look to the other students for inspiration. I’m constantly on the look out for those who are ahead of me, doing the things I hope to do, and those behind me who I can see will quickly surpass me.

While I enjoy the projects which are evocative of my previous passion (screen and novel writing), I’ve had a very difficult time with the labs which make me feel like I’m back in High School. I’ve tried different approaches, but none with enough consistency, nor tenacity to find my stride. The best habit I have been able to develop has been hunting for what looks like expert code. For anyone else that may hope to do the same, it’s important to realize that as a beginner you will not know what is “expert”, you will only what code is better than yours. However, if you get into the habit of recognizing enough code that is better than yours, you will soon be able to rank what you see; then aim for the top of that mountain.

Back to the labs, while the official solution code was helpful, I always discounted it on the assumption that whoever wrote the tests also wrote the solution. In my imagination, I assumed they were created simultaneously, one to match the other. The only thing I knew for certain was that the solution code was not written by someone in a comparable situation to me… and yet, I also knew that more than one solution is possible, and there are often times where solution code looks as if it was hastily written just to pass the test. To find code more applicable to my situation, I began to go through the forked labs on GitHub, I would tediously go through student by student, or click at random (7-10 forks) for comparison. I would contrast student forks with the official solutions, and my solutions, to see which seemed to be more “self documenting,” always in hope that I would discover a student that could write code I wanted to emulate.

Over time, I began to identify Mark Daniel Delgado as a student whose code was exceptional.

This past weekend while tackling what seemed like a particularly impossible Rails lab (at least impossible for me), I saw in one of Mark’s forks code that was not only NOT covered in the course, nor was it in the official solution, but it seemed to be LIGHT YEARS advanced. I was in awe; having seen on Slack how rapidly he completed the program made me feel that my chances of being a thinker/coder like him were either impossible (that he had studied computer science, and was just doing the course the way some people do CodeWars challenges, or he was coding virtuoso, an actual genius in the course)…

I also wondered: if it were possible for me to be like him – that he must be doing something that no one else has thought to do. If you’ve read Loonshots by Safi Bahcall, you would assume he was employing something akin to an S-type Loonshot (one of strategy).

Relevant aside: I recently completed Walter Isaacson’s “Da Vinci” in which Isaacson asserted that Da Vinci was not a “genius” in terms of the common conception, but more of a self-made genius in that Da Vinci’s ceaseless curiosity carried him through many problems and helped him reach many conclusions that those less dedicated could not achieve. That though we would not all become Da Vinci’s, we could perhaps lead more fulfilling lives.

With that aside in mind, I hoped that Mark Daniel Delgado was not a savant (a coding genius that could tell you how many characters there were on a given line of code, or quote documentation verbatim, or know by memory on what line a certain function lived), but more of a Da Vinci that could explain how he got where he was, how, and why. That with hard work, I might do the same.

I messaged Mark on Slack with fingers crossed that he would be able to share some nugget of advice that could help me move faster, more efficiently, and with greater depth. Not only did he write back, he was willing to do a screen share. I’m going to itemize all that I learned from conversation, and as he helped walk me through how he would tackle a lab.

NOTES FROM MY CONVERSATION WITH MARK DANIEL DELGADO

1. Code to the RSPEC test. Use “learn test” at the terminal to help determine sequence. Doing it like this will help the student get into the habit of CODING PAST THE PROBLEM. so essentially the understanding will take place passively, or as a byproduct of doing the tests. In other words, if you set out to “understand” the lab in the abstract, you will have nothing to grasp onto. If you set out to conquer the tests, you have the exact framework/almost a checklist of what Flatiron wanted you to know.
2. The student should get into the habit of cross-referencing what the RSPEC tests are asking for with the official documentation, stack overflow, and really anything to help fully know what is happening and why. NOTE: this is not about being able to comprehend what the ReadMe is asking for, but to understand the code and principles in tandem. Doing it like this MAKES IT POSSIBLE to actually skip the readme altogether and creates a situation where the student can generalize what is required of them. More importantly, it gives the student the opportunity to focus on the MOST EXPERT portion of a lab: the RSPEC tests. The RSPEC tests are perhaps the most advanced/expert level thing you will see on a lab. Even the official solutions pale in comparison because they are essentially written to make sure the tests work. The tests are more stringent than the myriad of solutions, in part because they encompass all solutions.
3. Don’t be afraid to alter the RSPEC test if you know your code should be passing. Sometimes the RSPEC test is dealing with an older version of Ruby or whatever. REMEMBER, your mission is to become a software engineer, the labs and tests and projects, are just stepping stones to get to that end. Don’t lose sight of the final goal. Don’t forget you’re in a forest because you’re looking at a single tree, nor forget you’re looking at a tree because you can only see the trunk or the branches.
4. The Student MUST be aware of their limitations at any given point. If you are stuck on something for more than 15 minutes, you probably do not understand enough context to actually learn. You will save time if you can recognize in 5 minutes, or instantly, what you know and what you don’t know. Recognizing your limitations is not about being lazy and saying “I can’t do this” for that can quickly become “I don’t want to do this”, but knowing what you don’t know. You know yourself better than anyone, so you will really have to take it upon yourself to be honest about your limitations. But knowing your limit is also empowering and liberating, for once you know you’re at a wall, you are able to more quickly vary the approach to find what works, and fill in those knowledge gaps. NOTE: using the RSPEC tests gives you an objective measure. Contrast this with wondering what the readme is expecting of you.
5. When looking at code ALWAYS consider PURPOSE over SYNTAX. Syntax is language specific, purpose spans across all programming languages. Think in terms of INPUT/OUTPUT, think in terms of order of operations and control flow, understand how the syntax you are writing translates into the fundamental concepts of programming.
6. Always be mindful of integration. Codewars type challenges will help you master syntax, and probably crack a coding interview, but they will not help you master something like “Model View Controller”. Being able to read the Integration Tests (multitiered tests in RSPEC that address many different parts of a program) will. Understanding integration will help you become a better programmer because you will understand how everything fits together, instead of how different parts work in isolation. To build a car, understanding how an engine, an axle, a transmission etc work is not sufficient; knowing how they fit together is (in some ways) more important.
7. In terms of learning (not just for Flatiron, but in general) be conscious of what is truly important. In other words, make sure that you are measuring what matters (even if only qualitatively) so that you can spend more time on the things that are important and crucial to success, and less time on those other things that will ultimately become irrelevant. This is a useful thought process especially when you consider it in the context of “5” (Purpose over Syntax). It’s also valuable in the context of projects: always do your best, but be wise about spending a lot of time building something that may be obsolete after the very next section. If that’s the case, you might want to wait until you have the requisite skill set to build it out.
8. Look for Experts. Watch expert builds LIVE. Try to learn from the best. If you watch amateur’s struggle through code on YouTube, you will learn to struggle like an amateur. If you watch an expert’s code build (similar to watching a masterful artist render a human face on YouTube), then you will better understand an Expert’s Approach.
9. Study Expert Code. In this case, if you go into any given lab, if you are able to put yourself into the expert’s shoes and imagine yourself building the lab… your skill as an expert is best demonstrated in those tests.
10. Be careful of being in situations where it is the blind leading the blind. This is similar to number “7” and being conscious of what is truly important. There may be social/psychological benefits to struggling as a group and being able to measure yourself to your peers, but be aware of what is going on.
11. Spend more time understanding how everything works; be conscious always of the big picture; THE WHY.