Forem: Jamees Bedford

How to Get Out of Tutorial Hell: Be more like Tony Hawk!

Jamees Bedford — Fri, 05 Feb 2021 08:00:01 +0000

When learning to code, many of you will experience something that I call 'the tutorial loop' or 'tutorial hell'. It was something that plagued my learning for a while - in fact I would consider not resolving this sooner was one of the biggest mistakes I made whilst learning web development. This article is my thoughts on how one should attempt to break away from this loop, why this is immensely bad for your learning, and then some of the strategies I used to learn more effectively.

The Tutorial Loop is the never ending cycle you may find yourself in when learning to code, where you watch tutorial after tutorial but never leave them with any working knowledge of the technology it is teaching. This prompts the developer to typically label the course as useless, and then find another one that may contain the 'secret sauce' to gaining superior programming knowledge.

It's a frustrating place to be in. You code along to the video, building out the same application as the teacher, and it leaves you feeling with a sense of accomplishment and pride, but ultimately this course has not really left you with any real world skills. In fact, all it has done has taught you how to code along to someone else.

There is a reason for this. You are not making any decisions or figuring things out for yourself.

When I was eleven or twelve, I got a Tony Hawk "Learn to Skate" video. I watched it for hours, soaking up every single word that Tony said. One of the main things I was interested in was how to "Drop in", a fundamental tricks any skateboarder would have to master, which is being able to roll down a quarter pipe ramp.

It's a hard trick for a beginner, because due to the nature of it, if you mess it up it has a large consequence. If you get overconfident and lean too far forward, you will fall flat on your face. Not confident enough, the skateboard will fly out from underneath you and backwards you go.

When I got to the skate ramp for the first time, I was so full of confidence due to having soaked up this knowledge from the man himself that there was absolutely no way I could fail. His words rung in my ears as I hovered over the drop, I leaned forwards and BAM, I slammed against the concrete. No major injuries, just a big dent in my pride.

Whilst listening to someone talk about how to do a certain task builds us with confidence and makes us think we can accomplish the skill being discussed, actually it requires practice. Repeating the same action, over and over again, practice after practice.

A typical 'Learn to Code' tutorial will usually have a 'code-along' video, or will build a final project. We see the final app in the tutorial, and we may even have recreated it ourselves by writing the code as it is taught to us. But what we didn't see is the hours the teacher put into to getting that application working in the first place, working through the design process, all the initial thinking as to exactly how this app is going to come together, all the bugs and errors they encountered along the way. They are showing you the polished, complete project rather than the process the took to getting there. Not to mention, the hours and hours of learning they have put in to get to a level of ability where they can comfortably teach a topic.

Much like Tony Hawk is able to nail his tricks and his How To video was perfect, we didn't see the hours and hours he had dedicated to learning these tricks, falling off and getting back up time and time again. The real learning to be had is in the process of figuring the hard bits out for ourself. And of course, failing, but consistently trying again.

It is important, that as a new software engineer, that you understand that this is the case and that learning to code is a long process. In fact, the sooner you realise that only relying on watching other people code the apps you want to be making is not the best way to learn, in your journey the better.

In Robert Greene's 'Mastery', he talks about how we each have the capability to go on to become a master in our craft, as long as we approach it in the right way:

"We enter a new field with excitement, but also fear about how much there is to learn ahead of us. The greatest danger here is boredom, impatience, fear, and confusion. Once we stop observing and learning, the process towards mastery comes to a halt."

As a new developer, we crave output. We enjoy going through a tutorial, coding along to the instructor because usually we will have an app or a project to show for it at the end. We feel fulfilled. Making slow progress on our own is boring and frustrating, but to become a master at any skill we must accept that boredom is part and parcel with the package. We can embrace boredom and choose to practice effectively!

They say to learn a spoken language, the best thing you can do is to go to a country that speaks it and practice it. In my opinion, a programming language is exactly the same. Pick through codebases that already exist, pull things apart, fix bugs in open source projects, create new projects. Anything that is requiring you to think and grow your knowledge. You need to figure out how to solve problems and overcome issues that you don't know the answer to. Use this experience to get good at finding out the answers yourself, by Googling/Stack Overflowing and reading documentation.

I'm not in this instance saying that you should avoid all tutorials, quite the contrary. Tutorials are really useful learning resources and are a great start to learning a new piece of tech, however, a 'start' is all they are.

Tony Hawk didn't learn to skate by watching other people skating.. and you shouldn't learn to program by watching others code.

Gatsby vs Next.js in 2021 - What, why and when?

Jamees Bedford — Fri, 22 Jan 2021 13:28:34 +0000

In 2019 I decided to write a post called "Gatsby vs Next.js - What, why and when?" out of frustration for the lack of resources that could summarise which of these React frameworks was best to use for what situations. I remember looking at both of these tools early on, trying to read articles considering the pros and cons and thinking "Ok cool, but I don't know what getInitialProps is or does". "What benefit does GraphQL bring to me?". I was sure many were feeling the same.

My approach was fairly jargon free, and I think because of this it has been my most viewed article.. well, ever.

It still is shared fairly regularly on Twitter, and it has just amassed over 76000 views on DEV.to (where I originally posted it). However, in true Javascript fashion, pretty much as soon as I released the article, it became outdated.

So. A year and a bit on, now that both Gatsby and Next are more mature, I am going to tackle it again, but update it for 2021. Still as jargon free as humanly possible. I hope you enjoy!

The Similarities - Why compare?

Firstly, I will go back to the basics. Gatsby and Next.js are both frameworks for React, which unless you have been living under a rock, is a Javascript library for building interfaces.
Not much has changed in this respect, so as I mentioned in my first article:

Both Gatsby and Next exist to lay the foundations of a React app, and offer you a guided way to build your application. What you are probably using to create a React app now is the boilerplate, create-react-app, which creates you all the basic functionality and tooling. In comparison, these two frameworks will lay the foundations for you to create an application - they are not classed as boilerplates, but toolkits, laying not only the foundations and then giving you a set of instructions on how to build the house well, with a well stocked toolbag full of the right tools.

To summarise:

create-react-app - Lays the foundations of a React Project. The rest is up to you.
Gatsby & Next - Lay the foundations of a React Project. Give you guidelines on how you should build on top of them as well as a set of tools.

And yes, still the same as 2019, they are both fairly similar, in that they each:

Provide a boilerplate application.
Generate incredibly performant, accessible and SEO friendly websites.
Create Single Page Applications out-of-the-box.
Have a really awesome developer experience.

Server Side Rendered vs Statically Generated

In the first article I started off describing the difference between 'Server Side Rendered' (SSR) and 'Statically Generated' (SSG) websites, the reason being because Next allowed you to only build server-side rendered pages, whilst Gatsby is a static site generator.

At time of writing, Gatsby generated pure HTML/CSS/JS at build time and was serverless. Whereas, Next created HTML/CSS/JS at run time, so each time a new request comes in, it created a new HTML page from the server.

But, alas, that has changed!

As of Next.js release 9.3, you can now choose how you pre-render your pages - using either Static generation or Server Side Rendering. Read more about it on the official Next docs --> https://nextjs.org/docs/basic-features/pages#pre-rendering.

This changes things, because arguably alongside the methods for data fetching (which I will get on to) this was the biggest difference between the two tools. In fact, I stated in the last article that if you had a smaller website it made sense to use Gatsby (SSG) and if you had a larger scale application with lots of content go for Next (SSR). But that is just not the case anymore.

So, the best way to approach the rest of the article, is to go into more detail about what each framework does well, and what it doesn't.

What Does Gatsby Do Well?

GraphQL

When building websites in Gatsby, you gain access to your data through a query language named GraphQL. Created originally by Facebook in 2012, GraphQL was used internally for the companies mobile applications. The benefit of GraphQL is that by nature, it allows specific data-fetching and Facebook found this useful to reduce network usage.

A GraphQL server, provides the Front-End with a pre-defined 'schema', which allows the client side to extract only the relevant information and the fields you want to query, rather than the alternative REST which hands the client all the data, relevant or not, from the API. This is more labour intensive.

An example of a GraphQL query is below:

{
  site {
    siteMetadata {
      title
    }
  }
}

It returns this:

{
  "site": {
    "siteMetadata": {
      "title": "Jamees' Shitty Website"
    }
  }
}

