DEV Community: Katie Lee

Lessons learnt on my road to code...

Katie Lee — Tue, 26 Jan 2021 12:23:48 +0000

Last week I officially graduated from the School of Code Bootcamp (🎉) and as such I've been reflecting on my journey into coding over the past year. Without trying to sound overly dramatic (okay maybe I do want it to sound a little bit dramatic...) I really have had the most amazing, life-changing experience and one which has led to a career change that I never planned to have at the grand old age of 32. Having spent the last decade as a professional musician and teacher, building a career in which I have shared some of my favourite moments in life with some of my favourite people in life, I was ready for a new challenge. (I have an insatiable appetite for personal progress in life... often a blessing, occasionally a curse.) I needed a new adventure. A new way to fulfill my potential. I found that desire satisfied in technology. And more specifically in coding.

Inspired by one of my favourite people (I won't say who because he'd be awfully embarrassed and probably kill me) I embarked on my journey from musician to programmer. I swapped the saxophone for a keyboard, exchanged the language of jazz for the language of JavaScript and went from complete newbie, to self-taught coder, to School of Code bootcamper, to School of Code graduate who's workplace-ready and probably the most enthusiastic junior on the planet right now, in less than a year. And on my road to code I learnt a lesson or two about the world of tech. I don't claim to know it all (or even half of it all) but these are some of my musings so far...

Tech is about team

This is something which probably surprised me the most at the beginning. Being from a non-programming background, I always had that stereotypical image in my head of a lone-ranger, genius developer, sitting alone in a basement somewhere, sleeping for a few hours a day, coding all night, and somehow doing amazing, clever programming things which were changing the world. Turns out I was only right about one thing there. (Incase I need to clarify it's the bit about technology changing the world.) These days, tech is all about TEAM! This pleases me greatly as I love team. I love people. I love communicating and getting to know people. I love the push and pull of working together, the discussions, the tensions, the glorious moments of unity and progress. I can do team. The ability to think creatively and solve problems by working with others is a vital skill to cultivate as working on a project or delivering a product requires expertise and experience in many fields.

To quote the late Steve Jobs:

"Great things in business are never done by one person. They're done by a team of people".

A huge part of the bootcamp has been learning how to work with others in Agile, cross-functional teams - something that has been made even more challenging by the fully remote nature of the course. But it has been worth persevering with because today's world is so complex that it is simply impossible to solve problems effectively alone. Teamwork and collaboration is not an opinion. Countless studies have proved the importance of healthy collaboration and teamwork on an organization's ability to make an impact. It's been amazing to see how each person in our bootcamp has been able to contribute different strengths and skills to their teams which resulted in some really creative final projects. We've all got something to bring. A skill you have, which you might take for granted, could be exactly what a team is missing and looking for. So try not to compare yourself to others. Just do your thing and do it really well. In fact, become the best at your thing. It's very likely that someone out there will like your thing and want your thing. (Okay I've said thing enough now...)

You'll never stop learning

What I love about technology is the constant progression, the change, the sense of moving forward. It satisfies my need for adventure and progress. From what I gather from the more experienced among us, by embarking on a tech career you are pretty much committing yourself to a lifelong education - there is always more to learn!

I have a theory about this. (It could be completely wrong so be sure to make up your own mind.) This 'you never know everything' reality kind of makes everyone a little bit more equal. You may have been working in your first coding job for a couple of months or you may be two decades into a successful career and the CTO of a big company, but you still need to commit time to your own educational journey, to look into and learn new technologies, to be willing to adapt to changing business environments or adopt the latest best practices. Maybe that's why I've found the tech community to be so helpful and encouraging in comparison to some other professions - no matter how experienced you are you can still remember what it's like to be a junior because the learning never stops.

So how I am feeling about this 'learning never stops' thing? Well, basically... great! It means that there's the potential for a really exciting and varied career, I'm pretty sure I'm never going to get bored at work, and I'm confident that I'm going to meet lots of amazing people along the way. Although I've learnt a lot over these past four months and made very rapid progress in a short amount of time, I am under no illusion that I am only at the very beginning of my programming journey. There are so many more languages to learn, technologies to master, processes to understand and situations to negotiate. On a good day this challenge can feel exciting. However, on a less good day it can feel a little overwhelming or even downright scary. But it shouldn't. And that's why I think that it's super important to make sure you always celebrate milestones and look back at how far you've already come. Which brings me nicely on to my next point. (It's almost as if I've planned this...)

Reflection is key

