5 Mindsets of Unsuccessful Developers

5 Mindsets of Unsuccessful Developers

There are plenty of things that can stifle you on your path to becoming a good software developer, and often they are states of mind that can be difficult to recognize because they are internal and part of you.

And there’s one thing I learned since I started programming, it’s that all unsuccessful developers typically share similar traits.

Knowing what to avoid is more important than knowing what to do!

1. Expecting Everything Instantly

It is definitely very important for programmers to learn new things quickly and apply them. That is the nature of the job that we are in.

But starting a tutorial of Kotlin and expecting to write Kotlin code in 2 days is just not going to happen.

And this habit of learning a little bit of something and then deciding to move to something completely new is really what it’s all about. That is exactly what is preventing you to become good at something.

Do you see what I mean?

Skipping around, dipping a toe in every language/framework, and doing half the tutorial track on various resources. You might end up being able to say “hi” in each language, but you won’t get close to speaking fluently in any of them.

2. Quitting Is Only For Losers

This may sound counter-intuitive. But sometimes you have to quit something to start something better. I am not talking about quitting the job or changing careers.

This applies to the realm of Software Development. The problems that you solve daily require you to change approaches and you should be flexible in quitting one solution for others.

What I mean by that is you should not be attached to the approach. So whenever you see something not working out, scrap it and start it from scratch with the same enthusiasm and a new approach.

“Genius is to know when to stop!” — Unknown

Take your time and explore. You are here to learn and bring something better to the table.

3. Learning Only Happens On The Job

This is one of the mindsets I had which hindered my progress. I realized this later on that I do not have to wait to work on projects on the job to learn something interesting.

I am not talking about enrolling in online courses and then forgetting everything just a few months later.

It is more related to the ideas that you might have in the back of your head. If you don’t think you have those ideas then maybe try scratching your head! ;-)

All I am saying is that you should create something using the tools at your disposal.

Programming is just a tool to bring ideas into reality.

So work on something of your own. That will not only boost your confidence but also will help you learn so much more.

Three years ago I had an idea that I turned into reality by creating this Android app.

4. Saying Yes To Almost Everything

As a software developer, we face not only syntax and logic challenges but client communication. This is crucial because some times, your client will ask you for features that will take a lot of time and will not add value to the final product or are not the aim of the application.

Generally, in a situation like that, the only option is to say yes and deliver the features. And that is not wrong by any means but before that always aim for more clarity.

The best way to achieve clarity is by asking questions.

By bringing clarity you and your team might be able to find an alternative solution making a win-win situation for both parties.

The problem is, most people never ask questions. They sit in this confusion and lack of clarity in discouragement.

5. Documentation Is Not Important

The general argument for writing or maintaining documentation is that when the code is under a lot of development, it’s more work to update both docs and code, which slows one down. If such work is delayed, divergence becomes increasingly likely.

But I don’t see any rule where you are supposed to write documentation when you are developing. You can defer the documentation.

I generally write expressive code and tend to add a Javadoc-style comment block to any non-trivial function for internal code, explaining some less obvious code.

But the second I write code that is interfacing with other developers I write it as an API. I fully document it, explain the action of each method and any non-obvious consequences, and then leave it with the expectation that it is done.

The simplest documentation that takes the least effort, but explains the functionality and purpose of the software fully, is the optimal solution to documentation.

Conclusion

A fixed mindset is an unproductive way of thinking that sits opposite of what’s called a growth mindset. As you might imagine, a growth mindset fosters personal growth and development.

The fixed mindset hinders growth, as it’s predominant concept is that we’re either good at something or not based on inherent abilities. This mindset contributes to negative thought patterns and puts limits on healthy behaviours.

Becoming a better version of yourself doesn’t happen overnight, but this is the perfect time to start, and avoiding the above mindsets will help you reach there faster! You can find me on LinkedIn and Twitter.

Other Interesting Articles

Lessons I’ve Learned in 5 Years as a Software Engineer