Good morning, good afternoon and good evening! Thank you for coming to check in on me and my progress for the semi-final week at the Northcoders Bootcamp, and what can I say besides thank the lords that it's the weekends!
Before I dive into what I've been up to this week, be sure to follow me on Linkedin, Twitter and Dev.to to keep up-to-date with my journey both here at Northcoders and beyond as a Software Engineer!
Before going straight into a list of topics of what happened this week. I would like to introduce the lovely members of Team G3O that have embarked on the journey of the final Northcoders Project with me:
So, this week we finally got stuck into the nitty gritty of coding our final Northcoders project. I won't go into too much detail until next week to avoid giving it away, but here's a list of topics that I'd like to cover in this week's blog post:
- The importance of "Spiking" technology
- Learning to trust the team
- Enjoying the process
- Importance of documentation & navigating documentation
- What is TypeScript and why you should learn it
The importance of "Spiking" technology
Last week I briefly covered the concept of "Spiking" technology and what it entails. If you would like to read more on that then please click on [this link] to find out more(https://bit.ly/3ErsmO9) . However, if you would like a simple explanation of what this means, then spiking technology includes exploring new technology to see how easy or difficult it is to setup and use, and exploring how fit for purpose it is.
Spiking is an incredibly significant part of the SDLC (Software Development Life Cycle) because changing technologies in the middle of an on-going project can throw spanners in the works and cause more headaches than necessary.
Our team had multiple incidents with the technologies that we were using throughout this week that ranged from not being able to even run an emulator to view the changes happening to the code, and much more - and so in essence, when you are planning out what technologies that you and your team are going to use in the future, ensure that your entire team are able to get the tools working before you explore if the technology itself is at a conceptual level, worth it for your project.
Learning to trust the team
During the Northcoders Bootcamp, the extent that you work with others are limited to pair programming with different members of the cohort. Therefore, besides pair programming we had little exposure to what it was like working in a group atmosphere on a single project. To add to this uncertainty of working with people on a single project, we had been speaking the prior 6-weeks on the back-end and front-end projects working solely on our projects, and so it was easy to only trust in myself during that time.
I won't sugarcoat it and say that I was anxious going into the final project phase because I hadn't worked with Jon, Cookie and Nikita before in pair programming, and it was a huge question mark in general going into the final project phase. However, as soon as the first day of actually coding our final project this week, I had learned the importance of trusting your team and letting myself gradually open up and trust everyone.
Whenever I, myself and the others needed help from each other, we would jump straight into the same Discord channel and start trying to figure out why things weren't working. Sure, sometimes we weren't able to find a solution immediately when we jumped in to try and fix things, but having another fresh pair of eyes and brains does wonders!
Personally for me and Cookie that have been consumed with working like cavemen on the back-end, which is an in-joke because going into the Front-End portion of the final project was like cavemen who have been living in the caves for years and finally seeing how much humanity has evolved π We would feel lost in what was going on because of this and I'm sure that Ellie, Jon, Nikita, and Antony had also felt the same because they were in the dark working on the front-end portion of the project.
But everytime that we had our daily morning standups (9AM on Discord) and afternoon standups (1:30 PM), I would be blown away at how much everyone has progressed on with their work, and it was just always a pleasure to see everyone's progress and share group therapy sessions when all of our code wasn't working the way we wanted it at all π
Enjoying the process
Perhaps backtracking a little back to last week's blog post, but I'm glad that my team was truly onboard with the idea that we decided to go with because the two other project ideas were too reliant on generating documentation more than it was coding, and didn't have the "enjoyful factor that we would want.
The most important part of the final project phase I believe is stepping out of your comfort zone and exploring new technologies within reason and really enjoying the process itself. For our group, we judged that our current project is challenging and fun to create - as opposed to spending over 2-3 weeks on a project that none of us are enthusiastic about.
Therefore, if you are a current Northcoder fast approaching the final project phase, then I really do implore you to explore new technologies and enjoy the process!
Importance of Documentation & Navigating Documentation
So you've heard it time and time again, documentation, documentation, documentation... I will be honest with you, before starting the Northcoders course and even a few weeks into the Fundamentals Phase of the course, I was always quick to close the documentation because it was so confusing and demotivating because I didn't understand what was being written.
However, the importance of documentation cannot be emphasised that much more during the final project phase, or when you're deciding to explore new technologies! For our group that were using a variety of different and new technologies, the only option was to navigate the documentaiton to gain an understanding of what we are actually trying to use.
But, what I have personally learnt about documentation is that building tolerance to not automatically alt + f4 and close the documentation is the first step. The second step would be to read the little summary blurb on most documentation that is there to explicitly tell you what that technology does, and during this step really think about what you're trying to achieve and if this technology will help you achieve what you want. The third step would be to view the "features" of that technology to further explore if this is something that will enable you to build things the way you want. The fourth step would be to view existing examples of that technology and to really read the code to understand what is going on. Lastly would be to just start using it. Sure, you can view endless video tutorials, however the best way to internalise anything is to learn by doing, so get your hands dirty with the new technology!
What is TypeScript and why you should learn it
With the absence of technical jargon you may have noticed that I don't want to spoil what our team have been using and working on, but I would just like to introduce what "TypeScript" is and why I think you should learn it.
TypeScript is a strongly typed programming language that is called a "Superset" of JavaScript. This means that you are able to specify a function's paremeters and its return value's type to be a certain type, and how it looks.
You might be asking? What is this, and why is it important? - Adding types to your functions and variables is what is called "Static Typing", and is especially important because it allows you to see ahead of time any errors where you may have assigned an incorrect data type to a certain variable.
But, this is not the only great thing about TypeScript. Another great thing about TypeScript is that unlike JavaScript that provides you the errors only after you have run the code, TypeScript will flag the errors before compilation, and this saved our team a significant portion of time during development especially since we were working with numerous packages and quite often, we wouldn't know what code someone else has written and so having the static type definitions of what data is what and what type, essentially was really useful for self-documentation.
I personally can confidently say that we wouldn't have been able to make this much progress as a team without of course working properly as a functioning team that gets along well, but without TypeScript we would be wasting a lot of time with inputting the wrong data types and a lot more!
Thoughts Going Forward
I am honestly really proud of not just myself, but my entire team pulling together and really giving it our all on this final project. Instead of feeling dejected about not getting a piece of code working for 1-2 days, we would each wallow in each other's sorrows and have a good laugh, it's honestly a great team atmosphere! I simply can't believe that next week will be my final week at the Northcoders Bootcamp, and I am both nervous and really looking forward to what happens above and beyond Northcoders!
But for now, I'm going to enjoy my time away from looking at code this weekend and enjoy the new Pokemon Scarlett and Violet that came out today!
As always, if you have made it this far thank you for the continued support and I hope to see you all again this time next week when the coding of our final project should be finished!
Socials
Feel free to give me a follow on any of my socials down below!
Top comments (0)