I started documenting my learning journey a while before I joined the School of Code. Early last year, with the support of my other half (who had recently made the jump into tech himself), I was teaching myself HTML, CSS and JavaScript basics using a combination of online resources, tutorials and kid's coding books (honestly the perfect level for me at the start). After a few months I was making good progress but some days I was finding it hard to stay motivated and see my progress. I didn't know what I was aiming for. It was then that I stumbled across the 100 Days Of Code challenge.

Now anyone who knows me well knows that I love a good challenge. I'll do anything for a badge. (Unfortunately there are no badges for 100 Days of Code but the pride was enough in this instance.) I was immediately hooked. It gave me fresh drive to keep learning as I wanted something new to tweet about each day. Tweeting with the #100DaysOfCode hashtag immediately made me feel part of something bigger (I'll come back to this later) and alongside tweeting I also committed to keeping quite a detailed learning diary in which I documented my progress, my thoughts that day and links to any work or resources I used. I continued with this throughout the summer, into September (the first day of the bootcamp was Day 53) and into November. When I finished my 100th day on the 17th November, I knew I had to keep the diary going (I'd begun to see it's value) right up until our School of Code final projects began! It was a commitment, and sometimes the last thing I felt like doing after an whole day of intense, remote learning but it was absolutely, 100% worth it and I'm so proud that I finished it! And here's why...

Firstly, having to write down exactly what I'd learnt each day really helped me to consolidate my learning. Some days I found it harder to articulate what I'd done which often meant that I hadn't quite grasped the concepts fully yet. This often led to another hour or so of me looking into things and going over them again in order to be able to clearly document them in my diary. At the time, this often felt like very hard work and a bit of a drain, but in hindsight it was this dedication to my diary that enabled me to make such rapid progress and build on my understanding each day without getting behind on the bootcamp. Consolidation is key!

Secondly, in those moments when things are a bit tough or I'm out of energy or I'm wondering if I made the right choice or if I'm simply wondering what I've done with all my time over the past 6 months, I can look back and see how much I've achieved and how far I've come. Even if no-one ever reads it apart from you it's worth doing. And to quote my mother, "if a job's worth doing, it's worth doing properly". So document, reflect and do it well! (If you want to see my 100 Days of Code / School of Code diary you can do so here...)

There's a community out there

I mentioned earlier that one of the things I have enjoyed about getting into coding is the tech community that surrounds it. Sadly (due to the current pandemic which we shall not dwell on) I have not yet had to chance to experience these communities in person but I have been able to join them online. People seem very helpful and from my experiences so far, senior developers always come across as willing to help us less experienced developers and point us in the right direction. Many even give up their time to mentor or coach others for no financial reward. (I know, these people are wonderful and brilliant.) Although I am new to this scene I have felt very welcome and get the impression that there are lots of people cheering me on, who want me to be successful and do well. Coming from a very competitive profession previously where it was a little more (very at times) dog-eat-dog this feels amazing! There's space for all of us. I really love that.