As you see, I have only specificed that I want title from siteMetadata when in fact the siteMetadata object contains a lot more information. You are able to specifiy exactly what piece of information you are after.

There are obvious benefits to GraphQL as a query language, it is gaining popularity across various applications. It is nice that Gatsby has this and makes it relatively easy to get up to speed with this tech.

The Plugins

In my mind, the coolest thing about Gatsby is its vast ecosystem of 'plugins'. - https://www.gatsbyjs.com/plugins
They are pre-made Node.js packages that allow you to plug pre-built functionality into your website. Essentially, its code that other developers have written that accomplish certain things.

Say for instance I wanted to display my Instagram feed on my website and show everyone my awesome desk and delicious plates of food I have been eating. Theres a plugin for that! The complexity would have already been worked out, and it is as simple as installing the plugin and putting it in the config for my site. I never have to visit the Instagram documentation and generate API keys and secrets, which saves time. Oh, so much time. And complexity of course!

This is cool because it allows even the greenest of developers to get up and running with a site that actually achieves things. I always say, the best way to learn is to build, and being able to get something up and running quickly is really rewarding.

Themes and Starters

As well as a large ecosystem of plugins, Gatsby has a vast amount of 'Starters' and 'Themes' that the community have created.

These are pre-built sites that developers have already created, in some cases styled and added functionality to with plugins. So, if I wanted to create a shop, then I would find a relevant starter or theme that had the required functionality - a cart, a link to Stripe etc. It is, again, really cool, and is something that I have used a lot, not so much professionally but for hacking around and seeing how things work.

What Doesn't Gatsby Do Well?

Arguably, Gatsby's greatest strengths are also its greatest flaws.

The fact that it is so opinionated on how you should be fetching your data, and the fact it focuses to intensely on the plugin ecosystem means that it is often hard to diverge from these.

Whilst the plugins get the developer up to a working app quickly, it becomes a repetitive task of installing the same plugins to set up even base functionality. Of course, you could build your own starter, but even then it is an element of complexity that you don't have with other tools.

Often I have found myself wanting to create something there is not a plugin already existing for. Having to create a plugin from scratch to cope with potentially a niche functionality that would be a quick thing to implement in a non-Gatsby app is made more complex. The developer ends up having to poke around in the gatsby-node.js file and create a custom Webpack config and it just doesn't feel intuitive.

Also - GraphQL... Whilst it is undeniably neat, one of the main purposes is lost in this case. As I mentioned earlier in the article, GraphQL is there to cure over-fetching, but Gatsby's bread and butter is Static Sites, which means that fetching all of the data from the API's will cause no extensions to runtime, it would take marginally longer at build time granted, but for flexibility that seems a worthwhile trade.

I made the statement in my last article that Gatsby is better for smaller applications, because if you have a massive amount of data you are going to want to potentially implement Server Side Rendering. GraphQL in that case, is almost like cracking a nut with a sledgehammer (in my own humble opinion).

Thankfully - Gatsby have realised this, and have published in their docs a page on 'Using Gatsby without GraphQL'. But this solution is a work around and they try very hard to convince you of the 'tradeoffs' of not using their data layer.

And whilst this doesn't necessarily affect the tool, there has been a handful of controversy around how some of the senior members of the Gatsby team treat their contractors. It kicked up so much mess that the team had to write an open letter to the community apologising - https://www.gatsbyjs.com/blog/open-letter-to-gatsby-community/.

Whilst a touching gesture, it glossed over many of the problems that were being spoken about in the community. The community was also a really big deal for Gatsby in the early days, where if you made a contribution in some way to the codebase you would be invited to the community, as a member on their GitHub page and be awarded with Gatsby flavoured swag. The Gatsby team would do knowledge shares and listen to what the software engineers using the tool actually wanted. Its not scalable, I know, but closing that down was a bit disappointing and it certainly leave a sour taste knowing that a handful of their staff were left unhappy from the working conditions.

What Does Next.js Do Well?

Flexibility

The main argument for Next this time last year was the fact it was flexible. It didn't force the developer into an ecosystem of plugins and GraphQL. Making Next.js able to Pre-render pages at build time (SSG) or request time (SSR) in a single project and give the developer to choose one or the other and switch between the two is a huge gain for flexibility.

Chances are your project is likely to change over time. You might want to add complexity that you hadn't considered before - and you think that SSR would be the best way of doing it. Thats all good :) That wouldn't be possible in Gatsby, so taking scalability into consideration when starting a project and going with the more flexible solution makes a lot of sense if there is any chance the project could scale.

The SSG functionality is really good!

On hearing that Statically Generated Sites were going to be a feature that the Next team were working on, I was initially worried. This was a step away from what they started with, however arguably the SSG functionality is way better than the SSR functionality ever was.

Working with the filesystem routing is a dream (something that Next did even when they were SSR focused) and there is no GraphQL in sight (unless you want it there of course!). If you export an async function called getStaticProps from a page, Next.js will pre-render this page at build time using the props returned by getStaticProps. There is even a feature called 'Incremental Static Generation' which means you can register new static pages at run time. Everything is just really well thought out, and they haven't forgotten about those who were using the tool for SSR before this new functionality was added.

Developer Experience

The Next.js docs are probably some of the best I have ever read anywhere. Getting up to speed is quick and easy, they have also included a section that relies on gamification (collecting points as you progress through the How-To guides by answering quiz questions and completing tasks), which is an excellent addition for people of all ability levels. I would love to see other projects include such focus on getting people up to speed!

The improvements of pain points from the team at Vercel is aggressive. If you mention you are stuck on something on Twitter, you can be pretty certain that one of the team will drop in and offer a solution. Its so nice to feel heard. Many of the larger issues that crop up on Twitter or elsewhere within the community are automatically created as Tickets.

The Vercel platform is awesome.

At the time of writing the first article, the company behind Next.JS were called 'Zeit'. They had a number of different products - Now, Next and Hyper where the most popular.
They have undergone a name change and have focused their platform more around deployments and streamlining that process for engineers and engineering teams alike. I have been blown away by the platform itself.

The part of it that first blew my mind was the one-click domain assigning. With a click of a button it took care of everything for me, and removed a process I usually hate. The more I have used the platform, the more I am impressed. Deploying is easy, the analytics they offer to see your projects is incredible. Everything is just so polished and user friendly.

Whilst not necessarily a part of 'Next.js' specifically, Vercel also has an array of 'serverless functions', pieces of backend code that are deployable to your project. These snippets take an HTTP request and provide a response, allowing you to plug and play extra functionality into your frontend codebase. There are functions that handle logic, from user authentication, form submission, database queries, custom slack commands as well as more.

In conjunction with Next.js this is a dream package for a Front End developer. I have moved the majority of my projects across from Netlify (which is equally as awesome), so I could use one 'ecosystem', so to speak, to handle every bit of my development process.

What Doesn't Next.js Do Well?

I struggled to write this in all honestly, because without diving into very specific technical features I would like to see, the only thing that comes to mind is the fact that it is harder to get something up and running as quicky as it is with Gatsby.

If I browse over to the Gatsby 'Starter' library, I could pick a template for a blog I like the look of, install it locally with one line of code and I am up and running.
Whilst it would undeniably be a shame to rely heavily on an eco-system of themes/starters and sharable plugins like Gatsby does, it is nice, if for no other reason than for learning different pieces of tech, to be able to pick up projects that are already started and have some configuration already too them and a small piece of UI. Of course, there are the serverless functions, but these are backend only and not the same UI building plugins that Gatsby boasts.

More and more templates and starter projects are popping up however, the recent additions of Next.js E-Commerce and Next.js Virtual Event are a great example - and it is 100% worth pointing out 'Nextra' which is a delicious docs generator, but I would love to see some more options that make it quick and easy to get a project up and running.

Conclusion

Both frameworks are absolutely a great choice for any Frontend developer who is looking to build a web app. Both allow for insanely performant websites, and both have good developer experiences.

I definitely think the landscape has changed since last writing my review in 2019. The choice was a little bit more clear cut then, because Gatsby was good for one thing (Static Sites) and Next was good for another thing (Server Side Rendered), as my last article examined.

Next.js is more versatile and flexible. If your project has the potential to grow beyond its current spec, I would go with Next.

But Gatsby makes it easier to get up and running quicker and achieve more with less coding. If you want to build something that is unlikely to diverge much from the current spec, Gatsby is a great choice.

