Makers: Lessons of the First Few Weeks
Today is Sunday, and my third week at Makers is officially over. The theme of fast-flying days that arose in week one has stuck around and to know that I’m 1/4 of the way through the main course is slightly scary. On one hand, the days have passed so quickly that it almost feels as though they didn’t even happen. On the other, the amount that I’ve crammed into those days makes them feel like a lifetime.
Below is a representation of what the inside of my brain feels like at the moment:
Makers has a saying: ‘it’s not hard, it’s just new’. And I’m already feeling the truth of it. Content that felt impossibly difficult in week one, now seems like a breeze. Our progression has been amazing and it’s inspired me to try harder in all aspects of life. Turns out that setting smart, achievable goals every morning can do wonders for productivity, and can easily be applied to fitness goals, personal goals, or whatever goals you like.
Anyway! Back to the point.
The main learning curve of weeks one and two was test-driven development. I had been prepared to learn new, Ruby-specific knowledge, but Makers prefers to look at the bigger picture. It’s all about process. It makes sense really, you can learn more about a specific language anytime you want with a quick google search. But developing a methodical process and learning how to break down problems into manageable ones takes practice and guidance and is a lot more valuable in the long-term.
Test-Driven Development (TDD)
Using TDD when writing code essentially just involves following a particular process: RGR, or ‘red, green, refractor’.
- Red: Write a test, run it, and pay attention to the red error messages that appear as it (predictably) fails.
- Green: Write the minimum amount of code required to pass the test.
- Refactor: Go back to the code and refactor it. Now that you’ve passed the test already, you can easily re-run them as you alter the code to ensure that you don’t break anything.
- Repeat.
It’s a simple idea, but hard to grasp at first. It feels counter-intuitive. Why write a test and run it when I already know that it’s going to fail? In fact, it didn’t start making sense until the weekend challenge.
Our task was to create a program with Airport objects which could release and land planes depending on the weather. It seems simple enough looking back, but this was the first challenge Makers gave us after taking the training wheels off. We’d been practicing TDD during the week but were given plenty of guidance and hints along the way. For this, we were on our own with the exception of a few user stories.
Looking at the task on Saturday morning, I panicked a little. I knew I could do it, but could I do it well? Starting was tricky. The instructions didn’t seem completely clear and I wasn’t sure which first steps I should take. That’s where TDD came in and it finally clicked.
We were taught to incorporate feature tests into our RGR cycle. A feature test is essentially a test for the features of a program. We implemented them by running a REPL (irb) and attempting to use the programme in the way we hoped it would function once complete.
The cycle essentially became the following: Write a feature test and fail it, write a unit test with the aim of producing the same error message as the feature test, then write the code to pass the tests and refractor.
Following this cycle gave me my first steps and eventually, all of the ones after that. Opening irb, I realised that first and foremost, a user must be able to create a new airport. Working from irb, it was obvious that this should come before even thinking about the planes or the weather, and it stopped me from getting ahead of myself.
As you can probably predict, typing ‘airport = Airport.new’ didn’t go so well, and I got my first error message: uninitialized constant Airport.
It followed that the next step was to create a unit test for an Airport class and, when that failed as well, I knew to create the class itself. TDD gives direction.
It’s easy to race ahead when you’re coding, but it’s not helpful. Often, it means running into unpredictable errors or writing overcomplicated code. The above example might sound simple or redundant, but as the project progressed and the code gained complexity, it kept me on the right path and ensured that I was creating a program with exactly the functionality that was required. No more and no less. TDD has plenty of other benefits which will quickly become apparent as the code that we’re writing becomes more and more complex.
Other Lessons
I won’t go into too much detail about the remaining lessons of the first three weeks, otherwise this will quickly turn into a ten thousand word essay, but here’s a quick summary of the main lessons (this is by no means exhaustive):
Week 1: Intro to TDD and Debugging
- Debugging was another subject that I underestimated at first. I knew to have a rough look at the error message and which line the problem seemed to originate from, but I was also guilty of simply trying things, altering code here and there and hoping I would get lucky. Makers taught me that process is everything and gave me a specific mantra to repeat: “Tighten the loop, create visibility”. In more words: look at the type of the error, use the stack trace to work out where the problem is happening in the code and create visibility, or put another way: ‘p everything’.
Week 2: OO Principles, Process Workshops and Diagramming
- Object-oriented principles that we covered included encapsulation, polymorphism and forwarding, among others. We practiced applying each of these with the mini challenges and practicals provided by Makers during the week, but it all came together for most of us during the main weekly and weekend projects. My code has become immeasurably easier to make sense of (for myself as well as new eyes), and I can’t wait until I have time to go back and improve on all of my lengthy Codewars solutions.
- Process workshops: these occur weekly, but I attended my first session in week two. After a day of work, we all get together on zoom and pair up to work on challenges one at a time while the other watches, so that we can get feedback on our process. Though kind of nerve-wracking at first, it’s been incredibly helpful (and I’d much rather fight the nerves and get used to being watched while I code now as opposed to later on in, for example, a job interview).
- Diagramming: In addition to strictly using TDD when we code, we were taught how to plan properly. Again, this is often underestimated as a skill and people get away with bad planning all the time, but there’s no denying that bad planning will trip you up when you’re least expecting it.
Week 3: Web
- This week brought something completely different. We had workshops to teach us the basics of how the web works and by Thursday I was building my own Macronutrients Calculator web application. The weekend challenge of building a Rock, Paper, Scissors web app was my favourite so far. It was clear this week that we’ve already become better learners. We had to quickly become familiar with Sinatra, Capybara, HTTP request types and the MVC pattern and best practices, and I really don’t know if I would have trusted myself to do that so quickly just a few weeks ago.
Above all else, the main lesson of Makers so far is to focus on process. And not just in the coding sense. The workload is immense, and it’s pretty much impossible to complete every practical, workshop and project to perfection. But that’s the point. We are here to learn as much as possible, so Makers throws more at us than we can handle. This way, we can be sure that our potential isn’t being capped.
It’s been an emotional rollercoaster, to say the least. I’m a perfectionist, and it’s not easy to accept that I can’t complete everything. I’ve been overwhelmed several times (thank you Dana, thank you meditation, thank you yoga and thank you reflection sessions for grounding me), but I’m realising that I’m learning at a pace I hadn’t anticipated and I have a lot to be proud of, as do the rest of my cohort. Makers know what they’re doing, and I’m feeling more and more confident that I’m going to leave the course feeling more prepared for the world of work in the coding industry than I had hoped for only a few weeks ago. Until then, I‘m happy to weather the storm.
