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 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%^* of a profesh day programming will be spent on code, with the rest on teamwork & communication or research & understanding problems. 60%^* 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.

*_{these stats are not credible, just go with it.}

TDD

I live with a TDD fanatic 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 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 is a popular testing framework for Ruby. It's a domain specific language (ie its a language - written in Ruby - specifically for testing).

Coding Challenges

_{pseudocode for my 'airport challenge' solution}

During the week we practised pairing and TDD by building a 'boris bikes' program, and I explored cohesion and coupling with a secret diary project.
The weekend challenge was building an airport and it destroyed me, but, with some coaxing and persistence I made something that kinda met the spec.

Misc

😻 Shout out to Angie for giving me kitty highlighters of joy
💅 Classes are an ATTITUDE
🌻 Met some donkeys in my lunch break
🍃 Enjoying daily meditation more than I expected