Forem: Simon Egersand 🎈

5 Tips to Write Clean Code in JavaScript

Simon Egersand 🎈 — Mon, 25 Jul 2022 13:32:23 +0000

As you become more experienced with JavaScript there are tips and principles on how to write clean code that you should know.

The craft of software engineering is a relatively new one. The craft of medicine has existed for thousands of years while software engineering has only been around since the beginning of the 1960s. We are all still learning how to write clean code. There are some principles though that are widely accepted by the community as best practices.

There are many principles for writing clean code, but I decided to focus on the five most important. These tips are recommendations and not strict rules. Practice these principles and your code will be cleaner!

Why Clean Code Is Important

As a beginner, your focus is not necessarily on writing clean code. Your focus should be on getting the code working and your tests passing. As you become more experienced you can start focusing on writing clean code.

In this article, I define clean code as:

Easy to read
Easy to understand

Clean code will help you get up-to-speed with and maintain a codebase. It's always worth the effort of making your code cleaner, even if it takes a longer time to write!

Write Clean Code in JavaScript

JavaScript, like any other language, has its special quirks. These tips are not necessarily limited to JavaScript and can be used for many other languages.

Extract Magic Numbers to Constants

"Magic numbers" refer to numbers that are used directly in the code, without any context. They lack meaning and should be extracted to constants with a meaningful variable name.

Bad:

const isOldEnough = (person) => {
  // What does 100 refer to? This is a so-called "magic number"
  return person.getAge() >= 100; 
}

Good:

const AGE_REQUIREMENT = 100; // Now we know what 100 refers to

const isOldEnough = (person) => {
  return person.getAge() >= AGE_REQUIREMENT;
}

Avoid Boolean Function Arguments

Boolean function arguments are a typical "code smell" (breaking fundamental programming standards). This is because they lack meaning. And it indicates that your function does more than one thing, which you should always avoid!

Bad:

const validateCreature = (creature, isHuman) => {
  if (isHuman) {
    // ...
  } else {
    // ...
  }
}

Good:

const validatePerson = (person) => {
  // ...
}

const validateCreature = (creature) => {
  // ...
}

Encapsulate Conditionals

Long conditional statements are hard to read because you have to keep all of them in your head. By encapsulating them into a function or a variable your code will be easier to reason about.

Bad:

if (
  person.getAge() > 30 &&
  person.getName() === "simon" &&
  person.getOrigin() === "sweden"
) {
  // ...
}

Good:

const isSimon =
  person.getAge() > 30 &&
  person.getName() === "simon" &&
  person.getOrigin() === "sweden";

if (isSimon) {
  // ...
}

// OR use a function

const isSimon = (person) => {
  return (
    person.getAge() > 30 &&
    person.getName() === "simon" &&
    person.getOrigin() === "sweden"
  );
};

if (isSimon(person)) {
  // ...
}

Avoid Negative Conditionals

Negative conditionals ("double negation") add an extra condition to your brain when you're reading the code. You would not say "I'm not not sleepy". You would say "I'm sleepy". The same practice applies to code!

Bad:

const isCreatureNotHuman = (creature) => {
  // ...
}

if (!isCreatureNotHuman(creature)) {
  // ...
}

Good:

const isCreatureHuman = (creature) => {
  // ...
}

if (isCreatureHuman(creature)) {
  // ...
}

Don't Use If Statements

This might sound crazy, but hear me out! If statements are easy to understand but do not scale. As soon as you have more than one or two if statements in the same function the code easily becomes hard to reason about.

Instead, use a switch statement or, if possible, a data structure like Array, Set, or Map.

Bad:

const isMammal = (creature) => {
  if (creature === "human") {
    return true;
  } else if (creature === "dog") {
    return true;
  } else if (creature === "cat") {
    return true;
  }
  // ...

  return false;
}

Good:

const isMammal = (creature) => {
  switch (creature) {
    case "human":
    case "dog":
    case "cat":
    // ...
      return true;
    default:
      return false;
  }
}

// OR even better, use a data structure

const isMammal = (creature) => {
  const mammals = ["human", "dog", "cat", /* ... */];
  return mammals.includes(creature);
}

Conclusion

These are my five most important principles for writing clean code in JavaScript. Practice makes perfect, and the same goes for writing code. If you already follow these principles today - keep it up! I'm sure you've practiced writing code a lot. If not - don't be discouraged! We all start somewhere 🙂

To summarise:

Extract Magic Numbers to Constants
Avoid Boolean Function Arguments
Encapsulate Conditionals
Avoid Negative Conditionals
Don't Use If Statements

Connect with me on Twitter, LinkedIn, or GitHub

Write Git Commit Messages That Your Colleagues Will Love

Simon Egersand 🎈 — Fri, 01 Jul 2022 12:58:58 +0000

Git commit messages are how we communicate to our future selves. They help you understand why a certain line of code was added to the code base. That's why knowing how to write a good Git commit message is important.

We've all been there; "Git is confusing", "Why can't I just push to the main branch?", "No one will ever read this message". These thoughts are normal and most people that have learned Git can probably relate. You might not appreciate good commit messages until you work with a code base that's been around for years. Or when you return to an old project of yours.

