DEV Community: Simon Barker

The missing WeatherKit REST API Docs

Simon Barker — Fri, 10 Jun 2022 09:23:55 +0000

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.

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.

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(
    {
      subject: "APP ID", // the reverse URL App Id you made above
    },
    privateKey,
    {
      jwtid: "YOUR TEAM ID.YOUR APP ID", // you can find your TeamID in the top right corner of your developer account, then put a `.` and then put in your reverse URL App Id
      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": {
    "subject": "APP_ID",
    "iat": 1654823790,
    "exp": 1654827390,
    "iss": "TEAM_ID",
    "jti": "TEAM_ID.APP_ID"
  },
  "signature": "d98jNki1tXX3mSYOAPp-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.

<!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>Document</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>
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;
  });
  </script>
</html>

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

If you want to see this widget in action you can see it on this page on my site

If you're still learning to code and some, or all of this, doesn't make sense then head over to All The Code where I teach people how to be amazing web developers. Join my mailing list for a free coding quick start guide and weekly tip and advice.

How To Get A Job After Coding Bootcamp

Simon Barker — Tue, 19 Apr 2022 22:04:49 +0000

Congratulations you have completed your coding bootcamp. You've come a long way since you decided to learn to code all those months ago, you can now create a web or native app, solve complicated user interface issues and have even learned about this weird thing called Git!

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.

5 Best books for software developers

Simon Barker — Mon, 18 Apr 2022 13:37:32 +0000

The best books for software developers is a hard list two write, there are so many excellent books for software developers across so many domains that it's almost hard to find any bad books. That being said there are some clear standouts that people hold in very high regard and they are books that all software developers should read at least once, if not many times, in their career.

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 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 😄

How To Learn New Skills As A Developer: A Framework

Simon Barker — Thu, 10 Mar 2022 12:20:23 +0000

A conversation in my favourite developer Slack the other day inspired this post 😀

Learning new skills as a developer is a key skill to have, and while you are a junior developer it’s a great time to “learn how to learn” new skills. Learning skills like:

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.

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 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.

Get more developer career advice like this by joining my mailing list at Career Switch To Coding.

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

CodeNewbies: Don’t let your past determine your future

Simon Barker — Sat, 22 Jan 2022 13:08:10 +0000

We often feel a debt to our past selves. We stay on a path because it’s the path we’ve always been on and changing course makes us feel like our past self was wrong.

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.

You can see this and some comments on Instagram as well:

Become A Better Developer Today: Quick Wins

Simon Barker — Thu, 09 Sep 2021 20:01:53 +0000

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

Head over to Career Switch To Coding and join my mailing list for regular tips and a free chapter of my book 😀

5 Interviews, 7 hours: Lessons From Not Getting A Big Tech Job Offer

Simon Barker — Wed, 08 Sep 2021 17:35:05 +0000

Earlier this year I broke one of my rules and interviewed with a tech company you HAVE heard of, they aren't a FAANG but if the next tier down had an awkward acronym then they would be in that. I applied because I used this company's product daily for the better part of a decade and genuinely like it. It's well made, solves a huge pain point in the market and they have a loyal and growing user base.

I need to stress how much I like this company's product because I genuinely don't think applying for Big Tech is worth the time and effort (doubly so for non-traditional programmers like me) due to the number of rounds and the puzzle like coding tests they tend to use. I was making a big exception with this one.

1. The Application

I applied for a Senior Backend role, spent around 90 minutes on the initial application and then thought I would never hear back as, quite honestly, I didn't think I would cut the mustard on what they were looking for. I have a PhD in Electrical Engineering but I am a 100% self taught developer and they are big enough that "CS Degree" could easily be one of their initial filters. Given how the process went, they probably should, but more on that later.

Well, 24 hours after applying I had a request to book a coding test! To say I was excited is probably an understatement, I was grinning from ear to ear for the next day or so.

2. The Coding Test

The first coding test was very enjoyable. The problem was to make an algorithm where, given an array of numbers like:

[1,2,3,6,7,8,12,13]

I needed to produce a number of ranges to "describe" the series, so the above would be:

[[1,3],[6,8],[12,13]]

I initially didn't understand the requirements so I asked for it to be explained another way and the interviewer said "think of it like a compression algorithm" at which point it clicked.

I used a two pointer approach leaving one pointer looking at the start of the range and the other pointer traversing until the next number was greater than "the number I'm at + 1".

Had a fun chat at the end with the interviewer, asked about their deployment times, team make up and what their favourite thing about the company was.

Lesson: if you don't get the task on the first read ask for another interpretation rather than sweating and stewing on what you're supposed to do.

Overall: 9/10, would do again.

3. The Life Story

I was invited to the next stage a few days later and asked to arrange an hour to discuss my life and what brought me to this point. This was a non-technical discussion with an internal recruiter that was very enjoyable and overran by 10 minutes. I made two errors here that, while didn't damage my application I don't think, certainly made the interview more challenging.

