In this blog post, I'd like to take a bit of a different approach compared to the other blog posts on my site. Instead of diving into a technical aspect, I would like to take the time to reflect on my learnings in my ~6 year old (as of writing this) career as a developer. For some context; I started of as a junior developer writing backend code for news outlets in my country after which I slowly transitioned into a team lead (in a team of 6 passionate backend developers) at an international e-commerce company (with more then 50 developers). Since I recently came into a situation where I had to look back at my career and think of the next steps, I figured it would be a good time to write this blog post.

Personal development:

Define your goals.

This might be an 'obvious' learning, especially if you've ever listened to any of the 'motivational' videos out there. However as simple as it is, this one really helped me kick-start my career.

When I started working at my first developer job, I got lucky to be working at a really cool company with a tightly knit group of colleagues. In this job, I still vividly remember the first evaluation talk I've had with my boss. Amongst other things, he gave me a set of clear targets to work towards to be able to grow towards a senior developer in their company. At that moment in time I didn't realize the impact this would have for my personal development, however as I gained more experience and I managed to 'check off' the list that he gave me, the time came for me that I was without goals, and at that moment I realized how difficult it was to come up with a good list and how much it helps to have a clear list of goals.

In a later blog post I will go into more details about the above, since I've personally experienced how difficult defining your career goals can be. However no matter how difficult it is, it will really pay of in the long run by (amongst things) enhancing your pleasure working.

Work on a pet project.

You have probably heard this one before, however I can't emphasize this point enough! Having an (ambitious) pet project definitely helped me more then once during my career. I've had several projects of which I'll list a few below to give you some ideas:

• Trying to create a clone of Google Photos (using Scala, Angular and Kubernetes).
• A microservice based personal assistant.
• Creating a location-based messaging app for Android.
• Participation in Advent-of-Code (using new languages).
• An application that generates a daily summary of different news outlets.

As you can see, some of these are quite ambitious! However don't let this scare you, because the nice part of such a pet project is that you don't have to finish it and you can implement whatever you want. Just playing around with new technologies / frameworks / libraries will help you by for example showing you new ways to do things. To give such an example, I never fully understood how DI (dependency injection) worked. Through working on the Scala application (in combination with the Play framework) it started to 'click' and therefore it allowed me to use the concept in my daily working life as well.

Whilst it can be fun to have ambitious projects, you can also definitely learn a lot from doing the 'full cycle' (defining the project until the release of the project) of a simpler project. Therefore don't get the idea that a pet project has to be ambitious, even a 'simple' to-do application with for example a new language, can teach you a lot! Just get started with something (feel free to copy one of my examples above)!

Learn design patterns.

I still vividly remember the moment I got introduced to design patterns. It was the last year of university, and we were tasked with going back to our projects from the first year and see how we could improve them by using design patterns. At the time these design patterns felt like a super power, teaching me how to write 'proper' maintainable code. Whilst they only thought us a few of the more familiar patterns (factories, builders and the strategy pattern to name a few), it did create a foundation for me to later on explore the other patterns out there. If someone would ask me what my biggest tip would be to become a better developer, learning design patterns would definitely make the top of the list!

Personally I have to admit that I don't know these patterns by heart, however I do know of their general existence (and what most patterns do in general). There are plenty of good sources out there if you want to dive a bit deeper into these design patterns, this being one of my personal favorites.

Workflow

Occasionally re-evaluate your development setup.

Personally I think that I should do this more often, since I always get a big motivation boost after such an evaluation. With this re-evaluation I'm personally looking at the following things:

• Does the tool / workflow still suit the work I'm doing right now?
• Is the tool / workflow still worth my time, or should I drop it?
• Are there better tools out there for the job?
• Are there new updates / plugins available for the tool (more about this in the next point)?

Of course some things are not that quick to change (e.g. your IDE / browser), however other things like the workflow in your to-do application might require a more frequent change. You can use this evaluation process for basically anything that you're using (even the plugins in your browser for example).