My usage has changed since writing in 2019 as well. I was much more actively writing code and building projects back then, now as a manager my coding time is much more limited. I was an avid Gatsby user in 2019 and as much if anyone had asked me which to use I would have recommended Gatsby.

As a personal preference now however, I will typically choose Next. My reasoning for this is flexibility. It just makes much more sense to me that over time my project might change and I want something that will seamlessly allow that to happen. Also having everything on one platform just makes sense to me. It saves me time and effort, whilst being easier to keep up with updates.

The Five Books that Changed my Life as a Software Engineer

Jamees Bedford — Fri, 15 Jan 2021 10:53:00 +0000

"Books are life's cheat codes".

It is no secret that I love to read. It is also no secret that many of the worlds most 'successful' people are aggressive readers who account at least some of their success to knowledge gained from books.

As a software developer, the obvious answer for my top five books would be technical chronicles, but actually I have found these haven't had much of an impact on me at all. Books that examine ways of living, how we go about our daily lives, approach productivity, interact with others have been overall much more impactful for me both in my working life as well as my personal life.

I wanted to run through the five books that have had the biggest impact on me. Whilst these aren't necessarily my favourite books, they contain lessons that dramatically changed the way I approached the world and in doing so have improved many parts of my existence.

If you do read through any of these, I would be so interested to hear how you got on. Please feel free to give me a shout, it would mean the world ❤️

The Bullet Journal Method

I remember clearly purchasing this book. Only a few months into my career change journey from labourer to software engineer, I was stood in a small independent shop that me and my partner love. We usually bought plants and candles when we visited, however in this instance this book caught my eye. It sounded interesting. At this point in life I was notoriously dis-organised, easily distractible and flicking through the pages it seemed a great technique to introducing some structure to my life. It was full of diagrams and explanations, and the minimal nature of the way it proposed I started keeping notes visually appealed to me. I bought it home with me, read it cover to cover, particularly interested by the fact the person (Ryder Carroll) who designed it was a Product Designer, and at numerous instances in the book he refers to Software Engineers using the format. It just seemed right for me, an aspiring software engineer to be using a productivity strategy that other engineers were using.

I have been Bullet Journalling for several years now, at one point (last year as a matter of fact) I experimented with digital based productivity apps (Things/Roam/Notion) but none of them were effective as BuJo. Not committing something in pen to paper made the systems feel much more expendable and forgettable. Crossing off my tasks on paper is an important ritual during my day, and it feels good to shut the laptop down and spend some time de-cluttering my mind.

This book changed my life in the sense that it made me begin a journey of discovering how to become productive and it also sparked the idea that I could improve certain parts of my life or character (in this case, my focus and productivity) through learning from books.

Atomic Habits

"1% progression everyday" is the ethos behind Atomic Habits. The lessons within teach the readers the importance on building habits for progression and creating greatness. It talks about good habit building process', how to make habits stick and the benefits of creating 'systems' to allow you to achieve your goals.

If my memory serves me correctly, I first heard James Clear on a podcast speaking about the idea of the "aggregation of marginal gains", which in essence means small and consistent changes add up to create massive impact. His example examined Dave Brailsford and the British Cycling team. When Brailsford took over the role of Performance Director to a team that was underachieving, he honed in on making marginal gains, by improving everything the cycling team was doing by 1%.

"They tested different types of massage gels to see which one led to the fastest muscle recovery. They hired a surgeon to teach each rider the best way to wash their hands to reduce the chances of catching a cold. They determined the type of pillow and mattress that led to the best night’s sleep for each rider. They even painted the inside of the team truck white, which helped them spot little bits of dust that would normally slip by unnoticed but could degrade the performance of the finely tuned bikes."

How that is relevant to me, was I adopted a very similar mindset when learning to write code. As long as I was getting 1% better each day, then over time I would get to where I wanted to be. Creating a strict but achievable study routine and building the process of learning specific topics each day helped me undeniably learn to code well quicker. There is no doubt in my mind that the hardest part of learning to code for people is the fact that it is a lengthy process, many give up as they aren't progressing quick enough or able to build the apps they want to be able to build. Progression at this point is hard to see, but focusing on 1% gains every day was an absolute game changer for me personally and undeniably helped me succeed.

How to Win Friends and Influence People

As a self-proclaimed introvert, interacting with people has never been something I have excelled at or felt comfortable with. For years I had worked in solitary, and that actually really suited me. I like my own company, I like my own space and at the time dealing with other people was energy sapping and uncomfortable.

When I started software development as a career it become apparent to me quickly that the key to unlocking progression was through being a strong communicator. I still believe that to this day. Therefore, my shyness became a focus point, an area to develop and grow in.

How to win friends and influence people was the first book I read on interacting with people, but for me, the lessons within this book created a fundamental shift in how I dealt with others. Only a couple of months after reading this book I progressed to a "Lead Engineer" on the merit of my 'people skills', I really don't think that this was a coincidence by any means.

A large part focuses on "How to get people to like you", and the secret to this became on to be the most valuable lesson. I have condensed the main points here:

Become genuinely interested in other people.
Smile.
Remember that a person’s name is to that person the sweetest and most important sound in any language.
Be a good listener. Encourage others to talk about themselves.
Talk in terms of the other person’s interests.
Make the other person feel important – and do it sincerely.

Whilst this all sounds fairly obvious, as far as an introvert goes, it is much easier to speak about someone else than it is to talk about yourself. So this is what I focused on. I became the best listener I could be, and folk appreciated it beyond belief. The feedback I get to this day from engineers I manage is that my listening skills and empathy are perhaps my biggest leadership strength.

The teachings in this book are actionable; it explains techniques you can practice over a video call, in your relationship, with the person working in the local shop. If you are less confident about speaking to others, then I strongly recommend you give this book a go.

Making a Manager

Making a Manager was the first book I read on management as a practice. I found myself in a very similar scenario to the author, in that I was given a sudden promotion and expected to lead. In essence, I knew very very little about how to manage anyone and at the time, this book was an absolute god-send in picking me up and setting me down on the right path.

Julie was an early designer at Facebook. As the team scaled she was made a manager of people, initially to her dismay, and "Making a Manager" focuses on the lessons she learnt from this point to her role as VP of design at Facebook.

The one beautiful thing about this book is that it is entirely relatable, to a degree that is unlike any other book on leadership I have ever read. It is honest, Julie walks through her mistakes as well as her wins. It helps you avoid traps and pitfalls in a way that no other book on leadership, from my perspective, manages to do. Many other leadership books focus on the ideal of leading, but are impracticable for someone who is lacking confidence and knowledge who realistically is looking for a guide to making good management decisions.

Entering the world of software engineer leadership had a massive change on my life, and this book was the helping hand I needed at the time to set me up for success. For that reason, it is one of the most valuable I have ever read. I recommend it to anyone who has the responsibility of managing engineers, designers or people of any profession for that matter.

Digital Minimalism

Digital Minimalism is the book I have read most recently out of this list. As a practice, it focuses on the idea that an individual should limit their screen time, social media time and de-clutter their virtual world, embracing the physical world and the joys and simplicities it has to offer - physical interactions for instance over digital ones. It shares many of the same principles as minimalism in the physical world.

As a concept, I had been aware of it for some time. Again, I had heard the author, Cal Newport, discuss the lessons on a podcast and initially, I wasn't too interested. I was posting regularly on social media and at that time my following was important to me.

I don't recall if there was a particular catalyst that suddenly lead me to examine my digital usage, or whether it was just a subtle change in attitude over time, but I read the book early last year when I had started a new job at Monzo. Inside I wasn't happy, I felt dissatisfied with the world, my relationship started to suffer because of it and I became not a particularly nice person to be around. My partner approached me and had said specifically that I should cut out social media, that I had become focused on others success that it was making me feel dissatisfied. I denied it for some time, but after a lot of reflection she was absolutely right. I compared myself endlessly with others, unhealthily so.

I read Digital Minimalism shortly after this and the relief and change in my behaviour was instant. I focused more on myself, my own journey and this allowed me to see the things that were important to me. I would be lying to you if I said I didn't fall occasionally into the old trap of comparison, but it is something I am getting stronger and stronger at. I limit my time on social media to 15 minutes a day, and my screen time is consistently less than 1 hour a day, and at this point I am happier and more content than I have ever been in my life.

