The Kindergarten-state-of-mind

Tom keeps focused.
My Colleague Tom in one of our last talks. You really have to bring a fresh and positive mind if you want to grasp what's going on here.

„Don’t worry about feeling stupid.“ They keep telling you this at Makers Academy. „You will get used to not knowing how things work,“ is another piece of advice I have heard several times.

But I do worry that I’m too stupid to get my head around this. I thought I knew how to make my objects talk to each other. I thought I had understood that a proc wraps a method to have it executed within another. I meant to know which tests I need to write for each class. But I run into the same problems again and again.

Battling the ships

My pairing-partner Chris and I have produced a small stack of models during the last week. We found out that it is better to delete some lines of code than to pass hours fiddling around to get the old lines working (again). The code we wrote could have been written within two hours maybe. But we had to think about how a ship could get onto the board and how it would be hit by one of the player’s shots.

One of the things I really like about Makers: we often start from scratch or at the same basis. This week we will extend our battleships-game with a web-interface (very excited about that!). (After programming a text-message-sending management system for a takeaway-restaurant during the weekend). Our coach Stephen is writing the underlying code-basis for battleships web in front of us. I think that’s perfect. Since I have tackled the problem for so long, I can follow his writing and I see how he is solving the issues.

When he programs one class, he doesn’t include the other classes at all. Let’s say he wants to program how the game ends:

  1. Write the RSpec-tests:
    it “knows a game is not over as long as none of the players has lost” do
    expect(game.over?).to eq false
    it “knows a game is over when one of the players has lost” do
    allow(player_one).to receive(:lost?).and_return(true)
    expect(game).to be_over
  2. Make the failing tests pass:
    The easiest way to make the first test pass is to creat a method called „over“ and make it return false. The second test forces you to change the code: Line one is the human-readable test. Line two makes player_one answer with „true“ to the method „lost?“. With this line we state that player_one has lost no matter what his board may look like.  Line three is the actual test. It expects the game to return „true“ when confronted with the  method „over?“ (RSpec looks vor a method „xyz?“ ending on „?“ when you write „….to be_xyz“).
  3. Code:
    def over?
    player_one.lost? or player_two.lost?

The coaches keep saying that testing (TDD) and class modelling (OOD) are two of the most important things we have to understand if we want to become web developers by May.

I try to stop worrying. I try to adopt the Kindergarten-state-of-mind, as Sam called it during my darkest hours at Makers last Friday.