First day as a junior developer

Today, we're going to discuss a topic that affects pretty much everyone, regardless of the field, but more particularly devs because of the impostor syndrome so present in IT...

The "pressure" of the first day...

A topic I've experienced several times in my life, notably as a temp worker, even if the assignments were generally long, since few lasted due to poor working conditions (perfectly understandable).

For a month now, I've once again lived through this experience as a developer, and it's through this experience that I'm going to share my personal experience with you.

The theme that comes up most often around this subject is "anxiety", and fully understanding this feeling, I hope this article will make you feel more at ease about a developer's first day.

What did I do on the first day?

My experience happened in two stages.

Preparation

First, configuring the tools we use on a daily basis, on the various assignments to make sure the project works locally.

As a dev, and even more so in full-remote, we use a lot of tools that enable organization/communication with as little friction as possible.

So we start by joining:

• the workspace on Trello for task organization
• the Discord server for daily calls and message exchanges
• Github or Bitbucket to manage our code as a team and pull or update the project.

To have as few issues as possible, make sure you have at least some knowledge of the tools, the terminal, and Git versioning

Launch

Then comes the moment to get a project running on our own machine...

The instructions were in the README to get the API running as well as the front-end part. So far so good, all that's left is to check on our localhost that everything is working.

Of course, like any self-respecting setup, it only half works...

The application runs, launches, but all I get is a green background without retrieving any other information. I look around on my own, start going in circles, then a rather unpleasant feeling set in.

The return of the one I thought I had left behind, the infamous impostor syndrome!

Even though it was fairly mild and life experience helps you put things into perspective more quickly, not feeling up to the task right from the project setup, you immediately think you're going to get "exposed".

Remember, before moving on, that if you got a mission or a position, there's a reason for it!

It was at that exact moment that I thought I was going to have my (first) last day.

The end of the day was approaching and I wanted at all costs to solve the problem on my own, but in the end, what unblocked me was COMMUNICATION.

No, asking questions doesn't make you an impostor, or an incompetent person, quite the opposite. It will teach you to understand things in depth, while clearing up gray areas.

I communicated about my problem, and I discovered that the issue wasn't coming from me, but from a dependency issue that the application was supposed to fetch and that was temporarily broken.

After that, everything worked!

We can already conclude from this that communicating about a problem as early as possible saves a considerable amount of time, especially on your first day.

Improvement

Then comes the third stage: after installation and the first task!

We start with a call at 9:00 am.

It's a daily call that lets us maintain regular communication in order to address issues as soon as possible.

It also lets us discuss what was done the day before, talk about the task we're about to start, and mention if we have past or future topics on which we'd like some food for thought.

The day begins, then comes the moment to log into the application's local back-office: "Unknown error, please contact the administrator."

Sure enough, I also notice that early in our professional experience, the relationship we have between our personal projects and those of companies is very different.

First because it's someone else's code, so when there's a bug we tend to get lost in the application, and also because we don't know the normal, theoretical behavior of it.

At that point, it's easy to tell yourself: "this isn't possible", "I'm not going to last long", because even after hours of searching, I kept going in circles.

In reality, the key skill here, and in the following cases, lay in the research and debugging methodology. It's essential to be able to express your problem in order to understand it better.

See the rubber duck method, learn how to look for a solution to a code problem

So once again, I communicate the state of affairs, we examine it together and that's what finally reassured me: I understood that I wasn't the only one, and that even a more experienced person can find themselves stuck.

But that's also when you learn the most! Pay close attention to the debugging process of a more experienced dev.

In the end, my problem stemmed from a case-sensitivity issue in the project's example environment variables file...

Proof that it's always something small, and I was finally able to tackle my first task!

In conclusion

What I take away from my first day is that despite the difficulty of a problem, you very quickly discover afterward an almost addictive satisfaction at successfully completing a new task.

But above all, that communication is an essential skill that every developer must learn to work on.

For that, I recommend a book, admittedly quite clichéd, but one that really helps understand the social process and is very effective in a workplace. That book is "How to Win Friends and Influence People" by Dale Carnegie!

For my other tips, here's a short list:

• Knowing how to use the command line and git is a cornerstone that you'll need no matter the company.
• Taking the time to read documentation, to explore the project and how it works are also actions that can really help you get involved in a project.
• Communicating about your problems and your progress fairly often, and sometimes more depending on the project's timeline context.

And finally...

• Have confidence in your abilities, impostor syndrome is very common no matter your level!

One way to make it disappear is to better understand and build up more problem-solving skills. Because whoever is good at problem-solving, no matter the issue, will have a solid methodology.

For example, you can practice pulling and setting up projects via Github; doing it often just for fun on existing projects helps you become comfortable with the process.