Why Diversity in Tech Matters

Jamees Bedford — Mon, 27 Apr 2020 13:57:08 +0000

Diversity is a topic that I am putting a lot of energy into at the minute.

If diversity isn’t something that is on your radar, then let me explain why it should and can be something that everyone pays more attention to.

Earlier, I posted on LinkedIn:

People in the software industry SHOULD be doing more to support those who are learning to code from "un-traditional" backgrounds. Myself included. We need diversity and I want to let everyone who is learning to code who has doubts because they don't fit the traditional "software engineer" mould that this is the case.

Not particularly controversial - why would you not want to support those who need it most? It didn’t take long for me to get the reply I was expecting:

No we shouldn't. I never learned how to code from people stopping what they do to help me. If you have that expectation, join politics. Bridges don't stay up by PR. At the end of the day, you have access to all the tools you need to learn. It's nobody's job but your own to ensure your own success in life. If you’re getting into something like Software and/or engineering as a whole, you should expect it to be hard, or you are in the wrong industry. We literally solve problems.

Just for arguments sake, this reply was left by a white male with a Computer Science degree.

I agree - it is no one’s job to ensure your own success in life. But wanting the journey to be hard for others because it was hard for you is a horrible mindset. A mindset I don’t understand.

Imagine: You are a single mum, struggling to make ends meet, learning code in your few hours of free time to try and make life just that little bit easier. You then read something like that. “You should expect it to be hard, or you are in the wrong industry”.

I still to this day do not understand why software is so fucking full of gatekeepers. It’s an industry, not a secret club. If it is hard to get into tech for someone who is so full of privilege it is leaking out onto other peoples social accounts, then how hard is the journey going to be for someone who is in a much worse situation in life. Someone who doesn’t have the time, the right bias or the money to get a degree but wants to learn software.

It doesn’t get any easier when you apply for jobs either. I have been fortunate enough to play a part in making code tests non-compulsory at Monzo. Our feedback showed that they were a struggle for those who are neurodiverse. They cause unnecessary anxiety. They are often favoured towards those who have a traditional degree in Computer Science, which is (sometimes) just not relevant for a modern day development job. There are far better ways, and more inclusive ways, of determining whether someone is up for the job or not.

I think back to when I was learning code, in my mid 20’s with no degree, suffering with anxiety. It was excruciatingly hard, and I was in a comfortable place where I could afford to spend a few hours a day learning. Just someone from the industry reaching out and saying “You can do this” would have meant the world to me, and it is something that we can all actively do. Why would you want people to go through the same struggle you went through when the world of difference can be made just by offering support, motivation and advice.

We need diverse software teams. Different peoples opinions help build more empathetic and therefore better software. Its just a shame that the industry is still riddled with old-hat techniques and views that don’t encourage this.

My mission in life right now is to use my privilege to help software become more diverse and to vouch for those who are under-represented and not following the traditional path into tech, and I think it is something we can all do better.

My Experience of Imposter Syndrome

Jamees Bedford — Mon, 11 Nov 2019 08:42:03 +0000

If you were trying to paint a picture of who was the likely candidate to suffer from imposter syndrome then it would likely be me.

I was a serial under-achiever at school and an anxiety sufferer. Feedback from teachers was always "he could be doing so much better if he applied himself some more" and really I was lucky to scrape myself through secondary education into sixth-form college. I remember sitting in Computer Science, stuck again on some minor issue that others seemingly were just understanding. A lad next to me said "people like you and I don't belong here". That comment stuck with me for a long time and sapped my confidence to an all time low.

Meanwhile, I was excelling at things I was interested in and things that people had no expectation of me to succeed in. By the time I was 13; I had reached Grade 6 piano, I held the school record for long jump which hadn't been broken in 16 years, I was a sponsored gamer who had been published in Playstation magazine and I had made and sold numerous websites from scratch. I felt I wasn't recognised for these accomplishments though, I was held accountable for my studies and my studies alone and just accepted the fact that I wasn't MEANT to be a good student. In that mindset I became a bad student.

I worked numerous technical jobs followed by some manual labour jobs over the years after leaving school and had generally a low view of myself. I had failed as far as I was concerned, I hadn't gotten a degree and therefore I had failed at life.

To cut an extremely long story short I ended up becoming a web developer through self-study and perseverance. That had many challenges of its own that I would love to dive in to at some point but that is a story for another time...

First Encountering Imposter Syndrome

I guess looking back I had always suffered with imposter syndrome one way or another in life, which probably explains my low confidence and lack of effort. The first I ever become aware of it though was on seeing another person in the dev community mention it. It clicked at that point, this was EXACTLY what I was experiencing.

My intro to the development world was through freelancing and contracting. I did short term contracts on and off for a couple of years whilst filling the time in between with freelance work for smallish companies and anything I could get my hands on. Sure, I suffered with low confidence during this time, but I am sure I never experienced "full-on" imposter syndrome.

It wasn't until I landed my first full time job, at a Data Science consultancy, that it hit me like a tonne of bricks. I was working amongst
people with PhD's and Masters and I have never felt so in-superior. My best method of attack was to try and ignore it, although in hindsight
I should have spoken to someone about the way I was feeling, after all, I did the interview the same as everyone else, I had as much right to be there as anyone else.

Every morning was intensely hard. I thought everyday was going to be the day I was "found out" and sacked from the job. Every PR I submitted would be done so with the expectation that whoever was doing a code review would think "this code is absolutely shit, what is this guy doing here?".
Every issue ticket that was assigned to me was a massive weight pressing down on me. If I didn't know exactly how to solve it at first glance I would become overwhelmed with panic and I would furiously try and solve it, even if it meant doing extra hours. I didn't want to admit that I couldn't do something.

How I Am Currently

In July I applied for what I would consider my dream job as an Engineering Manager at a company that have been voted LinkedIn's UK Top Startup for several years in a row. I never in a million years thought I would be accepted as it has been documented that only 1% of applicants actually get hired, and every stage of the interview was torturous and massively anxiety inducing, however I was successful and accepted the job and am coming to the end of my first month.

You would have thought that I would have been really struggling with my anxiety and imposter syndrome but that actually isn't the case. I have put this down to three things:

Firstly, the company understands imposter syndrome, and are therefore able to address it. Any anxieties I have had I openly talk about with
my manager and my team mates. Having people surrounding you who understand what you are going through is massively reassuring. If you are a long time sufferer, maybe ask potential companies about how they address issues like this. If they aren't understanding, maybe this isn't the environment you want to be in.

Secondly, I have openly started talking about my past. I'm proud of the fact I am a second career developer and came from humble beginnings. I tell people the story proudly and focus on the achievement and work I put in to get this far. Trying to hide my past and come across like everyone else is not a good strategy to improve my mental health. I unduly worried that I would be judged about my background but every single response I have had from people has been extremely positive and many people are interested in my story!

Thirdly, I feel more comfortable than ever talking to people about how I am feeling. Anxieties aren't supposed to be bottled up. Find someone you
trust, whether it is your partner, a family member, a colleague or even a member of the Dev community. Talk about how you are feeling! I promise you it will make you feel much better to share your problems.

Gatsby vs Next.JS - What, Why and When?

Jamees Bedford — Wed, 25 Sep 2019 07:08:45 +0000

I am still getting people reading this article nearly two years after writing it - which is awesome! But unfortunately, a lot of what is in this article is out of date.

I wrote a new version of this post updated for 2021. It can be found here --> https://dev.to/jameesy/gatsby-vs-next-js-in-2021-what-why-and-when-2fae

Ok firstly, I digress, I am a massive fan of both of these "frameworks". I can usually be seen gushing about them on my Twitter or Instagram, however, without a doubt, the question I get asked the most when talking about these tools is which is better?

Should I use Next.JS? But I have heard Gatsby is pretty 🔥, maybe I should use that?

So I thought I would discuss it a bit further in-depth and hopefully make the choice a little bit clearer.

LETS FIGHT!

Gatsby & Next - An Introduction

So what are Gatsby and Next other than buzzwords you have heard mentioned before but never really understood?

To put it in the most basic terms, in the same way, create-react-app will create you a boilerplate of a React project, these two frameworks will lay the foundations for you to create an application.

They have separated away from create-react-app however, in the sense that they are not classed as boilerplates, but toolkits, laying the foundations and then giving you a set of instructions on how to build the house as well.

