
# On burnout

This is not one of those "5 Steps To Tell If You have burnout" types of blog. This is about how burnout affects me and how I manage it.

What is burnout? I won't pretend you don't know what it is. I think everyone has or will experience it at one point during their career. Burnout and Impostor Syndrome are the two mental health issues software engineers are very likely to experience.

Some people are not very aware of their emotions, but they still find a way to be felt. The first time, for me, burnout was mostly physical. I blamed it on the stress caused by my job. It might've been true then, but now, thinking back, I know for sure it was burnout. Switching jobs fixed it, so I didn't give it much attention until it came back again. When it comes back, you feel it more intensely. Running away is not always an option, so now, I try to prevent it. We'll see what steps I take a bit later in the post.

There are 2 types that I've experienced: external and internal. Most of the literature on the subject is on external burnout. Your boss works the living light out of you until there is nothing, that's burnout. When you talk to a friend and explain your situation, it's easy to find this kind of burnout. "Your boss is such a jerk!", you will hear often. Sometimes you can do something about it, but mostly things are out of your control. The loss of control can feel overwhelming, especially when it during a long period of time! This can take a toll on your mental health and help fuel burnout.

Internal burnout is another kind of beast. You are just floating around with no direction, you have plenty of achievements, but they are not enough. It could be that you are experiencing internal burnout. I would imagine internal burnout is what a mid-life crisis feels like. I would also imagine, given the way things currently are, mid-life crisis happens to people in their 20s and 30s.

It's pretty clear that overworking yourself can burn you out, but what happens when you do little to no work. Some software development practices have periods in which developers suffer code freezes and work-life is reduced to 0. This can feel great, especially if you overworked yourself for the release. I've experienced this little voice in the back of your head: "You need to be working right now, why do you waste all day not doing work?" You find yourself doing meaningless work or nothing at all. This burned me out as well! Again, I felt this feeling of floating around in space, not going anywhere.

I told my colleagues, there is nothing to work on! They suggested I study something new, now that I have the time. Can you see where this is going? I had the time, but I didn't have the drive. There was no problem I had to solve, no direction to float towards. I've been experienced guilt, so much wasted time! Instead of embracing the rest time I had to work on my burnout, I've been burning myself more. Do you do the same?

It is important to know what burnout feels like. To fix it, you have to be aware of it. Imagine trying to work, but something pulls you back, you don't know why and you just say you are lazy. "I just have to power through the pain." You ignore what you feel, you push it away. It will come back punching, believe me. Next time you feel you are lazy, ask why?