In this article, I'll show you how to write Git commit messages that you and your colleagues will love.

Why Git Commit Messages Are Important

Have you opened up an old project and checked the commit messages with git log? If not, I recommend you do that now. If they're not filled with "Fix styling" or "Add endpoint" then great job! If you're like the rest of us, read on 😄

Or perhaps you joined a company with a code base that's been around for a few years. And you're trying to understand why some piece of code was added. Will you break anything if you change it? In this case, a good commit message is invaluable.

Simply put, by writing good Git commit messages you are future-proofing yourself and your colleagues. And as developers, we are reading a lot more code than writing it.

Reading vs. Writing Code

Uncle Bob (Robert C. Martin - author of popular programming books such as Clean Code) says

“Indeed, the ratio of time spent reading versus writing is well over 10 to 1. We are constantly reading old code as part of the effort to write new code. ...[Therefore,] making it easy to read makes it easier to write.” (ref.)

At times, to understand the code you will also need to read the commit message. I hope that you now see that the effort of writing a good commit message is worth it!

How To Write Good Git Commit Messages

Now that you're convinced that commit messages are important, let's look at how you can write them in a way that your colleagues will love!

A commit message consists of two parts: the subject line and the body. Here's an example from the bitcoin repo.

commit eb0b56b19017ab5c16c745e6da39c53126924ed6
Author: Pieter Wuille <pieter.wuille@gmail.com>
Date:   Fri Aug 1 22:57:55 2014 +0200

   Simplify serialize.h's exception handling

   Remove the 'state' and 'exceptmask' from serialize.h's stream
   implementations, as well as related methods.
   ...

The first line is the subject and what follows after the new-line is the body.

Focus On The Why

This is the most important rule. And it's also the most common mistake. Commit messages should explain why the code was added, not what was added. To see the what I can just read the code. But to understand the why I can only guess.

Even if I'm the author of the code, I will eventually forget the why.

Use Imperative Mood In The Subject Line

Imperative mood means "used to demand or require that an action be performed". This is the mood Git uses by default, and so should you.

For example, the git revert command will create a so-called "revert commit" for you. This commit will have a subject line with an imperative mood - "Revert 'Add field to schema'".

You can think about it that you are telling the system/app/etc. how to behave. This might be awkward at first but you'll get used to it.

Note: You can write in whatever mood you prefer for commit bodies.

Restrict Subject Line Length to 50 Characters

Have you ever seen a commit message on GitHub that ends with ...? That's because GitHub truncates the subject line if it goes above 72 characters. The rest of the subject line moves to the commit body.

50 characters is the recommendation by GitHub. The limit exists to make the commit more readable. And you're forced to explain your code changes in a concise and comprehensible way.

If you're having problems explaining your code changes with 50 characters you might be committing too many changes at once. If this is the case, you should split the commit into multiple commits.

Conclusion

These are the three most important rules to follow when writing Git commit messages. If you follow these rules your colleagues will quickly understand what the commit is about.

To summarise:

Focus On The Why
Use Imperative Mood In Subject Line
Restrict Subject Line Length to 50 Characters

To learn more git commit best practices, check out this excellent blog post.

Connect with me on Twitter, LinkedIn, or GitHub

6 Lessons Learned Maintaining a Popular Open-Source Project

Simon Egersand 🎈 — Wed, 08 Jun 2022 15:18:38 +0000

Between 2016 and 2018 I maintained an open-source project with +800k downloads/month. I learned six invaluable lessons by doing this, and I will now share them with you.

How It All Started 🛫

I joined Spotify in 2016 and my team needed a React date picker component. I searched GitHub and found many but eventually decided on one. I integrated it into our website and read the code and documentation. And I quickly realized there was room for improvement in this project. So I made a few PRs to add a code linter, some refactoring, and documentation improvements.

The owner of the project was the one reviewing and approving my pull requests (PRs). And here's where I saw my opportunity! I e-mailed him and asked if he needed help maintaining the project, and he happily welcomed me to the team! Wow! It felt like I had just joined a secret club! I had always wanted to maintain a popular open-source project, and it was exciting.

Maintaining an Open-Source Project 🛠

I had never maintained an open-source project before so I didn't know what to expect! The project was popular and there were a bunch of unresolved issues and unmerged PRs. I started by resolving these and moved on to improving the code quality.

Once I got to know the code base I made more significant improvements, changes to the API for example.

Lessons Learned 👩‍🏫

Two years and 154 commits later and I learned a lot! Here are my six most valuable lessons.

People Are Bad at Reading Documentation 🗒

I spent time writing documentation and improving the onboarding experience for the component. Still, I got questions that were answered in the documentation. It kept happening, and I would try to make the documentation more visible, but it didn't help.

The habit of "I can't make it immediately work, so I'm gonna ask!" is a bad one. As a software engineer, you will need to read documentation to learn and move forward. There won't always be someone to answer your question, and then what will you do?

Good Code Is Subjective 😋