To summarise:

create-react-app - Lays the foundations of a React Project. The rest is up to you.

Gatsby & Next - Lay the foundations of a React Project. Give you guidelines on how you should build on top of them.

...

But huh? That's strange? They both do... the same thing?

Sort of.

At first glance, they both look very similar in the sense they both:

Provide a boilerplate application.
Generate incredibly performant, accessible and SEO friendly websites.
Create Single Page Applications out-of-the-box.
Have a really awesome developer experience.

But actually, they are fundamentally different.

Server Side Rendered vs Statically Generated

Ok, so we start to get a little bit technical here, so stay with me... It's not too bad!

Gatsby is a static site generator tool. A static site generator generates static HTML on build time. It doesn’t use a server.

Next.JS is mainly a tool for server-side rendered pages. It dynamically generates the HTML every time a new request comes in with the use of a server.

Of course, both can call APIs client side. The fundamental difference is Next requires a server to be able to run. Gatsby can function without any server at all.

Gatsby just generates pure HTML/CSS/JS at build time, whereas Next creates HTML/CSS/JS at run time. So each time a new request comes in, it creates a new HTML page from the server.

I'm not going to go too deep into the pro's and cons of each here, however for some more in-depth reading check out this post - https://dev.to/stereobooster/server-side-rendering-or-ssr-what-is-it-for-and-when-to-use-it-2cpg

Data Handling

Another fundamental difference between the tools is the way in which they handle data.

Gatsby tells you how you should handle data in your app.

Next leaves the decision entirely up to you.

What does that even mean?

Gatsby uses something called GraphQL. GraphQL is a query language and if you’re familiar with SQL, it works in a very similar way. Using a special syntax, you describe the data you want in your component and then that data is given to you.

Gatsby makes that data available in the browser when needed by your components.

An example:

import React from "react"
import { graphql } from "gatsby"
export default ({ data }) => (
  <div>
    <h1>About {data.site.siteMetadata.title}</h1>
    <p>We're a very cool website you should return to often.</p>
  </div>
)
export const query = graphql`
  query {
    site {
      siteMetadata {
        title
      }
    }
  }
`

In the above example, you can see that we have a query to fetch title and then display title within the component. Awesome!

Gatsby also has lots of plugins for various data sources which (in theory) makes it easy to integrate against many data sources. Some examples of data sources plugins are Contentful, Wordpress, MongoDB and Forestry. This allows you to do things such as hook your site up to a CMS and have external control of the content.

When building for production, GraphQL is no longer used, but the data is persisted into JSON files instead.

... Ok cool.

Next on the other hand, how you manage your data is completely up to you. You have to decide on your own architecture how to manage data.

The benefit of that is that you aren't tied into any tech that you may or may not want to be using.

So what should I choose?

Whether you should use Gatsby or Next depends very much on your use case, as really they are both awesome.

When To Use Next.JS

If you have lots of content or if you expect your content to grow a lot over time, then static generated web pages are not the best solution for you. The reason is that it takes much time to build the site if you have lots of content.

When creating a very large app with thousands of pages it can be fairly slow to rebuild. And if you have to wait for a chunk of time when you hit publish before it goes live it’s not a perfect solution.

So if you have a site with content that you will expect to grow and grow over time, then Next.JS is the best choice for you.

Also, if you want more freedom with how you access your data, Next.JS is worth a shout.

It's worth mentioning here that the documentation for Next is some of the best I have ever come across. It has an interactive introduction that quizzes you as you go through the content to make sure you are following along :) awesome! 👏

When to Use Gatsby

I tend to, and this is my personal preference, use Gatsby when I am building small-scale websites and blogs. The eco-system is perfect for hooking up to a CMS (it is literally a breeze) and there are some awesome guides on how to get going with it all.

It is (in my mind) easier to get up and running with Gatsby, so that is worth keeping in mind. Again, the documentation is to a really high level, packed full of tutorials for you to follow along.

Gatsby also comes with some "starter" templates, as well as a relatively recently introduced "themes" which all make getting a fully functioning web app up and running a quick process.

Mac / Windows / Linux - Which Do You Use?

Jamees Bedford — Wed, 18 Sep 2019 07:50:05 +0000

Me personally, I was a long-time Windows user but moved to a Mac about three/four years ago. At the time it was so I could use Sketch, however I liked it so much I have never looked back.

The ABSOLUTE Beginners Guide to Linting

Jamees Bedford — Tue, 17 Sep 2019 05:42:36 +0000

We have likely all been there at one point. We excitedly install ESLint with the hope it will sort all of our code out and make us infinitely better at writing good, clean JavaScript.

You have heard that you should be linting, but it's one of those things you don't really understand the why or how behind.

We find some instructions online and before you know it, ESLint is installed and ready to play ball. We load our code up and are greeted by a massive sea of red squiggly lines and 1000’s of issues. If you are like me you probably panicked and uninstalled it as quickly as possible never to try again.

The nature of linters is that they need configuring. That can be a daunting task for a beginner and there aren’t that many great resources out there, so I have made a ‘Complete Beginners’ guide to getting set up with the linter and have it pointing out the bigger mistakes of your code.

Lint? WTF?

Linters solve the problem of messy and inconsistent code throughout projects which is often a vital part of the development cycle. The way they do this is defining a set of rules that everyone in a team should follow, but more important, linters help you to follow the best practices and help to prevent potential problems. They flag up with a warning if anything is not right or of concern.

The issue is if you are starting out you don’t often want to see all of the things you could improve on at once, but it would be handy to find the bigger issues that need addressing. Things like syntax issues, accidental global variables etc.

NPM Install

At this point, you should have Node and NPM installed on your system. To double-check run:



node -v
npm -v

This should return version numbers for each. If not then you just need to install Node and NPM.

To get ESLint run this command in your terminal:



npm install -g eslint

This will install ESLint to your system.

Next, swap to the root directory of your project folder that you want to install ESLint in and run the following command:



eslint --init

This should work, however, it has been documented that sometimes this can have some issues. If there are any problems with this, then try the following:



./node_modules/.bin/eslint --init

If all goes well you should be greeted with some text in your terminal asking “How Would you like to configure ESLint?”. Select the following:



Use a popular style guide
Standard
JS

Great! You are all set up and ready to get linting.

Setting Up A Super Basic Config

Now I expect most people who have had issues with linters before would have got this far and then would have lost the plot when they opened their project to find errors all over the place.

This is where the config file comes in to play!

Open up your project in your favourite text editor and you will notice you have a new edition of a .eslintrc.js file in your root directory. Open it up and you should see something like this:



module.exports = {
   "extends": "standard"
};

First thing first, change standard to eslint:recommended.



module.exports = {
   "extends": "eslint:recommended"
};

Awesome. If you peek at your files you will notice there is still a fair amount of errors. This is because we need to set an environment so the linter understands some of the global variables.



module.exports = {
   "env": {
     "browser": true,
     "commonjs": true,
     "es6": true,
     "jquery": true
   },
   "extends": "eslint:recommended",
}

This is set up to recognise ES6 and JQuery syntax as I believe that is likely to be what most people will be using in their starter projects, however, if you are using other frameworks then you can just add them to the ‘env’ section as I have done above.

Lint Away!

And there we have it! A perfect little ESLint config that isn’t going to scream and shout at you every time you do something a little bit wrong.

Obviously, as you improve and your needs change it is just a case of adding extra properties into this file! Simples!

Why I Gave Up Freelancing to Become an Employee 😱

Jamees Bedford — Fri, 13 Sep 2019 09:24:04 +0000

Following on from my article the other day where I went through the tactics I used for winning and keeping clients from my five years as a freelancer, I had a lot of questions about why I made the choice to go back to a full-time career.

I wanted to take this opportunity to dive into that subject a bit deeper and leave my thoughts and opinions on the topic.

Please note - this article isn't me telling you that one career path is better than the other, this is what is right for me.

First We Need to Go Back In Time 🦕

My first experience of building something and selling it was actually when I was pretty young. I sold my first website aged just 14, a simple WordPress build back in the day when it was a new technology and it wasn't so simple to get up and running.

I sold probably 10 / 15 websites over the space of a year, which was pretty awesome when I think back to it, so I always had the mindset that the internet was there and you could make money on it.