If you take something away from this blog post, it should be this: **you should always take a second to acknowledge how you feel and resolve why you feel like this**. There is only 1 step before fixing and that is noticing. I keep this personal page in my note tracking app. When I feel a negative emotion, I write it down to think about it later. Usually, before going to bed, I look at what I wrote down that day. _When X person wrote a code review on my pull request, my first feeling was anger, and I had a feeling of proving my point (which was wrong)_ (that's an actual example.) I thought, they were just trying to make my code better, but my ego got in the way. After I process the emotion I erase the text. Feels great and it also helps me get to sleep faster! Enough sidetrack, let's go back to burnout.

Let's go through some experiences that can cause burnout.

> Why should I bother doing this feature? I think it's pointless! It won't help anybody.

Sometimes there is a disconnect between business and development. If communication doesn't go both ways, it will cause the part that develops the software burnout. You keep working on stuff that nobody will use, or a feature that is done in an unintuitive way. You try to talk and explain yourself, but with no success. Ego and bad communications skills get in the way of your words. This can be a good time to improve your negotiation and communication skills. When you expose problems clearly and provide solutions, you can sometimes get your way. But, try and continue failing and burn yourself out. Tradeoffs...

> My boss overworks me, I've told them it's not ok, but nothing changes.

Most people would say you should quit your job, but I think that is not considerate at all. Saying that myself, I know I didn't think about the other person's feelings, I just experienced a negative emotion and I had a reactionary answer. Just listen to the other person, ask them why they keep working so much even though they know it's not healthy and sustainable. It can be feelings of inadequacy or they are going through hard times and they need the bread to keep coming to the table. Sometimes your circumstances are not what you would like. Keep working, but for a better environment. Make the changes necessary or change the job!

> Deploying the app is really stressful, I have to do so many manual steps, and I'm afraid to mess something up.

This one happened on a project I worked on. We had to rush out features for a release, there was no time for automating the deployment or good quality code, to be honest. I had to deploy changes to a database. It was a reporting database that was updated a few times a day. During the deployment, we cloned the database, switched traffic to the other one until we made sure everything worked out with our features. I had to manually deploy, check, and cleanup. Doing this for a while caused a lot of stress and caused me burnout. I should have taken the time to do a proper deploy pipeline. This would have saved me so much time and suffering. Don't do the same!

> Edge case doom loops.

I think we've all had to implement something we did work with before that is complex. We can't rely on experience. The task is a bit too difficult to be able to achieve a flow state. You figure out an edge case, you take a breather to figure it out. 2 hours passed by, you are overworked, yet nothing came of it, except anxiety! The workday is over, but you can't clock out. The feeling of anxiety and the need to solve all the edge cases is still there. The next day it's all the same, you are stuck in your own head. Feelings of guilt take over because you had to do your job and you didn't. To solve this I have 2 solutions. One is hard: you have to catch yourself when you do this and write down your thoughts. The second one is TDD. I have written a previous blog post on it (link [here](/posts/testing-javascript).) When an edge case pops out, take your head away from it by writing a test. It's not solved yet, but when you'll get to it, you'll get to it. It's all-natural, you can concentrate on the problem at hand and solve the issue later. You know there is that game for toddlers, where they have a board and different shapes. TDD is building the board for you, so you can jam code-shapes into it. At the end you take a look at the board, you take out some pieces and place them in easier, instead of jamming. The workday is done, the tests are written and the feature developed. You clock out and get on with your life.

Do these questions feel familiar? Pushing the answer away will push you 1 step towards burnout. **Our mind has ways to tell us the pain we feel should be removed, and burnout is one of those ways**. Next time, listen.


On burnout


# Conducting interviews as a software engineer

There is a lot of information out there on interviews. I would say most of it is information on how to be a good interviewee, not a good interviewer. I also think that the interview mini-game is not played right and is plagued with wrong behaviors.

Conducting interviews is one of those skills that nobody is taught. You see how the people that interview you behave and you will copy them once you begin conducting interviews yourself. Speaking on my behalf, bad interviews are energy drains, no matter which side of the table your chair is in. Let's see how we can improve this experience.

You have to make sure you know what the purpose of the interview is! Make sure you speak with the people person inside your company responsible for the hiring process. What is the purpose of the interview? It could be seniority level (senior, junior, unicorn, ninja) or the ability to communicate solutions to complex problems.

## About starting the interview

I like to start out by asking about prior job experience. You should study their resume and have some questions prepared. Listen carefully and make sure the other person knows you are engaged in the conversation. Don't talk about yourself unless asked to. I've been part of interviews where people conducting the interview won't stop talking about themselves and their experiences.

If you have questions, make sure they are well thought out. Don't ask: _Tell me about yourself_. It's a bit too personal and way too open-ended. Stay away from: how old are you, do you have a partner, do you plan on having children. Those questions are creepy, and, in some places, illegal.

The start of the interview should be easy-going. You just want to get to know the other person.

> Tell me one thing that you had to struggle with in your career.

Bad managers, horrible colleagues, spaghetti codebase, caffeine addiction. People get to deal with lots of things and trust me, they have an answer for this question.

> What is a difficult problem that you had to solve.

This one, I have to admit, is mostly for myself. I love to hear solutions to difficult problems. Sometimes you see a problem they hated to solve, sometimes it's something they love.

Respect their time! We live in a society where people pay with their time to get interviewed for your company's job. Try to be concise and efficient with your time.

When you have a good sense of the interviewee, it's time to ask something technical. Avoid the pop quiz strategy of asking: what is **insert javascript technical term like closure, this, prototype**. People study those terms for interviews. Find real code examples and have the interviewee explain what is going on. Don't make them feel bad about not knowing or getting some things wrong. Explain the concept briefly and move on. If they have a bad time, don't be mean. Let them know everyone is not at 100% during interviews, as they might be difficult at times.

## What to ask

Don't test like your high school math teacher. This should feel like a discussion between colleagues, not that time your literature teacher quizzed you about some dull novel that you spaced out while trying to read. Have a bit of awareness of how the conversation is going. Acknowledge from time to time that interviews are not quizzes, but conversations. We are people, stress doesn't always bring up the best in us. If the person you are interviewing doesn't feel stressed, you will get the best impression of who they are.

A good skill for software engineers to have is to break complex problems into smaller ones. Sometimes I ask about problems we had to solve during the job, like a bug or a complex feature. Have this prepared. If you just thought about this on the fly, chances are you won't explain it properly. If nothing comes up, ask people to break down youtube or facebook into components (this can be a frontend and a backend question). If you take notes, make sure you let them know. If you type while they answer it might look like you are not paying attention.

> Center this div

Oh, how horrible is this one. For some people flex is not enough. You have to use this cryptic solution that will never go past code review. If you have to test for CSS knowledge, find a more creative problem. Have a simple design that they can implement or a fun CSS Battle exercise. You want to test for the ability to do their job, not some weird edgy problem.

I don't enjoy live coding exercises, but if you do there are some things you should keep in mind. Don't write code on a whiteboard, unless the person chooses to do this. Let them know there is going to be some coding involved. Ask them what they prefer to type on, so you can have it prepared. They can bring their own laptop or do the interview over the internet.

> Here is this algorithm you will never use during the job. Write the solution in this MS Word document.

Don't be this sadistic. What does this elitist way of coding have to do anything with the job? First of all, who codes in MS Word? Also, nobody reverses a binary tree on the job. If you have to solve it, you can ask a colleague to explain the solution or google it. Look for what matters.

If the job requires a lot of algorithmic thinking, think of a real-world problem. If they find a solution that uses an algorithm, just stop it there. There is no point in making them implement it. Abstract the algorithm into a function and carry on.

Don't expect the interviewee to have the same preferences as you. If they enjoy redux as much as you, it doesn't mean they are a better or worse programmer. Hear the person out. If you don't agree with them, make sure you are on the same wavelength. Ask why and then say your opinion. Make a joke and move on, don't dwell on disagreements.

## Don't be tricked by your bias.

My job is best done by a person exactly like me. It's too easy to think that and to interview for that. Keep in mind not all software engineers should be the same. Heterogeneity is a good thing. Some people are good with databases, other people are great at communicating. There is a place for everyone. It's your job to determine if it is a good fit.

Some people mask discrimination with not being a good fit or incompatible with the company culture. This has happened with a person I interviewed. I thought they would be a great teammate. I gave in my good feedback and was excited to hear if they accepted the position. Somewhere up the management chain, someone decided that being of an older age would make them "not compatible with the company culture." Don't be like that, be as objective as possible.

Knowing what to ask is the easy part, you can prepare your questions before the interview depending on what seniority the interviewee is. You should have similar questions for every person. This makes it fair for everyone and it will make giving feedback easier, i.e. comparing people - ugh - easier.

## What to look for

When I first started conducting interviews, I was co-chair to a more senior person. I didn't get to talk a lot, but that was okay. Instead, I paid attention to the other people speaking. Sometimes my co-chair was getting too much time to speak and I would try to move the microphone to the other person. Not concentrating on what to ask next allowed me to be more aware of what was being discussed. People have different personalities, if you co-chair with someone, make sure you work together.

Now, the most difficult part of the interviewing process. **You need to ask questions, pay attention to the answers, and be aware of a few concepts**. It's easy to be lost in yourself, believe me. You can try to be cool and ask edgy questions - try to prove to the other person you are better, but that is not the point. You'll have plenty of time on the job to do that - just kidding, don't be an ass!

**Keep track of intuition.** Solving a problem once will, hopefully, make you solve it easier the next time. With time we develop our intuition, it makes work easier. Sometimes you ask a question and you can see the interviewee's intuition kick in. You can feel they want to stop you from speaking and answer the question. This can be a tell for someone's seniority. It goes well with the next concept to be aware of.

**Keep track of the ability to track patterns.** Redux is just like the command pattern used in Microsoft Excel. You can see patterns everywhere. As a software engineer, you have to be prepared to not repeat yourself. Patterns also make communication easier. You can only use this one object, you can't make more - Singleton. We need to send a message and some parts of the system have to subscribe to it - Observer/Pub-sub. You don't need to see how a row in a database is saved, just wrap it around an object - Facade/Adapter. You don't necessarily have to ask for the names of the patterns, just see if the person can see them.

**Keep track of commitment.** This one is really hard. Can you tell if this person will do their job? You can test for IQ, and other meaningless stuff, but are they gonna use their skills to do the job or just slack off? That's kind of a hot take, what do I mean by IQ is meaningless? You need a certain ability to be able to solve problems, but that doesn't mean that will keep you focused and direct you towards doing the job right!

Some people say "you are in IT just for the money! You have to love it! It must a hobby! You HAVE to spend your off time learning new stuff!". I say get over yourself. A job is a job, don't be romantic about it. Sometimes our job is our job, not our passion. That doesn't mean we don't do it well and don't find meaning in it. Usually, a good tell is how a person responds to a problem. You don't necessarily want to look for excitement in solving the problem. They have to have a spark. Some people feel stressed during the interview. You have to see if they like solving the problem. This one can be on you! If you ask something too edgy, they might get put off, so try to have something tailored to their persona. Design **this app that you use**. Let's make an app for **this hobby of yours**.

Most important, **Can this person be your colleague?**. At the end of the day, an interview is a simulation of you working with another person. Does the job require a lot of teamwork or is it more of a here's a task, see you when you are done-kind of situation. Can you steer the person away from a wrong path or do they ignore you completely? Do they ask questions when stuck or didn't understand?

Interviewing is a skill. Be well prepared and considerate!


Conducting interviews as a software engineer


# How do I test my code?

Writing tests can be a difficult process. From my experience, the interaction between developers and tests is not what could and should be. Some people view tests as a chore, something to do after you finished your implementation. This behavior can cause tests to be left out. Coding new features can often be a long and painful process. You might not have the willpower left to write tests. You are frustrated. That javascript library you just added to the project is not working as you expected. Who is going to write more code to prove the last 2 hours you spent have produced perfect and bug-free features? You'll play around with postman or use the part of the application you just modified and grab a cookie for a job well done.

Tests are best written while you develop your features. This can have amazing benefits! Write a test, make your code pass it, write another one, and so on. I think one of the most undervalued skills as a developer is to work in small and incremental steps. The test-first approach forces you to think this way. You should try to have your code functional as often as you can. Having to test your code will make you refactor it to be more usable. Sometimes the feature you are developing is very difficult to reach or you have to do a lot of manual steps to prepare the system to see if what you are doing works. Tests don't have this problem, once you wrote the setup for the test, it's there to be used for every test you write.

Depending on how many parts you are testing, tests have different names. I think it does not matter all that much how you call it. You should always try to write your tests in a way you get the most amount of value from the least time invested. You shouldn't try to cover all the cases that exist, just try to have the happy case covered.

Sometimes you find bugs in your code while you develop. Try to reproduce that bug in a test, fix it and see the test pass. I can feel the dopamine kick that this way of working would produce, just by writing about it. Having that red test turn green is a beautiful feeling. This can motivate you to keep going if you aren't particularly feeling pumped about coding that day.

There is this cool thing you can do just before taking a break or going home (A little side note here, writing going home during the pandemic, where most of us are working from home feels a little off, anyway going on...). Write a new test, see it fail, and lock your computer. This sounds kinda evil, but it works great. You will get on with your day, but you'll have that tingly sensation in your brain that tells you that something is not finished. I guarantee you the following morning, you will rush for your coffee and get back to the keyboard to fix that damn test! A note here, if you have trouble turning off work in your free time, this will do more bad than good, so to each his own.

Let's see an example.

## TDD example

You are working on an employee time tracking app. You are a subject for burnout working on such a thing, but you take pride in your work. You are going to develop it using TDD. First of all, let's see what is asked of you.

> We need to create departments. A department can be on the top level or can be part of another department. We need to search for departments based on hierarchies. Ex: we have to see all the departments that are children or inside the hierarchy of the finance department.

We'll start with making an express server. There may be other better libraries that make working with http easier, but express is very easy to read.

```ts
import express from "express";

export function makeServer(port: number = 3000) {
  const app = express();

  app.set("port", port);
  app.get("/", (_, res) => {
    res.json({ ok: true });
  });

  return app;
}
```

It looks like a basic example (sans hello world). Let's see the test.

```ts
import request from "supertest";
import { makeServer } from "./app";

describe("GET /", () => {
  it("should return 200 OK", async (done) => {
    const app = makeServer(0); // assign a free port

    let res = await request(app).get("/");
    expect(res.body).toEqual({ ok: true });

    done();
  });
});
```

Make sure the test library you are using has a watch feature. Also make sure it has a cool-looking console view with instant feedback, red/green colors, etc. We wanna make sure we feed our dopamine receptors with all the juice we can.

### Starting the rest api

We need a `create` and `list` endpoint. They should look like this:

- GET `/departments` - returns a list of departments
- POST `/departments` - creates a department

First, the test:

```ts
it("creates departments and checks if they exist", async (done) => {
  const app = makeServer(0);

  const departments = [{ name: "marketing" }, { name: "financial" }];

  for (const department of departments) {
    await request(app).post("/departments").send(department).expect(200);
  }

  await request(app).get("/departments").expect(200, departments);
  done();
});
```

Now we have a failing test that we need to fix. To parse the JSON in the request body so we use the handy `body-parser` library. To fix the failing test, we conjure some obscure and naive solution.

```ts
interface Department {
  name: string;
}

app.use(bodyParser.json());

const departments: Department[] = [];

app.get("/departments", (_, res) => {
  res.json(departments);
});

app.post("/departments", async (req, res) => {
  const department: Department = req.body;
  // do some validation
  departments.push(department);
  res.send();
});
```

At some point, we'll use a database for persisting the data, but we don't want to do that for now. Setting up the database is a boring task, we wanna continue with the red-green stuff.
Let's wrap the adding and listing inside an injectable object that can be replaced later.

```ts
interface DepartmentRepo {
  list(): Department[];
  add(dep: Department): unknown;
}

export function makeDepartmentRepo(): DepartmentRepo {
  const departmets: Department[] = [];
  return {
    add(department: Department) {
      departmets.push(department);
    },
    list() {
      return departmets;
    },
  };
}

export function makeServer(
  port: number = 3000,
  departmentRepo: DepartmentRepo
) {
  const app = express();

  app.set("port", port);
  app.use(bodyParser.json());

  app.get("/departments", (_, res) => {
    res.json(departmentRepo.list());
  });

  app.post("/departments", async (req, res) => {
    const department: Department = req.body;
    // do some validation
    departmentRepo.add(department);
    res.send();
  });

  return app;
}
```

To fix the test: `const app = makeServer(0, makeDepartmentRepo());`. You should always test that your code returns errors. We'll do that next. The add method of our repository has the following signature `add(dep: Department): unknown;`. There shouldn't be 2 departments with the same name, let's write a test to make sure!

```ts
it("creates 2 departments with the same name and expects an error", async (done) => {
  const app = makeServer(0, makeDepartmentRepo());
  const department = { name: "technology" };

  await request(app).post("/departments").send(department).expect(200);
  await request(app).post("/departments").send(department).expect(400);

  // also make sure we don't actually save the department, despite the error.
  await request(app).get("/departments").expect(200, [department]);
  done();
});
```

I don't particularily enjoy exceptions as a way of treating errors, so let's see a different approach.

```ts
interface DepartmentRepo {
  list(): Department[];
  add(dep: Department): [dep: Department, err: Error | null];
}
```

This way of error treatment is inspired from golang. I'm 100% sure if you are not familiar with go, you will not like how this looks, but bear with me.

```ts
export const duplicateDepartmentError = new Error("Department already exists");

// the repo method
add(department: Department) {
  if (departmets.some((d) => d.name === department.name)) {
    return [null, duplicateDepartmentError];
  }
  departmets.push(department);
  return [department, null];
}
// ...
app.post("/departments", async (req, res) => {
  const department: Department = req.body;
  // do some validation
  const [dep, err] = departmentRepo.add(department);

  if (err != null) {
    if (err === duplicateDepartmentError) {
      res.status(400).send({ error: duplicateDepartmentError.message });
    } else {
      res.status(500);
    }
    return;
  }

  res.send(dep);
});
```

## Adding data persistence

We played around enough, let's save the data. For that, we'll use SQLite. Most of the applications we build these days don't require complex database systems like PostgreSQL and such. SQLite has its downsides, but the ease of use and deployment is worth it. I encourage you to give it a try.

We'll not use an ORM. Those things are traps, maybe I'll go into detail about why I don't like ORMs in a later post. We'll just use a simple driver instead. `better-sqlite3` has a synchronous API. Yes, hearing that while writing javascript should make you uneasy. They promise `better concurrency than an asynchronous API... yes, you read that correctly`. That should be enough for our experiment. Concurrency will be a problem if we have a lot of users that use our app at the same time. At that point, we should just ditch SQLite and embrace PostgreSQL or your other favorite flavor.

To interact with the database we have to develop a new implementation for the interface `DepartmentRepo`. At this point, all of our tests will fail, but once we are done with our implementation they should pass again. To add and retrieve data from SQLite we need a table. Those should be created by migrations. There are multiple ways of running migrations, but let's not worry about the best way for now. We'll just run them when we start the test server.

The repo will end up looking like this.

```ts
export function makeDepartmentRepo(db: Database): DepartmentRepo {
  const listStatement = db.prepare(`SELECT * FROM department`);
  const getStatement = db.prepare(`SELECT * FROM department WHERE name = ?`);
  const insertStatement = db.prepare(
    `INSERT INTO department (name) VALUES (?)`
  );
  return {
    add(department: Department) {
      let existingDepartment: Department | undefined = getStatement.get(
        department.name
      );
      if (existingDepartment) {
        return [null, duplicateDepartmentError];
      }
      insertStatement.run(department.name);
      return [department, null];
    },
    list() {
      return listStatement.all();
    },
  };
}

export function makeDbConnection(fileName: string): Database {
  return new DB(fileName, { fileMustExist: false, timeout: 2000 });
}

export function runMigrations(db: Database): void {
  db.pragma("journal_mode = WAL");
  db.exec(`CREATE TABLE IF NOT EXISTS department (name text);`);
}
```

We'll add a test hook to build the environment:

```ts
let app: Express;

beforeEach(() => {
  // empty string makes a temp db
  let dbConnection = makeDbConnection("");
  runMigrations(dbConnection);
  app = makeServer(0, makeDepartmentRepo(dbConnection));
  app.on("close", () => {
    dbConnection.close();
  });
});
```

We prepare the statements before actually using them. We do this for a couple of reasons:

- if the statement is incorrect, the server will fail to start. Because we don't use an ORM, we might have typos in our SQL code.
- we might generate the SQL in the future. There is no need to manually type the SQL when we can use the machines to do the work for us.

Also, let's do some code review on the add method.

```ts
let existingDepartment: Department | undefined = getStatement.get(
  department.name
);
if (existingDepartment) {
  return [null, duplicateDepartmentError];
}
insertStatement.run(department.name);
return [department, null];
```

If you would use a database other than SQLite (and the sync driver) the method would be error-prone. If 2 requests with the same `primary key` are made at the same time, we would end up with 2 departments with the same name (there is no constraint on the table). Take a second to appreciate we don't have to burden of concurrency.

I hope you enjoyed the walkthrough. In another post, we will describe what situations SQL is not the right tool and we'll embrace NoSql.