I was a junior engineer when I started maintaining this project. I thought I had things figured out, but oh boy was I wrong. I had the fortune of working with more experienced engineers on this project and I learned a lot. I was confident and thought "This is how you write good code". And then someone would make a PR that would completely go against my beliefs, and I had to re-evaluate what good code looks like.

Now as a senior engineer I see that good code is not always objective. Sure, we agree on some good practices. But there will always be someone that disagrees with you, and with good reasons!

Good Git Commit Messages Are Rare 🤔

This is what surprised me the most about maintaining an open-source project. In an open-source world on GitHub using Git we have a limited space to communicate with our future selves. We should use that space wisely and by best effort try to be as clear as we can when writing commit messages.

That's how I feel anyway, but most people don't seem to agree. I would see PRs without any description and a commit message saying "Fix render bug". Not only is this a bad practice, but it also slows down the process of getting your PR merged.

Merging Someone Else’s PR Is a Great Feeling 😍

If you ever contributed to an open-source project you know the feeling of getting your PR merged. It feels great! I'm part of something bigger! And now I can tell you that it also feels great being the one to press the Merge button. It's a win-win-win situation. The PR author, the maintainer, and the people using the project all win.

People Are Awesome! 🤩

People take time out of their lives to contribute to a component used by people they don't know. This is what open-source is about, in my opinion. People coming together for the greater good. If you're not contributing to an open-source project today, give it a try. If you are, keep doing what you do, you are awesome ⭐️.

It’s Fun but Can Get Exhausting 😰

I had fun maintaining the project, but no matter how much time I spent fixing bugs there would always be new ones. The component was more complex than I first thought. At times there seemed like there was a never-ending stream of new issues being created.

It was basically me alone maintaining it, at this point, with support from a couple of other people. I felt a responsibility because there were real people having real issues. And I could help by fixing the bugs. And so I did. A lot. But it never stopped, and that's when I got exhausted.

Why I Stopped ✋

After two years of working on the project, I realized one day it had gone a month without me touching the project. This is when I decided to stop. I e-mailed the owner and explained. He said it was cool and thanked me for the help. He even sent me some Stuff We All Get (SWAG) from his company! A t-shirt and some stickers. Thanks, Javier!

Conclusion

Maintaining an open-source project is fun. People are awesome! But it can be exhausting.

Here's a summary of the lessons I learned:

People Are Bad at Reading Documentation 🗒
Good Code Is Subjective 😋
Good Git Commit Messages Are Rare 🤔
Merging Someone Else’s PR Is a Great Feeling 😍
People Are Awesome! 🤩
It’s Fun but Can Get Exhausting 😰

If you ever get a chance to try it I recommend you do. There are a million projects out there looking for help, be brave and start contributing! You have nothing to lose.

Connect with me on Twitter, LinkedIn, or GitHub

Originally published at prplcode.dev

Boost Your Software Engineer Career With These 4 Soft Skills

Simon Egersand 🎈 — Tue, 31 May 2022 13:30:59 +0000

Being a good software engineer is not only about your technological skills. You are working with people, and so you need what's called soft skills. Soft skills are at least as important, if not more, as technical skills to progress in your career.

In this post, I'll share my favorite soft software engineer skills you need to progress in your career.

4 Soft Skills to Boost Your Software Engineer Career

Teamwork 🤝

If you ever work at a company you will most likely work in a team. You will work with other software engineers, an engineering manager, and maybe even a product manager. You must learn how to work together with them.

I've seen examples of people who fail to work with the team, and the entire team suffers because of it. Not to mention, it will seriously stagger your progression in your career.

What It Means to Work in a Team

To work in a team is different from working alone (duh!). You need to consider your team members and include them in your decision-making. Maybe you will need to get your code reviewed before shipping to production. This forces you to learn how to create pull requests (PR). Preferably PRs that are easy to review.

To summarise: When you work in a team, you have to think about the people you work with. This applies when you make decisions, write code, communicate, and more.

How Do You Work in a Team?

So how do you work in a team? Most of us learn this the hard way. I certainly did. Here are the best tips I've learned along the way:

Be empathetic. 💚 Always. Your team might consist of members with different backgrounds. Maybe from different countries. This is a good thing! You should leverage this instead of trying to do things your way. See things from other's perspectives and you will learn something new, that's a promise.

Do the things you commit to. It's a big pet peeve when someone says "Yeah, I'll take care of that" and then don't. It's fine to don't do everything you commit to, but then you should communicate that to your team. "I know I said I would do X, but something happened and I didn't have time, can someone else do it, please?". It doesn't have to be harder than that.

Assume best intention. You should always assume your team members have the best intention when they do or say things. Lose trust in your team and you'll suffer negative effects for yourself and your team.

And lastly, life happens! This is something my manager always says, "life happens". It means that life is unpredictable. Things will happen in people's lives that they cannot control. These things might impact their work, and that's normal. Don't judge someone because they're unable to perform at their max, take a day off, or miss a meeting. To take care of a sick child, partner, or anything else is more important. Life is unpredictable! Work is just one part of life.

Communication 🗣️

You will need good communication skills when you work in a team. You will have meetings, lots of them. Daily stand-ups, project discussions, retrospectives, and more. In these meetings, you should share what's on your mind and what you have been thinking about.

