What do you need to become a great developer?

💡Curiosity
❤️Self-love and belief in yourself
👥ask for help and collab with other devs
📈keep learning + improving
What do you want to add? Happy Sunday. 🐿

Comments

[AliRaza35690]

Happy Sunday would do the job.

[Vincent Milum Jr]

Stubbornness. ¯_(ツ)_/¯ At least that's what worked for me. Too damn stubborn to give up on anything.

[Anja]

Yes keeping on it is key 😊👍

[Andrew Baisden]

Great list. I would add planning and having a roadmap of what you want to work on and the problems it could solve.

[Ryan Latta]

I think great developers, in addition to the Anja's list, solve real problems. I see a lot of developers focus on the solution side too much.

There is way too much code written that is never executed.

A great developer knows how to involve themselves deeply with customer, user, and stakeholder needs so they have a sense of what problems need to be solved and which ones are just going to be a source of bugs later.

[hidden_dude]

Learn to code defensively:

• use assertions (or better: permanent assertions)
• logging
• unit tests
• debug your code instead of executing
• hallway useability reviews
• rubber ducky code reviews
• code reviews

The bug is the enemy, pull out all the weapons against them.

[Anja]

Thanks for sharing! 😊 What's a hallway usability review?

[hidden_dude]

Actually it's "hallway usability testing"

see this article for an explanation: joelonsoftware.com/2000/08/09/the-...

[Eng Soon Cheah]

Communication also very important.

[Hammad Jamil]

Okay. i think hard work

[Order & Chaos Creative]

Study hard and work hard for several years. Repeat.

[Julien ✏️]

🔍 Know how to research : being able to find answers to your problems is a major building block to progress and solve challenges as a developer.
📝 Share your knowledge : as a developer you often heavily rely on the works other people put in sharing their experience and writing about great things they discovered. Do your part, share yours.

[Scott Simontis]

• Learn to make a persuasive business case for your proposed solutions. The coolest technical implementation doesn't mean anything if you cannot convince your superiors that it's a good investment and that it will make everyone's lives easier.
• Automate repetitive tasks. You will learn a lot in the process of automating the task, and it will save you time in the future to work on more interesting ideas.
• Ask why. Why did the system fail? Why didn't we get any alarms from our APM system before it crashed? Dig a couple layers deep when things go wrong to understand the root cause of the issue. Similarly, bugs may be symptoms of much more serious issues in the codebase that need to be discovered and dealt with.
• Write good documentation. Preserve knowledge within your organization and make the onboarding process suck less for the next person who comes along.
• Choose your battles wisely. There's a million things you could fix in some code bases, but what will deliver value now? You can't debate the merits of every fix, sometimes it's fairly evident that code needs to be fixed but the timing isn't right. You can only crusade for so many causes without wiping out the enthusiasm of your coworkers and supervisor, so make sure to get them involved with the cause when it really matters.

[Bill💡]

Excellent list! Agreed on all points.

Stepping back and asking why is a hugely important skill to have. You may be able to say "This broke because xyz happened and we can fix it easily", but ask "why did xyz happen?", "Did xyz cause anything else we've not discovered yet?", "How should we handle xyz in the future?", etc. This applies to all sorts of work in development and doesn't stop at code.

It's also worth repeating that it's repetitive tasks that should be automated. We all know that one person who spends hours automating something which could have been done manually much quicker, and their automation is never used again! Unless you're doing it purely as a learning project, I would recommend only automating tasks that are done frequently, or tasks which are done occasionally, but would benefit from automation to reduce human error.

When writing documentation, don't be afraid to write partial documents as it can be off putting if you think you need to document an entire process at once. You'll find some notes are better than no notes.

Put your documentation in source control! Not only does it protect the history, it also helps make it accessible to other members of the team. I've implemented a build pipeline using Azure Devops and DocFX, where once changes to documentation are committed to the Git repo, the documentation website is rebuilt and deployed with the latest changes.

[Anja]

Thanks for sharing all these important points!😊 You should create a separate blog post from them 😊📝