Learning to Code – Week Two

Last week was the second week of my time at Makers Academy. After an intensive first week, the pace continued, with the routine being established of Monday focused on Code Reviews of our end of week challenge, then Tuesday to Thursday undertaking a project whilst receiving lectures on relevant topics, and on Friday receiving our end of week challenge.

Our challenge during the week was to build a Battleships game in Ruby, to focus us on Object Oriented Design and Test Driven Development. As with last week’s challenge we worked in pairs. My pair this week was Josh (who is also writing his own blog).

What I’ve Learnt About Coding

Test Driven Development (TDD)

I hear a lot of mixed views on this. I admit that sometimes it’s frustrating when you just want to get stuck into writing code, but I do appreciate the focus it gives you on developing only what you need and I’m very glad that Makers reinforce this through all the teaching.

One key learning I’ve had on TDD has been to keep the scope of the test within the class you’re focused on. This is along the lines of SOLID principles. I can see that writing good tests is as important as writing good code. I’m getting the hang of mocks / doubles and stubbing, but practice is the key.

Less Is More

When writing our Battleships programme, by the end of the first day, Josh and I had created a large number of lines of code (LOC), in solving some key aspects of the game, such as enabling players to place their ships, ensuring they don’t get placed on other ships or go outside the grid. Our tests worked and we were pretty pleased with ourselves.

On the second day, we made more progress with the game but reduced our lines of code. We refactored many elements to achieve the same results with less code and improved readability.

Our lesson here is Red => Green => Refactor, i.e. write your tests, pass your tests, then look to improve it.

This was true of our end of week challenge – writing a method that would replicate how the inject method works in Ruby. Once my tests were green I had around 40 lines of code. But through spotting repetition and finding some other improvements I got this down to around 10. Very satisfying.

Domain Design Is As Hard as Coding

If not harder. If you get stuck on a coding issue Google is a ready helper. Unfortunately Google is less helpful with your domain model – what and how many classes do I need? Which object needs to do what? I think this is something that will get clearer with practice. I’ve noticed I have a tendency to overcomplicate my paper design and end up being more flexible when I come to coding. Something for me to keep an eye on.

What I’ve Learnt About Learning

I’m really enjoying learning and can feel my brain working in a way that it hadn’t for a while whilst in a career job. At Makers they record each lecture and make it available for playback, something I’ve used a couple of times. It’s difficult to take everything in when you’ve got a combination of watching code and listening to the explanation, whilst trying to make notes, so these videos are a really useful resource.

Other Reflections

At the start of week 2, Makers moved from their City Road premises to Commercial Street. A multi-level office this time with lectures on the first level, then workspace above and a “staff room” mezzanine. Very start-up look to it with exposed brick and wooden floors. In a great location, with Brick Lane to the East, the City to the West, Spitalfields to the North and the Tower of London to the South.

We know have 2 weeks off for the Christmas break. An opportunity to relax (a bit), reflect and keep on coding and reading up (I have a long list of things to do). I do find that at this stage I need to be coding regularly to keep the learnings in my head, so I’ll be making sure my GitHub streak continues throughout the break.

Also Friday night saw the Christmas Party / Office Warming. One reason why I’m doing this course is because I’m interested in opportunities in start-ups where I can bring a mix of my commercial skills, eCommerce management and following this course, some technical know how. So it was great on Friday night to get talking to Les, one of the founders of BorrowMyDoggy.com and hear about his experiences in starting and developing that business.

iPhone 6 vs 5: 3 design features Apple got wrong


I upgraded from a 5 to a 6 at launch 3 months ago. I like the 6 but don’t love it, for three key reasons;

1. Size
The  iPhone 6, even in the smaller version is too big for comfortable single hand usage. It’s not just the height and stretching your fingers to the top of the screen, it’s width as well. I forever feel as if it’s going to slip out of my hand, something the thinness and rounded edges exacerbate and something I never had with the 5. As a consequence It has jumped out of my hands and onto the floor a number of times.

2. Button Placement
Having the power button and the volume buttons directly opposite each other causes irritation. I’m often gripping the phone on both sides when trying to alter volume and find myself pressing the off button at the same time or vice-versa. Having the off button on the top as the iPhone 5 did was better.

3. Bend
The iPhone 6 feels flimsy. The iPhone 5 was solid. Mine has bent – by the volume control – see the photo below. The material of the casing feels too malleable. The metal casing of the iPhone 5 made it feel armoured, the iPhone 6 feels flimsy.

iPhone 6 bend
iPhone 6 bend

Apple’s usually been stunningly good at the hardware design as well as the software. With the iPhone 6 they’ve lost their touch.

Learning to Code – Week One

On Monday I arrived at the offices of Makers Academy to start my 12 week journey, along with 26 others, to become a web developer. It’s now Saturday and I’m gathering my reflections on the first week.

What I’ve Learnt About Coding

