Dev Journey Introduction
Boot Camp Weeks 1 & 2
JavaScript Foundations
Backend Block
Frontend block
Final Project Phase
Welcome back 👋 Three weeks of JS Foundations taught me so much, not just about JS. Primarily I had to learn to pick myself up and dust myself off, then clean up my melted brains from the floor...
Last few weeks in a paragraph (or two)...
Summer really takes it's time in the UK, especially if you live in the north! But finally, the sun has come out. 🌞 The extra work in the garden has been a welcome relief from JS Foundations. The relentless pace of boot camp 🏃♂️ means there is little time to recover from one mind-blowing concept before being introduced to the next, headaches from learning are a real thing! So i was grateful that pumpkins 🎃 grow relentlessly and seem to outgrow their pots weekly. I also had really successful time seeding peppers this year so ended up giving away seedlings 🫑 ↔️ 🍅 I did get some tomato plants in exchange though. More plants to home, but the upturn in weather has meant many of my indoor plants have been re homed outside 🪴 In boot camp, everything started to feel a lot less conceptual and a lot more 'real world'.
What did I get from JS Foundations...
Recursion isn't as scary as you think. Most people I know first encountered recursion on freeCodeCamp. I did, in the introduction to this blog recommend this resource (and still strongly do), but their introduction to recursion makes it a little more complicated than necessary. My advice would be to take a simple JS kata like factorial and try to replicate your solution using a recursive function. If you feel comfortable with recursion, then look up 'tail-end recursion', which removes the call stack build up and makes those recursive functions lightning-fast.
Pure functions make for complicated TDD. A pure function is one which won't modify or mutate any data outside it's scope. So the input data and everything outside of the function's scope should remain unaffected after it's invocation. This concept itself isn't complicated, but once you factor in TDD then you are back into the world of mock functions and I wish you luck! This is possibly still my weak link in JS, but I still have plenty of time to come back to it. Having said all that, I am becoming more and more friendly with jest and the procedural nature of TDD. It gives you absolute faith in the functionality of your code step by step. Also it requires an additional layer of planning, which creates far more robust, reliable code. I am certain than it will be no slower in terms of productivity as problems tend to be solved very quickly, due to the way TDD breaks coding down into small manageable and easily de-buggable problems.
Giving lectures where you are trying to explain the 'this' keyword looks really tricky as it renders the use of the word this redundant. The this keyword is implicitly bound to the object in which the method was invoked, which basically means that if you have a method which uses the keyword this, which is stored as a value within an object. When that method is invoked from within that object, the word this will be referring to that object. It means you can write functions using the word this instead of having to hard code each object's name into a function, thus making functions re-usable as methods within multiple objects. Object oriented programming seems relatively straightforward at the moment, compared to functional programming, but no doubt time will prove me wrong!
Classes, constructors and prototypes are better than factory functions. Classes brought with them one of the most fun couple of boot camp days so far. I was working with the legend Khizar, a knowledgeable and patient programming pair partner. Also we were using classes to build a Pokemon themed game, which pleased my partner as a childhood Pokemon fan and pleased me as an old-school gamer. Factory functions are the older way of using functions to build objects in JS. It allows you to build many objects using the same template, handy for example when building several Pokemon characters with similar attributes. The code when using factory functions isn't very DRY as there is tons of repetition. Fortunately classes and constructor functions do lots more for their money. They automatically create a new object and more important they create a prototypal link between the constructor and the object, meaning that any functions available in the constructor are also available in the created object, without the need to code the function in each object.
Asynch, call backs and the day we were told we cant return out of functions anymore. Because javascript is a synchronous language and human beings are impatient, this created a problem: When your app or web page hits say an image which takes a while to download, that would mean waiting for it to fully load before the rest of the page can continue to load and become interactive again. Thanks to Ryan Dahl, Node and a lovely place called 'the event loop' we have access to an asynchronous world where functions can live, waiting for data to be retrieved and when the call stack has cleared can return that information via our friend 'the callback function'. One nasty side effect of this is that our functions can no longer return in the traditional way as use of the word return, would mean the function would exit out, before the data had been retrieved. Instead all data is handed back using callbacks. This method of achieving asynch in JS is pretty confusing though and leads to something called 'the asynch tree of doom'. Fortunately I will mainly only have to recognise this method and not employ it myself too often.
Promises and the return of return. After a few days living in the frustrating confines of asynch land and callbacks, it became clear that this is a massive part of living with JS. The only way to avoid blocking code (code which stops other code executing) is to take advantage of the event loop. Fortunately there is the newer JS method of using promises. These guys allow you to stop stacking up callbacks and instead return (yes we are allowed to return again) promises into another block depending on their state. Promises can be pending (awaiting response), fulfilled (they are sent to the next then block) or rejected (they get sent to the catch block at the end of the chain, which catches all errors). And promises can be easily returned to the next then block if necessary, for example if you are wanting to write some logic based on the return values of two separate promises. I imagine we will end up using promises more than callbacks, but there is still asynch/await to come so stay tuned...
Imposter syndrome is real and just about everyone suffers from it. If you don't know what it is, then basically it is like that unshakable feeling of doom you get when you feel like you are in over your head. Something which I expect most people in most careers have felt at least once or twice. The problem is that in the world of software development you are constantly learning and equally frequently coming up against confusing concepts. Each time you hit a new concept which is unfathomable, the feelings of doubt are the same: "I should understand this by now". "I thought I could speak JavaScript". "Maybe this concept is just one step too far for my brain to take". The fact is, almost all computing concepts take practice before a full understanding is achieved. Don't listen to the doubting voices and remember that just about everyone else is going through it too.
Coming up in part four...
Backend week, company presentations and cohort drinks. Will I be able to handle going out in public places again?
Top comments (0)