Congratulations to the October cohort of makers! They graduated and presented on their final projects last Friday. Some teams had decided to run with ideas pitched at them by charities. There was Oodles, a service for connecting people with surplus food to charities that need surplus food to distribute, and Lookup, an app that allows you to assess roofs for potential yield of solar energy.
Lightbox is a secure messaging service for doctors to communicate patient data and discuss. Lastly, Hipspot uses twitter location data as a proxy for the popularity of restaurants, bars, nightclubs, etc.
Given the December cohort and I will be starting our final projects in a couple of weeks, it was a very inspirational, albeit a little intimidating, performance.
I caught some conversation from the many scrum-meetings that went into developing these projects and was impressed by all groups attention to process. Good process, so I have learned, is about writing clear user-stories, getting thorough test coverage, and adhering to best practices in naming and style conventions. This may sound boring compared to slapping together a feature-rich app. My hunch is there’s art and discipline in good process and if you do it right it makes the whole thing much more fun. We’ll see.
One highlight of the past week was a talk by Paul Carke, CTO of Ocado. It turns out that Ocado is not an online supermarket as many of have been led to believe, but is firstly and at heart a technology company. Paul Carke illustrated this point with a couple of incredible infographics, the first a virtual-lightshow of neon-coloured units, presumably representing individual customer orders, tracking back and forth along kilometers of conveyor belt in a warehouse. The second showed delivery routes unspooling from distribution centers across England. These two representations alone were extremely impressive (though I did notice that Norfolk and Cornwall were completely dark) and attest to the rapid pace at which Ocado is unsettling the grocery market with automation.
Lunchtime talks are the jet propellant of Makers. Usually there are phrases and acronyms that are over my head, but it’s motivational to be exposed to these vast areas of unknown technology, many still in the process of being hashed out.
Week 4 at Makers! You can see in this photograph that Ana the MA marketing wizard snapped of me, screens are a big deal. I took advantage of having two, plugging both into my Macbook for extra acreage. It’s useful now we’re quickly moving from working with a single page of code to a whole suite of controllers, models, feature tests, and an involved directory structure.
An interesting subject that came up this week in my conversations at Makers was pain in the learning process. Nobody likes to be in pain, even if it’s just the mental kind that you get when trying to fix an error you’ve never encountered before, yet it seems to be inescapable when getting to grips with something difficult and new.
It’s a controversial topic. Occasionally this week myself and many among the December cohort have felt out of depth, floundering in the unknown, and it seems to be a coach putting us in this position. “Aren’t they supposed to help you?” I hear you ask. Indeed, one reaction to this is to blame the coach for not fully explaining whatever the source of the frustration is. Another approach, which a lot of coders believe in, is to take pain as a sign (a sort of “code smell”, in the lingo) that your going about things the wrong way.
Though it’s true that if you’re fully driving your development with tests, making only incremental and necessary additions, and following all the SOLID, RESTful, (there are a lot of acronyms for good coding practices) decisions, frustration should be kept to a minimum. Stay zen! Factor out your emotions! These phrases are used a lot.
Even if it were so easy, is that really what we want? One coach, a graduate of Makers, made the point to me this past week though that if students don’t test the limits of their mental endurance while at Makers, they never will. At Makers we get to make mistakes, break things, get out of our depth, without really having to worry about the consequences.
Perhaps there are hidden dangers to playing it safe. I heard a story recently about Daniel Kish, President of World Access for the Blind, a man who has taught at least 500 children (as well as himself) to echolocate. In the anecdote, he persuades a blind boy who typically relies on other people for mobility to climb a tree. The boy hates it but Daniel keeps working on him, taking away the option of coming back down. Eventually the boy learns to climb trees and a great deal else too, but not without some pain along the way.
Alright enough musings, on to Fun Friday! Friday was fun for three main reasons:
1) My team and I won the first CodeJam. A coach organised “CodeJam”, a kind of rapid coding competition. Four teams of four had 15 minutes to solve code ‘katas’ – short problems designed to be repeated again and again for fluency. The time limit made it intense and we had some communication issues on the first problem which meant we didn’t quite get a solution in time.. but fortunately neither had any of the other teams. The second round we communicated a bit better and almost aced it, which was enough to go 2 for 0. No prize but lots of bragging rights, were that my style.
2) I presented at the first Makers Pecha Kucha of 2015. At 5pm Steve, a teacher at Makers, held a Pecha Kucha. My favourite presentation was by Canadian and fellow student Danielle, who introduced us to her far-flung hometown that I forget the name of. Mine was about Jeju-do, a beautiful island province of South Korea, and my residence until very recently. It was a great experience, though I felt that it was people already confident in public speaking who got up. Hopefully next time there will be more of a mix.
3) It was Friday!
I happened to pick up a book The Journey is the Destination this week, the title of which touches on my experience at Makers so far. It is an incredible collage-diary of a young photojournalist called Dan Eldon and his global explorations (sadly his life was cut short at 22 – but what a life!). There’s a lot of amazing photography and art, which is about all the culture I have time for right now.
Something that has become fully apparent to me only this week at MA is that the process of learning at Makers is itself the destination of learning. In other words, part of the challenge is to learn how to learn. But what does that really mean? They way I see it is that when you’re learning anything new there is a constant tension between what you understand and what you don’t yet understand. Being a good learner is about effectively managing this tension. If you go crashing into the unknown too recklessly, you’re going to get stuck in a myriad of things you don’t understand. This is dispiriting and the reason a lot of learners just give up.
The challenge as a student at MA is to carefully control how you advance in building with new and unfamiliar technology. Often what seems like a small step leads you into the thicket of non-understanding and you have to back out again to take even smaller steps and figure out exactly where it was that things didn’t go how you expected them to. The staff at MA are excellent at coaching students on this incremental journey, not giving up the answer but helping to clarify what’s at stake in each line of code. Eventually this process will be second nature.
Sometimes, however, a problem comes along that is completely beyond your experience and brings progress to a complete standstill. My pair partner and I had this on Thursday when, weirdly, our Cucumber tests of our Battleships game were going green (that’s a good thing) but when we loaded up our the website, we weren’t seeing what we expected to see. It turned out that it was to do with the program we were using to run the website, which was different to the program that the testing software uses. That this might make a difference hadn’t occurred to us and probably in a different context we would have given up. Fortunately we had an MA coach on hand :-).
A common topic of conversation amongst Makers students is, quite naturally, why are you here? What motivates you? Here I’ll list some of my reasons before focusing on one.
I want to work in a creative and fast-moving industry.The loop between design and realisation is very tight when coding, given that the only limit is how fast you can think/type.
The tech industry has some of the best business practices. This is only becoming fully apparent to me now with our exposure to various design practices, the Minimum Viable Product concept, etc.
A global skillset. What we are learning can be taken anywhere, because technology is everywhere.
More idealistically however, and this is coming from my own background in education, I am interested in how tech might transform access to and quality of learning. So many students around the world cannot get the teachers and materials they need or, even for those who can, the style and structure of learning is poor. Online platforms are beginning to provide low-cost options in a form that might even be more interactive and engaging for students than the average classroom.
At the moment though, it’s pretty restricted to the “hard-subjects”, such as maths and science, where there is an objective answer that can easily be validated by a computer. Sure there are other subjects but these usually have the form of lecture videos, reading material, etc. Basically, the traditional style of learning put online.
In the future, though, with machine learning and so on we may be able to have computers understand, evaluate, and respond to not just user-responses restricted to a set of pre-defined options but complex, opinionated, and synthetic judgements.
So anyway, that kind of stuff is what I want to be involved in. But first I have to understand how to encapsulate Cucumber tests >_< (more on that tomorrow).
So far it’s all been about Ruby. Even RSpec, the testing framework we have been using up until now to drive the development of Week 1’s Boris Bikes project and Week 2’s Battleships is written in Ruby.
This week though we’ve stepped out of that relative comfort zone into a technology called Cucumber, which we’re using to build our Battleships Online web game. As far as I can tell, Cucumber is structured to promote a business practice whereby you begin by describing program features in plain english. This forces you to think about the rationale for having these features in the first place, before you’ve done the difficult work of coding them. Running this description then invites a kind of virtual user of your web app or site to browse through and check that it works how it is supposed to.
There are a few layers to it to get from the English description to the behaviour of this ‘virtual user’, which deviate far from the Ruby syntax we’re used to it. So today was a slow process of writing the description, correcting syntax, and then writing the HTML to satisfy the test, correcting that.
Right now I can’t imagine how the project is going to look 3 days from now, which makes this week an exciting one to be at Makers