Imposter Syndrome (also known as Doubtia Debilitus) is a wide-spread neurological disorder caused by the disconnect between perception and reality of one’s abilities. It commonly affects newborn Software Developers from a non-traditional background, but has been observed amongst individuals of all dev-ages and backgrounds. It is generally triggered by comparing oneself to a false ideal, and conditions can worsen if symptoms are left untreated.

Symptoms

Some common symptoms include, but are not limited to:

Tunnel Vision — Usually imperceptible at an early stage, you might find yourself hyper-focused on minuscule areas of imperfection in largely successful endeavors. Despite overwhelming evidence to the contrary, you see the venture as a failure as a result.

Paranoid Delusions — The intense focus on small mistakes/areas for improvement can increase in severity and cause you to create inaccurate analysis of your self-worth. The perceived “failure” becomes the defining characteristic of yourself and you become convinced that this unknowledgeable true-self will one day be exposed.

Paralysis — The virus attacks the brain and body with such severity that it can sometimes cause productivity to come to a halt. This is a response to your extremely high perceived rate of failure, and they have concluded that “if I don’t start, I can’t fail.”

Treatments

Doctors recommend the following techniques to treat Imposter Syndrome. These are found to be the most effective treatments by the Researcher; your mileage may vary.

Change it up — Identify and remove yourself from environmental triggers, if only briefly, that could exacerbate symptoms. For instance, if you have consistently been working closely with someone much more experienced, it is suggested that you seek out opportunities to work alone or with someone who is more comparable in experience. While pairing with a senior developer is an excellent learning opportunity, it could sometimes lead to unrealistic expectations and self-assessment of yourself. This could occur no matter how supportive from the team. It is important to remember that though it may feel like you don’t know as much, even experienced developers sometimes Google simple things and you still have skills that are valuable and can contribute to the project.

Celebrate wins —The virus takes hold in your brain by exponentially multiplying negative thoughts. Fight it by celebrating any and all achievements, no matter how minuscule they might seem: “I took on a feature independently.”, “I demonstrated something for the Client.”, or “I gave my first lightning talk in front of a group.” Acknowledge these wins without qualifying it, then find a friend to give you a high-five or, if alone, give yourself a mental one. Consistency with treatment is a challenge, especially as the virus fights back. Keep at it. Maybe once or twice a day to start, and work up the frequency. Pretty soon, it will become second nature.

External affirmation — Taking the previous treatment a step further: when you are given a compliment, be sure to allow yourself to accept it. Strike words like “just”, “only”, “well…”, and “lucky” from your vocabulary. No more responding to compliments with: “It was just lightning talk.”, “Well… So-and-so had done it better.” or “I was lucky I got that job offer.”; a simple “Thank you” will do. Take pride in that someone else have noticed your achievement. Downplaying the significance of what you have done will only create fuel for the virus and feed into the negativity that it craves.

Long Term Effects

Whatever methods of treatment work for you, embrace it. But remember: we are all human. When you lapse and the virus is filling you with negative thoughts, don’t fret. Acknowledge what is happening and remember the achievements that got you to where you are. We are all learning to live with various degrees of imposter syndrome, and clinical trials conducted have uncovered that while the condition is serious, it is not chronic or terminal.

The research cited was from personal experience, no official clinical trials were conducted. No medical personnel were involved in the writing of this article.

I was recently caught off-guard at a job interview by this question:

What is ReST?

While my bootcamp instructors drilled us with algorithmic problems as found on Codewars, we did not allocate as much attention to the talk-about-coding type interview questions. Thinking back, it was negligent of me to assume that just because I understand something enough to use it, I could talk about it eloquently too.

WRONG!

I think I mumbled something about using HTTP verbs and URLs. I don’t really remember; I may have blacked out.

The paragraphs and images that follow barely skim the surface of understanding ReST, but should be sufficient knowledge to get you through your interview.

This is also what I wish I had given as my answer.

ReST stands for Representational State Transfer

So, now that that’s out of the way, we can get down to what it actually means.

Assuming that you, the Reader, are familiar with the Client-Server-Database structure of most web applications, the short answer is that ReST is a set of guidelines that describes how your client communicates with your server.

A “ReSTful” design is complex; way more complex than an Interviewer is looking for in a short interview answer. Here, we will cover the following:

• Endpoints named after resources
• Actions performed on those endpoints
• Stateless communications

SIDEBAR: If you are interested in diving into the nitty-gritty of ReSt, here is Chapter 5 of Roy Fielding’s dissertation.

HOCKEY!

Let’s say I have a very simple CRUD web application for a hockey league, where I keep track of all the teams in the league. Upon surveying the Users, I have condensed the user stories down to the following:

1. As a User, I want to be able to create a team, so that I can add a new team when they join the league.
2. As a User, I want to see (read) all the teams, so that I can get an overview of the league.
3. As a User, I want to be able to update a team’s information, so that I can track wins and losses.
4. As a User, I want to be able to delete a team, so that I can remove a team when they leave the league.

Knowing that a route consists of two parts: the path / URL and an HTTP action verb, let’s get started.

Resources as Endpoints

In a ReSTful architecture, the path is a noun describing a resource that is being accessed. It is generally named after database models (tables). These paths are the endpoints our client requests will hit.

In the hockey app above, our requests should all hit the path representing the Team resource. So let’s start the routes there and build up:

1. /team

2. /teams

3. /team

4. /team

Actions on Endpoints

If all these User Stories hit the same endpoint, how does the server know which of the actions to perform?

In order to differentiate between each of the CRUD activities, our request from the client will also send an HTTP action verb to the server, along with the path of the endpoint the app wants to hit.

Let’s update our routes for the hockey app:

1. POST /team

2. GET /teams

3. PUT or PATCH /team

4. DELETE /team

Stateless Communication

Another big part of ReSTful design is that the “communications must be stateless in nature” (Roy Fielding). That simply boils down to the fact that all the information needed to understand each request is sent along as part of the request itself.

For our hockey app, we will need to add something to the PUT/PATCH and DELETE routes so that our server knows which team we want to apply the action to.

Like so, where 1 will be the id of a specific team:

1. POST /team

2. GET /teams

3. PUT or PATCH /team/1

4. DELETE /team/1

TL;DR

To sum up the above points into a concise answer to the question, “What is ReST?”:

ReST is a structure for the communication between client and server, where each path is a noun, named after the resource being accessed. The requests contain an HTTP verb to define the action to be performed on the endpoint, as well as everything necessary to understand the request.

There you have it. It is two weeks late for that interview, but here is my answer.