I didn't do particularly well in school and left at 16 to work for minimum wage as a software developer for a construction manufacturing company, building and maintaining their stock tracking application in house and working on some PCB production.

Over the years I changed jobs but always stayed in the construction industry. I was a labourer and a van driver to name a few things!

So at the age of 25, I decided to jack in the job I was doing at the time, a Project Manager (again, for a construction company) to start building websites for people and really diving deep into modern web development.

If you want to know more about my success' and the methods then check out my post here - https://dev.to/countrysidecoder/an-ex-freelancers-guide-to-getting-your-first-clients-18ao

But needless to say, it was hard work. Very hard work.

Things I Liked About Freelancing ❤️

There was never a dull moment, I could be working on an e-commerce website one day and then an in-house CMS system the next. I got to know lots of people, lots of companies and I liked that.
I could set my own rules, boundaries and time frames.
I could (eventually) pick and choose jobs I wanted to work on.

...and no matter how hard I think about it, that is really it. Those three points.

Things I Disliked About Freelancing 👎

The time I could spend learning new tech was drastically decreased - I did not want to experiment with new tech in case it went wrong and cost me money, and any downtime I had was usually spent trying to locate more work or chase up existing clients.
You have no set income so it is much more stressful than having a salary. People don't always pay on time and when you have bills to pay and food to put on the table that is hard.
You need to be primarily a people person and work on your sales skills and not just your development skills.
Handover from clients can be an absolute pain.
It can at times be extremely lonely when you are working by yourself. You have no team to learn from.

So... Why did I Go Back To Full-Time? 🙌

I don't like the negative connotations revolving around working for someone.

I think it stems from the Gary-Vee-esque mindset of success manifests itself as "being your own boss", and I certainly thought that at one point.

However, I don't agree with that, and I came to learn it over time.

I looked up at who I consider being the influential developers and engineers, and they all work for companies. They excel at their career and move up to Lead Developers, CTO's, Engineering Managers. They are not losing because they are not working for themselves... They are winning because they are doing what they do best FOR someone else.

To put it bluntly, when I was freelancing I felt as though my skillset decreased. I was becoming outdated, falling behind the times and not being able to excel at my strengths but having to spend my time working on my weaknesses.

I missed being part of a team and having comrades all working together. Sure I like my alone time most of the time, but having someone who has your back if the shit hits the fan is a nice feeling.

Also, and possibly the main reason, security. I now get paid a handsome salary each month whilst getting all the other benefits I was missing. Sure, freedom is a brilliant perk of working for yourself, so I was able to find a company where I could set my working hours, as long as the job is done. If I want to take two hours for lunch to go into town and grab something I CAN. If I want to finish early I CAN.

I am infinitely happier and a stronger individual now for it.

Like I said at the start of this article, I am not trying to sway you one way or the other, but these are my personal thoughts and experiences.

If you have any questions regarding freelancing or careers then please feel free to leave a comment or hit me up and I will do my best to answer.

Also, go check out Chris Achards awesome post on how to start freelancing! - https://dev.to/chrisachard/how-to-quit-your-job-and-start-freelancing-as-a-software-developer-2ffh

An Ex-Freelancers Guide to Getting Your First Clients

Jamees Bedford — Mon, 09 Sep 2019 08:43:53 +0000

I was a freelancer for nearly five years of my life.

One of the things you learn fairly quickly, is freelancing isn't just about being an awesome developer, it is about becoming a good salesperson.

That's right... a salesperson 😬

Typically when I think of a salesperson I think of this guy:

A typical snake-oil salesperson. Someone who will pounce upon you and bully you into buying something.

But it doesn't have to be like that at all. In fact, my partner works in sales, she is shy and introverted however she excels at her job. She is the sales manager of a large company and has won many high-brow projects.

When I first started freelancing and realized that no one was flocking to me to chuck their cash in my face for my awesome skills, I realized sales were going to be key to my success.

I spoke to my partner and we had a good conversation about what she would do in this situation. She gave me these tips:

Go where the market is.
Find a problem, and offer a solution - If you try and sell someone something that they don't necessarily understand will benefit them, they won't go for it.
Find a way to be competitive without under-selling yourself.
Build long-lasting relationships.

I am going to tackle each of these points below in a dedicated section.

Enjoy! 😉

🤝 Go Where the Market Is

It's tempting to say "Everyone is on UpWork, I will go there"!

However, after spending a couple of weeks on the platform there are a few things I decided.

It's too competitive.
There is too much noise.
Lowest cost of living (often) prevails.
I am unable to build relationships because clients details are kept largely confidential.

I fell into a bit of a trap and mainly spent the first two weeks writing detailed proposals. I only heard back from one, a fairly basic website to be made for £100. I went through the process, spent a couple of days putting together some designs. The client was really happy, paid me my £15 as agreed and I carried on building only to never hear from them again.

I needed to rethink because this wasn't sustainable. All of this for £15!

✅ So what works?

I decided to follow my partner's advice. I needed to find somewhere where there was going to be work, but not a lot of competition.

Then it hit me. Instagram.

Take five minutes to look up small companies, tradespeople and other professionals in your area. There are LOADS.

Plumbers, electricians, window fitters, make up artists, hairdressers, cake makers, dog groomers, wedding videographers, photographers... They are all on there plugging their services.

I felt I was on to something.

These people have taken the time to set up an Instagram account to try and promote their business where peoples attentions are at. They understand the importance of being present on social media, yet many of them have websites that are not mobile responsive and therefore cannot convert sales from Instagram.

I'll repeat that - many of them have websites that are not mobile responsive and therefore cannot convert sales from IG.

We have found our audience, and we are starting to find they have a problem that needs fixing.

⚒ Find a Problem - Offer a Solution

I'll repeat the line I left you with for a third and last time...

Many of them have websites that are not mobile responsive and therefore cannot convert sales from IG.

This automatically gives you a hook that you can get people in with.

"Let me build you a website that looks nicer than the one you have now" will not work.

Business' are tough. They have margins to meet and often making things look pretty comes much later. However, if you can find a problem, and then offer a solution to that problem and tell your potential client exactly how it will benefit them, then you are on to a winner.

This is the tactic I took - I would look up small companies in my local area, check their website, if it was good I would move on, if it wasn't mobile responsive, or if they were selling a product and would benefit from E-Commerce, then I would use that as a selling point as well.

Here is an example of a DM I would send:

Hi 👋🏼 I was just looking through your page and you have some awesome products! I couldn't help but notice though that your CTA/website is not able to be viewed on mobile. It seems a shame that you will potentially be missing out on the people visiting your website who are viewing Instagram on their phone!

If you want to have a chat about sorting a solution for that, then feel free to give me a ring or we could chat over coffee.

Thanks for your time!

The ultimate aim here is to get the person speaking on the phone or meeting the client in person.

Sure it won't work for every single message sent, a lot of people will refuse or at least will keep you in mind for future.

When you have a client on the phone, however, the next stage comes in to play 😀 Converting!

💸 Find a Way to Be Competitive - But don't undersell yourself.

As many people as I ask will always take payment upfront for a website. Sure, they will split the payments down into different stages of the build, but it is still a lot of money upfront.

Being competitive will mean trying to undersell everyone else around me, and there is nothing to say that a potential client won't check online or elsewhere for a price check.

That got me thinking... Is there another way to be competitive without knocking my prices down?

Monthly payments.

Not only does this make the barrier to entry lower than an upfront cost, but it is also a tactic that makes you much more accessible for business'.

Would you rather pay £2000 upfront, or split the cost to £500 and then smaller monthly payments over the year.

I was sceptical at first, would it work?

I can safely say that this was possibly what transformed by freelancing to new heights. Clients were much more happy to sign a contract to pay me monthly, whilst I updated and maintained their website.

Rather than going through the complications of a hand-over and trying to work to using a CMS that the client knows or understands, then the ball is kept in your court. Use the tech-stack you like, keep the website on GitHub. Awesome 🤙🏻

❤️ Build long-lasting relationships.

This is made slightly easier than the fact you will be keeping in contact with the client because they are paying you monthly but still needs to be mentioned.

Now that the client knows you are trustworthy and offer a great service, they are more than likely to come back to you, or even recommend people to you. I had a client once who recommended me, and in the space of two months, I had three more clients purely from the fact he had mentioned what I had done for him.