This week we’ve dived into Ruby, focusing on Object Oriented Design and Test Driven Development.  Here are some things I want to remember as I go through the rest of the course.

  • There’s usually more than one way to get the result you’re looking for, but;
    • keep it simple, because you’ll have to maintain it, extend it or explain it to someone else.
    • use the ‘Least Power Principle’ (c) Sam, Maker’s Head of Education – avoid using a sledgehammer to crack a nut
  • Test Driven Development is the best way to approach coding
    • Know what you need it to do and make sure it does it
    • Saves you writing too much extraneous code
    • Failing tests is good, helps you learn and helps you code incrementally by doing just enough to solve each failure.
    • But beware false positives, start with an empty method and build in steps. If in doubt get stuck in with interactive ruby (irb).
  • Understand your domain model
    • You need to work out what objects will have what responsibilities, helps keep your code clean and easy to understand.
  • Refactoring your code
    • There’s always an opportunity to make your code shorter, simpler; write your tests, pass your tests, refactor.

What I’ve Learnt About Learning

20 years after leaving formal education, I was worried that I would find being in an intensive learning environment a tough experience, so here’s some thoughts on this.

  • This is not a passive learning experience – you have to be a “Knowledge Predator” (c) Sam again.
  • 20 minute principle – if you’re stuck for 20 minutes, ask for help.
  • Slow and steady aids digestion of learning.
  • Working in pairs (we’ve been pair programming) is good for understanding as your either having to explain or having something explained to you.
  • You learn by doing and getting stuck in – test driven development has been good for this as you can state what you’re trying to achieve and then go forth to achieve it.

Other Reflections

It’s been an exhausting week, but hugely enjoyable. It’s been interesting to meet the others on the course. A real mix of ages, nationalities and motivations for the course. I’m really looking forward to getting  to know them all more over the next 11 weeks.

Now to crack on with completing the weekend challenge and pre-reading for next week.


Net Neutrality & Barriers to Entry

Just one week to go until starting my 12 week course at Makers Academy (see previous post) and I’ve been ploughing through a variety of tutorials to get up to speed with many of the concepts we’ll be using.

The range of helpful online resources that are free to access, which people have invested a lot of their own time in is amazing.

There seems a strong sense of cooperation within the coding community, helping more people get involved and bring their ideas to life and to market.

I was pondering this in the context of the debate over net neutrality.

It seems to me that enabling Internet Service Providers (ISPs) to discriminate against certain traffic would lead to raised barriers of entry for new internet businesses, something which the area is happily short of.

Coming from 20 years in the airline industry, where barriers to entry are still very evident* it’s refreshing, as I embark on learning to code, to be able to think more open-mindedly about new business opportunities, something that not enshrining net neutrality could limit.

However we also have to consider the ISP’s perspective. Ever growing internet traffic demands investment in infrastructure to deliver to customers.

So who should pay;

  • The generator of the content (eg. Netflix, Facebook)?
  • The customer who is consuming it?
  • The ISP who is delivering the content?

The answer is probably a mix of all three;

  • Shouldn’t a content provider, like Netflix, pay the real cost of delivering their content across a constrained network, giving an incentive for efficiency?
  • Shouldn’t a customer who is consuming more bandwidth than others pay a proportionally higher cost for receiving that service?
  • Shouldn’t the ISP have an obligation to provide a base level of Internet access, without bias, to any customer?

What I do fundamentally believe at the heart of this is that companies involved in the distribution of the web should not be allowed to discriminate against specific providers of content.

Allowing discrimination would create barriers of entry disrupting innovation and competition.

And this is what I think really needs protecting in any legislation about Net Neutrality.

What are your thoughts?

* Getting a new airline off the ground is still quite difficult due to high cost of aircraft, even with leasing, certification and regulation, though the barriers to entry in the airline industry have lowered considerably through growth of non-hub airports, open skies agreements and web distribution to name just a few.

Why I Quit My Job To Learn To Code

I worked for the same company for 20 years, until last week. I’m now getting ready to join the December cohort at Makers Academy in Silicon Roundabout for a 3 month, full time course, learning Ruby on Rails, HTML5 and much more to take me from zero to “entry level programmer”.


My main reasons are;

  • I enjoy creating things – understanding code allows you to build stuff.
  • I had stopped learning new stuff – I’d had a fantastic career but wanted to do something different.
  • I love eCommerce – I spent half my career to date working on the business side of the web, great to supplement that experience with some tech know-how.
  • I’ve got a load of business ideas that need coding – so why not give it a go myself.

How am I feeling about it?

Excited – having been a one-company man the last 20 years it’s exciting to look forward to a new environment, people and culture.

Nervous – it’s been a long time since I’ve been in such a learning environment; I hope the grey cells are up to it.

What are my hopes for after I’ve completed the course?

At this stage I’m keeping a really open mind as to what I will do after the course. Become a junior developer, join a start-up, get back into a senior eCommerce position in an established company or venture forth on my own. All these are possible options, but I’ll wait until I finish the course before figuring that out.