I went to an odd but interesting 6th form college (last two years before university) and I started there, I planned to cover this in a couple of minutes and then move on. The problem was that this was 17 years ago and the interviewer got very interested in it. I spent nearly 10 minutes covering off the period of my life between 16 to 18 and immediately left me feeling pressed for time and added some stress.
Due to the above I then rushed some later sections and didn't really do them justice when those sections were far more relevant.

Lesson: Leave space for the recruiter to derail you, stick to relevant times in your life initially and if time allows reveal less relevant parts later on.

Overall: 7/10, would do again but would plan less content.

4. Technical Conversation

I was invited to the next 3 stages in one go, blocking out a whole afternoon for 3 calls. The first was a technical chat with a principal engineer about a project of my choosing.

I felt like this went well however this was the first time I made a real misstep that I was later told contributed to me not getting the role. I am a talker, I can often get on a bit of a roll and not leave enough opportunity for others to interject, apparently I did this in this interview and the interviewer felt I lacked some self-awareness.

Wether I agree is somewhat irrelevant since it was how they felt and I am aware enough of my personality to know I do this sometimes. In person it is much easier for me to pick up on the body language that indicates someone else wants to talk, on a video call when sharing my screen this is all but impossible for me.

Lesson: Leave intentional breaks to allow the interviewer to interject and ask questions.

Suggestion for interviewer: Don't raise your standing desk and awkwardly track you head up at the same time just after asking your first main question, it's incredibly distracting.

Overall: 7/10, it was an enjoyable experience and it was fun to talk about what I had spent the last 8 months working on.

5. Coding test 2

This. Went. Badly.

This interview is why I didn't get the job, I knew it half way through and my experience in this interview is why I just don't think self taught devs should apply to Big Tech unless you are prepared to waste a lot of time.

This was a "Pair Programming" test, in reality it was a coding test just like the first round and I was asked to implement Conway's Game of Life.

In speaking to lots of people afterwards this is apparently a common task to be set on degrees and in coding bootcamps, I had never even heard of it, let alone solved it before. I was also told by a number of that they thought it was "a bit harsh" to ask in an interview. I don't really have an opinion, I trust the interview knows what they are looking for.

I stumbled my way to a solution in 50 minutes, went down two dead ends, didn't understand a suggestion from the interviewer and generally wasn't proud of the code I had written.

When asked what else I would do at the end of this I said:

"I would significantly restructure this code, given that this is a solved problem I would research the best solution and implement it that way to get the best result".

The follow up question was "if this wasn't a known problem with a solution what would you do if this were a work task" I said I would speak to my team to see if they had seen something similar and have someone review where I had gotten to and make suggestions.

Apparently this answer didn't make up for the code I had written as the feedback I was given was "Inelegant solution and poorly structured code" 🤷‍♂️ I will come back to this line at the end ....

Lesson: try to cover off as many of the potential interview puzzles ahead of time so you are reimplementing a solution rather than solving it for the first time.

Overall: 1/10 I really didn't enjoy this interview.

6. Final Coding Test

After a 20 minute break I had one more round to go. It never even crossed my mind to back out but my brain was fried and I was not feeling confident.

This interview was to implement and LRU Cache. I hadn't come across this before either but this is the kind of programming that is right up my alley. A known set of requirements, a tangible problem to be solved and a clear outcome.

I really enjoyed this test, it actually did almost feel like pair programming as well. The interviewer was very friendly, we had some side chat about Swift (even though I was testing in JS) and their experience with it which helped ease me back into a relaxed coding mode.

I was told in feedback that the solution I chose was their least favourite approach however that was fine because I discussed all of my reasons, the trades offs I knew I was making and why they were probably ok given the end use case.

I was also told that in response to the previous interviewers line of "Inelegant solution and poorly structured code" this interviewer said "Did we interview the same candidate?" which is nice.

Lesson: never quit a process until it's over, if I had walked away after the previous interview I wouldn't have experienced this one, I would have had a sour taste in my mouth over the whole thing and I would have missed out on an hour and a bit with an awesome person who I thoroughly enjoyed my time with.

Overall: 10/10 would chat with again just for fun.

Feedback

After 5 days I got an email to say I was unsuccessful and that I could have a 15 minute chat if I liked to hear why.

I have weaved that feedback into the above narrative and it was very welcome. At the start of the call the recruiter asked if I had any ideas on why I didn't get an offer and I said "Conway's Game of Life" with a grin on my face, they chuckled (nicely) and said "yeah, pretty much".

They they also told me about talking too long in the technical conversation which was extra useful information.

Summary

Overall I am glad I went through this process however, I don't intend to apply to a company with a lengthy interview process again. This took up 7 hours of my time and, while the process was managed well, the people were nice and I gained some experience, I still ultimately fell down on a puzzle that if I had a CS degree I would probably have come across before.