If you don't communicate it might reflect poorly on you. Your team might not think that you care, or that your mind is elsewhere during the meeting. It's OK to not have an opinion, but you can still communicate by asking questions.

Compromise

If you can't compromise you will have a hard time as a software engineer. It's a skill you will need to learn, like it or not. Sometimes you need to compromise on the code you write. It might accumulate tech debt, but in the grand scheme of things, it makes sense. At other times you have to compromise with a team member on what approach to take. Swallow your ego and accept it.

Positivity 😸

And lastly, positivity! Who wants to work with a grouch? No one! Positivity and kindness go a long way. Who doesn't love the person who comes into the office and greets you with a smile? :)

Conclusion

These are my four favorite soft skills as a software engineer. I guarantee you that these soft skills will help your career. Being proficient in the technical aspects of being a software engineer is very important. But the soft skills are what make people want to work with you, and can open up new possibilities in your career.

Because honestly, who would you rather work with? Some grouchy technical genius who lacks empathy, or an average programmer that you connect and have fun with?

Learn More About Software Engineering

Connect with me on Twitter, LinkedIn, or GitHub

Originally published at prplcode.dev

Deploy An Express Node.js Application to Heroku Quickly and Easily

Simon Egersand 🎈 — Sat, 28 May 2022 13:55:57 +0000

With Heroku, you can deploy your Express Node.js application to production in just a few steps. In this post, I'll show you a step-by-step guide to deploying your Express Node.js application to Heroku.

To quickly get started you can use my repo template simeg/express-heroku-example.

What is Heroku?

Heroku is a Platform as a Service (PaaS), and should not be confused with Service as a Service (SaaS). It offers a hobby plan where you can deploy your applications for free, with some limitations.

For all my hobby website projects I use Heroku. I've created things like sudoku-js and impossible-tic-tac-toe. See the About sections for links to the applications.

Preparation

First, install the Heroku CLI. If you're on macOS run

$ brew tap heroku/brew && brew install heroku

Otherwise, head over to Heroku's website.

Deploy Node.js Application to Heroku

Now that you have the CLI installed, we can start writing some code. We will use a minimal example with an HTTP Express server.

Node.js Application

Bootstrap a Node.js application with npm init. Then add Express as a dependency with npm i --save express.

Now let's look at our slim Express server in index.js.

You can read more about Express here.

This HTTP server is simple. It has one GET endpoint which returns the 200 and the text Hello World!.

Now that we have the server ready, we need some extra things to be able to deploy it to Heroku. First of all, we need a Procfile.

This is the file that Heroku reads when it starts the application. As you can see the file runs npm start, so we need to create that too. We add it to package.json.

Also, notice the engines section. This is for Heroku to know what runtime to use to run your application. You can see what Node.js versions Heroku support on this site.

Deploy to Heroku

There are a few ways to deploy to Heroku. We will use git which is the easiest way.

Now that all the code is written we need to commit it.

$ git add .
$ git commit -m "Initial commit"

Then we need to create an application on Heroku.

$ heroku create

This command also adds a git remote called heroku. This remote is where we push to deploy our application. Let's do that now!

$ git push heroku main

At this point, Heroku will try to figure out what build pack to use. Essentially, what type of application are you deploying? Because we have a package.json file in our root, it knows it's a Node.js application.

When the command is done it will output a URL. Let's open it!

...
https://thawing-beyond-32509.herokuapp.com/ deployed to Heroku
...

And we can see Hello World! in the browser. Easy as pie!

Now you can check the logs for your application.

$ heroku logs --tail

Conclusion

Now you know how to deploy a Node.js application to Heroku. Heroku provides great tooling to quickly get something up and running. But this is just the start! Express allows you to build complex web applications. And with Heroku, you can quickly deploy them to production.

Check out Heroku's Best Practices for Node.js Development for tips and tricks. And their page about Node.js is also useful.

Connect with me on Twitter, LinkedIn, or GitHub

Originally published at prplcode.dev

Why Learning Functional Programming in JavaScript Will Make You a Better Developer

Simon Egersand 🎈 — Mon, 23 May 2022 14:58:48 +0000

Functional programming (abbreviated as FP) is a programming paradigm that's popular in JavaScript. JavaScript treats functions as first-class citizens and this makes it easy to write functional programming in JavaScript.

This post will tell you the basics and benefits of functional programming and how to use them in JavaScript.

What is Functional Programming?

Functional programming is a way of writing software with specific principles. The idea is that these principles will

Make it easier to write, test, and debug the code
Make it easier to reason about the code
Improve developer productivity
And more

Core Principles in Functional Programming

Pure Functions

Functions should be pure. Pure functions always produce the same output and have no side effects affecting the output. Side effects are anything that's outside the control of the function. E.g. any input/output (I/O) such as reading from a database/file or using console.log. Or even a static variable.

Here's a simple example

But I Need I/O?

An application without I/O is not that useful. Functional programming is not about eliminating I/O. Instead, you should separate the business logic from I/O. Any side effects should be handled at the edges of our processes, and not in the middle of them. By doing this you achieve pure business logic that is easily testable.

