Halfway through my Coding Bootcamp…
I’m still alive… just!
It’s been a crazy 7 weeks; 21 sprints, 30 morning katas, 84 hours in the car commuting and a quite a few games of exploding kittens. Unlike other cohorts, we’ve been lucky to get a week off thanks to a well time Christmas — and boy do we need it!
I thought this was quite a good time to look back and reflect on what I’ve learnt so far; both from a technical point of view but also about myself.
JavaScript
We started the course with 3 weeks of core JavaScript teaching to make sure we all had a solid foundation to build on. We also used this time to get used to the systems and processes we’ll use throughout the course; things like Git version control, pair programming and test driven development.
I’m a firm believer now in pair programming. At Northcoders we spend 50% of a sprint in pairs. When a new sprint is released, you usually spend the morning alone reading around the topic of the sprint and doing some spiking if you want. In the afternoon you then pair up and start the sprint afresh.
So far, I’ve paired with at least 12 different people and each one has been a completely different experience. You each bring your own experiences and skill sets and you end up learning a lot just from seeing how another person would approach a problem.
You’re also forced to develop your communication skills; as the navigator, your job is to explain your thoughts in English for your driver to then interpret into code. It’s also a lesson in humility as you won’t always be right so you need the right attitude going into a pairing experience.
Back-end
Before starting the course, I wasn’t sure what I was going to prefer between Front-End and Back-End — it seemed a lot of programmers have strong preferences between them and perhaps even someone’s natural skills would dictate what they would good at.
I definitely had the wrong idea about Back-End. I heard the words server and databases and pictured your stereotypical IT technician maintaining servers or manually entering information into databases.
Turns out, it is all about servers and databases but it’s actually really challenging to get it right and can be fun! We’ve learnt how to create our own express servers locally and how to set up endpoints using routers.
We’ve been introduced to the MVC model — after a lot of attempts I think I’ve finally got my head around it. I found it hard to organise my code at first when faced with completely blank projects — I realised I worked much better with a skeleton structure to start with and it’s about filling in the missing pieces. Something I now know how to set up myself.
I don’t know if it’s how everyone does it but I find it much easier going from one endpoint and trickling down thinking what does my controller, model and view therefore need to do in that order. It breaks a very daunting project down into smaller chunks.
Highlights so far
The more creative sprints
A lot of the sprints we do are quite prescriptive — like following a to do list of things to implement, so everybodies outputs look the same. Sometimes though we have opportunities to work on much more open-ended sprints. When this happens we always come together at the end of the sprint for a show and tell — it’s great to see how everyone interprets the brief differently and it gives you ideas for future sprints.
The first one was to create a terminal based Pokemon battler. It was amazing to see how far people went with this one; one team created different worlds complete with soundtrack! Sprints like this are also good to actually go home and show family and friends what you’ve learnt although turns out they don’t find it half as impressive as you’d hoped!
Creating our first web apps
In week 4 we got to create our first web app. Using the Twitter API we created a web server that would serve up data that had been fetched from Twitter. This was the turning point for me, until then I had no idea how servers worked and much of the internet was that mythical magic box to me. But even this simple sprint showed me what was possible with what we were learning.
In later sprints, we introduced different types of databases like PSQL and MongoDB — again I was blown away by how quickly you can produce ‘real’ things. It just reaffirmed that this was the right course for me, this was the stuff that I wanted to know how to build.
Third Party APIs
After being shown how to use the Twitter API we were encouraged to use other APIs and develop the skills for being able to pick up any API’s documentation and just use it.
My favourite sprint so far was when we were given the boundaries of using the Twitter API as a data source, IBM Watson’s tools and any other API’s to produce something interesting.
In my pair, we created a web app that takes a users twitter handle, fetches their latest tweets and using Watson Tone Analyzer and Spotify’s Get Recommendations Based on Seeds endpoint, returns a song to match the mood of each tweet.
I really enjoyed having the freedom to just see what was possible using the tools and then figuring out what was achievable in the time frame and how best to go about it.
Morning Katas
I’m not sure everyone else on my cohort would agree but I really enjoy the morning kata challenges we are set. Everyday we’re given a new kata, a discrete JavaScript problem similar to the type you see on CodeWars. The purpose is to help us develop our problem solving skills so that when we find similar problems in our sprints we have strategies for tackling them (also good practice for tech tests!)
For me, I just enjoy going from that empty function, then using TDD (test driven development) to figure out the simplest case and making it pass for that… then building up tests and functionality until it does everything it needs to do. Then I look back it and think, is there a better way of solving this. (Normally RegEx is the key for concise solutions so I’ve been forcing myself to use it more.)
I think it just appeals to the same parts of the brain that enjoyed doing maths problems at school; discrete problems, challenging your knowledge and then the satisfaction of completing it.
Hardest thing to learn so far
Asynchronous programming!
I’d been living in the happy world of synchronous code for so long, that when we first got introduced to async I remember just thinking “err… no thanks”. Then we learnt that when you’re dealing with web servers, it’s unavoidable, so I reluctantly engaged in the conversation.
We started with callbacks, which most of us found really confusing. Especially when you have many functions each requiring it’s own callback… we kept getting so lost. The only tactic I kept holding onto was, whatever is the most deeply nested must happen last.
But then we learnt about Promises and it made so much more sense. Do this, then this, then finish. I think because promises are so much more readable I found it a lot easier to figure out which things were going to be async and therefore needed to handled as such. I’m still finding it tough, and even little things like whether something needs to be returned or not is a bit 50/50 for me, but I’m sure like everything else, the more we use it, the clearer it will be.
What have I learnt about myself
To be more adaptable
Especially when it comes to pair programming; it’s hard to go from always programming alone and therefore developing your own habits and styles to suddenly having someone else contributing to your code. But that’s the bit I’d had to realise, when I’m pair programming, I need to think of it as our code, not mine, therefore if they choose their variable names or layouts styles differently to me, it does not matter. If it really bothers me, then I know I can go always back afterwards, once we split and change things, but I never do, so I know it isn’t that important.
To have more patience and empathy
Sometimes when I get really into something I find it hard to slow down and make sure my pair is still with me, but I need to and it is usually for the best. It’s when we rush things that we make mistakes or miss the point.
I’m also developing my communication skills. At the start, I was getting easily frustrated if someone couldn’t see what I could see or didn’t understand my explanation — I might have blamed them, when it’s not their fault at all. I just needed to find another way of communicating my ideas, a way more in tune with their way of thinking or communicating.
I can get quite competitive
I had forgotten how competitive I can be. At the start of the course they really stress how it’s not a competition, how the sprints aren’t designed to be completed and the most important thing is to make sure you (and your pair if you’re pair programming) understand the material.
In my first mentor meeting I admitted I was struggling with feeling competitive with my peers and myself. We found a way of reframing things and discussed more realistic ways of measuring success (of course it involved a spreadsheet).
My strategies for when it’s all gone Pete Tong…
- Draw it out. Pen and paper. Sometimes you need to forget about the code to actually figure out what problem it is you’re facing. Draw it out either for yourself or someone else and sometimes the answer just appears!
- Use the debugger (or console logs…) Often something’s gone wrong just because one tiny thing isn’t working as you’d expect. Following your variables, line by line, as either they go through a for loop or get passed between functions, is often the quickest way to see why you’re getting an unexpected result.
- Learn how to persevere. I think debugging skills are underrated — most the stuff you write first time has some sort of error, so it’s better to expect the errors and just learn to enjoy the process of finding them.
- (PREVENTATIVE:) TDD where you can — the methodical approach to programming really does reduce risk of errors (or at least you’ve set up your tests sensibly to then highlight what’s failed if you change your code later on
5 weeks to go!
The weeks have flown by; it’s hard to believe we only have 5 weeks left.
The next 3 weeks will be spent learning Front-End; we’re covering working with the DOM, React JS, responsive design… and a load of stuff I’ve never heard of.
The final 2 weeks are Project Phase — in groups of 4 we’re creating a complete web app as a final showcase piece. Before we broke up for Christmas we had to decide our projects; I’m really excited about mine and will definitely be sharing more about that in the coming weeks.
