2. Learn Ethical Hacking From Scratch

3. Microsoft Excel - Excel from Beginner to Advanced

4. Machine Learning A-Z: Hands-On Python & R In Data Science

5. 2022 Complete Python Bootcamp From Zero to Hero in Python

Links to these courses are affiliate links and so I may receive a small commission if you purchase one

No, it's also about understanding how the web works and, to a certain extent what got us here.

There has been a real push in the last couple of years to bring back and rely on some older, core technologies of the web. We are hearing a lot of discussion of technologies that seem new but are really just a fantastic modern implementation of tried and tested approaches that have been around for a long time.

In this post we are going to explore static sites, server side rendered sites and single page applications and how they fit together in the coming years.

Browsing the web

When you type a url into your browser address bar you are saying “hey, whatever thing lives here …. I want it”

What is returned is a stream of data with some clues to tell your browser “what” it’s being sent so that it knows what to do with it.

Once that data is received your browser will show you it in the best way possible for that content type.

An HTML file will be rendered as a web page, a JSON object will be displayed as text and a directory of files will look like a file explorer.

Static Content

In the early days of the web it was just files on computers that other computers could look at. Your browser would request an HTML file in a specific directory on a remote computer, and that computer would serve that request. Hence the name server. It’s just a fancy word for “another computer that will listen to me and send me stuff”.

These files were just HTML text that your browser would render as a webpage. If the owner of the files wanted to change anything they would need to edit the relevant HTML file and save it.

Hence the name static, if the file never changed, then you would get the same content every time. This was a Static Site. There are now tools to help us generate all these files in a more manageable way and the concept is called Static Site Generation …. But I’m jumping ahead.

Server Side Rendering (SSR)

The problem with static sites is that content can’t be customised in anyway to the user and all content needs to be in a file. Well a server is just a computer, so we realised that rather than sending a request for an HTML file, we could instead send a request to program/application that creates HTML on the fly and sends it back to your browser.

As far as your browser knows, it has been sent HTML so it knows to render it as a web page BUT the server now runs a small program (written in PHP, Java or, more recently, Python or JavaScript) that creates the HTML. This app can be as simple as a templating system, where it grabs some HTML for the header, some HTML for the footer and then inserts the content the user actually want in the middle OR it can be as full featured as Facebook or Amazon.

Suddenly the web could be a whole lot more dynamic as we were rendering our HTML on the server on a per request basis and sending it back to the client AS IF they had just requested a static web page.

This was the start of the modern web, but we needed one more thing to really bring on the Web2.0 revolution.

AJAX

Probably one of the coolest acronyms in the tech industry, it stands for, Asynchronous JavaScript and XML. Forget about the XML bit for the purposes of this discussion, and focus on Asynchronous JavaScript as it was a GAME CHANGER.

We already had JavaScript and it was able to do some interesting and fun things on an HTML web page, but it’s capabilities were pretty limited.

Up to now, that HTML page we’ve been talking about that your browser receives (static or server rendered) would come with links to other files that the browser needed to fetch as well. And those links might include JavaScript files that your browser would request form the server, receive and then execute.

But what that JavaScript could do was constrained to just your browser.

Until AJAX.

This technology allowed developers to write JavaScript that could request content from the server WITHOUT having to refresh the webpage you were on.

This meant you could click a button and instead of causing a page navigation, it would instead send a request to the server for some data. When that data came back the JavaScript that sent the request could process the data and update the webpage …. without a page refresh.

Initially it was clunky and limited BUT finally web pages could function like desktop apps … The age of the web app was born.

Single Page Application (SPA)

As we built upon AJAX and worked out the kinks, we started to realise that if JavaScript could make requests to a server AND it has access to the full browser page the user is looking at …. then why don’t we get JavaScript to render webpages for us, in the browser?

And this is exactly what React, Angular and Vue do for us. When you go to a webpage for a site using one of these you are sent a single HTML file that tells the browser to get a single (usually quite large) JavaScript file.

When that JavaScript file is received the browser executes it and then it gets VERY busy.

That JavaScript file starts requesting data from the server and telling the browser to render different bits of HTML as the data streams in. When you click a button that same JavaScript captures the click event, does what it needs to do and then updates the HTML on the page as required.

In fact, when you click a link on these sites you don’t actually do a page navigation, the JavaScript usually captures this event, requests the data it needs from the server and then renders the correct HTML so it looks like a new page.

“BUT Simon!” I hear you say, “the address bar changes so I must be on a new page”

Yeh, the JavaScript rewrites that so it looks like you navigated to a new page, you didn’t really!

Bringing it home

So that’s the history of the web, where does this leave us now?

Well static sites are incredibly fast, but they have limited interaction and updating the content can be a pain. There is also no concept of “logged in” with a static site, the content is freely available to the whole internet.

Server side rendered apps solve the dynamic problem holding static sites back AND they can have the concept of user accounts and not making everything public, BUT they can be clunky to navigate around and page loads are a pain.

Single page applications solve the problem of page loads and also have the concept of user accounts and making sure content isn’t completely public BUT that initial JavaScript load can be really big, very slow and pretty bad for search engine optimisation.

What is to be done?

Enter the full stack JavaScript framework.

Full stack JavaScript frameworks aim to combine all of the benefits of the above three concepts into a single framework with great developer and user experience.

• They can combine aspects of Static Site Generation (SSG) for the parts of your site that are public and need to be FAST.
• They offer Server Side Rendering (SSR) for initial page loads that require data from a database or from another service.
• They the then drive the browser side interactions and data fetching with the Single Page Application (SPA) technology of React to make sure it feels modern and interactive like people have come to expect.

Learning path

These technologies will drive the future of the web, but first you need to learn the underlying concepts of HTML, CSS, JavaScript.

So if you’re still learning then stay the path on those.

Don’t worry if you didn’t understand all of the above, this is a very high level (which is a fancy way of saying vague 🤣) explanation aimed at raising your awareness so that when you hear these terms you understand how they fit into the bigger web development picture.

90% of being a good web developer is knowing something exists so you can deep dive on it when you need to.

Project

If you’re looking for a project where you can see many of these concepts in action and build a page up from scratch, add functionality in JavaScript and then start interacting with APIs and third part services then my link tree series is for you. We build up a social media link tree from HTML and CSS, adding JavaScript, integrating with Mailchimp, Stripe and Supabase and then wrapping up with deployment to Vercel for hosting!

Part 1 is on YouTube 😀

WeatherKit is Apple's new weather data service, announced at WWDC 2022 it is the their answer to privacy focussed weather data. Not only have they created this for use in native iOS Swift apps but they have also created a REST API so that web developers are able to access it as well.

In fact, it's where this widget is getting its weather data from - if you reload the page it might change depending on how turbulent London's weather is right now.

The WeatherKit REST API Documentation is fairly limited on how to get this set up so here is a guide to get up you up and running with Apple's WeatherKit. In fact, I had a labs call with two Apple engineers to get this working which was pretty cool. We will build a simple ExpressJS server and a index.html page to display weather for a set location.

UPDATE: Apple have since updated their documentation on this topic including adding a page on the JWT creation that was such a pain before.

WeatherKit REST API setup

The REST API requires a signed JWT to be attached to each request. To set this up you need:

• A paid developer account
• An App Identifier
• A key

You can set up an App Identifier on the Identifiers page of your developer account. You need to create a new App ID of type App, give it a Bundle ID in reverse-domain name style, so com.myapp.weather or similar, and then make sure you select WeatherKit from the App Services tab. This App Identifier can take about 30 minutes to propagate through Apple's systems.

For the key you go to the Keys page in your developer account and add a new key with WeatherKit selected. Remember to download the key file you get at the end!

WeatherKit REST API JWT

Now you have your key and App Identifier we can create a server to sign that key. You will be signing the JWT yourself so you will need a backend/server where you can execute your code, as always do not expose your key to the browser or client

So, let's create a little ExpressJS server. Comments in the code explain what is going on. I'm assuming you know how to use ExpressJS already.

const express = require("express");
const axios = require("axios");
const fs = require("fs");
const jwt = require("jsonwebtoken");
var cors = require("cors");

const app = express();
const port = 3000;

app.use(cors());

app.get("/", async (req, res) => {
  // This is the key file you downloaded from Apple
  var privateKey = fs.readFileSync("YOUR KEY FILE FROM DEVELOPER CENTER.p8");

  // Creating the signed token needs specific data
  var token = jwt.sign(
    {
      sub: "APP ID", // the reverse URL App Id you made above
    },
    privateKey,
    {
      issuer: "TEAM ID", // find your TeamID in your developer account
      expiresIn: "1h", // give it 1 hour of validity
      keyid: "KEY ID", // this is the ID for the key you created
      algorithm: "ES256", // this is the algorithm Apple used
      header: {
        // see details below for this
        id: "YOUR TEAM ID.YOUR APP ID",
      },
    }
  );

  // log your token so you can decode it and manually check it's ok, more below on this
  //console.log(token);

  const url =
    "https://weatherkit.apple.com/api/v1/weather/en/51.677612/-2.937941?dataSets=currentWeather&timezone=Europe/London";

  // add the token to your headers
  const config = {
    headers: { Authorization: `Bearer ${token}` },
  };

  // get the data
  const { data: weatherData } = await axios.get(url, config);

  // prove we have data
  //console.log(weatherData);

  // return the data to your front end
  res.json(weatherData);
});

app.listen(port, () => {
  console.log(`Example app listening on port ${port}`);
});

Your decoded JWT needs to look like this:

{
  "header": {
    "alg": "ES256",
    "typ": "JWT",
    "kid": "KEY_ID",
    "id": "TEAM_ID.APP_ID" // this is the bit that has been tricking people up
  },
  "payload": {
    "subj": "APP_ID",
    "iat": 1654823790,
    "exp": 1654827390,
    "iss": "TEAM_ID",
  },
  "signature": "D108jNki1tXX3mSYOAPp-Wpds8kEbGJ-lhKPtasdfSqoDyiJ2WbeI6U73UWCYWQgISlDOzaXdI5rSrSFcrg5g"
}

