Weeknotes - 01 Makers
Tags: bootcamp, beginners, ruby, coding
Published: 2019-06-02 17:16:24

---
title: Weeknotes - 01 Makers
published: true
description: Reflections on the past week at Makers Academy
tags: bootcamp, beginners, Ruby, coding
series: Makers weeknotes
---

# Welcome to Makers

It's been an exciting few days, meeting my fab cohort and the coaches, discovering the instant hot water tap in the kitchen and, finding out where the best place to work in the office is.

## Learning

Every morning started with a short learning workshop, a chance to reflect on the journey so far and set up the day with mini-goals on the path to the Big Three goals all [Makers](https://makers.tech) students strive to achieve in 12 weeks:

> - I can make anything
> - I help my teams succeed
> - I am equipped for longterm growth

The key ideas I chose to work on were 1) deciding what was the most important thing to focus on that day, 2) adapting to the growth mindset by rewarding _learning_ over completion, and 3) tracking my learning with evidence.

## Debugging

Maybe 60%<sup>* </sup> of a profesh day programming will be spent on code, with the rest on teamwork & communication or research & understanding problems. 60%<sup>* </sup> of that code time will be spent on debugging, with the rest on writing tests, code, and refactoring.
How do I get the code to do what I **expect**? Read the error, check the output, reproduce the problem, p everything ever, and always go back to the spec to avoid assumptions in behavior.

*<sub>_these stats are not credible, just go with it._</sub>

## TDD

I live with a [TDD fanatic](https://github.com/quii/learn-go-with-tests) and I don't need any further convincing that TDD is a neat way to write flexible code that people can look at and say "OMG it's gorrrgeous!".
Actually _producing_ it is another matter, and I've found transforming user stories into requirements really hard.  Dr Balbes' article on [splitting stories for agile teams](https://techbeacon.com/app-dev-testing/practical-guide-user-story-splitting-agile-teams) was helpful.

The golden rule for the TDD process is **Red, Green, Refactor** (aka write a test: watch it fail, write some code: make it pass, improve the code without changing the behavior).

Another idea to remember to help write tests is **Arrange, Act, Assert** (aka Given, When, Then) wherein sometimes the act and assert are the same thing [but just don't worry about that its fiiine].  _Arranging_ your tests means the test code has access to whatever it needs to run, for example, an instance of the class you're testing. _Act_ is the behavior being tested. _Assert_ is what you are expecting to happen.

Note: [RSpec](https://rspec.info/) is a popular testing framework for [Ruby](https://www.ruby-lang.org/en/).  It's a domain specific language (ie its a language - written in Ruby - specifically for _testing_).

## Coding Challenges 

![](https://thepracticaldev.s3.amazonaws.com/i/scc8xgnm0z8xdt2qxbp3.png)
<sub>_pseudocode for my 'airport challenge' solution_</sub>

During the week we practised pairing and TDD by building a '[boris bikes](https://tfl.gov.uk/modes/cycling/santander-cycles)' program, and I explored cohesion and coupling with a secret diary project.
The weekend challenge was building an [airport](https://github.com/ruthmoog/airport_challenge) and it *destroyed me*, but, with some coaxing and persistence I made something that kinda met the spec.

## Misc

 :heart_eyes_cat: Shout out to Angie for giving me kitty highlighters of joy
 :nail_care: [Classes](https://blog.makersacademy.com/coding101-ruby-classes-explained-b0645a721288) are an ATTITUDE
 :sunflower: Met some [donkeys](https://www.spitalfieldscityfarm.org/) in my lunch break 
 :leaves: Enjoying daily meditation more than I expected