By James Nowecki
We’ve just finished week 5 of the _nology coding bootcamp, and the previous two weeks of coding has been an intensive and thorough lesson in JavaScript, which has suited me very well. I particularly enjoy the logical side of programming, and now, it feels like the course is beginning to get into full flow…
Our training in JavaScript started with the basics of simple and complex data types, functions and loops, and the initial challenges shared a common theme of ‘build a function that does x’. I took a pragmatic approach and started implementing the functionality we had learned into one of my personal projects, which gave me an opportunity to test I understood the concepts completely enough to apply them in a different and practical setting.
The first week of JS culminated in a basic tech test to build a functioning Morse Code translator. The second week has focused on Object-Oriented Programming (OOP), writing tests with Jest, and Test Driven Development (TDD). The OOP approach was logical and made a lot of sense to me with my research background. I also learned a lot from the testing, and our morning of TDD improved both my ability to write tests, but also to write code in general. It felt like this was a critical turn, which is helping me put all the pieces together. Everything was going SO WELL: until out of the blue we were tasked with a timed tech test.
We were given a very short briefing, and 5 hours to create a space invaders-style game, which all had to be written in under 150 lines of code. Breaking the challenge down, I began by allocating a good 20 minutes of this time to dissect the problem, and write pseudocode. This is one of the areas where I have really been able to leverage the problem-solving skills I honed in my career-to-date as a research scientist. In this field, approaching problems which in some cases, no one had had to deal with before, was a common characteristic of the job. A structured approach which breaks the problem down into sensible bite-sized sub-problems was essential, asking questions such as:
- What is the problem, and what will we gain from resolving it?
- Are we asking the right questions?
- What do we already know about areas related to the problem?
- Has this, or a similar problem been encountered before? If so, how was it approached?
- What tools would we need to explore and potentially resolve the problem?
- How many samples do we need to feel confident in our dataset? Label our samples in a sensible way so others can use them in the future with confidence (just like function and variable names!)
- What is our hypothesis?
- What would we expect the results to be?
- If the results differ from this, why do they differ? Was our hypothesis incorrect, or did something unexpected happen?
- Rework the hypothesis and test again. Loop until the hypothesis fits the dataset.
In the case of the timed tech test, I broke the problem down and pseudocoded it, and then began with building the OOP parts, as this was pretty straightforward and an ‘easy win’ to build some momentum. Once these were in place, I started to build up the functionality with an ‘inside out’ approach, writing the most specific, basic functions first, testing them to validate they were working (thanks, day of testing and TDD!), then incorporating them into the larger ‘wrapper’ functions. When the 5 hours were up, I emerged, pleased to have completed a minimum viable product (in well under 150 lines of code!) within the time limit. This validated the approach I had taken, and I feel so encouraged by my ability to complete these kinds of tests now, with over half of the bootcamp left to go.
We finished the week on a high note as a group, with an evening of pizza, beer, and board games. Never underestimate the problem-solving practice of a board game! Approaching a game you’ve never played before requires you to learn a new set of rules, experiment and play with the mechanics of the game, seek similarities with previous experience, and define what you think to be an optimal strategy to approach the game. I regularly draw upon this experience when approaching problems.
Games aside, I’d like to acknowledge the value of previous experience in relation to professional soft skills, which make the difference between a coder and an effective developer in a tech team. Working face-to-face with people with complex needs in my previous role gave me a real foundation and confidence in these skills. Bolstered by the excellent training provided by Tracy from Realise on the _nology course, I delivered a well-received TED-style talk on the demonstration match between AlphaGo and Lee Sedol (pictured above), AI and machine learning at the end of the week.
Just because you’re midway through a career change, doesn’t mean you should disregard the skills you gained in your previous role! You’ll be surprised by how your unique skills will allow you to grow and develop on your coding journey.