Prologue

I wrote this blog five years ago when I was a junior developer. The tips I shared back then are still rules I follow today and have become an integral part of me. I've grown a lot as a developer, so now I want to give back to the community as an intermediate developer.
The advice mentioned here is for people who love their craft and want to get better at it, not for the sake of better compensation but for the joy of programming.

1) Love your job

I've seen people treat programming as just a job, doing it only for the money. They program to earn a living and go about their daily lives. This lifestyle is fine, its your choice. But don't be surprised if your skills don't improve and you become stagnant. To become great at programming, you have to love your job. You spend most of your day programming at your day job, and if you don't love it, you won't take the initiative to improve your skills while working.

I have a personal story to share. I once worked at a company I hated. I didn't take any initiative to improve the codebase or learn new things to enhance the application architecture. Now, I work at a job I love and treat it as my own product. This often leads me to learn new things and develop the codebase in a well-structured manner because I don't want to ruin it. If you do what you don't love, you'll do more harm than good. You can learn after work, but you would have wasted around six hours of your day and accomplished very little.

2) Be a generalist

Never put yourself in a box. Don’t think of yourself as just a frontend developer or backend developer. Think of yourself as a software developer. Great developers don't limit themselves to specific technologies they focus on solving problems, not just parts of a problem. If you limit yourself to a certain stack, you won't become a great problem solver. Software development is all about problem-solving, and if you don’t understand how to build an end-to-end product, you won’t be a good problem solver.

At the start of your career, you might have to choose a specific stack to prove yourself as a great software developer. But don't let that limit you. If you work at a good company, talk with a senior or other developers to gain insights into different teams and learn new things. Start taking responsibility for other parts of your company's codebase to transition into a more full-stack developer role. This way, you'll start thinking more about solving whole problems rather than just parts. If you are not welcomed to work with other stacks I would recommend working at another job. A company should never limit the learning of their engineers.

So, be a generalist. Don’t limit yourself to one part of the stack. Learn to solve problems as a software developer. Generalists find it easier to be good at solving specific problems because they can pick up new technologies faster since they already have a broad understanding.

3) Never stop learning new tech ( Be a tinkerer )

This is a crucial point that many developers overlook. To be a good problem solver, you must keep yourself up to date with the latest advancements in your technology. I find a lot of joy in my hobby projects, which help me develop many skills. When you tinker with new stuff, you learn a lot, and you never know when it will become useful.

For example, imagine you've been tasked with creating a blogging application for your company. They want a custom solution, not something that uses Webflow and other similar services. If you've kept up with the latest advancements, you can use modern CMS tools like Supabase or Pocketbase to develop the backend quickly. It might take just 30 minutes to set up a CMS for your blogging site, saving you from creating and managing the database and backend code. Then you can focus on the frontend according to your company's needs.

Here's a personal example: I’ve been learning Go for a month on the side. Recently, I had to write a cron job to update user metrics every 30 minutes. Knowing that Go is great and very fast for such tasks, I created the cron job in Go, built the binary, and scheduled a system daemon task with a timer for every 30 minutes. It works efficiently and consumes fewer resources. If I hadn't been tinkering in my spare time and only wrote code at my day job, I wouldn’t have come up with the best solution in a reasonable time. The cron job would have been written in Node, which would take more time as the user base grows.

So, never stop learning and creating on the side. The best way to learn is by creating and tinkering. I’ve been learning Ruby on Rails and Go on the side, and I’ve come to appreciate the different features that various ecosystems offer. This has helped me integrate new ideas into my workflow.

4) Take ownership

I recently watched a video of ThePrimagen that inspired me to write this blog. He mentioned that the best way to solve a problem or become a great software developer is to take ownership of the product. He talked about how Doom was created by just four guys who delivered such a good product because they took ownership. They knew they had no one else to rely on, so they made it their responsibility to develop the best possible software. There was no Plan B. They never felt burnout or gave up because they owned the product, not just the tasks.

To improve your skills as a software developer, you need to start taking ownership of the product you are building, not just features or tasks. You will find it much more enjoyable to work on a product when you see any feature or bug as your problem to solve, not just another task for someone else. This is the best way to beat burnout. When you take ownership, you will find joy in improving and making the product more efficient.

If you are working on a product, you can't blame others for any bugs that come up when users find them. You are part of the problem if things go wrong, so you have to take ownership to fix them and make a great product. Good, scalable products are built by teams, and if you don't take ownership, you are not a good team member. When you take ownership, you write the best possible code to create the best possible software, not just another software product.

Like the four guys who made Doom, they put in an insane amount of time to create something that was theirs, and they never settled for just another game, they created an era-defining game. The rest, as they say, is history. The same applies to you, if you want to make the best possible software, you have to start taking ownership and think of the product as your own.

Epilogue

I feel good after writing this blog and sharing my thoughts with the community. We might argue about frameworks, languages, and tools, but these debates help us improve. They push technology forward, making our community very competitive. Let's keep the passion alive!