It doesn't need to be anything special, but dropping in a phone call every now and then or meeting up for a bit of lunch will help build those relationships. If you sell your client a website and then drop off the face of the earth you are going to come across as being untrustworthy.

I hope this helps some of you in the same way it helped me! Ultimately there will be a lot of failures and you will get things wrong at times.

Freelancing isn't easy! It likely never will be either!

But hopefully, with these few tips, you will be able to get yourself a few clients and start generating that income!

The Ultimate Guide to Finding a Job in Tech

Jamees Bedford — Fri, 30 Aug 2019 14:35:33 +0000

👋🏼 Introduction

I have been actively mentoring developers, both new and experienced, for just over half a year. One of the main concerns between all engineers usually revolves around finding a job.

If you are already employed, chances are getting there was an exhausting process. Sometimes it can feel daunting to even start to think about having to go through all of that again.

This process is even more intimidating if you are looking for your first job, an internship or looking for a career change.

Where do you start? What do you need to prepare? Is there anything I could do better?

In writing this article I am looking to create an extensive guide that eases people through the journey.

🌱 Step One - Preparation

This stage is all about laying the groundwork that you will use for your applications. These are the typical things that people think about and know they should have, but perhaps don't quite know how to enhance to increase their chances.

📑 CV/Resume

Everyone needs a good CV/Resume.

As someone who reads a lot of them, I have come to understand the importance of fine-tuning them to be eye-catching and concise. You would not believe the amount of CV's that are 5 pages long, with size 8 font. I can guarantee you, I'm probably not going to read past the first page.

Without a doubt, one of the hardest parts (but most important) of this is a personal statement. It should reflect your personality and your relevance to the role. The aim is to speak highly of yourself without sounding like you are blowing your own trumpet... for example, I would write:

"I am an experienced engineer and people manager with over five years of working in a team lead/managerial position. Not following a traditional route into the tech space has given me an unparalleled empathy for coaching people of all ability level and backgrounds. Outside of work I actively mentor new developers, teaching them how to get started and progress in the world of engineering, a cause I feel extremely passionate about."

The rest of the CV is dedicated to detailing all the relevant experience you have, whether it real-world paid experience, or things you have done online.

If you haven't worked as a developer before, open-source work can be a really positive thing to put here.

On a side note, jobs that you have had in the past ARE relevant, even if they aren't in technology. Communication, teamwork, customer service... ALL RELEVANT.

✅ DO

Keep it brief - no more than two pages. Preferably one page.
Keep readability in mind. A size 10/11 font will be fine. If you find it doesn't fit on the page, you have written too much.
Find ways to make your experiences relevant... Have you worked in a team, interacted with customers?
Edit it depending on the job you are applying for. Make it personal. How do you fit in with the culture? etc

🆘 DON'T

Be generic and sound like a robot. You want to stand out amidst other applicants.
Waffle. Keep it straight and to the point.
Reference online tutorials or courses. It likely doesn't mean a lot to the reader and is wasted space.

📝 Covering Letter

Cover letters are equally as hard as a personal statement but are SUPER important.

If you go through a recruiter (we will discuss that later), more often than not they will not allow a cover letter, however, if you are applying direct you should ALWAYS ALWAYS ALWAYS write one. Even if it says it is optional.

I again like to write this depending on the job you are applying for. I have a master cover letter template and then edit it when I understand more about the company I am approaching.

Here is an example, I wrote this in the context of applying to a job role similar to the one I am in now:

"I am sending my resume in response to the open position for ...

My background in managing teams consists of four years working as a Product Manager for a ventilation company, looking after a team of twenty ducting engineers before realising a dream and moving into software. I since progressed to a lead developer position, however always missed the role of coaching and helping individuals grow personally.

Due to this, I started mentoring budding developers in 2018 and jumped at the opportunity to become Team Manager at my current workplace, a leading Data Science consultancy offering R, Python and JavaScript services. Here I played an integral part in positioning the engineering resource for a strategic change into being a more product-focused company.

Most recently, I have worked closely with Talent and Development to define an engineering career framework, allowing developers to have a clearer insight into the characteristics and skills the company deems important, enabling career growth.

I am always keen to seek new challenges, and it would be an honour to work for a company who are actively offering such a ground-breaking service, hold culture and wellness of their employees in such high regard and to help its extremely talented engineers reach their potential."

You can see that there is a personal touch to the letter. I have referenced what the company do in the last paragraph.

Another tip I have is to reference a talk or a piece of work someone from the company has done. For instance "I am applying after watching an inspiring talk by ... which really showcased the companies values. I would love to be a part of that".

✅ DO

Keep it brief - no more than half a page.
Keep readability in mind. A size 10/11 font will be fine. If you find it doesn't fit on the page, you have written too much.
Add a personal touch, showcasing that you have some interest in the company outside of just chasing a role.
Edit it depending on the job you are applying for. Make it personal. How do you fit in with the culture? etc.
Create a benefit that the company will be getting if they take you on. My benefit is that I actively practice coaching outside of my full-time role and I can bring that to a company.

🆘 DON'T

Be generic and sound like a robot. You want to stand out amidst other applicants.
Waffle. Keep it straight and to the point.
Talk about yourself in an arrogant way. There is a fine line between showcasing what you can do and boasting.

🖼 Portfolio

This is a controversial topic that gives people a lot of trouble.

People I have spoken to have put off applying for jobs because they weren't happy with their portfolio.

Newsflash: I am STILL not happy with my portfolio. I got my current role with absolutely NO portfolio. If I had waited until I was happy, I would still be waiting!

I am a true believer that you should do something simple, and do it well. Just flicking through Twitter and looking at some of the most well-known developers, a lot of them have VERY simple websites with some articles.

I think as a new developer, you are not necessarily going to possess all of the design skills that a designer will have. Therefore, although it is great fun to build something and be ambitious with your projects, I think for job apps you should stick to something really really simple.

An ambitious website that has a massive amount of projects, articles, pictures opens up the ground for things to go wrong. Is whoever viewing your website going to be doing it on a phone? Are they going to be on a 27" Mac... If something goes wrong or looks off, they will likely notice it and remember it.

I know I had an applicant recently whose portfolio still had some placeholder text from where he had obviously used a template and not filled that field... There is nothing wrong with using a template, but I remembered his portfolio for the WRONG REASONS.

There is no shortage of tools to get a good website up and running if you are that way inclined (Gatsby starters anyone?).

So just your name, a brief paragraph about what you do, and some links to social accounts (GitHub, LinkedIn, Twitter etc) will be fine.

Articles are also a really good thing (more on that later too).

✅ DO

Keep it simple - Unless you are confident you can pull it off.
Link to relevant social accounts.
Make it responsive. You don't know what screen sizes it will be viewed on.
Keep it accessible.
Google Lighthouse test it just to make sure of the above.
If you WANT to showcase a project, then one fully complete project is miles better than five half-baked projects. Keep that in mind.

🆘 DON'T

Be too ambitious.. it doesn't matter!

🤳🏻 Social Media - Online Presence

Most people have some sort of online presence. Whether it be Twitter/Instagram/Youtube/Facebook.

These are both good and (potentially) bad. Let me explain.

👍🏾 The Benefit

It can showcase your character and your passion for technology and development.

It can help you interact with other similar-minded people (Networking).

It gives you a creative platform to showcase your talents.

👎🏼 The Negative

It can showcase your character.

It can help you interact with other similar-minded people and start arguments.

It gives you a platform to be an idiot.

In all seriousness though, don't put anything on Social Media that you wouldn't want an employer to see. I know for a fact I will Google a candidates name. If they have 50k followers on Instagram and are using the platform to spread a positive message within the community it is such a positive thing. If they are on Twitter and are starting flame wars then I have to question is this the sort of person I want in my team? Probably not.

One thing I always recommend to people is to document their process. Whether it be discussing the latest course you are doing and what you are finding hard about it, or whether you are documenting the build of a particularly ambitious project, people are going to want to hear about it and you will be surprised at the number of people it helps.

This all works in your favour when you come to apply for a job, as well as helping you improve your communication skills and grow your presence in the industry.

⚒ Open Source

I will shout about the benefit of Open Source projects until the end of time.

Why is it so good?

Because it gives you REAL WORLD experience, without having to sell your services on a freelance basis.

The number one complaint I find with new developers is they find it hard to get real-world experience, and even junior jobs require it.