JavaScript is not a purely functional programming language. So there's nothing from stopping you doing whatever you feel comfortable with though. Haskell, on the other hand, is an example of a purely functional programming language. In Haskell, you're enforced to use the functional programming principles.

Immutable State

Immutable state means that the state should not change. Instead of changing the state, in functional programming we copy it. This might seem counter-intuitive: why would we want to copy state instead of changing it?

In JavaScript, you can pass values by reference. This can be dangerous. Let's look at an example.

Recursion

With recursion, lists are not iterated using for, while, or do...while because they mutate state (increasing the counter, for example). Instead, in functional programming functions such as map(), filter(), and reduce() are used.

The word "recursion" scared me for a long time, I have to admit. But in JavaScript, you can quickly see the benefits of readability and productivity using these functions.

Let's look at an example!

Functional Programming in JavaScript

I showed you briefly how to use map() already. Let's dig into it some more.

map() iterates over your list, one element at a time, and lets you replace it with something new. This is useful for updating a value for all elements in a list, for example. It then returns a new list, leaving the old one unmodified. So it follows the functional programming principle of not modifying state.

And there are two more functions you should know about, filter() and reduce().

filter() will let you filter out unwanted elements from a list. This is useful for removing elements that meet certain criteria from a list. E.g. "filter out fruit that's more expensive than 5. And just like map(), it returns a new list.

reduce() will let you "reduce" a list of elements into a single value. This is useful for working with numbers.

This function was the hardest one to understand for me. I recommend you check out the MDN Web Docs about it.

Conclusion

Now you know what functional programming is about, why it's useful, and how to use it in JavaScript. It might take some time to get used to but it's well worth the effort. The functions we covered are available in all major programming languages. This is not something specific to JavaScript.

Connect with me on Twitter, LinkedIn, or GitHub

Originally published at prplcode.dev

Top 4 Free Coding Resources for Students

Simon Egersand 🎈 — Mon, 16 May 2022 15:19:04 +0000

As a student, free coding resources allow you to try out professional tools and services that you otherwise would have to pay for. Fortunately, there are companies that realize the value of allowing students to try their services for free. If you're a student, use this opportunity to get your hands on some quality resources!

(I am not affiliated, associated, authorized, endorsed by, or in any way officially connected with any of these companies)

Free Coding Resources for Students

GitHub Student Developer Pack

This is most likely the best free coding resource for a student you'll find. You'll get access to a TON of services, subscriptions, and credits. Get a free domain, experiment with a cloud provider, free premium courses, and a lot more. For example:

1-year domain name registration on the .me TLD (Namecheap)
$100 in platform credit for new users (DigitalOcean)
12-month subscription of Canva's Pro tier (Canva)
Access to 25+ Microsoft Azure cloud services plus $100 in Azure credit (Microsoft Azure)
6-months access to all courses and workshops (FrontendMasters)
And more!

I used this when I was a student to deploy a website with my own domain. And to get access to a bunch of awesome courses. I learned a lot, which helped me get a job at Spotify.

JetBrains Free Educational License

JetBrains is the company behind the popular IDEAs: IntelliJ, WebStorm, PyCharm, and more. As a student (or teacher) you get access to the professional versions.

Personally, these are my favorite IDEAs and what I use in my day-to-day. When I was a student, I tried a few IDEAs but JetBrains products are simply the best, in my opinion. I won't go into why, but I do recommend you pick up a license.

Heroku

Heroku is a platform to deploy your applications. You can for example deploy a website or a backend service. Additionally, Heroku allows you to attach resources such as a database, monitoring, and more. They provide step-by-step guides which makes it easy.

Most of these resources can be used with the free hobby tier, which makes it perfect for personal projects. I've used Heroku for many years. It's my go-to service to deploy personal projects and make them available on the web.

The free hobby tier is not specific for students, anyone can use it!

Unity Student Plan

Is game development more your kind of thing? Then you should check out the Unity Student Plan. Unity is a cross-platform game engine that was used for games such as Overcooked, Disco Elysium, Hollow Knight, and more. I mean, just look at this list!

The gaming industry is growing, fast! And that comes with a growing need for game developers. Getting experience with an application like Unity will make it easy to find your first job.

Conclusion

These are my top four free coding resources for students. I remember discovering these when I was a student and found it quite amazing they are all free. If you're a student, be sure to check them out. This is an opportunity to experiment with tools and services that professionals use.

Connect with me on Twitter, LinkedIn, or GitHub

Originally published at prplcode.dev

How My GitHub Profile Landed Me a Job at Spotify

Simon Egersand 🎈 — Sun, 15 May 2022 09:50:41 +0000

This is the experience of how my GitHub profile got me a job at Spotify. The key was my GitHub profile and the various repos I had worked on the years before. This post will be personal, and the key takeaway is the importance of a portfolio. It doesn't have to be a good portfolio (mine certainly wasn't). But having a portfolio can be the difference between getting the job or not.

Spotify Interview

Before Spotify, I worked as a software engineer at a different company. It was my first job after university and it was all right. I learned how software was being developed professionally which was fun and interesting. One day, I get an e-mail from Spotify and they were asking for applications for 3-month internships. I immediately sent them my CV.