I know that my journey into tech would not have been what it is without my amazing School of Code family. The School of Code team have a done a great job of cultivating a close knit community but I think it's ultimately the intensity of the experience which really knits each cohort together. If I think back to the start of my bootcamp experience...I was thrown together with 47 other bootcampers from all different backgrounds, different ages, different life situations. Before you even speak to them for the first time you know that there's something special about these people as they've already successfully completed a rigorous interview process, they've all decided to step out of their comfort zones and been willing to try something completely new, they've left their jobs and have sacrificed having an income for the next 4 months, and all of this to try to learn to code - which I'd just like to mention is one of the hardest skills to learn and at this stage they've got no idea if they're even going to enjoy it or be good at it! These people are special. Or crazy. (I'm allowed to say that because I am one of them.) And that's before we even get started on the course. It's instantly 0 to 100 mph on the learning front, 8 hour teaching days on Zoom, homework, projects, recap tasks, afternoon energisers (these are fun), mime you lunch (only eat something you can mime), pair programming, guest lectures, waking up in the middle of the night thinking about code (who am I now?), group presentations, mastery tasks, daily squats (yes my legs are like tree trunks), trying to explain to your friends and family what exactly you're doing with your time. And then there's all the blood, sweat and tears. The blood is metaphorical. The sweat and tears are not. (Believe me, you don't know what a cold sweat is until you've had to do a live demo of your product in front of hundred's of potential employers on Demo Day.) All of this bonds you together. I will never forget my bootcamp experience or any of the friends I have made along the way. We walked through the fire of SoC together and have made it to the other side. (For those of you who think I'm being dramatic again, it really does feel like this!)

Many ex-bootcampers now come back as mentors or to give lectures on the course and there's something really nice about seeing this full circle of education. The student becomes the teacher. It's inspiring for current bootcampers to see where they might be in a few years and it's also rewarding for ex-bootcampers to be able to give back to an organisation which changed the direction of their life (for the better!). I know that it's definitely something that I'd like to do as I continue in my tech career. I'm so thankful that I've had the opportunity to embark on this amazing adventure and I want to help others make this journey and excel on it as they go. It seems that once you've been a bootcamper, you'll never really leave the School of Code family.💖

So if you're new to tech or trying to learn to code I would encourage you to find a tribe. Whether it's a community on Twitter, a channel on Slack, by joining 100 Days of Code, or finding out what's going on in your local town or city (there will be something tech related for sure) - go for it! It helps to accelerate your learning, build understanding and you might come away with some really great friends. I can highly recommend it.

Tech needs YOU!

I wanted to end with this point as I believe it's an important one. Diversity and inclusion is one of the biggest challenges facing the tech industry today. Sure, it's come a long way in the past few years but there is still so much further to go. Technology now rules the world. People across every corner of the earth now use or rely on technology in some way (even if they don't realise it) and we need to make sure that the businesses creating this technology have the same diversity of thought and perspectives as their users.

This is the part where I'm going to big up the School of Code. The School of Code aims to get more and different types of people into tech and they are doing a fantastic job of it! A big blocker for a many people wanting to get into technology is the cost of retraining but the School of Code bootcamp is free. Yes you heard, FREE! This means that a career change into tech is an option for so many more people. If you’d told me two years ago that as a jazz musician I was soon to become a software developer and land my first job in the tech industry I would never have believed it. (I still have to pinch myself!)

So if you live in the West Midlands (UK) and are ready for a new challenge in life, hungry to learn new skills, willing to put in LOTS of hard work and wanting to start a new career in tech, this might be the perfect opportunity for you! You can find out more about how the School of Code works and how to apply on their website.

So there we have it. A few thoughts from a recently graduated bootcamper. There's more stuff I could talk about (wotwotwot, that really important day Tommy slept in, the terrible happy birthday singing, sign off's, silent zoom clapping, "you're on mute", etc. etc.) but I'm going to leave it there.

My closing thoughts (I know you're dying to hear them...) - there is room for you in this industry. Whatever your background, age or experiences you've got something to offer to the world of technology. What are you waiting for? Tech needs you! 🙂

What really happens when you click on a link...?

Katie Lee — Thu, 31 Dec 2020 09:45:37 +0000

Have you ever thought about what happens when you click on a link in the web browser and get taken to a new web page? It's something that I'd never really considered until I started learning to program earlier this year...it just kind-of happened. The internet would work it's magic and I got taken to my desired location without another thought. On the odd occasion when things went wrong and I was served up an error message, I would spend a while baffling at what 404 really meant, try furiously refreshing the page a few times and then give up, assuming there was an angry gremlin in the system that didn't want me to buy another pair of shoes even if they were 60% off and definitely not like that other pair I already owned. But since learning to code earlier this year and becoming what you might call internet savvy, I've learnt that the process is far more complex than I ever thought. And super awesome! So prepare yourselves for an exciting journey across time, space and acronyms as I take you behind the scenes to find out what really happens when we click on a link...

The Internet & the World Wide Web

Before we dive into the details let's stand back and look at the big picture for a moment. What is the internet? Is it the same as the World Wide Web? The answer is no! Although we often use the terms interchangeably, the internet and the World Wide Web are not the same. The internet is a very big network of computers (more accurately a network of networks) transferring lots and lots of data around the globe. The World Wide Web runs on top of the internet - it is a huge distributed application running on millions of servers world wide and it is accessed using a special program called a web browser. The fundamental building block of the web is a single page - a document containing content which contains links to other pages. These links (text or images you can click on and they take you to another page) are called hyperlinks and they form a huge web of interconnected pages. Text containing hyperlinks is so powerful that it got named hypertext - the language of the web. Web pages are the most common type of hypertext document today and these pages are retrieved and rendered by web browsers which allows us to read them. In order for pages to link to each other, each hypertext page needs a unique address and this is specified by a Uniform Resource Locator (URL).

URL, IP & DNS

The URL is an address that shows where a particular page can be found on the World Wide Web. It is constructed in the following way:

The URL allows access to a specific resource on a web server and as we can see from above it's often a domain name followed by the page name. However, in order for the web page to be retrieved, the URL needs to be translated into an IP address. Web browsers interact through IP (Internet Protocol) addresses which are unique identifiers - you could think of them as a numerical label assigned to each device connected to a computer network.

A protocol is just a system of rules that define how data is exchanged within or between computers. Communications between devices require that the devices agree on the format of the data that is being exchanged. We're going to learn about lots of other protocols as we go on...

Every computer connected to a network gets an unique IP address which other machines use to find the device, just like a street address is used to find a particular house. An IP address format looks like this: AAA.BBB.CCC.DDD. It’s a sequence of numbers (all between 001 and 255) separated by full stops. The below IP address is one of Google's servers:

`172.217.7.238`

You can use the IP address instead of the URL to get content from a website (have a go typing the above IP address into the browser - you should get Google's home page) but it would be impossible to remember the IP address of every website! That's why domain names were invented. These domain names are translated into machine IP addresses with a DNS lookup. DNS stands for Domain Name System and it is a huge database where the domain name is stored with its corresponding IP address - you could think of it as the phone book of the internet.

So the first thing that happens when you click on a link is the browser issues a DNS address lookup to a DNS or naming server. It takes a domain name as input and replies back with the matching computers IP address. If the naming server doesn't have the address in its database, it will pass the address further up the naming server food chain. If no naming server can find the IP address, the failure is passed back down to your browser. At this stage you'll probably see an error message which might look something like this:

If the address is found, the IP address is sent to your browser and once the browser receives the IP address it opens a connection with the web server at the IP address you want. It then asks the web server for a specific page and it does this using HTTP.

HTTP

HTTP (HyperText Transfer Protocol) allows the fetching of resources (eg. web pages) and it is the foundation of any data exchange on the web. It is a client-server protocol which means requests are initiated by the client (the web browser) and communication between the client and the server is via requests and responses. In the most basic terms, the client sends a GET request to the other computer (the server) via a command such as GET/thepageyouwant and the server responds with the information:

This information is interpreted by the web browser and rendered to the screen. To go to another page, your computer simply sends another request and this goes on and on. The first documented version of HyperText Transfer Protocol only had one command - GET. Now there are many more types of requests used to manipulate data on the internet. Some of these include POST, PUT and DELETE - you can read more about the different types of HTTP requests here. In later versions, HTTP also added status codes which prefixed any hypertext that was sent following a request. For example, status code 200 mean everything's okay, I've got the page and here it is! Status codes in the 400's are for client errors, eg. 404 page not found which means the file or page that the browser is requesting wasn't found by the server.

To communicate over the network, internet protocol is followed. TCP/IP (Transmission Control Protocol / Internet Protocol) is the most common protocol but before we find out more about that we're going to learn how data is actually sent over the internet...

ROUTING & PACKETS

As we discovered at the start, the internet is a huge network of networks which sends data to and from different computers. Just like there are different roads you could take to drive to a destination, there are often multiple paths to get data from one location to another. Routing is the process of selecting a path for traffic in a network or between or across multiple networks. With millions of computers online all exchanging data, bottlenecks can appear and disappear in milliseconds. Network routers are constantly trying to balance the load across the network to ensure speedy and reliable delivery. This is called congestion control. Messages are passed through several stops on the way to their destination a bit like the postal service. When you post a letter from London to Edinburgh it might pass through a number of cities / sorting offices on the way, depending on traffic, road closures or transport routes, before it reaches Edinburgh. The same is true when sending data over the internet. Using different routes makes communications more reliable and fault-tolerant as if there is a blockage on one route, the message can take another route.

This message switching technique, in which messages are sent in their entirety from source to destination one hop at a time, is called message switching. And the number of hops a message takes along its route is called the hop count. Keeping track of the hop count is useful as it can help identify routing problems. The hop count is stored with the message and updated along its journey. If messages have high hop counts, most likely something has gone awry in the routing. However, the downside to message switching is that messages are sometimes big which means that they clog up the network because the whole message has to be transmitted from one stop to the next before continuing on its way. This ties up the whole route so no other messages can get through until it's done. Other messages have to wait until the big file transfer is finished or take a less efficient route which is not ideal. The solution is Packet Switching.

Instead of sending the whole message all in one go, big messages are chopped up into many smaller pieces called packets and sent individually across the network. They may take different routes but they all end up at the correct destination as each packet contains a destination address (IP address) so the network routers know which computer to forward them to.

Packets are made up of a header and a payload. Data in the header is used by networking hardware to direct the packet to its destination and the payload is the actual data being sent. Once the packet has reached its destination the payload is extracted and used by application software. Chopping up data into small packets and passing these along flexible routes with spare capacity is so efficient and fault-tolerant it's what the whole internet runs on today. Internet packets have to conform to a certain standard called IP - for example, each packet needs an address and there are limits to the size and weight of packages. However, IP is very low level protocol and there isn't much more than a destination address in the packets header. This means that a packet can show up at a computer, but the computer may not know which application to give the data to (eg. Skype or Call of Duty). For this reason, more advanced protocols were developed to sit on top of IP - UDP and TCP.

UDP

So we've seen that IP gets the packet to the right computer but it's UDP which gets it to the right program. UDP (User Datagram Protocol) has its own header which sits inside the data. Inside the UDP is some extra useful information - the port number. Each program on the computer will have a unique port so when a packet arrives to a computer, the operating system will look inside the UDP header and hand it to the right program. The UDP header also includes a checksum which allows the data to be verified for correctness. The checksum sits in the header and it is the sum of all the data in each packet which is calculated before the packet is sent. When the receiving computer gets the packet it repeats this process, adding up all the data. If that sum is the same as the checksum sent in the header then everything is good! But if the numbers don't match, the data must have got corrupted at some point in transit. UDP doesn't offer any ways to fix the data or request a new copy so typically the packets are just discarded. It also doesn't offer any mechanisms to know if packets are getting through to their destination successfully or not. If different packets from the same message take different routes through the network the packets may arrive at their destination out of order or some may not arrive at all. This is fine for applications that rely on high speeds of data transmission such as video chat or online video games - if some packets don't arrive the video goes a bit glitchy for a seconds but it's not the end of the world. But it can be a problem for other types of data transmission such as an email or web pages. If only half of your email arrives or only half a web page loads this would not be good. Luckily there are other protocols (I told you there were a lot!) which we can use to handle this...

TCP

This is where TCP (Transmission Control Protocol) comes into things. Like UDP it rides inside the data payload of IP packets. For this reason, people refer to this combination of protocols as TCP/IP. Like UDP, TCP contains the port and checksum along with some other fancier features. TCP packets are given sequential numbers so they can be put into the correct order when they arrive at the receiving computer by the TCP implementation in your operating system. TCP requires that once a computer correctly receives a packet and the data passes the checksum that it sends back an acknowledgement (ACK) to the sending computer. If enough time passes and the sending computer doesn't receive an ACK, the sending computer will presume the packet has been lost and send it again. The packet may not have got lost - it may be the ACK that got lost or it might just be taking a long time to send - but that doesn't matter. The important thing is that the packet has been sent again. If a duplicate packet arrives the receiver has the sequence number so can discard any duplicates. TCP isn't limited to a back and forth conversation - it can send many packets at once and have many outstanding ACKS which increases bandwidth significantly as you aren't wasting time waiting for ACK's to return. The success rates of ACK's and the round trip time between sending and acknowledging can be used to infer network congestion. TCP uses this information to adjust how aggressively to send packets - a mechanism for congestion control. It can throttle it's transmission rate according to available bandwidth which is pretty cool! So you may be thinking why use UDP when you've got TCP? Well all the ACK packets doubles the number of messages on the network yet your not actually transmitting any more data. That overhead is sometimes not worth the improved robustness especially for time critical applications like video chat or online gaming.

So...after our slight detour into routing and packets, let get back to our hyperlink. We've clicked on our link and it's performed a DNS lookup to find the IP address. Once the browser receives the IP address it initiates a connection with the server at that address using a process called TCP 3-Way Handshake. The client computer sends a SYN (synchronize) message to see whether second computer (the server) is open for new connection or not. If the server is open for a new connection too it sends an ACK (acknowledgement) message with a SYN message as well. After this the first computer receives its message and acknowledges it by sending an ACK message back.

Now the connection is built between the client and the server they can both communicate and share information with each other. The browser can send a HTTP GET request to the server for a specific page and the server responds by sending it back. It travels across the network in lots of little packets back to the client where TCP put all the packets back in order. The web page is then reconstructed from the different sub-documents fetched (eg. text, layout description) and the browser renders the content. If the page has images or videos, the browser will see this and request that they are bought to the web page as well, one at a time. And ta daaa...just like that your web page has loaded!

Which brings us to the end of our whistle-stop tour from our starting point - the click of a link - to our destination - page load! Who knew there was so much going on behind the scenes? Next time you click on a link you'll know that it's not just magic...it's actually a series of complex protocols and interactions which happens between a number of computers all over the world. And the most amazing thing is that it happens in a matter of milliseconds! Which actually does sound like magic when you think about it. Super cool 🙂