THIS IS THE ANSWER

Sure, it is intimidating, because you may mess up... But this is one of the most valuable lessons in your journey to developerhood (is that a word? It is now).

Pull requests, branches, Merge Requests, forking - all super important concepts that you probably just aren't going to get that much practice with outside of a project that has lots of contributors.

Even if it is doing something small, like writing a more concise piece of documentation, it is something you can talk about in an interview and experience you can put on your resume!

How fucking cool would it be if you were applying for a job as a Front-End developer who will be working with React when you have actively worked on the React codebase? Fucking cool is the answer 😎

✅ DO

Choose a project you have an interest in.
Check through the existing issue list. Even if it's just helping answer a question someone might have, its all good experience.
Interact with the other contributors. Many projects have their own Discord or Spectrum communities.
Adhere to good code and Git practices. This is your chance to put it into practice.
Shout about your new real-world experience from the rooftops.

🆘 DON'T

Rush the process. Take time and care in your approach.
Bite off more than you can chew.

🚀 Step Two - Applying

On first glance, this might seem fairly simple. Surely you just fire up Indeed.com and go through the list?

That's certainly one way of doing it, but I think of it like this. Everyone will be doing the same. The competition will be more fierce.

There are other ways of finding jobs!

👀 Good Places to Look You Might Not Have Thought Of

The job section on LinkedIn is actually really good, so sign up if you haven't already and fill in your profile.

You will also quickly notice that there are A LOT of recruiters working on LinkedIn. They will swoop on you like a vulture to a corpse.

Find the more trusted recruiters to work with. Having someone fighting your corner and pushing you through the process can actually be a really positive thing. I always tell people recruiters are trying to earn their commission, and they do so when they have gotten you in the door and working there. They also have access to jobs that you wouldn't have seen anywhere else.

Glassdoor

Glassdoor is primarily a website that allows people to rate the companies they work for. However, they can also rate the interviews they have had at a company.

If the company you are applying for is established, this can be an absolute gold mine of information.

Software engineers will have written about the process so you know exactly what to expect from an interview which gives you valuable time to prepare yourself.

Glassdoor also has a job section which is really good and has a wealth of different jobs for you to check out. It has the added benefit of showing you whether the company is good to work for and what their values/culture are.

Google

Good old-fashioned Google.

One technique I have for finding work is Googling local agencies and companies to me. Compile a list of ten companies in your area and their websites and if they have a job section then apply.

Even if they don't have a job section, it would be worth sending them an email and a CV regardless. Just introduce yourself. Especially small agencies may not need someone there now, but they never know when their junior developer might leave and having someone's CV from the local area will be a big help to them.

Of course, this doesn't have to be done locally. Even big companies will have a job section, and often these jobs aren't listed on traditional job search websites.

Compile a list of ten companies you admire, and I am sure you will find at least 4/5 companies that are after someone with the same skillsets as yourself.

🦸🏽‍♂️ Which Jobs to Apply For

Sometimes it could seem as though companies are after a superhero!

A junior dev with experience in React, Node, Kubernetes, AWS, Docker, Svelte, Go, Java, Python. Bollocks to that!

You have to remember that a lot of these job specs are written by HR teams and not development teams.

For sure, someone has asked me before "what is a perfect candidate" and before you know it you have listed off a list of all these technologies.. but as we all know, that's not realistic.

Apply for these jobs anyways! As long as you have good knowledge of at least a few of the things in their technology stacks, that will likely be more than enough and there is always the option of training and upskilling!

🧮 Organising Your Search

Job hunting can quickly get out of hand.

All the job apps look the same, you don't know what you have applied for, and before you know it you have got yourself in a mess!

I have a system for job hunting!

I use Notion, because it allows you to create columns and link directly to a webpage however whatever productivity app you have will be just as good no doubt.

I spend a day or two solely looking for opportunities, linking to all of the positions I like the look of.

When I have applied to them, I move them into the "Applied" column. If I hear back and it's a negative, I move it into the rejection column. I also have a column for jobs that have decided to take things further.

Organising your search can make you much more productive and will let you avoid mishaps like applying to the same job twice!

✅ DO

Apply to jobs even if they don't seem a perfect fit.
Keep looking continuously. You never know when the perfect role might appear.
Reach out to your network, as it might throw up some offers.
Make a list of jobs you have applied for, so you don't apply twice.
Be upfront with recruiters about your needs/wants.

🆘 DON'T

Apply to anything and everything. At least make sure you have some experience in their tech stack.
Just stick to looking on one website. You will miss out on a tonne of opportunities.

🤝Step Three - Interviews

The dreaded interview! Everyone is scared of this stage, and it can be fairly brutal, however, it is important to give yourself the best chance of success.

Importantly, you must remember that not being accepted is not necessarily a reflection on your ability. Interviews are to be taken as learning experiences, and you have to get good at them by practising.

🧠 Research and Prep

As I mentioned above, Glassdoor is a really good place to find a lot of information about the interview process of a company.

If the company is not well established, or not large in size, that might not pull up any answers, however.

Looking around online for any content revolving around the senior members of the company, or any employee-generated content is really important. Many companies will speak openly about their culture/values and gaining context is a really good thing, even if it doesn't shed any light on the technicalities of an interview.

It has also become more common for companies to store their code tests on GitHub. Whilst I certainly don't recommend cheating, it can be good to practice what a real-life code test is like before you come down to doing the real thing. Below is the code test for Just Eat:

https://github.com/justeat/JustEat.RecruitmentTest

There are other tests out there so practice away!

👩🏻‍💻 On the Day

What To Wear

Wear something in keeping with the context of the company. If you know they wear formal clothing, go in something formal. However, even formal clothes should be comfortable. I remember wearing a new suit to an interview once and I was constantly thinking about how much it was scratching my neck and therefore didn't perform to my best.

If they wear informal clothes, then wear something comfortable whilst still looking presentable. I like to wear a jumper, black jeans and smart trainers.

I heard a comment once that you should wear no more than 2 colours, and ever since then, I have always worn black to an interview. I don't know why but I would worry if I didn't have black on now! Whilst I'm not saying that's the right thing to do, you should certainly give at least some thought to what you want to wear so you can pick something that makes you feel at ease!

Ask Questions, Even if You Know the Answers

You should ALWAYS ask questions, so make sure you prepare some beforehand. If something is discussed in depth that you were going to ask then obviously don't mention it.

Asking questions shows you have a genuine interest in the company, which is always a positive thing.

Be Polite, Smile 😃

It goes without saying, but someone has invited you into their company, and you want them to hire you. The least you can do is show them respect and some manners.

Where I work now, they have an agreement with the reception of the building we rent our office space to provide their feedback on the candidate. If they are rude you will fail the interview automatically, regardless of your ability.

Good manners cost nothing!

Be Passionate

I have always said that I would take someone who was passionate and less skilled than someone who had no passion for the industry but was really knowledgable.

As a team manager, you are looking for individuals who are passionate about their craft, who will continuously strive to achieve more. Outright knowledge is not the be-all and end-all.

Don't Try and Haggle

There is something really off-putting about people who mention salary and terms of work within an interview. You should at least have some idea that this role is a good fit for your needs before you go for an interview, and this is not the time to bring it up unless prompted.

My experience is that this should be left until an offer has been established. If the company want you, you leave yourself more leverage to ask for a slightly higher salary or an extra day of remote working. Don't cut your nose off to spite your face, as some would say!

✅ DO

Do your research... again!
Think of some questions you want to ask beforehand.
Wear something you feel comfortable in.
Arrive promptly - about 10/15 minutes before the interview is scheduled.
Ask for some water if you need it.
Try and make eye contact. It can be hard, but creating a connection with someone is made easier with eye contact.
Treat everyone with respect, not just the interviewer.

🆘 DON'T

Come across arrogant or unopen to change.
Go off-topic when answering questions, even if they require a long answer.

👋 Conclusion

I hope this has been helpful to at least some of you 😆 If there is anything you would like me to add to this article, I will certainly do so. My intention is to keep adding to it over time, so all suggestions will be greatly received!

What's the one thing you wished you were better at?

Jamees Bedford — Fri, 26 Jul 2019 14:47:23 +0000

What is the one thing (technical or non-technical) you wished you were better at?

For me:

I would love the ability to pick up technical concepts from books. I just can't work like that even though I would love to be able to.