Outside of this I've had 10 job offers in the past 2 years off the back of 2 to 3 round interview processes so it is totally possible to get job offers without the hoops described above.

If you want more of this sign up to my mailing list at Career Switch To Coding

Could #buildInPublic Get You A Job?

Simon Barker — Tue, 07 Sep 2021 14:34:06 +0000

#buildInPublic is all the rage at the moment in the IndieHackers scene and I think it is a great thing for new developers looking for a job to do as well. Basically keep your side project code in a public GitHub repo and tell people about it. Talk about what you are making, the choices you made and what you are finding tricky.

This idea is probably mortifying to you, that’s ok. Putting our code out into the world is scary, you will make mistakes and have some questionable design decisions BUT, it will give you one thing that is vital when you are coding in a job and that is the experience of knowing other people can, and will, view your code.

In any good software team, your code will be reviewed by a team member before it is merged into the main codebase. This is an opportunity to catch mistakes, make sure one other person knows what you are doing and for them to make constructive comments on how to improve it.

Coding in public means you can ask other people to look at your code to simulate this- ask other coders on Reddit, Instagram, Slack/Discord, StackExchange etc. if they can take a look. Start with a small specific function and if you build a rapport you can ask them to look wider at the repo. Don’t expect masses of depth but even 5 minutes of a senior developer looking at your code can really improve your skills.

Getting used to this sooner rather than later ticks this off and makes it a complete non issue at the interview. I have been asked a number of times, “a team member has made a suggestion on your code, how would you handle this?” If you have had your code in public for a while you will have this question sorted and won’t be phased by it.

If you want more like this go sign up to the CareerSwitchToCoding.com mailing list and get a free chapter of my book 😀

6 Tips To Beat The Take Home Coding Test

Simon Barker — Mon, 06 Sep 2021 17:09:05 +0000

Take home coding tests are seen by many as the ideal alternative to stressful in person live tests. While that may be true to a certain extent, it doesn't mean that there aren't pitfalls to be wary of, here are my 6 top tips for making sure you crack your next take home test:

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.
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.
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.
Ideally host it as a Github repo and send them the link to it. Emailing projects with many files zipped up can be flaky.
Flag best practice breaches. 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.
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 your next take home test.

If you want more like this head over to CareerSwitchToCoding.com and sign up to the mailing list for a free chapter from my book 😀

"Smallest Unit of Learning": Dealing with the ever expanding world of development

Simon Barker — Sun, 05 Sep 2021 17:09:04 +0000

There is so much to learn and know in software development that it can be overwhelming. When you first set out to learn it's like you're a child in the middle of a huge field full of toys that you know are amazing but have no idea how to play with, or what they even do.

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.

Stop! Put Down That Ternary, Lines Are Free

Simon Barker — Sat, 04 Sep 2021 08:20:49 +0000

Variable Names

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

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?

Update

As some awesome people have highlighted in the comments below, I got this code wrong and the ternary to if/else is wrong. I wrong this code specifically for the article, didn't test it properly and only thought about one of the variables was true, in which case a switch statement on an enum would have been better. I still stand by multi-level ternaries being worse than a correct if/else equivalent however in this case I choose a poor example.

30 Developer Portfolio Project Ideas

Simon Barker — Fri, 03 Sep 2021 16:30:26 +0000

It's hard to know what projects to make when trying to flesh out your portfolio, often we get caught up thinking it needs to be something unique. Projects need to be small, complete and functional, making your own take on any of these well trodden paths would be a great project for your portfolio. Each idea has a suggested rough tech stack you could use but in reality you could make all of these in pretty much any technology.

Straw Poll Web App - React, NestJS
Pokedex - Angular, PokeApi.co
Weather App - SwiftUI, openweathermap.org/api
Tweet Scheduler - JS/HTML/CSS and Supabase
Workout creator- Kotlin, Android
Timer Web App - React
Reminders text message - Vue, Twilio
Crypto Tracker - Angular, ExpressJS
Chat Web App - React, socket.io, NestJS
File Uploader Plugin - Angular, Ruby
IMDB Ratings Scraper - HTML/CSS, Python
Egg Timer - HTML/CSS, JS, CapacitorJS
Meme Maker - UIKit, Swift
Colour Picker App from Camera - Flutter, Dart
Tax Calculator - Angular
Slack Plugin - JS
Shopify Theme - NodeJS, React, GraphQL
Wordpress Plugin - HTML/CSS, JS, PHP
Instagram Post Maker - Kotlin, Android
Todo List CLI App - Python
Notes App - UIKit, AppKit
Flash Card App - SwiftUI
GitHub Timeline - Vue
Conway's Game Of Life - HTML/CSS, JS
Expenses Tracker - React, Electron
Currency Converter - React
Clone an App - same tech
URL Shortener - HTML/CSS, JS, Lavarel
Mine Sweeper - PhaserJS
Habit Tracker - Swift, UIKIt