4 tips to develop an awesome developer mindset in 2024

Being a great developer requires more than implementing features and fixing bugs. If you really want to make a difference, you also have to develop a great mindset. Those 4 tips can help you gain more influence with more fun on the software projects you are working on.

Being an awesome developer is a daily decision. Let's take a look at 4 important tips that can help you stay on track.

1. Take responsibility

As awesome developers, we are always responsible for our actions and decisions. Of course, we will now and then fail to meet our goals or make bad decisions.

In those cases, it's time to take ownership of your failure and learn from it. Next time, you will be smarter.

Embrace the change

Artificial intelligence is here to stay, and it is coming fast .

Awesome developers don't blame new technology for making more and more jobs obsolete.

Instead, they embrace the change that AI brings to our daily lives. For example, we already have OpenAI, ChatGPT and GitHub Copilot available at our fingertips, so let's get comfortable using those tools and honor the great value they provide us.

By adopting new tools, you become quicker at producing great, robust and maintainable software.

I believe that eventually software development is completely made obsolete by AI. And if you stay up-to-date with the new tech, you will grow into the new era of jobs that comes with it.

2. Never stop learning

The major skill that you should master as an awesome developer is your ability to learn .

Learn effectively

The Pareto principle , aka the 80/20 rule , states that you can reach 80% of the desired goal with only 20% effort.

Of course, those numbers are not the exact 20/80 ratio for every possible application, but it's surprisingly accurate in most cases.

The gist of this principle is that not everything that you can learn about a certain topic is equally relevant.

Instead of finding out on your own what is most relevant, you can consider taking a course, if you are just starting out on the topic. This way, you delegate the application of the Pareto principle to the course creator.

Additionally, there are often well-written guides and/or third-party content from other developers on the given topic, who often highlight the most relevant parts.

Learn efficiently

We learn faster and more in-depth, if we directly execute on what we have learned. Additionally, we can better recall those learnings, which is also desirable.

Courses often provide hands-on examples.

Naturally, you can be creative and make up your own exercises. But keep in mind, that you want to be effective, so stay focused on the thing you currently aim to learn.

If teach others about a technology, you are looking at the topics from another perspective. Since you really have to think the stuff through and your students give you feedback by asking questions, this is a fantastic method to become aware of what you don't know yet.

3. Be pragmatic

Our job is to deliver great software. What does this mean? There are multiple desirable attributes. Here are some of them:

• Quality: It should do what it is expected to do.
• Maintainability and extensibility: It should be easy to change or extend it.
• Usability: It should be easy to use.
• Performance: It should use only as much resource as necessary.

Hacker vs perfectionist

Perfectionism is the enemy of progress.

Winston Churchill

As awesome developers, we want to deliver great software. There are two opposing roles: The hacker and the perfectionist .

The hacker tries to solve the problem as quickly as possible and as soon as this goal is achieved, he or she goes on to the next topic. The result is a quick-and-dirty solution that is most likely hard to maintain and extend. If someone (this may also be the author) looks at the code two weeks later, the whole code must be re-read to understand what is going on.

The perfectionist, on the other hand, writes clean code and solves the problem at hand only accidentally. The code is over-engineered and takes ages to be finished authoring. A reader also has to dig deep into the code to follow all the paths through the jungle of abstractions until he or she finally knows what has to be changed (not rarely this is the whole stack of abstractions).

Finding the sweet spot

Most likely, in a standard software project, you want to avoid falling into either of those roles. It's challenging to find the sweet spot between the extremes.

Where on this scale you should operate is project dependent on the project constraints like

• Budget
• Changing requirements
• Deadlines

Sometimes you simply have to follow the principle "Done is better than perfect." - Perfect software does not exist, anyway.

Furthermore, it's good advice to follow the YAGNI (you ain't gonna need it) principle. This prevents you from over-engineering your application.

Learn about proven software architecture principles

Software architecture should evolve during a project.

You should definitely know about the most important design patterns. Knowing common principles like DRY and SRP does help as well to write maintainable software.

There are some architecture archetypes that you can follow to get started. For example, I recommend reading Clean Architecture by Robert C. Martin . I learned a lot about proven design principles from this book.

To get started, you can also have a look at Uncle Bob's blog post about this topic.

Learn the rules like a pro, so you can break them like an artist.

— Pablo Picasso

Depending on the project, you should decide how strictly to follow the archetypes and principles. If you break a principle, it helps to be aware of it, and you should have good reasons to do so.

4. Develop your personality

The minority of projects is a one-man-show. Having great team skills is critical. As awesome developers, we don't only develop code, but we also develop our personality.

Be teachable

One significant skill is to be able to know when someone is smarter than you at a certain topic. Then it's time to bury your ego and be eager to learn from this person.

Keep your Ego small

When talking to stakeholders or project externals, pass on praise to your team, even if you did most of the heavy lifting.

This behavior not only gains you respect from your fellow developers, but also from your conversational partner.

Be honest

Don't fear to speak up if something has to be improved. Your primary goal is to deliver great software fast. This does not work, if you and your team are piling up technical debt or your team communication sucks. Remember, you are a problem solver.

There are more or less polite ways to do so. If you want to optimize your communication skills, I recommend learning about personality types and the DISC assessment .

Lead by questions and suggestions

When you intend to lead to a certain decision, be it a technical or a functional one, ask the right questions. People tend to directly say what they think is the right way. This is much better than holding back with your own opinion.

But if you want to take more influence in the final decision-making, it makes sense to lead the others into a direction that you like. This is a softer approach which lets you find a solution together. Sometimes you also change your mind during the discussion, and it's easier to change your mind, if you did not state your initial opinion too forceful.

Final words

The tips listed above are more or less hard to master, depending on your current knowledge and mindset. You can apply the Pareto principle here as well. Ask yourself: What didn't I focus on yet? Where can I grow the most? Which mindset shift will have the most impact on my daily life as a developer?

No one is perfect, but you can get close to it. So, let's continue working on ourselves!