A couple of days later I receive a phone call and I get called for an interview. The day of the interview is approaching and I'm starting to feel sick 😨. On the day of the interview, I had a fever, but I took some medicine and went there anyway. The interview did not go well. We talked and did some coding exercises on the board. I completely blacked out (partially because of the medicine). The last thing I said was "Please, check out my GitHub profile" and they said they would.

After the interview, I was so disappointed in myself 😔. I returned home to my job, which now seemed boring and bleak.

The Call Back

A few days pass and I get a phone call. It was the recruiter! He said they liked me and would like to offer me the internship! Wow, what a feeling! 😃 I accepted, and a few weeks later I quit my current job. My friends and colleagues were surprised I would quit my full-time job for a 3-month internship, but I didn't care. My two greatest passions in life are technology and music, and I was going to be working with both! 💻🎸

Internship Ends

The deal with the internship was, that if they liked me they would offer me a permanent job. The date when my internship was ending was quickly approaching. I was nervous, but I had learned so much and met a lot of people from different parts of the world so I was happy either way. We had a meeting and they said they would like to offer me a permanent job. Again, bliss! I felt such a relief and of course, excitement!

My GitHub Profile

Later, I was talking to someone in my team about my interview. I told her how bad it went, and how surprised I was to still get the offer. She told me something like "Yeah, they told me it went bad. But when we looked at your GitHub profile we saw that you actually can code. And that's why we wanted you".

My profile did not contain a lot; some HTML, CSS, and JavaScript websites I had built for fun and to learn. Before the interview, I looked through the code to make sure it looked nice and tidy.

Conclusion

I got an internship that later led to a permanent job at Spotify, thanks to my GitHub profile. I realized how crucial having a portfolio is. It doesn't have to be the best, just something to show what you can do. This was 6 years ago. I still work at Spotify, now as a Senior Software Engineer. It turned out to be an amazing place to work so I haven't found a good reason to leave.

If I can do it, you can too!! 👊 Thanks for reading.

Connect with me on Twitter, LinkedIn, or GitHub
Originally published at prplcode.dev

Vim — Why You Should Use It!

Simon Egersand 🎈 — Sat, 14 May 2022 13:38:04 +0000

Vim is a powerful text editor, and in this post, I will convince you to use it. Feared and loved by coders and writers, it’s a controversial text editor, and with good reasons. It has a steep learning curve, but it’s well worth it. In this post, I’ll explain why you should use Vim or Vim key bindings in your favorite IDE.

What is Vim?

