What a working day looks like as a (junior) developer

Something I always wondered about on my path to becoming a developer was, what would it be like to work at a company? What does a typical day look like? I'm sure many of you ask yourselves these questions all the time, so I'd like to show you what my work day (at a large company) looks like.

I got my first job in the technical field 3 months ago. I was very happy, and also very curious how it will be to work in a real company. And finally I would get to know it.

Before I started working, my daily life looked like this: Wake up, go to the computer, read some articles that could be useful for one of my side projects, and then work my side projects. Of course, the hours I spent programming each day varied, some days I spent only 3 hours programming, other days I spent up to ten hours (especially when I was trying to fix a bug, you know how that feels 🤪).

And the fascinating thing is that little has actually changed since I've had the job, although I now talk/write to people I'm working with on a project from time to time. Currently, I'm working remotely because of the pandemic, and that won't change much in the future.

The initial phase

At first, I didn't want to work remotely. After being at home for so long, I was glad to have a reason to go outside again, to go to the company, to meet people, to talk. But after a few days, I realized how great the benefits are of working from home. (No wasting time making myself "pretty", no two-hour commutes, no fast food, no unproductive breaks). I can work between 6am and 10pm, on the basis of trust that I'm productive ~8 hours per day.

In the beginning, I had to learn Angular 👀 and Java Spring Boot. Therefore, apart from the daily scrum meetings (which will be explained later), I was sort of on my own in learning and adapting these two languages. After two months, I started working on some internal projects we have to actively apply my knowledge.

Internal project

I have been given a company laptop. And as with my side projects, I program with Visual Studio Code, which I have set to my needs, the extension I want, other programs I need.

On GitLab (which is hardly different from GitHub in operation, so I quickly found my way around), the Scrummaster created Issues for the project repository. We developers, there are 3 of us, assigned the issues we want to work on. In my case it was the frontend part, which was split into several issues.

In the dailies I indicated how far I am (I showed the code), how long I think I need for the issue, what problems or challenges I had (e.g. I have a bug and haven't found a solution yet. Or, I want to fetch data but haven't figured out the best way to do it yet) There's no shame in it, it's purely so the team can (learn to) estimate how long someone thinks it will take.

Issues

One issue was e.g: Create two form fields where the user can insert his home address. Parts of the acceptance criteria (AC) were: It must be centered, validation added, and much more. This issue took me two days. It was the first time writing code in Angular for me, and I didn't know much about advantages and disadvantages with template driven forms and reactive forms.

Another issue was to add a calendar that meets certain conditions (AC). The user must be able to select a date between today and the next 10 days. Only the months that are related to this period must be selectable. The month view must not show the last days of the old month or the first days of the new month, and much more. This issue took me two weeks to complete. I had decided (it was my decision how to do it) to work with moment.js, and for that I had to learn how this framework works.

Each developer worked on their own branch. One commit (and push) per day should be made. Not to make sure that work is done, but in case someone spontaneously gets sick and so the code is not lost, or the others can continue working with it. When everyone is done with their issues (sprint is over), it was merged. (We developers could do this together if we wanted to, in order to be able to process merge conflicts as quickly as possible.

Working at a client project

I work in a large company. We provide IT solutions for other companies, so each project is unique and each project needs its own team to apply for if you are interested in that project and want to work in that team. But the interviews are more about seeing if a member fits into the team, to harmonize with everyone, because for the time of the project this should not stand in the way of a Scrum team.

Project requirements

When you work on a project, the requirements may change with each project. Some projects may require you to work on-site at the company, at a specific start and end time. The programming languages you work with may also vary. Also, the duration of a project can vary from 1 month to 2-3 years. This makes working in a company really interesting. I really like this way of working. It makes the experience exciting and fulfilling.

Scrum

Scrum is a very good keyword here. We work with the Scrum framework (as do many other companies, especially in tech), so it's good to know about Scrum before applying for jobs. What does Scrum mean?

The Scrum method is a framework for agile product development and agile project management.

Every day, the developers on the team have a Daily Scrum Meeting of no more than 15 minutes to talk about, for example, what someone did yesterday, what someone is up to today, obstacles, successes, etc. This meeting takes place every day at the same time.

Every two weeks we have a sprint planning meeting to discuss the topics (sprint backlog) that we are most likely to solve in the next 2 weeks out of all the open topics (product backlog). Each developer chooses the topics they want to work on.

On each day, I work on my topic until it is done (meets the definition of done). The first thing I always do at the beginning of the day is to google for a solution to my problem. Yes, Googling 📲.

It's like you read over and over again on the internet: Google was, is, and always will be your best friend when trying to solve a problem. So don't be afraid to use it, even when pair programming during an interview.

Furthermore, I read articles about the language I'm programming in to improve my code, or watch tutorials about my issue on YouTube. So, I do the exact same things like I do when working on my side projects.

My first project

🔜 My first project, which starts in January, will still take place remotely and my way of working will hardly differ from the way I've been working so far, I guess. But if, I will definitely let you know. I am really excited, but I'm also already excited to see what the next project will look like too.

Thanks for your reading and time. I really appreciate it!