To get id in the header I needed to set it manually when creating the JWT, Apple is looking for id in the header and depending on your JWT signing library of choice that may not (probably won't) be there by default.

 header: {
    id: "YOUR TEAM ID.YOUR APP ID", // see details below for this
},

WeatherKit REST API Front end

To call the serve end point you can use the code below in an index.html to make a simple front end that starts with default data and then adds in the data from weather kit.

I've included Axios with a CDN link on line 5 and then line 11 pulls in TailwindCSS via a CDN as well for quick and easy styling and explains why the HTML tags have so many classes on them.

<!DOCTYPE html>
<html lang="en">
  <head>
    <meta charset="UTF-8" />
    <script
      src="https://cdnjs.cloudflare.com/ajax/libs/axios/1.0.0-alpha.1/axios.min.js"
      integrity="sha512-xIPqqrfvUAc/Cspuj7Bq0UtHNo/5qkdyngx6Vwt+tmbvTLDszzXM0G6c91LXmGrRx8KEPulT+AfOOez+TeVylg=="
      crossorigin="anonymous"
      referrerpolicy="no-referrer"
    ></script>
    <script src="https://cdn.tailwindcss.com"></script>
    <meta http-equiv="X-UA-Compatible" content="IE=edge" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <title>Weather Kit Example</title>
  </head>
  <body>
    <div class="container max-w-3xl mx-auto p-8">
      <h1 class="text-3xl text-center font-bold text-gray-700">All The Code</h1>
      <div
        class="shadow-lg shadow-black/40 w-[400px] p-4 mx-auto mt-10 rounded flex flex-col gap-y-6"
      >
        <h2 class="text-xl font-bold text-center">Current Weather</h2>
        <div class="text-7xl font-black text-center">
          <span id="temperature">0</span> <span class="font-thin">&#8451;</span>
        </div>
        <div class="flex flex-row justify-between">
          <div class="flex flex-col text-center w-1/3">
            <div id="wind" class="text-3xl font-bold">17.5</div>
            <div class="text-3xl">Wind</div>
          </div>
          <div class="flex flex-col text-center w-1/3">
            <div id="uv" class="text-3xl font-bold">0</div>
            <div class="text-3xl">UV</div>
          </div>
          <div class="flex flex-col text-center w-1/3">
            <div class="text-3xl font-bold"><span id="cloud">81</span>%</div>
            <div class="text-3xl">Cloud</div>
          </div>
        </div>
      </div>
      <div class="text-center mt-10">
        Weather data provided by
        <a href="https://weather-data.apple.com/legal-attribution.html"
          >Apple WeatherKit</a
        >
      </div>
    </div>
  </body>

  <script>
    // add the below script in here
  </script>
</html>

The JavaScript to get the data

axios
  .get("http://localhost:3000", {
    headers: { "Access-Control-Allow-Origin": "*" },
  })
  .then((res) => {
    let temp = document.getElementById("temperature");

    temp.innerHTML = res.data.currentWeather.temperature;

    if (parseFloat(res.data.currentWeather.temperature) < 15) {
      temp.classList.add("text-blue-500");
    } else {
      temp.classList.add("text-red-500");
    }

    document.getElementById("wind").innerHTML =
      res.data.currentWeather.windSpeed;
    document.getElementById("uv").innerHTML = res.data.currentWeather.uvIndex;
    document.getElementById("cloud").innerHTML =
      res.data.currentWeather.cloudCover * 100;
  });

When this page loads it will request weather data from Apple via your server with a sign JWT 😊

As a web developer your terminal is a core part of you toolkit. I recently had to reformat my Mac and that meant I had to setup my terminal again from scratch. I could have pieced it together from a back up but I thought it would be a good opportunity to start over and see what's changed in the years since I last did this.

This is what I got to, looks pretty nice right?

Let's look at that line, it tells me:

• All-The-Code-Website is the current working directory
• on main tells me I'm on the main git branch
• [$!+] tells me some git statuses, I have $ stashed changes (that's never good!), ! unstaged changes and + uncommitted changes
• on version 0.1.0 of the site
• running node version 16.15.0

Handy right? Let's look at how I made this and at some key terms along the way.

Terminal App

I use two terminal apps:

1. iTerm2 - one of the most powerful and extendible terminal apps for the Mac
2. The one built into VSCode

A terminal is the name given to an application that runs a shell - we will cover the shell next. There is one that comes with MacOS but it's not great

So, go download iTerm2.

Command Shell: ZSH

The default command shell on MacOS is now ZSH. It used to be Bash but this changed with the release of MacOS Catalina. Both are different types of the same thing, a shell.

A shell is the interface you are using to interact with you computer within your terminal app. You type commands into the terminal and the shell executes the commands and displays the results to your terminal app.

Oh My Zsh

Oh My ZSH is a great tool that makes your ZSH shell much, much more powerful 🚀 and who wouldn't want that? There are hundreds of plugins available for Oh My Zsh that make you a better developer.

Let's get Oh My Zsh installed, open up iTerm2 and enter the following:

sh -c "$(curl -fsSL https://raw.githubusercontent.com/ohmyzsh/ohmyzsh/master/tools/install.sh)"

After a few seconds it will be installed ... welcome to having more power!

.zshrc

You should now have a new file in your home directory .zshrc. Find out by typing this in to your terminal:

cd ~
ls -a

Line 1 takes you to your home directory, line 2 lists (ls) the contents of that directory and the -a flag makes sure you see all files, even hidden ones (which is what the . at the start of .zshrc does)

If you quit and restart your terminal app you should notice things look a littler different already.

Plugins

Let's add some plugins to Oh My Zsh to step things up.

Find this line in your .zshrc:

plugins=(git)

and change it to this:

plugins=(git copypath dirhistory macos sudo common-aliases gitignore history)

As follows:

• git: handy git details right in your command prompt
• copypath: simply type copypath and the current working directory is not in your clipboard
• dirhistory: use alt + up and alt + down to navigate your directory structure
• macos: handy Mac specific utilities
• sudo: run a command that needs sudo at the start and you didn't add it, hit esc twice and now you do, along with the command you tried to run
• common-alias: does what it says on the tin
• gitignore: no more searching online for .gitignore templates, type gi list to see all that are available
• history: type h to see your command history

Go check out the docs on all these. You can find them in the Oh My Zsh plugins wiki.

You need to tell ZSH to reread the .zshrc file, to do that type this into your terminal:

source ~/.zshrc

Themes

The standard Oh My Zsh theme is ok but my favorite is one we need to install separately - SpaceShip 🚀 check out the SpaceShip theme GitHub repo and then come back and we'll install it!

We need to install PowerLine fonts first. Enter the following in to your terminal:

git clone https://github.com/powerline/fonts.git --depth=1
cd fonts
./install.sh
cd ..
rm -rf fonts

Great, now we can install SpaceShip! Enter the following into your terminal to clone the repo and save it to the ZSH themes directory in one go:

git clone https://github.com/spaceship-prompt/spaceship-prompt.git "$ZSH_CUSTOM/themes/spaceship-prompt" --depth=1

Then symlink it to your Oh My Zsh themes directory with this command:

ln -s "$ZSH_CUSTOM/themes/spaceship-prompt/spaceship.zsh-theme" "$ZSH_CUSTOM/themes/spaceship.zsh-theme"

Now set the theme in your .zshrc file ZSH_THEME="spaceship"

Finally to get the font set up correctly jump back to iTerm2, open preferences go to Profiles and then Text and choose the font you want. It needs to be one of the Powerline fonts for everything to look right.

VSCode

To get fonts working in VSCode you will need to open up the settings file in JSON mode: CMD + Shift + P and select the JSON settings options. Then add these lines to the end of the settings file before the closing }.

"terminal.integrated.defaultProfile.osx": "zsh",
"terminal.external.osxExec": "iTerm2.app",
"terminal.integrated.fontFamily": "Fira Mono for Powerline",
"terminal.integrated.fontSize": 12,
"terminal.integrated.env.osx": {
    "LC_ALL": "C.UTF-8"
}

That last list is to make sure emoji render properly in VSCode, it's still hit and miss but it helps.

Again run source ~/.zshrc and checkout your beautiful new terminal 🚀🥳

Wrap up

So there you go, you've gone from a boring looking terminal to a modern, colorful one and learned some Linux commands along the way! This obviously isn't the most important thing in the world, however your terminal is a key tool in your developer toolbox and having it as good as possible is nice.

No matter where you are in your web development journey, there is a strong chance you have heard of Docker. Docker has grown from humble beginnings, as an internal tool for a web hosting company, to becoming a core tenant of modern web development. But, what is Docker?

In this post I will explain exactly what Docker is with a fun analogy. Then we will run through a small example to show you its power and why it's worth your time to know. From keeping a consistent developer experience to making deployments easier there are a number of benefits to using it.

Now, let's dive in.

Contents

1. Docker explanation and analogies
2. Example of NodeJS server in Docker container

Docker Explained

Put simply, Docker is a way for you to make sure your web application has all the things it needs to be able to run, no matter what computer you put it on. Docker means consistency.

If the computer in question has the Docker runtime installed, then it can run your app.

In fact, this idea has it's own name:

Containerisation

Docker is just the most popular flavour of containerisation.

So what is containerisation?

When you write software, you rely on lots of other code. Even if you write everything yourself and pull in no libraries or frameworks, you are still relying on the operating system having everything you need to run your application.

This is true of all software. Be it an iPhone app or a server application running in the cloud. This is why you see descriptions in App Stores say they need at least iOS 15, or Windows 11.2. The code inside the application will be dependent on the operating system having certain capabilities that aren't available on early versions.

When you are developing your own apps this sort of thing can become quite the pain in the ass, because not only is your software dependent on things in the operating system but also other things that you add into the mix, like environment variables and specific settings.

All these requirements can make it difficult to know exactly what setup is required to make an application run somewhere new. And unless you are making a little tool for yourself, your code will eventually need to run somewhere else!

Containerisation makes all of these problems go away

Let's look at an analogy for containerisation

In my garage I am fortunate enough to have a pretty good home gym. Squat rack, barbells, pull up bar, dumbbells, all sorts of things. No matter the gym session I want to do I can go in there and have a great workout.

In no single session do I use all the equipment I have, in fact some things will go weeks between uses, they aren't required for every session but eventually everything gets used.

In this example you can think of my garage as my own computer. Everything I need, no matter what I'm doing, customised in any number of ways that I can't remember.

Now, let's say I want to go and do a specific workout somewhere else. I'm going away with family and I want to be able to have a good workout everyday.

I don't need every item in my gym to have a good workout, I just need certain items to take with me. So, I grab some kind of container, like a big box, and put inside it all the items I will need. Let's grab

• two sets of dumbbells (heavy and light)
• two resistance bands
• a single weight plate
• a skipping rope.

Not much, but plenty for a good, specific workout, in fact I'm going to put a print out of a workout in the container as well. Also let's write on the outside of the container where to start:

Start workout with the first exercise in the instructions

Now, so long as I have that container with me I can always do the workout in the box.

In fact, since all of the dependencies are in the container, anyone who knows how to open the box and read the instructions could do it, anywhere in the world, and they would have the same great workout as me.

Well, that's exactly what Docker is.

In this analogy:

• The box is the Docker container
• The workout items are the dependencies your code needs
• The workout instruction are your code
• The command on the outside of the box is the start command for your application
• And the "any person who can read" is the equivalent to a computer with the docker runtime installed on it

Docker NodeJS Example

Firstly we need a simple application to run. Let's whip up a small NodeJS server really quickly. Create a new directory anywhere on your machine.

mkdir dockerExample

Go into that directory and run.

cd dockerExample
npm init

Hit enter to set all the defaults.

We are going to make a simple server so we'll use Express. Run:

npm i express

Now create an index.js file in your project

And add the following code:

const express = require("express");
const app = express();
const port = 3001;

(async () => {
  app.get("/", async (req, res) => {
    res.send("Hello from Docker");
  });

  app.listen(port, () => {
    console.log(`Listening on port ${port}`);
  });
})();

You can now run this small server from your terminal with:

node index.js

You will get a message in your terminal like the below:

Listening on port 3001

and if you go to http://localhost:3001 in a web browser you will see the following message:

Hello from Docker

Which is a bit of a lie because right now this is not yet in Docker.

Adding Docker

First thing we need to do is install Docker to your machine. Go to the Docker website and select the correct choice for your operating systemm

Once downloaded and you've launched the Docker app we can get going.

Docker file vs image vs container

Now you have Docker running you can run Docker containers. Like I said above, these are little containers that run your code in a portable, isolated way.

But before you get to a container there are two other things you need to know about, a docker file and a docker image.

• A Docker file is what you write that lays out what you want your Docker container to be.
• A Docker image is all the code bundled up ready to run whenever you need it. This is like any other application on your computer, Docker will grab this and turn it in to a running container when you want it.

Let's start with the file.

Docker file

Add a file to your project, in the same directory as index.js called Dockerfile (no extension, just Dockerfile) and add the following contents:

FROM node:16.15.0

WORKDIR /var/www/

COPY . .

RUN npm install
RUN chown -R node:node .

USER node

CMD [ "node", "index.js" ]

Don't panic! I'm going to explain all this line by line.

• Line 1: here we are saying we want to use another image and then add to it. Docker has a big registry of other images that you can use as the basis to your image and then add to it. In this case we say that we want a specific version of the node image. What you will get is a Linux machine with Node version 16.15.0 installed on it.
• Line 2: remember that this is a little virtual computer we are running here so it has a file structure just like your computer. Here we are setting the directory we want to work in as /var/www.
• Line 5: when your container is running it won't know anything about your computer, it's totally isolated. However when turning you Dockerfile into an image it knows about your computer. In this case COPY is a Docker command that can copy files from your computer into the image. Here we say COPY the contents of the current directory of my computer in to the current working directory of the image. So if you are in dockerExample when you run this is will copy everything in that directory into /var/www in the Docker image. This is how your code gets into the container.
• Line 7: The RUN command allows you to execute a command in the build process of the image, in this case we want to install any dependencies that our code has, just like we would locally to download Express.
• Line 8: for improved security we will be changing from the root super user (which is what you are within that Docker image at the moment) to the node user, which has far few privileges. So we use the Linux command chown to give the node user privileges to run code in this directory.
• Line 10: we use the USER command to switch to that node user.
• Line 12: finally we specify the command that will be run when the container is launched. In this case we run the the command we were running on our local machine in the last section. This means that when the container comes to life it will launch our code automatically.

With that saved to your Dockerfile you can now build the image.

In your terminal (making sure you are in the directory with the Dockerfile in it) run:

docker build . -t example

This tells Docker to build an image based on the Dockerfile in the current directory (that's what the . is for at the end). the -t example will be helpful in a minute, it tags the image with the word example.

You should see an output like this:

[+] Building 2.0s (10/10) FINISHED
 => [internal] load build definition from Dockerfile                                                                                                                      0.0s
 => => transferring dockerfile: 37B                                                                                                                                       0.0s
 => [internal] load .dockerignore                                                                                                                                         0.0s
 => => transferring context: 2B                                                                                                                                           0.0s
 => [internal] load metadata for docker.io/library/node:16.15.0                                                                                                           1.8s
 => [1/5] FROM docker.io/library/node:16.15.0@sha256:1817bb941c9a30fe2a6d75ff8675a8f6def408efe3d3ff43dbb006e2b534fa14                                                     0.0s
 => [internal] load build context                                                                                                                                         0.1s
 => => transferring context: 27.64kB                                                                                                                                      0.0s
 => CACHED [2/5] WORKDIR /var/www/                                                                                                                                        0.0s
 => CACHED [3/5] COPY . .                                                                                                                                                 0.0s
 => CACHED [4/5] RUN npm install                                                                                                                                          0.0s
 => CACHED [5/5] RUN chown -R node:node .                                                                                                                                 0.0s
 => exporting to image                                                                                                                                                    0.0s
 => => exporting layers                                                                                                                                                   0.0s
 => => writing image sha256:e263406aa4b0dee204b2043acclkjb7a890edf46f29dfe9b41af8bf2a0ebf8                                                                                0.0s
 => => naming to docker.io/library/example                                                                                                                                0.0s

Which means it worked! 🥳

So now you have and image that Docker can run.

Docker image

Go to your terminal and type:

docker image list

and you will see something list this:

REPOSITORY   TAG       IMAGE ID       CREATED          SIZE
example      latest    e263406aa4b0   15 minutes ago   913MB

Look at the size! 913MB for a little server that replies with a string? Remember though that this is a version of Linux that has Node installed on it that als have your code. There are ways of reducing this size but for this introduction to Docker this is fine for now.

Notice also the example at the start as well, that's what we named it with the -t above.

Docker container

We have an image now but this isn't running. We need to "spin up" this into a container. So lets do it.

Remember above where I said that the container has no idea about your machine? Well that's true, but like any computer you can open up network connections to it, and that's what we are going to do here. Spin up this container we are going to tell it to open up a network port so we can send it messages from our browser.

In your terminal run this command:

docker container run -p 3001:3001 example

Here we are telling docker to run a container with a link from our computers port 3001 to the containers port 3001. The final argument is the container name.

docker: Error response from daemon: Ports are not available: exposing port TCP 0.0.0.0:3001 -> 0.0.0.0:0: listen tcp 0.0.0.0:3001: bind: address already in use.

All being well you should see:

Listening on port 3001

in your terminal. To test it visit http://localhost:3001 in your web browser to see the output again. This time the hello really is from Docker 😊

View running Docker containers

To see this container running open a new terminal window and type:

docker container list

and you will get this:

CONTAINER ID   IMAGE     COMMAND                  CREATED         STATUS         PORTS                    NAMES
672d7e57f9ab   example   "docker-entrypoint.s…"   4 minutes ago   Up 4 minutes   0.0.0.0:3001->3001/tcp   epic_spence

and you can see you example image used for this container.

Want proof that this is really doing something? Copy the CONTAINER_ID from the output above and run this command in a terminal window:

docker stop 672d7e57f9ab

replacing the id I have above with whatever yours is. This will take a few seconds. Once done you can run docker container list again to see no containers running. Try that web address and it won't work either.

To show you that it really is Docker running your code run this command:

docker container run -p 3002:3001 example

This will link you computers port 3002 to the Docker post 3001 (the one that your app is listening on).

The result message will still be Listening on port 3001 because that message is from the Docker container now running.

Now go to http://localhost:3001 in your browser. You won't get anything. Now go to http://localhost:3002 and you will see your "Hello from Docker" message.

How to delete a Docker image

Follow the steps above to stop the container, and then run:

docker image rm example

to delete it and get back that 913MB of space.

docker image rm example -f

What is Docker wrap up

This was a very simple overview of Docker. It is incredibly powerful and while this example might seem a bit pointless I want you to imagine a more complicated application, with many dependencies, multiple build steps all wrapped up in a single image that you can put on any server or computer, run docker container run imageName and now it's up and running doing it's thing.

Really powerful and is the gateway to the world of DevOps and making deployments easier.

All the source code for this project can be found in the AllTheCode GitHub repo.

In my view you can learn web development in 6 months.

Of course it depends on your starting point and existing time commitments. But, with commitment and finding time each day it can be done, even for a complete beginner.

I learned to code 15 years ago. Back then the world of web dev much younger and less overwhelming to newbies. Sure, there was no Stack Overflow but there also weren’t a million frameworks and languages vying for my attention either so I was able to focus on a few core areas.

Unfortunately many people have tried to get into web development and failed. So, let's layout a clear and concise path to becoming a web developer in the next 6 months.

No fuss, no muss, just pure actionable steps.

Right now web development is confusing, noisy and difficult to comprehend

People struggle to get into web development through no fault of their own. Here are the primary culprits that stop people becoming a web developer:

• It's fast paced and ever changing so it’s hard to know what to learn.
• It's an established industry with very few set best practices - because it’s so fast paced.
• There's a lot of bad and outdated advice floating around the internet. With plenty of abandoned tutorials guides that just stop as you’re about to get to the good bit.
• People think they need to be a geek or "good with computers" and it puts them off.

I'm going to explain how you can overcome all this and become a web developer.

Here's how, step by step:

Step 1: Pick the learning path that fits you best

This is the most important part. People who commit to a path that suits their lifestyle and existing commitments are 10x more likely to see it though than those who over commit.

Your three main options are:

• Free YouTube courses like those from Brad Traversy, Ania Kubów, or even my own 30 Days Of JavaScript course.

• A paid platform like Zero To Mastery's Web Developer Career Path Course or CodeCademy which have opinionated learning paths and a clear goal for you.

• A paid full time bootcamp like Flatiron School or Makers.tech

My personal suggestion is the second one, a paid platform. The courses are excellent and focussed on taking you through a very practical path without you having to dedicate 3-6 months full time to it like a bootcamp.

Once you have chosen your path don’t try to do too much. If you only have 15 minutes a day then just do that. Don’t start at 3 hours a day and burn out after 4 days. 

Slow and steady really does with the race here.

Step 2: Build your own projects from day one

Many people get stuck in tutorial hell. This is a phase where they feel like they can code but really they can only follow along with a tutorial. They are only able to take very minor detours from the happy path described by it.

If you can't make a project on your own then, you'll never make it as a developer. You need to get used to starting new projects regularly and feeling you way through it, like a real web developer does.

Step 3: Talk about what you're learning on LinkedIn

You're learning to code to have a better life, most likely to get a good job with that sweet sweet developer money 😉

Getting a job is a lot easier with a network. So start building that network when you start learning.

Share a post on LinkedIn about what you learnt in your first week, what you found hard and what you are looking forward to in the next week.

Here's an example:

Spent most of this week learning about responsive layouts with CSS. I looks like you can use flex and grid to force certain responsive behaviors - I never realized this about modern websites, I thought they loaded a different site for different screens. Next week I'll be looking at how we can show different types of navigation depending on the screen size. Anything I should be on the look out for?

Doing this every week, just a couple of hundred words, will attract comments of support and encouragement, often from senior developers who, when you are ready, will be able to help you get that first job.

Reply to every comment, ask questions and be consistent.

Wrap up

How long it takes to learn web development still depends on how much time you have to commit to it but, with a little bit of work everyday, you can lean web development in 6 to 12 months with the steps above. No step is more important than the other BUT each one builds upon the former, so follow the process, trust the process and get ready for a new career as a web developer!

1. The Odin Project

A long standing free and open source project that goes deep into the web development world.

2. Free Code Camp

Completely free and full of thousands of hours of courses and tutorials.

3. 100 Days Of Swift

Paul Hudson is a legend in the Swift world so if you've ever wanted to get into native iOS development then this is the course to get you started.

4. Harvards CS50

This is the course I took when I first learnt to code and it's amazing. Kept up to date each year this course takes you through the full software developer learning process from the ground up.

5. CodeCademy

One of the most established online learn to code platforms, this is a great place to start your journey and a proven path for hundreds of thousands of developers.

Wrap Up

There you have it, if you want a free place to learn to code then any of these 5 would be a great option. Of course if you are looking to learn JavaScript for free then check out my own 30 Days Of JavaScript course right here at all the code 😃

You're wondering, though …

Do I have what it takes to be a developer? 🤔

Learning to code is 100% possible for anyone to do. Millions of developers who don't a have a CS degree prove this. But you also need the right mindset to succeed long term. Here are the top 5 personality traits you need to work on to become a great software engineer.

1. Software Engineer Personality Trait: Curiosity

Curiosity is vital. Not just of technical topics but of the context your code runs in, the people it impacts and how it changes their world

Have a think about how curious are you. Could you be more curious about the work you do and the world around you?

It's pretty important for software developers, because for your whole carer you will be learning new things, solving other people's problems and investigating surprising and infuriating bugs.

Developing your curiosity is going to make the whole process, and your whole career, a lot more fun. Aim to be the most curious person in the room and the universe will pay you back in spades.

Read to the end to find out how I stay curious and learn about areas unrelated to software engineering.

2. Software Engineer Personality Trait: Persistence

Learning to code is hard. Persistence is the only thing that will get you through.

Debugging code is hard. 5 days into a bug hunt that feels like it’s going nowhere, you're going to need to be persistent to get it solved.

Much of your career you will be working on problems that you don’t know the solution to. You will know that you can solve it eventually but when things get hard you don't want to have to rely on motivation. Motivation is a fickle beast, instead persistence is the thing that will carry you.

If you couple this with curiosity, then rather than getting frustrated and annoyed you will simply see each obstacle as an opportunity to sate that curiosity and learn something new.

Are you persistent?

If you’re concerned you aren’t persistent enough to make it as a developer then I want you to take a look back at previous successes you’ve had. Look at the line of where you started to where you are now, see how much you have improved in some area. That improvement doesn’t happen by chance, it takes persistence to make a change and improve.

Improving your persistence

If you want to improve your persistence then take a leaf out of the weird and wonderful world of bodybuilding and weightlifting - two areas I am passionate about. Each session a weightlifter goes to the gym and works slightly harder than last session. They put a tiny amount more weight on the bar. Or they do a couple more repetitions of an exercise. Or even just do their reps a little slower. By doing this they incrementally improve every day and work toward their goals.

This process is called progressive overload and it takes patience and persistence.

You can apply it in your coding. Each day try to stick at a problem just little longer. Make a piece of UI slightly nicer or simply take some more time than usual to actively pursue making something better.

Doing this will improve your persistence and give you a positive feedback loop to keep going and keep growing as a software engineer.

3. Software Engineer Personality Trait: Ability To Learn

The ability to learn is vital for software engineers because once you've learnt to code that's not the end of it. You'll be learning new things for the rest of your career.

That's a good thing though! It means your career will evolve and change without you even needing to try.

Most industries would love for that to be the case.

You'll need to learn new skills every 2 to 5 years and there will be way more things to learn than you can ever learn. This means you get to choose where to take direct your studies.

If you get bored of making mobile apps you can jump into game development.

Bored of games? Get a job at a huge tech company and help solve the biggest scalability problems in the world.

Fed up of working for "the man"? Go freelance and pick and choose your projects.

Needing to keep up in software isn't a bug, it's a feature.

4. Software Engineer Personality Trait: Focus

Being able to block out distractions and hold complex models in your head is one of the key requirements of software engineering. One of the things you hear a lot about is the damage of context switching and how it causes productivity losses. The reason it’s so damaging to a software engineers productivity is that it takes time to build that mental model of your code work. If you get into a place where that model is stable in your head and you’re writing great code, then loosing focus is the last thing you want.

My ADHD tendencies mean that I’m very good at focussing for short bursts when I really care about a problem or topic. However if longer, sustained focus is needed then I need to start diving into my toolbox of tricks to keep me on task. Here's what works for me:

• Walking on a desk treadmill occupies part of my brain for about 90 minutes of pure focus
• Listening to music I know well can keep me in the zone
• Moving to a new, ideally more comfortable location
• Making the room darker
• Leaving focus work to the end of the day when I’m just a little bit tired

This are what work for me. For you it could be a very different. Maybe you like silence or lots of sunlight. Take the time to find out.

5. Software Engineer Personality Traits: Pragmatism

Every software engineer needs to learn where they fall on the pragmatist vs perfectionist spectrum. Are you a "just solve the problem" type? Or do you want to craft an artisanal solution to every problem factoring in all eventualities?

I lean heavily towards pragmatic solutions. I'd rather ship something that will need to be rewritten in 12 months time that make something perfect that never gets used to its full capabilities. My belief is that we can’t make a perfect system because software is a living thing, it changes and evolves as we learn the problem space. Therefore I don’t aim for perfect, I aim for “good and improvable”.

Others hate the idea of shipping something that can't deal with all eventualities and might need rewriting in the future because something got missed.

We are ultimately paid to solve problems and ship software, so if you lean to the perfectionist end of the spectrum then make sure it's not to the detriment of that goal.

Software Engineer Personality Traits Wrap Up

Don’t worry if you feel like you have a long way to go on really refining these 5 traits. Most software developers do! Those who say they don’t are almost certainly fooling themselves. Take time to focus on improving where you can and remember, software engineering is a journey. We spend our whole careers looking for ways to solve problems and improve systems. Applying the same process to ourselves is perfectly natural.

Computer science degrees can be earned in a variety of different time lengths, depending on your needs and interests. The shortest would be 12 months and the longest 5 years.

What is computer science?

Computer science is the study of computer systems and their applications. It covers a broad range of topics, including software development, programming, computer security, and network administration. If you enjoy thinking about complex problems and how to create elegant solutions to them then you will feel right at home in this area.

Why should you get a computer science degree

Computer science is an excellent choice for those interested in a career in the computer industry. Graduates will find themselves in high demand by employers all over the world. Technology is a rapidly growing field, with new applications and technologies being developed all the time. You will have the skills to make fun apps like Instagram and Tinder whilst also be able to work on large an complex business problems for the worlds largest and most impactful companies. The choice on where to go really is yours!

How long does it take to get a computer science degree?

In order to get a computer science degree, you'll need to have a strong foundation in math and science. Most degrees will require you to carry out coursework in programming languages such as Java, C++ and even primarily web technologies like JavaScript and Python. Given this they can take a long time to complete, typically four years, though some programs can be completed in as little as two years or even one if it's a masters following on from a technical undergraduate degree.

Degree programs typically include a mix of coursework in theory and practice. In the first few years, you'll take courses that cover the basics of computer programming, software development, and computer systems. In the later years, you'll have the opportunity to specialize in a particular area of computer science, such as computer security or network administration.

Tips on how to choose the right computer science degree program

1. Consider your interests: When choosing a computer science degree program, it's important to consider your interests and what you want to get out of the program. Do you want to focus on software development, or are you interested in computer and network security? Or perhaps is the hardware aspect that really interests you so an electronics component would be crucial. Make sure the program you choose offers courses that align with your interests.

2. Consider your career goals: What do you want to do after you graduate? If you're not sure, that's okay! Many graduates find careers in fields outside of computer science. But if you have a specific career in mind, such as iOS app developer or cyber security analyst, make sure the program you choose will help you achieve your goals.

3. Consider the time commitment: Computer science degrees typically take four years to complete, and can cost a large amount of money. Make sure you are able to financially support yourself for that length of time.

4. Do your research: When choosing a computer science degree program, it's important to do your research and choose a program that's right for you, speak to the schools that interest you and ask lots of questions. Find course alumni on LinkedIn and ask if they would recommend the course and school.

Computer science degree alternatives

If you're not sure a degree is right for you, or if you don't have the time to commit to a full four-year degree, there are a number of alternatives available.

Shorter degree programmes

One option is to get a computer science degree in a shorter time frame. Many schools offer accelerated programs that can be completed in as little as two years. Another option is to get a complete on online. Online degrees offer the same coursework as traditional on site degrees, but with the flexibility of being able to study from anywhere in the world.

Coding Bootcamps

Coding bootcamps are a great alternative to computer science degrees for students who want to learn how to code and become software developers. Bootcamps offer an immersive, accelerated learning experience that can teach you everything you need to know in just a few months. Coding bootcamps are also a great option if you're not sure if is is the right field for you. Many bootcamps offer job placement assistance and can help you transition a successful career as well.

Self taught

There are a number of different ways to learn computer science without getting a degree. One option is to teach yourself using YouTube videos, online courses such as CS50.net, or course platforms like Zero To Mastery or Udemy. These resources can be a great way to learn the basics of the subject and software development.

Conclusion

A computer science degree can be earned in as little as 12 months, or up to five years depending on the program you choose. There are also a number of alternatives available if you're not sure if computer science is right for you, or if you don't have the time to commit to a full four-year degree. Whichever route you choose, make sure you do your research to find the best option for your needs!

Wrong, now is the time to start getting your name out there, especially if you're struggling to stand out form the crowd of all the other computer science graduates! Not to mention those pesky self taught and coding bootcamp people.

Here is a list of all the steps you can take to rapidly get your first software developer job now that you've graduated.

1. Get a LinkedIn account and make sure your profile is up to date, include any side projects you've worked on as well as any experience you have in the industry, even if it's just customer facing roles.
2. Start writing short articles about your experiences as a computer science graduate, what obstacles you faced and how you overcame them. This will show that you are able to communicate your thoughts and experiences clearly as well as giving you a platform to share your work with potential employers. Share these on LinkedIn and reply to the comments you get.
3. Start attending meetups, there are software developer meetups for almost every city and they're a great way to network with like minded people who can give you advice and help you on your job hunt. There are also lots of online communities you can join from Facebook and LinkedIn groups to Discords and Slacks.
4. Show you can build, computer science graduates have the great technical foundations to be software developers but you need to show that you can build real world projects that work. This means showing you can solve problems with code that is maintainable and scalable. The best way to do this is with side projects that can be found and used online.
5. Get a GitHub account and populate it with some side projects, this will show employers that you are passionate about code and are constantly learning new things. Ideally you want to have an introduction page on your GitHub that highlights what technical skills you have and the type of work you like doing.
6. Start speaking to recruiters! Recruiters can be a great way to learn about new opportunities as well as giving you insights into the job market. They can also be a great help in getting your resume in front of the right people, and sometimes they have access to jobs that aren't advertised publicly. However, it's important to remember that not all recruiters are created equal. Some are better than others, and they are rarely technical so make sure they understand what you are capable of.
7. Put together an amazing portfolio that showcases your skills and experiences. This is one of the most important things you can do to get a job as a software developer. You need to show not only that you can make something but also why you choose the technologies and approaches you took. A short summary of each project and what you did will really help give people and idea of what you can do. Make sure each project is hosted online and can be used.
8. Read all of this site! We have loads of content on how to get your first job from dozens of free blog articles to an 80 page book on the topic!

There you have it, follow these steps and you'll be on your way to getting your first software developer job in no time! Good luck!

P.S. Check out our blog post on Skills required to be a full stack developer: a checklist if you want to get into the thriving world of web development.

P.P.S. If you're looking for a great software developer job, be sure to check out our job board

Now that you have finished your coding bootcamp it's time to start looking for a job.

If you went to a good bootcamp they should have dedicated some time to this part. Knowing how to code and knowing how to get a coding job are sadly slightly different skills. So ideally they will have taught you how to look for a developer job at companies that are open to hiring coding bootcamp graduates and they should have explained about how to showcase your skills in the best way possible, how to talk about the projects you have made and how to show these companies that you have the skills and experience they need.

If they didn't cover that kind of thing or their advice isn't working for you, then never fear, here are my top tips for coding bootcamp graduates to get a job after they graduate.

1. Software Developer

Stop using Junior, Aspiring or any other word to indicate you are new to the field, in your LinkedIn title or resume. It will be very obvious from your work history that you are new, so you don't need to lead with it. You are a Software Developer, you may not have much experience yet but it's not for you to pigeon hole yourself as junior, mid or senior. Don't put yourself on the back foot from the first moment someone reads your profile.

2. Coding Bootcamp Graduate Projects

During your coding bootcamp you should have made at least one reasonable sized project. Let's get that online, hosted at a domain in a state that is useable for someone to go and have a play with. It doesn't matter if it's not the most exciting app in the world. So long as it works and it was made by you then it shows you can code.

3. More Projects

One project from your coding bootcamp is great but ideally as a coding bootcamp graduate looking for a job, you should still be coding and making projects. If you've stopped then it's time to roll your sleeves back up and keep honing those skills. You want at least one project up and running on a domain, or in an app store, that you made on your own after your coding bootcamp finished.

I have three rules for portfolio projects. They need to be small, complete and functional. Small doesn't mean tiny, it should still have taken a few weeks to make. But it doesn't need to be the start of the next great startup to come out of your country! It does also need to be functional. People need to be able to use it, to test it and play around with what you've made, screen shots don't cut it I'm afraid. Finally it needs to be complete, no dead ends or obviously missing features, someone should be able to feel like they are using a small and useful tool/app.

4. Projects First

A company will hire you because they believe you can build useful software to solve their problems. Since you haven't yet done that for any other company you need to lead with the next best thing, the software you have written for your portfolio projects! While you might be most proud of your education, or your previous work history, it's not the thing that will get you the job. Showing you can code is what will do that. So put that first in a section called "Relevant Projects" and put a few bullet points about what each project is, how you made it and the technologies used. These should be front and center on your resume, your LinkedIn and your portfolio site. If you're looking for project ideas here are 30 developer portfolio project ideas for you.

5. Stop Remaking Your Portfolio Site

As a new developer it's tempting to make your own portfolio site. And then remake it, and then remake it again. Your portfolio site is not what will get you the job though. The projects on your portfolio site are. Unless you are an amazing designer it will almost certainly not be the best first impression so just use a pre-existing template and host it on Wordpress or Squarespace. Take the time you save here and make another project that shows you can use code to solve real problems.

6. Start Blogging

It doesn't need to be much, just a short 500 word post each week shared on LinkedIn about what you learned that week or what you built. No one expects you to be an expert so don't be afraid that it will make you look bad, quite the opposite in fact. People on LinkedIn will see consistent posts created by you and start to comment and help. Eventually you can ask this network for a job and you'll quickly have people getting in touch.

Don't believe me? Hear from Yusuf Chowdhury in this episode of the All The Code podcast talk about how he used exactly this process to land his first 2 developer jobs without ever actually applying for them and instead being head hunted on LinkedIn, as a junior dev!

7. Data Structures and Algorithms

You leaned a lot on your coding bootcamp but one area you are likely to be weak on is your data structures and algorithms. These are taught extensively on computer science degrees but they can feel very abstract and lack direct applicability for a coding bootcamp to teach to the same level. You will have covered them to some extent but not to the depth that some employers need. It's worth investing some time in this area and taking a couple of weeks out from building projects to fill in some gaps in this area. The two best resources here are Educative.io which has great courses targeting fundamentals like this and The Imposters Handbook which was specifically written by Rob to help fill in the technical blanks that self taught developers and coding bootcamp graduates often have.

Conclusion

Getting a job after a coding bootcamp can feel like an uphill battle at times. What you have to remember is that while you have learned the skills required to be a software developer, you need to take some time to present that to the world in a way that shows your future employer that you really can do that job.

So, if you're looking for top books for software developers to improve your skills and knowledge, no matter where you are in your career, then here are the 5 books that have had the most meaningful impact on my career as a software developer.

1. The Phoenix Project

Learn DevOps in this fun fiction book, it’s a really enjoyable book even before you consider all the great lessons it teaches around DevOps and how you modernize an old and failing system to become a positive force for a business.

Follow our intrepid new head of IT operations as he navigates a disastrous release, gets the teams work in progress under control and learns the 3 ways of DevOps from a strange, almost mystical outsider. 10/10, I have recommended it to many friends and colleagues and all have enjoyed it, even those that aren't software developers.

2. Clean Code

As relevant today as the day it first came out learn about Bob Martin's career and how he has improved his developer skills through multiple companies and projects. Some of these ideas are now mainstays in the software developer industry and many developers have adopted his practices to great success.

My particular favorite suggestion is having known sections of code that you can produce on demand that can be used as daily practice, he calls them Code Katas and they can help get you into the coding mood when you are perhaps struggling to get going.

3. The Unicorn Project

Sibling to The Phoenix Project that happens roughly in parallel. This focuses on how a developer, new to a failing project, begins to get a handle on things. Our senior developer uses automation, functional programming and strong team work and collaboration to set up new systems and upgrade legacy code to support the future growth of the company.

Software developers of any level will appreciate the problems that she has to deal with and some of it might ring a little too close to home. Another page turner, although much more specific to software development than The Phoenix Project.

4. The Imposters Handbook

Delightful summaries of CS concepts for every level of software developer. I'm self taught and so, like every self taught software developer, I have some gaps in my knowledge that is considered standard for people who have done a computer science degree.

If you want to get a high level understanding of the concepts taught on a software developer focussed degree then this book can form the cornerstone of that. Written by a self taught developer who set out to fill in his own blanks, this is an enjoyable book that will make you a better software developer.

5. The Pragmatic Programmer

If you've ever heard the terms "Rubber Ducking" or "DRY" when talking to other software developers and wondered where those terms came from then this is the place. This book is probably one of the most famous and iconic books on software development. This book is a series of tips and examples collated together for you to dip in and out of throughout your career.

Summary

There we have it, the 5 books for software developers that have had the most impact on my career. If you are starting your journey to becoming a software developer or perhaps you are already in a software developer role and looking at how to get ahead then these books are the best places to set your career in the right direction.

Note: some of these links are affiliate links and if you purchase the book I may get a small commission, which is pretty awesome and a great way of supporting what I do at All The Code, joining my newsletter is another great way to support me 😄

Software engineers are always needed, and are being hired by major companies across all industries. These jobs are not hard to find, but they do require a certain set of skills. Read on to learn what qualifications you will need to be considered for these positions.

What is a software engineer?

Software engineers are people who create, design and develop new computer programs. They also test their work to make sure it will run correctly. They tend to work as part of a team consisting of other software engineers, quality assurers and product focussed people.

Historically software engineers generally worked in an office setting, but they can also be found in the field or, ever increasingly as a full time remote worker at home or abroad. A software engineer is a person who specializes in the design, development, testing and maintenance of computer software. A software engineer's work varies from programming and writing code to designing and developing new products.

Software engineers are responsible for the creation and use of software, as well as its performance, usability and quality. Software engineers take on many roles like system architects or database administrators. They can be found working in the technology, video game, medical device or any number of industries.

Why become a software engineer?

Software engineering role are in demand and it's easy to see why. Software engineering is an exciting, challenging, and rewarding career that offers the opportunity to work on some of the most complex problems in the world. There are many paths to becoming a software engineer, from formal education to self-teaching.

The demand for software engineers is growing enormously and with a projected need of 5 million new engineers by 2030. This blog post will cover three ways you can make your way into this field: through university degree programs, through boot camps, or by teaching yourself.

Software engineering university degree programs

Software engineer degrees are offered at universities across the world. The largest and most famous universities have put many of their courses online for free so you can see what it's like before committing to 4 years of study and a lot of cost to get that much sought after software engineering degree. Here are five free university courses that help you become a software engineer:

1. Harvard CS50.net - this is how I learned to code properly nearly 15 years ago, as good now as it was then this the gold standard in online free university courses.
2. Stanford CS101 - a close second is this course from the university at the beating heart of Silicon Valley.
3. MIT: Introduction to Computer Science and Programming Using Python - MIT is known the world over as a hub of high flying technical innovation, learn from their professors.
4. University of British Columbia: How to code Simple Data - takes a unique approach to learning to code and focusses on deep fundamentals with clear practical application.
5. University of Michigan: Programming for everybody and Python - uses the most popular beginner language to take you from no code to all the code.

Software engineer boot camps

These have been growing in popularity for years and now there are hundreds of software engineering boot camps available in cities around the world or even 100% remote and online. Here are 5 software engineering boot camps:

1. Flatiron
2. Career Foundry
3. Boolean
4. LeWagon
5. School Of Code

Software engineer self taught paths

There are so many resources online to learn software engineering now that self teaching is a very viable option [in fact it's the path I took over 15 years ago). There are YouTube channels, free courses, paid one off courses and membership platforms that guide you through a well trodden path. Here are 5 resources to get you started on your self taught software engineer journey:

1. Brad Traversy YouTube channel
2. Zero To Mastery learn to code platform
3. Udemy course platform
4. FreeCodeCamp.org
5. The Odin Project

How to become a software engineer summary

Which ever route you choose to becoming a software engineer know that at the end there is a fulfilling a in demand career waiting for you.

• new programming languages
• new frameworks
• new technologies

is something you will need to do on a regular basis throughout your software developer career. Being able to learn new skills will help unlock pay rises, promotions and work on exciting projects.

The problem is that you can’t always take the same approach you did when you first learnt to code. Learning to code is a very “bottom up” learning activity. You need to learn fundamental concepts and spend a long time working though difficult and challenging things. This is why learning to code is So. Time. Consuming. Taking many months or even years.

You can’t set aside that amount of time whenever you need to learn a new framework or programming language. You need a quicker way to learn, something called “top down” learning. This is where you skim a topic to get a feel for it and then dive into the specific areas you need to learn whilst also working with it in an active project.

To achieve this, you need a framework!

This framework is designed to help you learn new software developer skills, it is not designed to help you learn how to code. If you don’t yet know how to code then you need a different approach to actually learn how to code.

Junior developer: Learn new skills framework

Here’s a tried and tested way for software developers to learn new skills:

• Find a video explaining the concept.
• Go through it at 2x speed to understand the broad 50,000 ft view. Take notes on things you don’t understand and draw parallels to things you do understand from previous learnings.
• Take a look at the docs and skim through those, seeing if there’s any deviation from the video to make sure the video you watched was accurate.
• Now that you have an all encompassing view of the subject, with notes about things you don’t understand, you can start diving into the subtopics until you’re comfortable with your level of understanding.
• Take as much or as little time as you need to at this stage. Dive into the theory or reasoning behind why choices are made to the level that you feel you need. If you are only lightly working with something you may not need to go too deep, but if the skill is going make up a core part of your work then taking the time to go deeper, and understand the fundamentals is important.
• Start to build something as early as possible, if they have a quick start project then spin that up. If you have a project you have inherited from another developer then start poking around with that by changing things and seeing what breaks. Start to mesh the theory you are learning, with the practical applications of the code you have in front of you.
• As you start to gain more comfort with the project and the code you are dealing with, you can determine the best way to be guided. You can either methodically work through the documentation/learning plan or you can be guided by the project you are making and problems as they arise.

If you get stuck learning a new software developer skill

If you get stuck when learning a new software developer skill or feel like you aren’t making any progress, then don’t force it. Sometimes you need to switch learning paths and have another go. This is perfectly natural so don’t let it demotivate you.

When learning a really big topic, or something quite different, then taking a more foundational approach can be quicker in the long run. For instance, if you have learnt JavaScript and suddenly find yourself needing to learn Rust, then a top down approach is going to be challenging because there are so many new concepts in learning Rust that you just won’t have covered in with JavaScript.

The trick is knowing if you are making progress or if you are spinning your wheels. This is why it’s important to have a project in active development when learning a new software developer skill. That way you can see the progress you are making and avoid getting stuck in tutorial hell instead of actually learning a new skill as a software developer.

Finally, A special thanks to Sean for providing the inspiration to this post, he’s awesome and you should go follow him on Twitter.

If there is one thing that humans hate, it is the feeling of being wrong.

Just because you spent the first half of your life dedicated to being a biologist, physiotherapist or postman doesn’t mean that you can’t make a change.

Don’t let where you have been decide where you go next, if you want to change to being a developer then draw a line in the sand and realise that no time was wasted, you weren’t wrong for pursuing something else and now you’re making a change.

Take what you have learned in your previous career and apply that to tech, if you spent years working in a client facing role you’re going to be excellent at working with users on product improvement, if you spent years reading legal documents you’ll be great at whizzing through documentation and Grokking a new library quicker than other devs.

I have a PhD in electrical engineering and often feel I should be using it in some way. The truth is I am, just not the bits you would expect:

• ✍️ I wrote the better part of 200,000 words over my PhD and now I write on the internet every day.
• 🎙 I have given dozens of presentations and now I have a podcast.
• 📊 I managed my own time and projects and now I run a business teaching developers how to land early career jobs.
• 👨‍💻 I taught myself to code and now I code everyday.

Embrace your past and use it to spring into your new developer career.

1. CodingBlocks.net

This is by far my favourite coding podcast, friendly hosts, diverse topics and extremely informative. CodingBlocks isn’t afraid to dive into the weeds on a topic and even spread it out over multiple episodes if needs be, these aren’t just quick hits and hot takes - they are in it for the long haul.

2. Under The Radar

“A show about independent iOS app development” It’s been years since I released a native iOS app but the topics covered here are relevant to anyone interested in making iOS apps, be it with web technologies or Swift. Both of the hosts have had an active App Store presence since the first day of the store so, what they don’t know about iOS app development probably isn’t worth knowing!

3. Code Newbie

When taking your first steps into the world of code it’s nice to have a helping hand to guide your journey, hear stories from people just like you and how they navigated the early part of their careers with this excellent podcast. Running over 17 seasons there is plenty to get into.

4. HTML All The Things

Much more than just HTML, this show covers topics for all levels and isn’t afraid to go against the grain, pushing back against the latest hotness in the JavaScript world where needed and stepping back with a more nuanced point of view.

5. Tabs and Spaces

This is a fun podcast that really feels like listening to three friends chatting at the pub, interviews and deep dives on topics that all developers care about, this is well worth putting into your rotation.

6. All The Code

Have you subscribed to the CSTC podcast yet? If not subscribe to hear interviews with amazing seasoned devs and those just starting out.

With the average US Python developer salary now over $100,000 per year it's also a very profitable language to learn. So, what are the best ways to learn Python?

1. Learn Python With CS50 (3 months)

If you have no programming skills at all and have the time to start at the beginning then Harvard's free online CS50.net class is a great place to start, it takes you through a couple of other languages first but you land up learning Python in the second half. This course is amazing but it has a time commitment as it starts with the fundamentals so is very much "bottom up" learning.

2. Learn Python by Automating The Boring Stuff (6 weeks)

This book "Automate the Boring Stuff with Python", which is made available for free by the author, takes a practical approach to learning Python by showing you how to automate boring tasks like bulk file renaming and completing online forms. A great first primer on the language and it has been many peoples first introduction to coding.

3. Learn Python The Hard Way (6 weeks)

Learn Python "The Hard Way" is more a branding term than anything else so don't be put off! This just means that the author expects you to type out and execute all the code in the book so really learn the language. Version 2 of this book used to be free and this is how I learnt Python, version 3 is $29.99 and is widely regarded as worth the investment (in both money and time).

4. Learn Python on Udemy: 100 Days of Code: The Complete Python Pro Bootcamp for 2022

Already updated for 2022 the 100 Days of Code: The Complete Python Pro Bootcamp for 2022 course it's the clear winner of Udemy Python courses. With 60 hours of content video this course takes you from having no Python to being able to build applications and solve problems with it. Udemy has sales on all the time so remember to never pay full price, just wait a week or two and they will have it on sale.

5. Learn Python With a Youtube Crash Course (90 minutes)

Brad Traversy has a jam packed Python crash course that goes through everything you need to know in 90 mins. Probably best for those of you with some programming knowledge but even for a complete beginner this will give you a broad overview and help decide if Python is for you.

Learn Python Summary

What ever way you decide to learn Python remember that learning is just the start, you need to build projects, solve problems and practice, practice, practice. For that there is no better list of sample projects than my post 30 Developer Portfolio Project Ideas.

Below is an overview of the types of days to expect at different places, make sure to read to the end to see an overview of what will be common to all of them.

Software developer at an agency

Agencies deliver software projects for clients who don't have in house developers, need more capacity for a short period of time or simply don't have the skills in hose for a specific type of work. Agencies tend to have many projects underway at once and you will be assigned to one or two of them for a few months at a time. Your main focus will be on building the features required for your clients project with fairly strict deadlines, the client wants the software and your company want to make the client happy.

Agencies can be stressful to work at, you will need to work quickly, efficiently and be very good at keeping stakeholders up to date. Expect a few more calls each day that you typically get in other types of companies and the expectation that you will deliver.

The enormous positive is that you get to change projects every few months, which can feel like a whole new job, you get exposed to a wide variety of technologies and you spend little time maintaining legacy code and fixing bugs.

Software developer at an established company

Working for an older, more established business who's main business focussed isn't directly related to technology (like a manufacturing firm, retailer, bank, energy company etc) will see you working across internal projects that help the business achieve its primary aim. You will feel more in a supporting role where the work you do is less about "cool tech" and more about "is this the best way to help us sell more widgets?" (whatever those widgets might be).

There is less pressure than an agency however deadlines are still very much a thing and other departments will be relying on you to complete work for them, likewise you will also be reliant on other departments delivering on their promises to you and you could get held up waiting for marketing, finance etc to get back to you on something.

You will also have a lot of legacy code to manage and monitor. This will help you get used to working with a large code base and debugging weird issues far more than a new greenfield project.

Work will feel slower and you won't feel like you achieve as much as you like many days but that's to be expected and totally fine, you are not here to crank code, you are here to deliver on what the business needs, and bug fixes for users is very high on that list.

But there will most likely be good processes in place, the company will be stable and they will offer a lot more beyond just coding and an office full of bean bags. Larger established companies offer a career path, a sense of achievement and being part of something bigger than just a single deliverable.

Software developer at a start up

Start ups are cool, hip and fun. They inhabit the middle ground of the established company and an agency. There is legacy code but it's not that old, there is pressure to deliver but there's no external client impatiently jumping around and you will have to do a bit of support and bug fixing but it mostly feels like feature work so it's not that draining.

Being a software developer at a start up is seen by many as the perfect balance, the enormous trade off is instability. The company might not have found product market fit yet, it might not have even launched and the founders are trying to raise money to keep the lights on, there will be minimal documentation and processes in place and the code base will be full of shortcuts and hacks.

The flip-side of this is that you can have a huge impact on your team and the organisation, if you join a company of 20 people then you are 5% of the company, that's a huge opportunity to input on product direction, working practices and you might even get some equity.

Software developer typical day

Above are three examples of what a developer role can feel like at different companies that employ software developers, lets wrap this up with what a typical day might look like no matter where you are:

Morning:

• Stand up meeting with team, 15 minutes. Talk about the work you are doing, any blockers you have.
• Development work on your current feature. This could be solo, paired with another developer or a mix of both.
• Chat with user or product owner. If you need to clarify something about your work the quickest way is to talk to the person using it or the person in charge of the product.

Afternoon:

• Team meeting to look over the backlog of work and plan how it will be tackled, group exercise in which everyone gets to have input on how the feature/solution will be implemented.
• Investigate and fix a bug related to a support ticket, lots of looking through logs, talking to the user/support person and trying to recreate it.
• Development work on your current feature, adding documentation.
• Reviewing another team members code.

Software developer day summary

Every company is different and one of the amazing things of being a software developer is that if you find you don't like one style of work then there are thousands of other companies who work differently. Sometimes you can get into a regular pattern of work but it's unusual to be just cranking out code each day for hours on end, from the outside it might look like we are just twiddling with computers all day but it's a lot more than that!

Here are some common mistakes you might be making daily that are slowing you down, holding you back and building tech debt.

🧪 Not writing tests. Get used to writing these sooner rather than later. You don’t need to go full Test Driven Development (TDD) but at least be comfortable. I should have started earlier!

📄 Not documenting code. Coming back to old code is a nightmare without good docs, I can’t remember how code I wrote last week works so after 1 year I have no chance.

🧰 Not breaking out common code into a reusable library. Reusable code is your toolbox, it saves you time, effort and complexity. Start building your personal toolbox or your teams toolbox now.

🍱 Forgetting to split projects into smaller modules. Good organisation is the best way to keep a codebase sensible and manageable, it doesn’t come for free though so you have to work at it.

🏛 Not using external libraries. Build on other peoples code and don’t write everything from scratch, this lets you move faster, benefit from others work and you can focus on your core business logic.

💅 Not using an auto code formatter. Worrying about how to format and layout your code should be the last thing on your mind, get used to auto format on save and you will love it!

🤖 Not automating. There is a knack in knowing when to automate, too early in a process and you risk automating the wrong thing and having to change it, too late and you'll have an overly complex process to automate that will take weeks to sort out. If you've done the same thing 3 times in a short period of time (measured in weeks) then it's time to automate it.

Summary

None of these on their own will derail a software project but all of them can add friction to the development process and slow you down. Pick one and implement it in your current project today.

One more win

Join the mailing list below for regular tips and a FREE copy of the All The Code quick start guide 😀

1. Make sure you know exactly when the test is due, they might be casual about it but see if you can nail them to a deadline. This would be expected in a job and so you should do the same here, it actually works in your favour as well, if they want it done in 24 hours and you had been thinking "I'll get to it at the weekend" you can now re-asses.
2. Don’t be afraid to ask questions about it if you need to. It’s unlikely that they have covered off literally everything in the spec. If you are short on time and just want to get started then add a comment to the readme about an assumption you made that saved you asking a question.
3. Add a readme, explain your thinking and approach. At the end of the readme add some notes on what you found challenging and how you would improve it. Make sure the readme contains all steps required to get the project up and running so that they can run it locally if they want to.
4. Ideally host it as a Github repo and send them the link to it. Emailing projects with many files zipped up can be flaky.
5. If you go down the Github route and have passwords or API tokens in your code then highlight in the readme, or in a comment, that you know this is bad practice but for the purposes of the test you have included them. If the test specifically tells you not to do this then don’t, however that’s getting beyond what I think would be expected of in a reasonable take home test.
6. Don’t solve more than they ask for, the idea here is that you have been given a task to do to assess your coding skills and your ability to follow instructions. By all means do a good job but this isn’t the time to “express yourself”.

There you have it, everything you need to make sure you next take home test.

Remember to sign up to the mailing list if you want more like this delivered straight to your inbox 😀

As you progress through your career this feeling subsides a little bit as you build the foundational skills that let you pick up a toy and think "huh, this looks like that other toy I played with last week but it's red and made from cork instead of plastic" and you can muddle your way though.

More technology to learn than time to learn it

The problem that remains through all of our careers is that there is significantly more to learn than any one person can hope to cover in a life time. In fact I would go so far as to say that many developers already interact with enough different technologies each day that even learning all of those properly is a lifetimes work.

For example, gone are the days where a web developer could hold the entirety of that industry's knowledge in their head. 20 years ago when the web was first taking on a form that would be recognizanble as what we have today, it was probably possible to know everything about how it worked. Now, that just isn't the case, we have layer upon layer of abstraction running so deep that we've made a technological Mariana trench, and we are still digging!

What to do as a code newbie?

Depending on where you are in your career I see two options. If you are new to coding and still finding your feet, then focus on fundamentals. I'm not one of these militant people who says you must master data structures and algorithms before even looking at things like React or Django but I do think it's important to know where you would like to work for the first portion of your career and focus on the fundamentals in that area to begin with.

If you want to be a front end web developer then HTML/CSS, JS and React are probably your best initial focusses. f you want to be an iOS developer then you want to learn Swift, UIKit and a smattering of SwiftUI.

Don't hop around too much or get distracted by the new and the shiny, you will keep picking up and putting down toys and never really learn how to enjoy one fully. All those other technologies will be there to pick up in the future, and having good fundamentals in one area will actually transfer very well into other technologies - you are rarely starting from scratch again.

What to do if you're mid career?

If you are mid career, like me, then you have probably already been through a few cycles of "learn it all" and "I don't want to touch a keyboard for a second longer than needed" already. I have oscillated between fear of missing the next big thing and just wanting to go back to using JQuery many times already.

The thing that I have recently found that helps is to not force myself to learn everything new just because the whole world seems to be focussing on it. Instead look at what my current job, or the next job I want, actually need and then make something fun in that technology.

This is hard if the next thing I need to learn is a bit boring or specific to a larger scale application but if it's a new flavour of database or front end tech then I will spin up an old project I know pretty well and reimplement some, or all, of it in said new technology. These projects are small, fun and useful to my life, so I usually quite enjoy pottering about with them because I don't need to think through the business logic too much and can focus on the fun of learning a new thing.

Summary

Regardless of where you are on your coding journey you will feel pressure to learn and to keep up but don't loose sight of the end goal, which is to make products and solve problems. With a few exceptions it doesn't really matter what technology you use and hopping between them isn't all that hard once you have a good grasp in one area. Find enjoyment in the learning process and don't try to take on too much, focus on the smallest next unit of learning that can add value to your daily work.

We have all opened up code that looks like this:

const fds = (fda + fdb)/gtr;

and wondered if the original author hated the universe, was a genuine genius or was somehow allergic to typing. There is nothing in that code to indicate what those variable relate to or how fds might be useful in the future.

The variable names are meaningless to our brain and remembering these letter groupings while tracing their use through the code adds a huge amount of cognitive load.

Fortunately we have, in the main, moved away from this type of variable naming. It was ripe in the Fortran and early C days but now we use more descriptive names that show the intent of the code and it is much easier follow along. If a variable is called maxWidth it is much easier to understand and remember than mW. It's the different between holding a group of letters in your head vs the concept of what it represents, are brains are pretty terrible at the former but excellent at the latter.

Ternaries and Destructuring

Whilst we have clearly improved when it comes to naming variables there is an area of coding that we are going backwards in, and that is the desire for smaller and smaller files - even at the cost of legibility.

Small composable blocks of code is a great ideal to aim for, having 45 tabs open in a code editor isn't always ideal but it probably is better than 3 files of 2,000+ lines each. However, I would rather have those 3 big files to wrangle than dozens or hundreds of the following:

const {
  data: {
    header: { personId, storeId, locationId, stockUnit },
  },
} = msg;

or

const result = isAdmin ? "All Allowed" : isManager ? "Some Allowed" : isAlien ? "Run" : "Not Allowed";

In isolation the above examples are reasonably understandable (i've chosen fairly simple examples) however, amongst a full application, surrounded by other business logic and less straightforward variable names, both of these can be written in a longer, more understandable manner. Let's take that ternary:

let result = "Not Allowed";
if (isAdmin) {
  result = "All Allowed";
}
if (isManager) {
  result = "Some Allowed";
}
if (isAlien) {
  result = "Run";
}

The above is considerably longer but much easier to read. The added vertical space is a more than worthwhile tradeoff in the aid of readability to me.

We should be striving to write code that is understandable to the newest and least experienced members of the team. Business logic is where the complexity should lie in code, not in the syntax itself. When a new developer or new team member is reading unfamiliar code they should be focussing all of their efforts on understanding the what the code does and not the exotic structures used to save a few lines.

The rise of ternary

Ternary operators have always been a bit of syntactic sugar to make very simple if/else statements shorter. I would agree that an if/else that takes up only 5 lines and is very simple should be simplified, however the rise in ternary in the Javascript world over the last decade is starting to get out of hand. I'm starting to see multi level ternaries with map and find in them where that all important : of the ternary becomes impossible to spot.

I think this has happened thanks to React, more specifically JSX, and it's liberal use of ternary statements for conditional rendering. I don't want this to become a rant on JSX (which at worst I would say I am ambivalent on) but let's not let JSX practices bleed in to JS/TS and other best practice.

Take Away

Code for legibility and not brevity. We moved away from terse and incomprehensible variable names, let's not regress with the equivalent with syntax.

If you want a selfish motivation then I ask: would you rather new team members just understand the code you wrote or spend the rest of your days in that company answering questions about it?

1. Straw Poll Web App - React, NestJS
2. Pokedex - Angular, PokeApi.co
3. Weather App - SwiftUI, openweathermap.org/api
4. Tweet Scheduler - JS/HTML/CSS and Supabase
5. Workout creator- Kotlin, Android
6. Timer Web App - React
7. Reminders text message - Vue, Twilio
8. Crypto Tracker - Angular, ExpressJS
9. Chat Web App - React, socket.io, NestJS
10. File Uploader Plugin - Angular, Ruby
11. IMDB Ratings Scraper - HTML/CSS, Python
12. Egg Timer - HTML/CSS, JS, CapacitorJS
13. Meme Maker - UIKit, Swift
14. Colour Picker App from Camera - Flutter, Dart
15. Tax Calculator - Angular
16. Slack Plugin - JS
17. Shopify Theme - NodeJS, React, GraphQL
18. Wordpress Plugin - HTML/CSS, JS, PHP
19. Instagram Post Maker - Kotlin, Android
20. Todo List CLI App - Python
21. Notes App - UIKit, AppKit
22. Flash Card App - SwiftUI
23. GitHub Timeline - Vue
24. Conway's Game Of Life - HTML/CSS, JS
25. Expenses Tracker - React, Electron
26. Currency Converter - React
27. Clone an App - same tech
28. URL Shortener - HTML/CSS, JS, Lavarel
29. Mine Sweeper - PhaserJS
30. Habit Tracker - Swift, UIKIt

Situations like this can lead to you cherry picking your reviewers, having endless back and forths about a forEach vs a for, and generally feeling a bit fed up with the whole process.

Well, let me introduce you to a system that lets the reviewer express their thoughts in a manner that indicates exactly how important each comment is and how much attention you need to pay to it.

MoSCoW, taken from the world of project management is the name given to a list of requirements laid out as:

• Musts
• Shoulds
• Coulds
• Woulds

I won't dwell on what they mean exactly in the world they originate from because it's not relevant and the system is so self explanatory you've probably already worked out where I'm going.

M/S/C/W

Each comment should begin with M:, S:, C or W: and then the comment.

• Must: this has to be changed to be approved. These are errors that either go against the coding standards of the team or are clearly just incorrect and will lead to a bug. These can't be ignored.
• Should: these are things that would be an obvious and clear improvement. You have to give a reason to ignore this and the code reviewer has to agree. A third party can be brought in if needs be.
• Could: these are for niceties that the reviewer thinks would improve the codebase in some way but are probably going above and beyond what the task requires. If they have an idea for a slightly better function name or they want to leave a comment but aren't all that bothered if you take the advice then this is the prefix to use. These can be ignored without a reason given.
• Would: these are reserved for the "I wouldn't have done it this way" comments that require lots of rework but are 100% personal preference. These rarely get used because a would is really just the reviewer being given space to express their thoughts. An ideal usage of this is to educate a junior member of the team and perhaps follow up with a conversation around it post review.

In the example above about a for loop I would say:

S: Use forEach here to avoid off by one errors and aid understanding of
loop conditions

or similar.

Summary

Introduce this at your next team meeting, get a clear understanding of your musts and a rough idea of some shoulds and you will see how liberating this is for everyone involved in the code review process.

It's not wonder we don't like them!

Whether you are a seasoned pro at coding interviews or a complete newbie who has only ever heard the horror stories we can all improve. Here are my tips to getting through your next test.

1. Play the game

We all know that you won't have to reverse a linked list in the actual job, but during the interview you need to forget that. Whatever challenge they have you do, treat it like a real work task, that way when you get stuck and stressed your brain won't be saying "this is madness, the job won't be like this!" If you let those thoughts get in to your head you will get in a downward spiral that won't do you any favours.

2. Question and Clarify

On the topic of making yourself believe this is a proper task, really treat it like one. This means you ask questions to clarify what is required and clear up any ambiguities there are in the task. If you don't understand something the way it is written, don't be afraid to speak up, it could have been written in such a way to make sure you ask questions. Often the most important parts of an interview happen outside the core test so asking questions, clarifying points and reiterating what they want you to do is vital because those are all things you will be expected to do in the actual job.

3. Check the rules

It's no secret that Google is the main tool in a developers box and a good interviewer will allow for this. Don't sweat through not being able to remember the syntax for .reduce() when you could Google it. Ask at the start of the interview if Googling is allowed and to what extent you can use it, if it's a solved problem (like reversing a linked list) they will say not to Google that explicitly, but usually language syntax and standard library functions are fair game. Each company will vary slightly and asking what is and isn't allowed is only a good thing.

4. Talk, talk, talk

Don't code in silence, make sure you are verbalising your thoughts. This felt very alien to me the first time I did it so I would suggest practicing on a small problem yourself, get used to talking about what you are coding, tell them what you are thinking and the trade offs you are making. Don't think in silence and then write code, the interviewer isn't a mind reader so help them out. If you are making a trade off between two approaches ask for their input. For example "do we want faster reads of writes do you think? I'm thinking the writes are more important but would love your input"

5. Tell them what you're skipping

If you are taking a short cut that you wouldn't usually do then tell them and explain why. If you don't want to waste 10 minutes setting up an automated test library and you normally would then let the interviewer know that. This goes hand in hand with talking about what you are doing and could subtly de-rail you if you skip over something without addressing it.

6. Test as you go

Don't forget to run your code. Don't code for 25 minutes and then run it for the first time! They want to see an iterative process, how you respond to errors and how you debug them. Don't be afraid to debug with console.log('here') if that's the best tool for the job, they want to see how you solve problems, how you deal with roadblocks and how you think.

7. Be yourself and be honest

Imposter syndrome is horrible, made worse by if you actually are one! Be yourself in the interview, code how you want to code and make your level clear. The last thing you want is to make out you know things you don't, or have experience you don't, only to get found out on the job. Don't let the pressure of performing in an interview change who you are. If you code as you and don't pretend to be smarter or more experienced than you are then you can go into that job imposter syndrome free 😀

"Oh it doesn't matter, I'm just playing at the moment"

This is a sentence that gets my attention, and not for good reasons. When people say this it's usually not after discussing something that would actually be considered "play". No, it tends to be after mentioning something actually quite serious and important like investing, learning to code, starting to apply for jobs.

Describing your efforts in any of the above areas as "playing" is jarring to me and leads me to follow up with:

"What do you mean?"

At this point they usually get a little uncomfortable and say something like:

"Well it's ok if I don't hear back from recruiters because I am just playing about before doing it properly in the future"

Or some version of that.

Let me translate what they really mean:

"I'm trying a new thing, I don't really know anything about it because learning about how to do it properly is boring and uncomfortable and I think there is a reasonable chance that I may fail. As a result I am making out like it's not that important to me and that I am almost expecting it to fail because then I won't look or feel as stupid as if I conveyed to you that I really hope this works. I am pre-emptively admitting defeat so that the emotional fall I feel, should this fail, won't hurt as much and I can say "I didn't really expect anything from this, I was just playing" "

Basically, they are setting themselves up for failure and absolving themselves of any real responsibility for that failure at the same time. Quite the mental gymnastics.

Instead what they should be saying:

"I'm learning to code and starting to apply for jobs. It's hard going and I'm not sure how it will pan out but I'm really keen to learn everything I can about this process and I'm really confident I can make it work. There's a chance that it's going to take a few attempts and that I might fail in the short term but I can take all of those learnings and redouble my efforts until I reach my goal"

I don't know about you but I'd rather bet on the second person than the first. No matter the odds or the size of the challenge they are tackling.

While some people initially thrived, as the months dragged on it eventually took a toll on all of us, I witnessed many of my friends let work engulf their life to the point where they were signing off WhatsApp messages with "Kind Regards" and suggesting agendas for Saturday Zoom calls with drinks - it would be funny if it weren't so painfully a sign of poor mental health.

I started a new job in October 2020, leaving a wonderful company that was deeply impacted by COVID. I went to a consultancy building a product in arguably the fastest growing area of tech over the past few years. Greenfield project, lots of input on direction and near complete autonomy to implement parts of the system how I wanted in a very small team.

The problem? The business had no idea what they actually wanted us to build and we burned ourselves up in about 8 months flat. Coming out of that experience, thankfully in a new role elsewhere, I can look back and see where I could have done a much better job managing the situation and my mental health.

Clarify roles, responsibilities and expectations

No one knew where their roles and responsibilities started and ended. This meant many product level decisions were pushed down to dev and we spent a lot of time saying no. Saying no is an important skill as a developer but we were making calls on things that really should have been decided at a product level, you can only say no for so long before it wears on your soul and you start saying yes simply to lift your mood a bit. We would oscillate between saying no and then yes and then having to say no again mid feature because we had over committed.

If everyone in the team had a clear understanding of where key decisions should be made we wouldn't have gotten in to this negative feedback loop.

Time box meetings and have an aim

Meetings with no set aim, no idea of what would be needed to make a decision and (as above) no idea who has the final say lead to endless meetings that achieved nothing. Meetings should have a clear purpose, a "what do we want to get out of this time?" to keep it on track and moving toward a conclusion. I would often look at a screen of faces discussing the same feature for the 4th hour that week and be amazed at the amount of wasted time and money having all these people stuck in an endless loop.

Limit your projects

The pressure to learn new technologies is huge, if you are learning masses during your day job working with new things then don't also pile on with extra learning in the evening. If you do want to code for fun in the evening then make sure it really is fun. I have a new rule which is to limit myself to one learning project and one doing project at a time. If work is straightforward because I know the technologies then I will learn something new in my spare time, if work is all new then any coding I do in the evenings should be for fun and low mental effort.

Vary your work types

I got stuck in two modes in that job:

1. Coding like my life depended on it
2. Endless calls talking about the product

I should have given myself other ways to work during that time, like listening to documentation with Speechify rather than forcing myself to stare at the screen more. I should have suggested we try more interactive whiteboard sessions for calls rather than just talking endlessly. I should have gone for a walk whilst on morning standup to get some new perspective.

Push back against unreasonable deadlines

We were given a list of features and a deadline that had had no technical input at all. We raised an eye brow at this initially but then just worked to hit it. Product encouraged us to skip writing tests, skip automating repetitive tasks and increase the number of points each sprint to hit the deadline. I used the term "coding for my life" above because that's what it felt like.

We should have stuck to our guns, written tests, automated tasks and gained a real idea of the development velocity instead of simply aiming to deliver features come hell or high water. Development work isn't like manufacturing work, you can't just throw more time, more people and a faster cadence to get more done - things break, tech debt builds and quality suffers.

We should have descoped the project and found a happy medium between getting features out the door and building a reliable and scalable codebase at a sustainable pace.

Pomodoro

I would sometimes work for 5 hours straight without taking a break only to then be basically useless for the rest of the day. Breaking work up in to 50 minutes chunks with 10 minute breaks is a much more sustainable approach to the day and is what I now implement. Mental work doesn't have the same pain and tiredness feedback of physical work and so it's far harder to know when you need a break. On a building site it's far easier to spot someone stagger because they're too tired work more. To make up for that lack of feedback we need to automate our breaks and stick to them.

Turn off notifications

This one is huge, a constant stream of notifications through the day is death by a thousand cuts to your cognitive abilities. If anything is truly important enough your team will find a way to contact you, otherwise those Slack notifications can wait to the top of the hour. Either dedicate some time each day to triage emails and notifications or set a specific point each hour to check in, perhaps just after one of your 10 minute Pomodoro breaks.

Sleep

No matter how engrossed in that feature you are or how much you think scrolling on Instagram or Twitter for 5 more minuets will make you happy, neither will be as good for you as just going to sleep and getting in a solid 7-9 hours on the regular.

Exercise 30-60 minutes a day

Physically tiring yourself out, getting your body moving and releasing the hormones that come from exercise into your body will do wonders for your focus, sleep and overall mental health. It doesn't need to be weights or running, it can be skipping or dancing or kicking a ball against a wall, just something that gets you a bit out of breath and breaks a sweat. If you can break up your work day with exercise even better.

Summary

That project ended in failure, the product was over featured in places that didn't really matter and underserved in actually useful features. 100% of the dev team coincidentally handed their notice in on the same day and so the project was put on pause and the non-dev members repurposed to other projects.

I narrowly avoided burnout, more by luck than judgement but I am at a new place now that clearly promotes sustainable working practices which is much better for my mental health.

If you don't have a specific area in mind then developing your strengths in the shared attributes should allow you to move discipline when you decide you want to.

Web developer

Loosely subdivided down into 3 categories of Frontend, Backend and Full-stack the world of web development is broad and ever changing.

Frontend work is concerned with the creation of the user interface and user experience (two fields in their own right that, while don’t concern themselves with coding, offer deep and interesting careers) and handling the interactions with other services such as third party remote APIs and the applications own backend.

The backend of the web is the 90% of the iceberg you can’t see. It’s where the majority of the web’s code lives and is responsible for handling requests, fetching data, running through business logic tasks and generally keeping the wheels on the bus. While there are many applications that are useful with only frontend code, there will come a time in nearly any project that some backend heft will need to be brought to the party.

Full-stack is the combination of both of these areas, people working in this category tend to have a preference one way or the other but the trade off for breadth is that their skills likely don't run as deep in either end as someone focussed specifically on front or back. The trade off however is that you can get a whole system up and running with less people. I consider my self full stack and rely on specialists when things get tricky.

DevOps

DevOps is the name given to a reasonably recent field that has emerged to blur the lines between development (the building of software) and operations (the deployment and maintenance of software).

If this field is new to you I highly recommend reading the Phoenix Project and the Unicorn Project, which are fictional stories that explain and reveal the concepts of DevOps through the trials and tribulations of a company called Parts Unlimited and their transformation from the older practices around software to embracing DevOps.

If you have recently learned to code then it is unlikely that this is the area you would want to go into, however it is very much in demand at the moment and if you have a love of "tinkering" with computers from a previous hobby or role, then this could be an excellent way to get into the industry.

Data Science

Data Science is all the rage at the moment and is in very high demand. Certainly, salaries in this discipline are leading the way and most large companies are adding a Data Scientist to every team and smaller companies are rapidly hiring data scientists now because they see the value of the data they have on their clients and customers.

Data Science has existed in many forms for 30 years or more, it is essentially using data to make informed decisions. It is often lumped together with Machine Learning and Artificial Intelligence and while these disciplines are different the lines are very blurred and they are more marketing terms than anything. The best description I have read, that I sadly can't remember the origin for, is:

• Data Science: Analysing what has happened
• Machine Learning: Predicting what will happen
• Artificial Intelligence: Deciding what will happen

Data is the foundation to all of them.

Embedded Programming

Embedded programmers don’t get the attention of web and app developers, but we interact with their work hundreds of times per day. Every time you use a microwave, TV remote, washing machine, drive a car, or swipe into a building with a key card, embedded code gets executed. Embedded code is often referred to as firmware, as it’s baked into the little black electronic chips you see on printed circuit boards and is considered “firm” as it may be hard or even impossible to change once flashed onto the host chip.

The best example of relatable firmware programming is Arduino. Arduino uses a standard Atmel microcontroller on a nice board and has some magic instilled in it to massively reduce the barrier to entry for this field.

The first code I ever wrote “in anger” was embedded code for a little wireless microcontroller which I had made that could transmit a light sensor reading back to a laptop to be displayed on the screen. There is something equally amazing and terrifying about writing code to run on little tiny black squares on a circuit board. For some reason, nothing else in programming matches the joy of simply making an LED flash on and off.

Native App Developer

There are a few ways of making Apps.

1. You can use the native languages for iOS and Android, which are Swift and Kotlin respectively
2. You can learn Javascript and use one of the many technologies that allow JS apps to run like a native app shipped via an app store like React Native and Ionic
3. You can learn Dart and the Flutter framework or C# and the Xamarin framework.

All of them end up with apps running on a a smart phone distributed in the main from an App Store. The world of smart phone apps is one of the biggest social and technological changes we have experienced in last 20 years, and probably second only to the internet in the last 100 years. If you want to make apps then you need to decide on one of the above approaches.

Others

There are of course many sub categories to all of these and if you think any are large enough to warrant their own write up please chime in below. Industries like automotive sector use their own special languages and PLC programmers also have specific skills and knowledge as well.

Setting aside the ridiculousness of that statement I want to look at the difference between working on greenfield projects and older, more established IT estates at companies for whom tech probably isn't their primary focus. Is one better than the other?

Start up / greenfield work

Nearly everyone loves the first page of a new notebook, that sense of opportunity of what this book could be, the person you will become once you write your thoughts and ideas in it - there is something exciting about it. We all know after page 3 it will be full of scribbled notes from calls and reminders for tasks you need to do, but still, we hover the pen over the page just that bit longer on page one, like we're stepping out in to the first fresh snowfall of the year not wanting to ruin it.

Starting a new codebase is similar, all those ideas and possibilities. Knowing that this time you will "do it the right way" is alluring, not having decades of technical debt to slow you down is freeing.

You will get to know more of the code, you have a hand in crafting many of the main areas, and so further changes and refinements are fast because you already know the code and the patterns employed. You don't need to reference documentation all the time or go spelunking through layers of function calls because you already know the final DynamoDB document that the data you need ends up in.

Working on a greenfield project can make you feel like a coding god. You know what to do and where to do it. You deliver features quickly and you're on top of your tech debt. It's nice but short lived because all greenfield projects grow old, become complex and no one knows how it all works, not really any way.

Brownfield

Working on old IT estates is tedious, hard and boring. Nothing new happens and it's all just maintenance!

This misconception is what startups and agencies want you to believe because it's their best narrative to persuade you to come and work for them. At some companies it might be true, but that's not an issue inherent with older codebases but instead organisations that are set up in such a way that this is how they view their IT systems. Funnily enough a boring company that isn't really innovating will probably have boring IT projects that will feel like the above.

Companies that recognise the value in their IT department and are actively adding features and modernising their IT estate on the other hand, offer something equally fun and, I think, more challenging than greenfield projects.

• They teach you the ability to decipher how a system works without relying on knowledge you accrued from making it yourself. You become a better problem solver.
• You are forced to become comfortable woking on a system you only partially understand.
• You learn the value of tests, not because you are forced to write them but because you will loath previous developers who didn't write any for the code you now have to change.
• You will be given the chance to modernise an old system using best practices and compare new approaches to the "old ways" and see not only the benefits but also the downsides.

Greenfield vs Brownfield

There is no right or wrong answer to which is better but I will say that I have seen developers come to existing IT projects, having only previously worked on greenfield projects, and flail for 6 months getting frustrated and annoyed at how slow everything feels because their expectations have been set unrealistically high from their experience to date. Most of the work with existing code bases is working out exactly what you have to change and where, rather than the change itself.

People who start their careers on old systems, adding features, fixing old bugs and generally ushering this creaky beast into more modern times don't have this painful learning curve, and when they come to a greenfield project they are delighted and appreciative of this window of time where they can move fast and break things.

The thing that both of us have found in our conversations with Bootcamps, recruiters, hiring managers and developers is that the single best way to get your foot in the interview door is to show off what you can do. The best way to do this is to:

1. Make things
2. Add those things to a portfolio site

Skills don't have a voice

So many developers believe that their "skills speak for themselves" and believe simply listing their skills on a CV or resume is enough.

Well I've got news for you.

Putting your skills on your CV with no evidence isn't your skills speaking for themselves. It's you speaking for yourself and, quite frankly, the person reading that list of skills doesn't know you from a hole in the ground or if they can trust you.

You know what is "letting you skills speak for themselves?" building projects and releasing them so people can actually see what you can make - literally letting your skills speak for themselves. Funnily enough, skills don't have a voice of their own, they actually can't speak, so your completed, functional projects are the voice they so desperately need.

Go slow to go fast

People think that taking 2 months to make a project or two will slow down their job search and that it's a waste of time. Well, do you know what is a waste of time? Applying to 300 jobs and getting 10 interviews when you could have applied to 50 and got 20 interviews because the hiring managers could actually see your work.

In the end, making projects is time invested to make an asset that will serve you for years to come on every job hunt. One of my main projects on my portfolio is 10 years old, still working, still getting traffic and still showing off my skills.

Don't make you own portfolio site

I've said it before and upset lots of front end devs but I'll say it again. Don't make your own portfolio site!

[

View this post on Instagram

](https://www.instagram.com/p/CRWPN50D69a/?utm_source=ig_embed&utm_campaign=loading)

A post shared by Simon Barker | Web Developer (@allthecode)

//www.instagram.com/embed.js

You don't have to use Troopl, you can use Squarespace or Wix or whatever but, the expectation on websites is so high now that spending weeks trying to match what out of the box platforms can do is pointless. You are much better off spending that time making your take on a todo list app or Spotify Playlist maker and showing you can solve tricky business logic problems than you are do an ok but not great job at parallax.

Painters don't make their own frames, developers shouldn't make their own portfolio site.

Summary

1. Make small, functional and complete projects.
2. Release them in to the world.
3. Put together a turnkey portfolio site to show your work off.
4. Get more interviews.

• this isn't an ad, they didn't ask me to write about them, they didn't pay me, they don't know I'm writing this. I just like the guys and think what they are making is cool. If I were going to write an advertisement I would do it for my own stuff 🤣

Something about it sounded familiar so I did a quick search through my work journal and sure enough unearthed a note from 3 months earlier where I had seen this issue myself and jotted down the solution.

"You're running the wrong node version for that application" I confidently reply.

I looked like a super hero for remembering, when in fact all I did was look back through my external store of knowledge where I jot things down every day and regurgitate it. It helped in this case that the issue had a cool name in it (which is why I use this as my main example) but if it was something I had come across in my career, pretty much any relevant search term would work.

The value in keeping a work journal is huge, here's why.

It's not for you to read

It's tempting to think that a journal is for you to go back and read. In reality it's not, it's a searchable store of knowledge where one of the pieces of information is the date it happened on. Don't worry about making it interesting to read or feel like a story, it's a series of notes, events, error messages and solutions from your day that could be useful in the future.

It's a database

It's really a database, a loosely structured, highly searchable database that enables the value of your developer experience to compound over time. The more you put into it the more valuable it becomes because of how bad our memories are. Each nugget of information makes connections to other morsels of information highlighting links you may have missed. Searching for .htaccess in my database brings up rewrite rules for old projects, reminds me of old projects I had forgotten about and highlights bits of tangential information that can unearth memories, like the terror of ftp'ing on to a live server and hot fixing a PHP bug without a git commit or line of yaml insight, good times!

It gives you confidence

We often forget how far we have come, we focus on our current point in space and time, rather than the line and trajectory we are on. Having a store of knowledge, no matter how disorganized and seemingly disparate, lets us see how far we have come, how many problems we have solved and struggles we have overcome.

As digital creators much of our work is invisible 🙁

When my wife sees a car from particularly high end sports car company drive past she is reminded of the work she put into that car's development, when my friend drives over certain bridges he can see the physical manifestation of his work.

I on the other hand don't see the database migrations or api rewrite that took months of my time at my first job. I can, however look at my journal and see the things I learned, techniques I mastered and best practices I applied during that work because I noted it all down.

Anything will do

Don't sweat the tool you use, text files work fine if you have a good way to search them. Notion is my favorite app of choice at the moment. Evernote was all the rage for a few years there and now Obsidian is the new king in town. So long as it's quick to jot something down, has good search and doesn't get in your way then it's good enough to get going with!

So, go forth and journal!!

1. Starting with "Dear Sirs/Madam"😩

When I hired people this would be a massive black mark against the candidate from the start. It shows they didn't even go to the About Us page on our website, they are just applying to as many roles as possible with no thought. I didn't expect applicants to only be applying to us but I did expect them to at least look at what we do and take a minute or two to find a name.

Many people say they can't find a name to address the application. This may have been valid 30 years ago but now there is always a name you can find, ring reception and ask, look on LinkedIn for someone in the hiring department or head of HR, heck put the CEO's name down if you need to, just something to show you have a clue who you're applying to.

2. Don't use LinkedIn Easy Apply 🤦‍♂️

I've written about this before, LinkedIn EasyApply is there to make LinkedIn look good, not to make you look good. It increases the "applications per listing" and so a company thinks they are getting good value for money when hiring through LinkedIn. In reality it makes it so quick for you, and everyone else, to apply with a generic CV, that the company is inundated and they simply delete half the applications at the start. If they can find a good candidate in 200 they can probably find one in just 100 and save 50% of the time!

3. Not tailoring your resume/CV 🤷‍♀️

Each application doesn't need to be a hand crafted work of art, this would take far too long, but each one should be tailored slightly to the role you are applying for. If it's more backend focussed move relevant bullet points up, maybe take out three of the five frontend examples and instead highlight that one time you worked on a CI/CD deployment pipeline instead. Little tweaks go a long way to helping the recruiter or hiring manager pattern match you to the job the vacancy they have.

4. Listing every job you've ever had 📜

No one wants to see every job you have had, especially if it's the surf shop at your local beach for 6 months after university. If you are really thin on the ground for experience then put those jobs in an "Other Employment" section and only highlight the parts of those roles that carry over to software development. Listing 12 roles is a waste of space that would be better spent highlighting a few great examples from your most relevant and recent roles or projects.

5. Not linking to your portfolio or Github ☠️

You spent all that time making these wonderful projects and then at the last minute, when they really matter, you pull the punch and drop the link from your CV. I get it, it's scary showing someone what you have made, but I would rather see someone shipped something simple and went through the process of finishing a project than nothing at all. Portfolio projects don't need to be innovative start up ideas, just your take on a todo list app is fine. Just show them you have shipped something once, ever.

6. Not highlighting where your skills match the job 🤯

This goes hand in hand with tailoring your resume/CV but is actually even easier. When I say highlight, I literally mean to highlight the technologies you have worked with, if you have written an app in SwiftUI or a backend in NodeJS then make that names pop slightly. This makes it easy for the hiring manager to pattern match you to the job and their required skills. It's all about making their life easier, so make things obvious.

7. Only applying if you 100% match the job spec 😢

Job ads are wish lists, very few people match them completely. If you wait until you match every requirement on a job advert your will never apply. Some people say you want to hit 80%, I personally believe 50% is fine to put an application in, especially if you are a career switcher and have experience in the industry or are a seasoned dev who likewise has industry relevant experience. So long as you don't lie, you can be confident that if they think you are a good fit they will hire you anyway, while you might not have worked in their specific database technology, it's not like your previous database knowledge is suddenly useless.

Summary

There you have it, the most common mistakes that are holding back your job search and preventing you from landing you first job or you next well earned step up the ladder 😀

To do that as a junior? For your first role? Impossible .... until COVID poured lighter fluid on the digital transformation that businesses have been laggardly working through over the past 25 years. Now everyone is remote, including junior developers, a role that actually really benefits from in person work.

So, how do you succeed in this new world being a remote junior developer? If you think back to my post Expectations on Junior Developers are not what you think you will understand that you're not expected to be a genius cranking out amazing code from the get go. In fact the expectation is often that your coding ability will be pretty low. It will be expected you can code simple solutions to simple isolated problems but after that your main priorities are to:

• That you will listen and learn
• That you will help where you can
• You are keen no matter the technology

Let's form a strategy to make sure you crush these goals and also make the most of your time as a junior.

Communication as a remote junior developer

Your team would rather hear from you on a regular basis than wonder what you're doing and have to come asking. We are taught from a young age though to not interrupt, you need to forget this. In remote work you will always feel like you are interrupting someone, because you likely are! You don't know what they are doing when you message or call them and you'll need to get comfortable with this otherwise you'll sit and stew on a problem for hours longer than you should.

So people know what you're up to you give very short status updates in the team group channel or if you have found something interesting in the last half a day then pop it as well. If you get your first ticket done then mention it in that same channel, also ask for code review at the same time. Basically tell people what you're up to.

This might seem overly communicative but it makes up for the chit chat in the kitchen or overheard conversations when in the office. When you share an office with people it's impossible to not get an idea of what everyone is doing and how they are getting on, that is all stripped away in remote work so replicating that with little messages here and there brings the context back in.

A good junior developer is inquisitive

You're going to be left to your own devices much more than in person working, so go exploring. You should have access to the company wiki (if not, ask for it) from day one. Spending time at the end of each day looking through it and asking a couple of questions will broaden your knowledge very quickly and get you used to reading documentation.

Go spelunking through the database. Run some select queries or browse through some documents by yourself. Data drives all applications and knowing what your company's data looks like, where it lives and how's its structured will enable you to form great questions when the time comes.

If you see something interesting then ask about it in the group chat. Even if you feel stupid asking the question it doesn't matter, it's all about learning and gathering information. Get into the mindset that you would rather look stupid than actually be stupid.

In fact say this to your team, tell them you may ask a lot of questions but it's because you want to learn and be as helpful as possible as soon as possible. So long as you are asking good questions they wont' mind.

Being a junior developer requires openness

Be open about your skill level, what you find challenging, what you find straight forward and what you have worked with before. Pretending you know something when you don't is a quick way to loose the trust of your team and start to feel isolated. In daily stand up talk about what you have accomplished but also what is holding you back, where you struggled and ask for suggestions on where to look to improve.

It is much easier in person for people to pick up the body language and vocal queues that you might not fully understand something and so you can be saved the embarrassment of outright saying you're confused. So you need to be proactive and clear in what you get and don't get.

Journalling your junior developer experience

I'm not a big one for keeping a daily journal about my feelings, however I am a big proponent of keeping a daily work journal about what I did, what problems I had, how I solved them and any interesting things I learned. It doesn't need to be anything fancy, mine is just a new notion page for each day in "YYYY-MM-DD DayName" format and a list of bullet points, screenshots, links and code snippets that I can refer back to.

This is to solidify your learning and give you something to go back to in the future when you remember something you once looked at but aren't quite sure. I also keep a note of the Jira tickets I work on each day to help when searching.

Dealing with barriers as a junior developer

Working remotely adds a barrier that none of us can get round, even sitting on an open Skype call when working all day (which I personally hate) can't make up for being in the same office as the rest of your team. Once you are settled in your career this is just another one of those minor work inconveniences that you navigate and handle, but as a junior this barrier can exacerbate all the fear and anxieties you have.

So be pro-active about reducing the impact of that barrier. Be a bit more interactive on Slack than you might otherwise like, be clear and open about what you are doing, ask questions that come off the back of your own research on the code base and find out what other developers are working on.

From DevOps and Infra-as-code to React and serverless, there is an enormous array of technologies to learn and master, with new ones being released all the time. So, how can I possibly say that there is one to learn that will make you forever employable?

What magical technology is so foundational and ubiquitous that it could possibly be considered valuable enough for a developer to learn to give employability security for life? This magical technology is old, it's older than Javascript, older than Python and basically the same age as C!

Is it a bird? Is it a plane?

Some say it's a programming language, others say it's not, but it meets the modern trend of being declarative and also being cross platform. It powers some of the largest websites in the world whilst also being light enough to run in little phone apps.

The technology I am talking about is SQL, which stands for Structured Query Language and is a relational database technology that has been, and will continue to be, a core foundational technology of the web. If you are a web developer who doesn't know SQL you need to bump it to the top of your "To Learn" list today.

It might not get the press that NoSQL does, it might not be as hot as MongoDB or ElasticSearch and it might feel a bit too much like IT and not Dev'ing, but SQL is pervasive and is much better at solving many problems still than NoSQL.

NoSQL is powerful and amazing. The schema-less design approach allows you to feel very free and unconstrained, however when you want to start managing relationships and keeping duplicated data in sync across many documents you start to feel the trade off for that write time freedom.

Want to grab related data in SQL? Well it's just a LEFT JOIN away

Where to learn SQL

You can start to learn basic SQL concepts and follow along with a Udemy course or searching for SQL on FreeCodeCamp.org however another good resource is the SQL murder mystery site:

• Walkthrough for beginners
• Interactive Book
• SQL Murder Mystery

Installing SQL

There are a number of free flavours of SQL like MySQL and PostgreSQL, either one is fine — people do have opinions on which is better, at this learning stage it really doesn't matter though.

You can get MySQL as part of a one click MAMP, WAMP or XAMPP installation, you can install them directly onto your system or you can run them in a Docker container if that's your preference.

Getting data for learning SQL

Database technologies can be hard to get really good at without some real data. Inserting small amounts of data in a tutorial like songs and albums is good for the basics but when you land in a job with a SQL database with 1,000 tables that is 15 years old you're going to find yourself wishing for more experience that that. Here are a couple:

• IMDB Database
• F1 Data

Summary

SQL might not be the new hotness but it's also not going anywhere, it is a manifestation of relational algebra and has been used to build much of the web.

The idea that if you write Javascript you should use NoSQL is nonsense. You should use the best database technology for the data needs your project has. Most large systems will use multiple database and storage technologies including both SQL and NoSQL. SQL has been around for 50 years now and its relevance is only growing, especially with the growing importance of Data Science.

So, when you are burnt out on learning your 15th Javascript frame work and want to work on something stable you will be very happy you have SQL to underpin your career and skills.

You will see this term a lot on job specs, to clarify it isn’t agile the adjective with a lowercase 'a', it is Agile the noun, the name of a specific way of working that is very common in software development. If you see a job that doesn’t mention it, it may instead mention Scrum. This is a more opinionated derivative of Agile with a few extra rules and specifics.

Agile is a whole industry, there are conferences, books and qualifications and you can make a whole career as an Agile Coach or in one of the specific roles laid out in Scrum. While being an expert in the topic isn't vital to an early career software developer having un understanding of the rough process and terminology is important. This is one of those scenarios where a bit of knowledge can go a long way and allow you to talk with more confidence in interviews and set you apart from other junior developers.

The Agile Manifesto

The Agile manifesto is short enough that I’m just going to note it down below:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

Individuals and interactions over processes and tools

Working software over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

What does the Agile Manifesto mean to a developer?

The simplest way I can summarize this is that teams of developers should aim to make the smallest amount of useful, functional software that provides value to a user, show it to them, get feedback and then improve or expand what they have made.

Rather than getting an enormous shopping list of features and then spending 18 months building it only to find that it’s not really what the user/customer wanted, we instead build little and often and get feedback so we can course correct as we go.

Scrum

Scrum goes further than this and defines:

• working in short blocks of time called sprints (often two weeks, but sometimes delightfully 3)
• that will tackle a fixed iteration of work
• having a review of the work at the end of the sprint to show users what was made
• regularly looking over a backlog of tasks
• and planning which ones to bring into the next sprint based on user needs and how much capacity the team has.
• Each piece of work is called a user story and a number is assigned to it during the planning sessions to indicate how complex the work will be to complete
• the numbers are called story points and follow the fibonacci sequence (1, 2, 3, 5, 8, 13, 21, ...). They follow the fibonacci sequence to limit the options that can be chosen and stop team members squabbling over whether something is a 6 or 7, pick 8 and move on.

That’s more than you’ll be expected to know in your first job, if you want to really get it then I suggest you read the Scrum guide, it’s delightfully short and quite interesting.

You will also often hear people say "as defined in the Scrum guide", if you've read it you will find realise that many of these people haven't read the guide. In fact much of what is in the bullets above isn't in the Scrum guide, it's just how people have taken the concepts and developed them over the years to become the industry norm.

• Crumby offices ✅
• Beige walls ✅
• Boring industry ✅
• PHP ✅
• No MacBooks ✅

Wrong, wrong, wrong, wrong and wrong.

Some of the most interesting work you can do as a developer is at "non-tech" companies, in established industries on an older tech stack, perhaps in PHP on industrial estate somewhere. Why? Because those businesses have enough legacy and foundation to generate interesting problems.

So, if the above aren't the signs of a toxic workplace, then what are?

Toxic workplace sign 1️⃣ Immovable deadlines

This shows that the company don't realise how hard it is to estimate technical work and has no appreciation of the ways that unforeseen complexity can delay a well run project no matter the quality of the dev team. This doesn't mean that there should be no deadlines, that would be absurd as well, but a business that can't be flexible and accommodate the unforeseen and either move the deadline or descope the work is not a healthy place to be. Often they will move deadlines for finance and marketing but not for technical work, if you see this - run! 🏃‍♀️

Toxic workplace sign 2️⃣ Feature lists decided without technical input

Product people are amazing, and good ones know that dev work is like an iceberg, the bit above the water that you can see (the UI) is likely less than 30% of the work. A bad product person will set features without this in mind and massively over burden a project, or block of work because "it's just clicking a button". Never mind that that button might kick off several parallel jobs, run deployments and spin up scalable infrastructure. If your product people aren't working hand in hand with your technical management and team then when it comes to crunch time it's going to hurt ... you.

Toxic workplace sign 3️⃣ Pressure to complete all work every sprint

Agile is about fast feedback, short blocks of work and getting a rough idea of a teams rate of delivery. Product managers who expect the sprint velocity (delivery rate) to go up each sprint "because you are getting more accustomed to the code base" are really just forcing you to work harder and faster so that they can look good. Some sprints your team might deliver 80 points and other 65, the second sprint isn't a failure, its a reflection that no matter how much Agile coaches try to make dev work like a factory production line, it isn't.

Toxic workplace sign 4️⃣ Pair programming is banned

True pair programming, where two devs work on the same feature and deliver it together is great for onboarding, up-skilling and increasing organisational knowhow. It can be slower in the short term but, occasional to regular pairing is a good example of "go slow to go fast" because in the long run the overall level of the team is higher and they can operate quicker. Banning this for short term gain is a sign of misaligned priorities in the company.

Toxic workplace sign 5️⃣ Pressure to skip tests and QA processes

This is the ultimate symptom of a broken system and team, I've been here and it’s horrible. Pressure to deliver is so hight that things that sound like they're "not adding customer value" get pushed to the wayside. This is another example of short term gain for masses of long term loss and eventually drowning in tech debt. As a developer it is your responsibility to test what you wrote and know it works, the work isn't done until it's tested.

Seriously, don’t apply to companies who think the rubbish I just wrote. Or that copy the hiring practices of those companies because they think it's what they should do.

The truth is that very few tech companies need the level of technical perfection that they think they need. The reason they find it “so hard to hire good talent” is because they have multiple rounds of interview that absorb hours of your personal time and brain space requiring you to solve puzzles and do backflips all while dealing with the stress of an interview and where one miss-step blacklists you!

So stop applying to these companies, it’s a waste of everyone’s time.

Big Tech Broke Tech Hiring

The tech hiring process is broken because Big Tech broke it:

• take home tests
• technical deep dives
• presentations
• pair programming sessions (that are really just more technical tests in disguise)
• and follow up call after follow up call

"But that's what companies need to do!" I hear you cry! How else will they find the right people?

Well, I’ve been through 11 interview processes in the last 2 years, receiving 10 job offers, and only one required me to do more than 3 rounds. Some, including my current role at an EduTech startup, didn't require a coding test at all.

The one long interview process I went through was 5 rounds across 7 hours and ended with a follow up call from the recruiter where they said "it was a really tough call but your solution on test 4 wasn't as elegant as the interviewer would have liked" he did then chuckle and say that the final interviewer asked if they had seen the same candidate because I "smashed it" and "I think this will be our loss".

If after 7 hours of tests a role isn't offered simply because in 60 minutes someone couldn't write Conway's Game Of Life as elegantly as possible but everyone else thought they were a good fit for the role then the problem isn't "lack of tech talent", it's their hiring processes.

What's the developer hiring process alternative?

The reason only one required me to go through more than 3 rounds is because I actively avoid applying to places that require more than 3. I made an exception in this case because I have used the company's product a lot and have a genuine affinity for it. Otherwise I wouldn't have bothered.

Multi stage interview processes where one person can kill your chance of getting the job are a waste of your time. Stop playing their game and start applying to companies who actually understand that not every developer on staff needs 20 years experience and a PhD in Computer Engineering from Stanford, and instead realise that people come from a variety of backgrounds, with a range of skills and most of what you do each day can be learned on the job as and when required.

Find that local digital agency who struggle to find developers and want to grow their client base. Or, that regional e-commerce retailer with a home grown order management system that they need modernised who will appreciate you and your time.

Most developers never work in big tech. Not working for Apple or Facebook or Google isn't a bug, in fact it could be considered a feature for many companies. You can have a wonderful, interesting and fruitful career without being bounced from pillar to post going through the hoops that jumped up Big Tech bros put up for you.

Ask how many rounds of interview there will be at the start, if it's more than 3 and they're not paying you for your time then "regretfully pass on their process" and move on. If we all stop playing their stupid game, they will have to adapt.

• A basic understanding of how the internet works and HTTP requests (GET, POST, PUT, PATCH and DELETE) and the basic response codes (200, 404, 500)
  • httpstatuses.com
  • What is a URL?
  • HTTP request methods
• HTML - W3Schools HTML
• CSS - W3Schools CSS
• A CSS frameworks like Tailwind or Bootstrap
• JavaScript - W3Schools JS - yes just one language, it’s the only viable option for frontend so just use it on the backend as well.
• Package manager like npm - @allthecode npm overview
• NodeJS - W3Schools NodeJS and ExpressJS
• React
• React Component library like MaterialUI
• Git version control - W3Schools Git
• Know enough about security to know that you don’t know enough about security (CORS, HTTPS, Content Security Policy) - Web Dev Security Basics
• A database technology (pick a or b)
  1. a) MySQL is a great started RDBMS - W3Schools SQL
  2. b) MongoDB is the primary NoSQL database technology - University Mongodb
• How to make a REST API in NodeJS and Express
• Docker and containerization - this is a more advanced topic however having an awareness of Docker and the basics of a Docker file would be a big ✅
• Awareness of testing with Jest for Javascript.
• Understanding of Linux commands and some basic OS principles.

Absolutely required items are in bold.

Being full stack is not about being an expert in all of these, it is about knowing enough to get a system up and running, being able to search for the right things on Google and have a sensible conversation with someone who is an expert in their respective areas. You need to be a good, well rounded developer but you don’t need to be expert in every field!

DO WHAT YOU SAY YOU’RE GOING TO DO

Seriously, so many people don’t keep their word that just simply making sure you follow through and are reliable will put you head and shoulders above everyone else.

This sounds like obvious advice, surely everyone keeps their word? Well, take a moment and think about it ... how often have your broken your word? Not just to others but to yourself as well.

How many times did you set out to learn to code? How many times have you said you'll get up at 6 AM, only to change your mind at 6:01 AM? How many times have you said you'll follow up and email someone and just haven't? Eat healthier and then the next day eaten a family sized bag of Doritos?

We tend to think about "Our Word" as commitments to big and important stuff, like not cheating on our spouse or picking a parent up from the airport in mid-winter. But our word is pervasive, it is about all aspects in our life, from getting up when we say we will to updating a Jira ticket and completing a code review by the end of the day like we promised.

Think about how many times someone has broken their word to you. How did that make you feel? How did they manage the situation? Imagine if you NEVER broke yours?

You would almost certainly make less commitments but people would learn that when you say you will do something, it will get done. You become a person who can be relied on, who can be trusted and promoted above others.

If you know that something is going to slip, that you are going to have to break your word then it's your responsibility to tell the person relying on you. Propose a mitigation "I can't do that PR today but I have asked Brian to do it and he promises it will get done" or a new time frame "This work was bigger than I thought, I need another day, does that work for you? If not then we need to form a plan to fix this and make sure it doesn't happen again"

Give your word and mean it.

Own your word and protect it.

What if your word was iron? Sheeesh, then you’d be dangerous!

I have a secret to tell you, the expectations on junior developers is pretty low and that's because the job of being a developer is different from simply "knowing how to code".

• Communicating with none technical people
• Estimated how long something will take
• Learning the existing code base and data structures
• Working with git in a team
• Debugging live applications

All of these are core skills of being a developer that can really only be learned "on the job", with this being your first job no one expects you to know all these things.

So what do they expect from you?

1. That you can code simple solutions to simple problems. Don't get fancy, your code will likely not be the best structured and so 3 levels of ternary on one line isn't going to impress anyone if they can't understand it. Use simpler constructs with good variable and function names and focus on expressing your codes intention as clearly as possible.
2. That you will listen. You might come in with a few projects under your belt but in the grand scheme of things you just haven't been coding long enough to not be able to learn something from everyone on the team. Right now, the best thing you can do is learn about the code base, learn about the business needs and absorb as much as you can on all aspects of developer life. This also applies to feedback, don't be defensive about your code, accept code review comments and make changes as suggested.
3. That you are keen no matter the technology. Companies that have existing code will have a lot of different technologies across their IT estate. If you know React and server-less but get asked to work on some crusty old PHP and JQuery app then just dive in. Take it as an opportunity to learn something and increase your future employability. If you want a long fruitful career in tech then you will be changing language and technology often, at this stage working on older stuff is just as valuable as new stuff.
4. That you help. Don't just stick to your work and ignore what's going on around you. If a deployment has gone wrong, find out if you can help - it might just be monitoring a stream of logs but it's helping the team. If the database has gone down and customers are sending support requests faster than they can be closed, then see if you can help answer them. If someone is stuck, even if they are a senior, ask if they can explain it to you, often giving them someone to talk it though with leads to a solution due to the new perspective they gain.

Following these 4 tips will put you head and shoulders above many new developers and show you are in the career to develop both technically and as a professional.

Junior tech question of the topic of "Gatekeeping": 🌈🧙‍♂️

Sometimes there are people that behave in a Gatekeeping manner, for example:

A) Not passing the knowledge they possess
B) Believing that advanced stuff is just for a selected few

My solution 👇#TechNewbieTips

— Alegarciy 🇨🇷 SWE looking for internship (@alegarciy) July 30, 2021

Because...

Software development is a team sport

Unless you are flying solo like Marco Arment on Overcast or David Smith with his many wonderful apps, then chances are you will be working as part of a team. As is common in a team there are people with varying experience levels and skills. For the team to work at its best, knowledge needs to be shared.

Sadly, some team members choose to indulge in "Empire Building" where rather than share their skills and knowledge they would rather become vital. The hero. The only person with enough knowledge in certain areas that can fix issues.

These people don't like to share.

They were probably the kid in kindergarten who hid the red fire truck at the end of every recess so that only they got to play with it.

Gatekeepers are building their own cell

Before talking about how to avoid becoming a gate keeper I want to speculate on why some people so readily indulge in this behavior and why, from their point of view, it is reasonable.

You see, these people are terrified of being replaced.

They are scared that new people coming in will know more, work harder and cheaper than them, so they build a little empire of secrets and infrastructure that only they understand. They are protecting for downside risk and in doing so a reinforcing side effect kicks in that solidifies their belief that they are just a new hire away from obsolescence .... they never get promoted.

The reason they never get promoted is because they are made themselves too important in one area and are quite literally irreplaceable. The problem with being irreplaceable is that they are also un-promotable, so they fall into this toxic positive feedback loop where they feel more vulnerable to they hoard more which makes them less likely to be promoted reaffirming their fears. They have protected themselves from downside risk so well that they have entirely removed all upside risk, they trapped themselves.

They have become the gate keeper that @alegarciy talks about above.

How to not become a gatekeeper

While being un-fireable might sound great, the reality is less so, as highlighted. So, how do you avoid becoming so yourself?

1. Remember that a key part of being a senior developer is getting the most out of other members of the team, you should be a multiplying factor. A force for good. So get used to this from early on. Openly explain your code to other people, grab 10 minutes with someone during a piece of work and tell them what you're doing, ask for their thoughts. Get used to being open about your code.
2. Invite people from other teams to review your code. We all fall into the trap of inviting the same few people to review our pull requests. Break the pattern once in a while and add someone new to the mix. They will be exposed to more of what other teams are doing and you will get fresh input.
3. Write documentation. I know it's dull but it's vital for a healthy team and codebase. Docs increases organisational knowledge, reduces your inbound requests for help and improves your communication skills. It can even catch bugs because it forces you to look at your code from a new perspective.
4. Stay up to date. This doesn't mean doing 10 Udemy courses a year but at least keep abreast of new frameworks and carve out some time each year to try a new technology in work or as a side project. This will keep you employable and stop that fear of "being replaced" building up.

The trend here is transparency. If you are transparent and proud of your work you will beat back the negative, gate keeper tendencies that can build as you move through your career.

Let your code thrive in an open museum, not locked away in a private collection.

The truth is you need very little to start learning to code and become a developer, it is potentially the most accessible well paying career in history. Before we cover off the things you do need, let's look at the things you definitely don't need.

1. A degree. You thought this was just going to a be a silly list of gadgets didn't you? Nope, we are tackling the big stuff here. You really don't need a degree to learn to code, the demand for developers is so high at the moment that anyone from any background can learn to code and get a developer job if they have the right skills. Need proof? Just listen to every episode of the All The Code podcast to hear people say that demand is sky high!
2. Lots of money. With the obvious exception of having access to a computer and the internet you don't need much else. Enough money to be able to get by day to day and have food, shelter and power and you're good to go. Sadly this isn't a given for all of the world but, if you are here reading this then you probably pass the bar.
3. Lots of time. Eventually you are going to need a decent chunk of time to learn to code but, to get started and make significant gains you only need 15-30 minutes a day. Doesn't sound like much does it? I know, but if you multiply that out across a full year that is 91 to 182 hours. Imagine how much you can learn in that time. YouTube videos while the kettle boils, blog article when waiting for the bus, 10 minutes on CodeCademy at the end of the day. It all adds up!
4. To be good at maths. I'm not terrible at maths but I'm also not all that good at it, I can get by. Most programming tasks can be accomplished with simple arithmetic and decent logical thinking, it’s more important you can imagine a process or flow of information than it is that you can do partial differential equations (I certainly can't!)
5. Gadgets. Tech Instagram and YouTube is full of LEDs, mechanical keyboards, fancy mice, Apple stuff and fancy chairs. You don't need any of it to learn to code and change your life, all of that is a distraction to gain more attention on social media.

What do you need to start learning to code?

1. A modern-ish computer. You don't need a top of the line MacBook or Razer gaming machine, you need something with 4 or 8GB of RAM, a sensible storage drive (100GB+) and a processor released sometime in the last 5 years. If you are really tight on money then speak to your local repair shop, they might be able to put something together for you from spares. It doesn't need to be a laptop, if you go for a desktop then you will also need to factor in a monitor so don’t get fooled by the cheaper price.
2. An internet connection. You will need access to the internet to realistically learn to code. This wasn't the case in the past, and some purists may still argue this with me. Even if you can learn everything with sporadic internet access and books, you will still need to develop the skill of "Googling" at some point because it is key to a developers problem solving tool box.
3. A basic grasp of English. I have the huge privilege of being a native English speaker so I can't exactly say to what level you will need but, given the world’s most common programming languages use English based keywords it's a given you will need to know the meaning of at least those words.

That's it, everything else is a nice to have. I didn't even use a desk when I learned to code. I sat on a second hand sofa in a house that I couldn't afford to run the heating in, wrapped in two blankets on a 5 year old computer.

This of course is unrealistic and constantly pinging other developers on Slack, Zoom or in person is a quick way to “not make friends”. So, how can you ask the number of questions you need to without feeling like you are a burden on the team or worse, getting a black mark against your name?

There are a few rules I like to stick to before speaking to someone, these might sound like they will slow you down, and in the short term they will. In the long term you will learn more, ask better questions and move faster.

5 rules to check before asking a question

• Double check for simple typos: Go look at the git diff viewer that your text editor or IDE has so you can easily see what changes you have made since the last commit and see if you’ve missed a semicolon, miss-spelt a variable or something else simple.
• Go and read the project/repo Readme: If you missed a bit of config or setup then the answer could lie in there.
• Google any and all error messages: Find the last call in the stack trace that is from your code, copy that error and paste it into Google, most errors have been seen before and posted online. It might not exactly solve your issue but could get you close.
• Reread the task/ticker you have been given: This will remind you of your starting point and might make you rethink the approach that has lead you to this point, the main question here being “Am I even on the right path?”
• Check your input data: As the old saying goes “Garbage in, garbage out”. If you are working with bad data then your code won’t be able to operate correctly and could well explain why you are having problems.

Speak to a rubber duck

Ask a rubber duck?

It’s really not as silly as it sounds, many developers have one on their desk 🦆

If you have been through all of the above and still have no solution then it’s time to speak to a rubber duck before speaking to a person as a practise run. Tell the duck what you are trying to do and where you are stuck, often the answer will materialise in your mind as if the duck is an oracle. And if the answer still alludes you?

Still stuck?

If you are still stuck after doing all of the above and speaking to a duck then it’s time to find a team member to speak to. Unsurprisingly there are 5 rules to this as well, although just aim to follow at least one - doing all 5 every time is likely to bore people 😀

• Tell them what you tried: You should have already practiced this with the duck, basically just rattle through the 5 rules above in order. This shows you didn’t just give up at the first hurdle and lets them skip over some simple things to save time.
• Suggest something you might have missed: This is great for showing that while you are stuck you might have some idea of the direction you should go in, it could be as simple as “Is there some gap in my knowledge that is an obvious place to check next?” to as specific as “I notice this call to the ServiceAPI, is it possible the problem lies there?”
• Ask if they’ve seen something like this before: This is a quick and simple one and can jog their memory that yes, they saw this 6 months ago and that’s a good place to start.
• Ask if there are any docs that cover this area I can look at: This shows a willingness to carry on looking at this independently and that you aren’t just relying on them to do the work for you.
• Ask for a next step rather than a full solution: Sometimes people want to help you the whole way through but really you just need a next step. This again shows a willingness to take the burden of the work and not absorb too much of their time. It also helps your learning as too much help can sometimes make you brain switch off and information just washes over you.

Using the above rules and steps you will be able to ask as many questions as you like because your team will know you have covered off the basics and aren’t just looking for them to do the work for you

This sounds sensible, but it’s wrong. Too many applications is almost as bad as no applications.

Your Easy Apply application:

• will look like everyone else’s Easy Apply application, you won’t stand out at all.
• won’t be tailored to the role.
• could easily get caught in the “delete 50% of these because there are too many applications”.
• will trick you into thinking you are making lots of good applications because “LinkedIn made this feature, it must work and be great”.

In the case of a post with many vacancies, like Amazon warehouse operators then this could be a valid strategy, however for the roles we care about in software development, this is rarely the case, usually it’s one or two vacancies.

In this situation it’s more effective for everyone involved to have a small number of applicants who are all a great fit for the role, rather than 100s, many of whom are not suitable.

Why did LinkedIn make Easy Apply?

This is one of those classic cases where the incentives for LinkedIn, their users (you) and their customers (the hiring companies) don’t align:

1. LinkedIn want to show a customer that they got “great value for money” by getting lots of applicants.
2. Users want to apply to as few jobs as possible to get a job.
3. Companies want a small number of high quality applications.

It looks like the users and the companies have he most aligned incentives so why did LinkedIn make the feature?

LinkedIn made Easy Apply because they control the platform and they call the shots, they say “we’ll find you great candidates” the subtext they don’t say is that they will also find you hundreds of bad candidates by making it so easy to apply.

What you should do instead

Next time you find yourself hovering on Easy Apply, don’t!

Instead apply directly to the company with a slightly tailored CV/Resume that highlights where your skills and experience align with the job specification and cover email that does the same with a few sentences and a couple of bullet points highlighting the most relevant bits from your CV.

We even hear successful people talk about their mentors and the amazing influence they had on them.

If only you could find a mentor, right? You'd be set!

So, back to the original question:

How to find a coding mentor to help my career?

It sounds like a big ask doesn't in? Saying to someone:

"Hey, would you mind helping me progress in my career while I have nothing to offer in return?"

Well I have a secret to tell you.

You don't have to ask someone to be your mentor, you can just decide to be their mentee and start being mentored. It really is that simple.

What does a mentor do?

You see, a mentor is just someone you can ask questions to and get answers that will hopefully help you on your journey. Which, if you think about it, sounds an awful lot like a conversation where one person is a bit more experienced in one area than the other.

In fact, because of this one simple fact finding a mentor is so easy and simple I can sum it up with a Tweet:

The most important bit is that last bit, don't treat them like your personal problem solver and make sure you give back in some way: buy them a coffee, buy their book, send them flowers ... whatever, just something to show you appreciate them.

We have built up such an aura around this idea of a mentor that we forget that "getting a mentor" isn't a silver bullet for success anyway, they don't do the work for you, they don't magic away your obstacles, the simply offer informal guidance when asked.

How can I ask someone to be my mentor?

Is there someone in your life you have being trying to ask to be your mentor and you're stressing about how to ask them?

Well, don't ask them! You don't need to!

Pretend you did and they they said yes, and then skip to the questions you really want answered and start having a conversation from that point.

Heck, you could already have a mentor and not realise it!

There is so much jargon in the coding and software development world that it can be hard to even know what to call what you do!

So when are you a coder, a developer or an engineer? Is there any difference? If there is, does it matter? It comes down to where you are writing code.

Coder - Individual

• Knows one or more programming languages
• Solves problems with code
• Works independently
• Understands relevant infrastructure/systems for application deployments
• Uses version control
• Writes tests for personal confidence in codebase

Developer - Team member

• Works in a team
• Writes tests for team and business confidence in code base
• Understands and engages with Agile/project management principles
• Works with project owner/manager/customer/client at the feature level
• Cognisant of business needs and tradeoffs
• Writes documentation for current and future team members

Software Engineer - Broadest scope

• Designs overall architecture of a system
• Works closely with stake holders at the system level
• Implements working practices to maximize team delivery
• Makes far reaching technology decisions that has lasting impact for the code base

Neither is better than the other. These are all about the mode of work you find yourself in and all good developers will find themselves moving fluidly between the roles throughout the career.

In reality the difference is minimal and while you’re learning to code you shouldn’t worry about titles like this. There is no difference in the learning path between the them so stick to your plan and don’t be thrown off course because you think one might be different (or better) than the other.

Remember, every developer is a coder. So, learn to code, solve problems and build things.

• "What will my hours be?"
• "Can I use my own keyboard?"
• "Mac or PC?"

These are all valid questions, but are they good? If we're being honest ... no.

So, how do you come up with good questions?

Part of your preparation for an interview is to get at least three questions together that you can deploy when asked the above. The framework I use is:

• One question unique to the person you are talking to
• One that is unique to the company
• One that is quite generic

Let’s looks at an example set for AirBNB:

1. As a team lead at AirBNB how do you oversee workload and make sure that the team is delivering at a good pace whilst also being sustainable?
2. How has the recent IPO changed the culture in the company?
3. What would success look like in the first three months of this role?

Once you have the answers to these you can then finish up with "just a couple more quick ones" and ask about the hours, keyboard and flavour of hardware or whatever else you need to know.

Here are some more examples of developer interview questions I have used over the years:

1. What’s the feature lifecycle process? Is it primarily driven by user feedback or strategic road map or a mix of both? Who owns features and how does it move from concept through to release?
2. In the job description you have specified and ability to write concise code? What does this mean?
3. What does the process look like from committing my last line of code to it running in production?
4. What’s the balance of pair programming to individual coding?
5. If I wanted to propose a new way of working how would I go about bringing that the to team? is there a formal process?
6. Are you profitable yet? If not how long is your current runway and what are you doing to extend it?
7. What’s you approach to in-house development beyond just development skills? I’m self taught and will be coding all the time so I’m more concerned about making sure my soft skills develop successfully especially given the added problems of remote work.
8. If you use open source technologies do you have anything in place to give back to the community?

“What if I choose the wrong language?”

“What if it doesn’t do what I need it to?”

The truth is there is no wrong first language. You will hear strong voices in favor or against every language under the digital sun, most of them will have valid points however, all of them will miss one key thing.

Learning to program is different from learning a programming language.

Programming languages are a tool that enable you to learn how to write code and solve problems. Most languages share similar underlying concepts, so concepts learned with one will apply to most of the others.

You don’t want to hear me waffle on about ideological aspects of programming vs programming languages though, you want an answer!

Learn Javascript first.

It’s the only language that is natively supported in web browsers, it can run on servers, it can run locally on your computer and you can even build mobile applications for iOS and Android with it. At this point, Javascript is the universal language. So, as a starting point, it’s perfect.

Once you have a good understanding of Javascript you can then move on to other languages that are more specific, if you want.

Your first language is not your last language, no language is wrong but Javascript has the broadest application.

Great junior developer Solve Problems.

Not just solve them but find them and fix them.

You will find yourself speaking to lots of non-technical people in the business and all of them will have their own little bugbears about something in the app or the system that bothers them or doesn’t work. It could be tiny things like a list being ordered by date ascending rather than date descending, or a typo on one obscure button that they see a lot.

Write them all down, create a backlog item in your ticketing system and ask your manager if you can pull it into the next sprint as professional development work. Don’t tell the user you are working on it, just fix it, ship it and then let them know that it’s fixed.

Do this a few times and people will think you are a superstar because you are one!

If you don’t have any access to users then speak to your developer team and fix the little things that they hate but don’t have time to work on.

My favorite on that I did was reversing a list for someone, she had to scroll through years of deliveries multiple times per day so she could select the one she had just added. This wasn’t all that time-consuming but it was very annoying, I was able to fix this in about 10 minutes when I got back to my desk after meeting her for the first time and 3 days later it was released.

She was delighted.

This is 9 months of decent daily effort at about 2-3 hours most days. If your schedule means you can’t make that work then aim for a little bit every day. The daily consistency is more important than the raw amount.

The truth is that learning to code is a unique journey for everyone, it's not simply learning the syntax and knowing how to "speak" a programming language. It's a way of thinking, that comes very naturally to some and not so naturally to others. Part of learning to code is hooking up that wiring in your brain to think through how to break a problem down into small chunks and how to express those solutions in code.

Also, it takes time to learn something. You can't just force a concept into your brain and "know it", some annoying people can but they are very rare. How many times in school did we cram for a test, pass, and then forget it all a week later? That knowledge wasn't ever really set in our brains, we just held it long enough to repeat it under set conditions.

9 months is a realistic time frame regardless of the field you want to get into, be it app development, backend programming, frontend web development, embedded programming, or even the latest booming industry, data science.

So, how good will you be after 9 months?

You'll be ok, you'll be able to implement any solution in code, you'll still be Googling and searching Stackoverflow a lot but that's fine, I've been doing this for 13 years and I still Google and search Stackoverflow a lot. Your design patterns might be a bit iffy, your tests might be fragile (if you are even writing any) and you'll write some horribly slow spaghetti code at times but all those things will improve with time.

So, if you're sat thinking that learning to code is an impossible mountain that will take years to climb ... stop, pick a highly rated course on Udemy or anything on Freecodecamp.org and just start, do a few hours every day, and in 9 months you will know how to code.

How to get the most from those 9 months is a post for another day!

It could be writing a parts management app for a regional mechanic, reducing the checkout process from 4 steps to 2 for an e-commerce site, or making a Github action for your team that publishes to your Slack each time a build fails.

These are all quite big problems and you might be thinking “Simon, I’m new to programming, it would take me forever to make one of those!”

That’s fine, because really these are groupings of smaller problems, which are themselves groupings of smaller problems, until we get right the way down to the building blocks of our code.

Each line of code we write solves a little problem.

It is the smallest instruction required to accomplishes the task at hand so that the next line of code has what it needs to solve its part of the problem.

You see, code at its heart a set of very specific instructions that tell a computer how to solve a problem for a user. Having a good understanding of that problem is the key first step to building great software. Let’s take one of the above examples and break it down into some smaller chunks: writing a parts management app for a mechanics:

1. Some way for a garage to record that they have taken delivery of some parts
2. A place to record what stock each garage has
3. Some way for a mechanic to subtract 1 or more items from their locations total when they use a part
4. A method to correct the amount of stock a location has for loss, breakages, or prior human error
5. Some kind of warning system that tells the central purchasing manager that a location is down to the minimum number in stock
6. A way for the purchasing manager to request one location send stock to another location
7. Some method for the purchasing manager to place an order with the supplier

Suddenly this feels a whole lot more manageable doesn’t it? (The last problem sounds general enough we could probably hook into an existing service that already offers that kind of functionality)

To prove the point a bit more let’s take the first of those and drill in further: “Some way for a garage to record that they have taken delivery of some parts”. Let’s look at it as a user flow:

1. The user opens the delivery screen on the stock manager app
2. They tap a “Take delivery” button
3. They search for and select the item from the global list
4. They set the quantity
5. They select if it is a new order (maybe even enter the purchase order number), or if it’s from another store and select a transfer order number
6. They click save
7. They are asked to double-check and confirm the entry is correct
8. The app saves this to the central database

We’ll stop there but you can see that we are quickly breaking this problem down into smaller and smaller chunks without writing a line of code. Once you fully understand the solution to the problem you can present this back to users to make sure you’re correct and then start writing code making sure to get feedback from users at every step of the way.

When you find yourself in an interview and the question of “tell me about a time you solved a problem and tell me the approach you took” it’s this kind of answer they are looking for, breaking down a large problem into smaller and small chunks.

This is one of the many topics covered in the Coding Unicorn E-Book.

One final note:

Many of the small problems above are common to many, if not all software projects, so breaking your problem down and identifying the generic problems will allow you to find pre-made solutions that are industry standard, so you can focus on adding user value and not reinventing the wheel. Things like databases, UI frameworks,  libraries to make network requests are all common tasks and there is no point in writing that stuff yourself from scratch.