Vim is a free and open-source text editor. It was first published in 1991. The name stands for Vi IMproved (vi is a different text editor). It's known for its steep learning curve and how hard it is to exit. As of today, 2.6M people have viewed the question "How do I exit the Vim editor?" on StackOverflow. But don't let this frighten you! (and by the way, it's :wq to save and exit)

Why You Should Use Vim

Here are four reasons why you should use Vim (or Vim key bindings).

Efficiency

The key bindings. They are optimized for efficiency, so your hands stay where you learned to put them: left hand on asdf and right hand on jkl. It offers many shortcuts and forces you to only use the keyboard (that's right, throw away your mouse!). Once you learn the shortcuts, even the basic ones, you'll quickly be more efficient at writing text and code. You can edit text, navigate your document, and execute commands without leaving Vim.

I won't go into details here exactly what key bindings are available. Read on to find out where to learn them.

Vim key bindings are available for all popular IDEs. So you can enjoy all the cool modern features while using Vim's awesome key bindings.

Customizable

Not only does it come with a ton of shortcuts, but you can also create your own! And even your own plugins. There's a big community for plugins. At VimAwesome there are currently ~20k plugins available. And there are many plugin managers to make it easy to manage your plugins.

When Vim starts it reads a configuration file called .vimrc. This is where you put your custom shortcuts and load your plugins.

It's Available Everywhere

Vim is available pretty much everywhere. Whether you're using Windows, macOS or a UNIX based distribution, it's there. This makes it convenient to work in environments without graphical user interface (GUI). Such as a Raspberry Pi.

There are even extensions for your favorite browser that adds key bindings.

Vimium (Chrome)
Vimium-FF (Firefox)
Vimari (Safari)

You Will Feel Awesome

I saved this point for last but it might be the most important one. Using these key bindings will make you feel awesome, I promise. Your coworkers will envy your speed, and your parents will consider you a genuine computer wizard! 🧙‍♀️

Now that I've convinced you to use it, let me tell you where you can learn it.

Where to Learn

I recommend you start with vimtutor. It's an application available in macOS and UNIX based distributions. For Windows, you need to install Vim to get access to it.

Simply type vimtutor in your terminal to start learning!

Once you learn the basics there's this awesome cheat sheet. And endless tutorials online.

Conclusion

Vim is a powerful text editing application that’s heavily used by software engineers. There are key binding plugins for all major IDEs, so you can enjoy the cool features of your IDE while still using Vim key bindings. It's highly customizable and its community is very active. Start learning today by typing vimtutor in your terminal!

Connect with me on Twitter, LinkedIn, or GitHub

Originally published at prplcode.dev

Why Testing Your Code Is Important

Simon Egersand 🎈 — Thu, 12 May 2022 15:08:01 +0000

Testing your code is an important part of the software development process. It's how you confirm that your code behaves as you want it to. It also allows you to find and fix bugs early on before they have a chance to cause problems in production.

In this article, we'll go over why testing your code is important. There are many different ways of testing your code, and we'll cover the most important way -- unit testing.

Always Test Your Code

Before we talk about the why's, let's talk about the what. What is code testing? It's making sure your code works the way you want it to work. Easy as that.

Now, why should you bother testing your code? Imagine you have a program with a single module. It's responsible for one thing and one thing only. Testing it might seem like overkill (but I recommend always testing your code). Now imagine your program has five modules that all do different things. Additionally, the modules communicate with each other. Your program now has many possible states and testing all states manually will take up a lot of your precious time.

Instead, you should write tests to confirm the behavior! By testing your code, you also protect yourself against breaking features when you add new code. You want to write quality code, right? That's not possible without testing it.

Unit Testing Your Code

There are various types of tests that you can run on your code, but unit tests are the most important. They allow you to test individual units of code in isolation.

Let's look at this JavaScript function.

const incrementByOne = input => {
  if (input < 0) {
    return 0;
  }

  return input + 1;
};

Now let's write some tests. I like to start by testing the "happy path".

test('should increment by 1', () => {

  const input = 9;

  const actual = incrementByOne(input);
  const expected = 10;

  expect(actual).toBe(expected);
});

And then for the fun part; the edge cases!

test('should return 0 when negative input', () => {

  const input = -1;

  const actual = incrementByOne(input);
  const expected = 0;

  expect(actual).toBe(expected);
});

We've now tested everything, and have 100% test coverage. And we're happy, or are we?

I chose JavaScript because it's dynamically typed, and we're allowed to pass any type into our function (psst! This is a good reason to instead use TypeScript).

What happens if we pass a string?

test('should increment by 1', () => {

  const input = 'my-string';

  const actual = incrementByOne(input);
  const expected = ???;

  expect(actual).toBe(expected);
});

The function will return my-string1 because the + operator works between types in JavaScript. This is not what we want, so let's fix it.

Let's update the function to handle this case.

const incrementByOne = input => {
  if (typeof input !== 'number') {
    throw new TypeError('Only number type allowed');
  }

  if (input < 0) {
    return 0;
  }

  return input + 1;
};

And now let's add another test to our test suite.

test('should throw when non-number input', () => {

  const input = 'my-string';

  const expected = new TypeError('Only number type allowed');
  expect(() => incrementbyOne(input)).toThrowError(expected);
});

This was a simple example. Websites and programs are never trivial though, and I hope you can see the value of testing your code now. Testing your code is a crucial part of delivering high-quality software. And it should be a fundamental part of your software development process!

Unit testing is not a silver bullet, and it is not a substitute for other forms of testing, such as system testing and user acceptance testing. But, unit testing is an important part of the software testing process and should not be ignored.

Conclusion

When it comes to code, testing is key to avoiding bugs and ensuring that your code runs as expected. By taking the time to test your code, you can avoid costly mistakes and ensure that your code is ready for prime time.

Enjoyed this post? Then check out Stop using meaningless test values!

Connect with me on Twitter, LinkedIn and Github

Originally published at prplcode.dev

6 Mistakes Junior Developers Make and How to Avoid Them

Simon Egersand 🎈 — Tue, 10 May 2022 14:49:40 +0000

Junior developers make many mistakes. Believe me, I’ve been one myself. But there are ways you can avoid them.

In this article, we’ll take a look at 6 of the most common mistakes junior developers make and offer advice on how to avoid them.

Mistakes Junior Developers Make and How to Avoid Them

1. Focusing on Code Instead of the Big Picture 🖼

It’s easy to get bogged down in the details when you’re starting out. But it’s important to remember that code is only a small part of the development process. Focusing on the big picture will help you understand the overall goal of your project and help you make better decisions. To come up with good solutions you need to spend time thinking. Do you think the author of React came up with the idea for the framework in a day? Not likely.

2. Not Reading Documentation 📄

Junior developers often don’t read documentation, or they only read it superficially. But the fact is, that documentation is an important source of information. And you need to read it in-depth if you want to be a successful developer.

Documentation can help you learn the syntax and usage of a language or library, as well as how to use a tool or library properly. It can also help you understand the API for a particular software system. So, be sure to read the documentation.

3. Ignoring Best Practices

Best practices are there for a reason – they make development faster, easier, and more reliable. Junior developers can speed up their learning process by paying attention to best practices and following them.

4. Not Asking Questions 🙋‍♀️

Another common mistake junior developers make is not asking questions. Again, this can be due to a lack of confidence, or feeling like you should already know the answer.

But the fact is, you won’t know everything, and you won’t always be able to figure things out on your own. Asking questions is a good way to learn and gain knowledge. Not asking questions can lead to misunderstandings and errors.

5. Underestimating the Importance of Practice

Junior developers often underestimate the importance of practice. It’s not enough to just learn the theory – you also need to practice what you have learned.

Practice makes perfect, and the more you practice, the better you will become. Try to find opportunities to practice your skills, whether it’s through tutorials, exercises, or projects. No one is born a great developer, everything takes practice!

6. Forgetting to Celebrate Small Victories 🎉

It can be easy to get caught up in the work and forget to celebrate your successes. Taking the time to celebrate small victories is an important way to stay motivated and keep up your morale.

Avoiding these mistakes will help you move up the career ladder quickly and smoothly. But don’t forget that everyone makes mistakes – the key is to learn from them and move on!

Conclusion

It’s important for junior developers to understand common mistakes so they can try to avoid them. By becoming aware of the most common errors, junior developers can focus on fixing these issues and become better developers.

Learn More About Software Engineering

Connect with me on Twitter @prplcode

Originally published on https://prplcode.dev

8 Habits of Highly Productive People

Simon Egersand 🎈 — Mon, 09 May 2022 14:43:06 +0000

There are habits of highly productive people that make them accomplish a lot, every day. Did you ever have one of those days, where you finished everything on your to-do list? Imagine having those days every day. This is what the days for highly productive people look like and here are some of their habits.

Productive People Are Just Like Us

Productive people are not robots. They are like you and me, with the difference that they know where and how to spend their time to get things done. By practicing their habits we can all become more productive. It won’t happen overnight but every little step counts!

Habits of Highly Productive People

1. Don’t Multi-Task

At first, this might seem counter-intuitive. But it’s a scientific fact that doing two things at the same time reduces your productivity.

Doing more than one task at a time, especially more than one complex task, takes a toll on productivity.
American Psychological Association

Our brains are bad at context switching, which is exactly what happens when you multi-task. Like with computers, context switching (for threads) is expensive. So if you’re doing something else while reading this article — one thing at a time, please!

2. Take More Brakes

If you spend more time working, you’d expect more results, right? Unfortunately, that’s not how our brains work. We get distracted and lose focus after working for a longer period of time. Research shows that breaks, even as short as 3 minutes long, improve your productivity. And if you add some stretching exercises with your breaks you’ll be even more productive.

These results provide evidence that frequent short breaks from continuous computer-mediated work can benefit worker productivity and well-being […]
HENNING et al., 2001

3. Focus on the Most Important Tasks First

Start your day by taking a few minutes to make a to-do list with all the tasks you want to finish. Then rank them, and start working on the most important one. By doing this, you reduce the risk of procrastination. Because it’s easy to spend the day doing the easy tasks that are less important. Instead, you should spend your time on the most impactful tasks you have.

4. Apply the 80/20 Rule

The 80/20 rule (also known as the Pareto Principle), says that only 20% of what you do each day produces 80% of your results. With this in mind, highly productive people identify 20% of their most impactful work for the day. The 80% that’s left they try to cut from their schedules to find more tasks that will have more impact. And this is what you should do too! Do it tomorrow and you’ll notice the difference.

5. Do The Challenging Tasks Before Lunch

We all know the feeling of coming back from lunch and sitting down, trying to get back into the zone. It’s difficult because our bodies are busy! It’s spending energy ingesting and processing the food we consumed. This is why you should do your most challenging tasks before lunch. Repetitive tasks or meetings you can save for after lunch. By maintaining a schedule like this you’ll definitely be more productive.

6. Automate The Repetitive Work

Performing repetitive work not only kills your motivation but also hinders your productivity. If you find yourself in this position try to think of ways of automating this task. This can be simple things such as:

Learn keyboard shortcuts
Compose a list of steps for common tasks (what is also known as an algorithm)
If you have programming knowledge, write a programming script for a common task

7. Get a Good Day’s Start

Studies have shown that morning is the best time of day for creative thinking. To give yourself the best chance for creative thinking you need a good morning ritual. A healthy breakfast, meditation, reading, and exercise are activities that sharpen your brain.

Especially in these times of remote work (see here to read about 4 Lessons Learned Working Remotely for +2 Years), it’s easy to neglect the importance of a good morning ritual. To be highly productive you need to get a good day’s start.

8. Identify and Reduce Distractions

If you’re like me, you’re getting distracted throughout the day by e-mails and push notifications. If you want to be productive you need to identify and reduce these types of distractions. This you can do from your phone or application settings. Ask yourself, do you need a sound notification when you receive an e-mail? Getting into the zone takes time but you can easily get brought back out of it by a single sound notification. Value your productivity higher!

Conclusion

To summarise:

Don’t Multi-Task
Take More Breaks
Focus on the Most Important Tasks First
Apply the 80/20 Rules
Do The Challenging Tasks Before Lunch
Automate The Repetitive Work
Get a Good Day’s Start
Identify and Reduce Distractions

You too can become a highly productive person! It’s not magic or unhealthy, it’s a mindset and requires dedication. Personally, I’m not a highly productive person but I’m working on it every day. While it’s hard sometimes I remind myself it’s for the best.

Connect with me on Twitter @prplcode

Originally published at https://prplcode.dev