A good example of this would be my to-do workflow, I've recently switched to the Getting Things Done approach for my to-do list. This because I noticed that I encountered a lot of chaos and stress from my (at that time) 'current' setup, which caused me to look around and try a new approach. I have to admit that I'm quite liking it thus far and I definitely feel more productive right now!

Master your IDE.

This point was already slightly introduced in the last point, but since I'm spending the majority of my day behind an IDE, I find it important to learn the IDE of my choice from the inside out. This means that I've spend time learning / investigating the following things:

• Ways to improve my debugging skills with the IDE.
• How to navigate through the code in a smart way.
• Popular shortcuts and refactor features like multiple carets.
• Occasionally checking the plugin store to see if there are new and helpful plugins out there to help me in my work.

During the years that I've worked, it definitely feels like the above have enhanced my developer skills. Even the plugins alone have helped me improve my skills by for example warning me about inefficient code patterns. Here are some examples of some of my favorite plugins:

• Sonarlint
• PHPInspections EA extended
• Database Navigator (although a simpler version is also present by default in your IDE).
• Markdown editor

If you're unsure where to start with the above, I would recommend just to spend some time in the plugin store and Google around for other blog posts / Twitter threads talking about mastering your IDE (like for example, this Twitter thread).

Schedule your day.

One thing that I've noticed is, that the more that I 'climbed' the corporate ladder, the more secure I had to be with my time. Whereas before I had the option to just do things at the go and not worry too much about my next steps, it would be impossible to do that right now. This because my current work requires me to try and stay atop of things so that I can for example, help the product owner define a roadmap for a new technical feature whilst also guiding people, reviewing code, answering questions and to top it off spend time working on my own features. These 'additions' to my work definitely caught up to me, because at one point in time it felt like I could get nothing done and kept bouncing around from 'request to request' which really killed my motivation to work.

At that point in time I realized I had to change things in order to get a grip again. Thus I started looking into various flows used by others in a comparable situation. One of such a flow I encountered is the book Deep Work by Cal Newport. This book talks about various things to enter the 'Deep Work' state which basically boils down to the state of work in which you're losing track of the world around you.

Whilst there are various lessons I've learned from this book, the one that stood out to me the most, is the art of blocking time in your calendar to focus on your own work. In a nutshell I'm basically creating blocks of 1 - 2 hours where I'm turning off all notifications and where I'm trying to focus (deeply) on my own task. Often times I find that once I'm done with such a block, no one really missed me and I can just catch up on the questions / e-mails I've received in the meantime whilst still getting the satisfied feeling from having made a bunch of progress on my own features. Admittedly I tend to only get 1 or 2 of such blocks a day, however they do really help me find enjoyment in the work I'm doing.

If you're finding yourself in the same position as I was in, I would really recommend reading the book (or a summary) and see how you can apply it in your life!

Define deadlines.

And last but not least, but defining deadlines is definitely something that has helped me numerous times. Here I'm referring to defining deadlines for myself, but also for others. I'm fully aware that it can be a bit difficult to set meaningful deadlines, since they do have to be meaningful (especially for giving them to others). This because otherwise people tend to start taking your deadlines with a grain of salt, and not caring as much if they're not meeting your deadline.

Even though it can be difficult to set these deadlines, I've really noticed (even when getting tasked with tasks from colleagues) that without deadlines, tasks just tend to gather dust at the bottom of my to-do list. Whilst it is true that I'm scheduling both tasks with and without a deadline, the moment I can't complete all the tasks for that day, I personally tend to move the tasks without deadline first.

I can't emphasize this enough, but do try to keep the deadlines realistic and meaningful. If you're asking someone to do a 1 hour code-review within 30 minutes from now, you're gonna get resistance and in the end reduce the likelihood of the person to take on your (future) requests. Also if you're asking someone to do something for you before a given deadline, but it doesn't matter if that deadline gets exceeded with a week or so, it will hurt your credibility and it might cause that person to take your deadlines not as serious in the future.

Therefore it's important to find a balance, try to set realistic and concrete (in 2 days instead of 'soon') deadlines and see the benefits for yourself!

These were some of the learnings that I've made during my career as a developer. What are some things you've learned during your career? Do you agree with my learnings? Please let me know below!