As a trainer at click solutions, I regularly supervise trainees and students. Through appropriate onboarding and the teaching of technical content they grow from beginners to real developers. Sometimes even really good developers.
What are good developers and what distinguishes them?
Probably not π. I think being a good developer it is definitely not related to
- typing fast (maybe even faster than this cat),
- the number of lines of code per day or
- even the theme on your favorite editor.
In my understanding a good developer...
... writes working code
That comes as a surprise, huh? But yes, good developers make sure that their code works. They do this by:
- thinking about it in detail - What can go wrong? Beginners are usually too optimistic and think too little about the case of failure.
- planning it - Do I have all the information? Are there any side effects? Beginners often start typing immediately to get things done quickly. Not always the best way to write good code.
- testing it - Are all requirements met? Does everything work as expected or am I overlooking something? Beginners sometimes don't test their own piece of code.
... has internalized KISS
Just to clarify. When I say KISS I don't mean the hard rock band from the 80s. It's more the demand to strive for the simplest solution possible for a certain problem. So, Keep It Simple, Stupid! Good developers do that (because they are not stupid, right? π).
... has understood DRY
Copy & Paste? No, thank you. Rather: Don't Repeat Yourself. Good developers do repeat themselves, they encapsulate functionality - even if time is running out again. This prevents errors or inconsistencies and increases maintainability at the same time.
... never stops learning
Technologies/Frameworks come and go. The IT sector is determined by constantly changing requirements and innovations. State-of-the-art topics of today may already be outdated tomorrow. Good developers are aware of this fact and educate themselves independently. Ideally, they love to learn for life.
... has learned to work in a team
A good developer has understood that working together is faster, better and makes way more fun than being a lone wolf. They share their code & knowledge, ask for help and help others. Lone wolfs may do a good job, but teams do amazing things.
... wants to get better (every day)
Working in a team brings certain advantages. For example, you always have someone you can ask for advice or feedback. Feedback is a very good way to develop yourself further, as it gives you insight into the way others think and see things, especially about your code or the way you got there. A good developer knows that and asks for feedback to get better (maybe even every day).
... communicates (in time and purposefully)
Problems occur from time to time - they are inevitable. But good developers know when they have lost their way without getting ahead on their own and communicate this before reaching a point of no return (e.g. missing an important deadline). But the same applies when there is something that prevent them from being productive or when they have open questions (e.g. unclear requirements from business side).
Conclusion
There are many aspects to being a good developer, but please remember: no one is born a master or is even perfect. Aiming to be a better developer already takes you a big step further. If you take the time and work on yourself, the rest will come naturally.
Maybe one more not so unimportant thought at the end. To become a good developer, however, you have to do one thing above all: practice, practice, practice... Practice makes perfect! π
What do you think? What makes a good developer for you? Let's discuss in the comments!
If you liked this post, please give me a β€οΈ or even a π¦ and feel free to follow me on dev.to. Appreciate it! βοΈ
Finally a few more articles from me. Check it out!
Top comments (41)
Let's add one more: good developers can explain the code they create to people who are not developers themselves.
I might take that one step further.
Good developers write their code and document it specifically for the "next guy".
So that they don't have to explain it in person.
Thanks for this @beernutz . It is something I really struggle with and would like some guidance.
How do you this easily? Do you document via comments or using an external application (like Notion, Google Docs etc).
Will appreciate your insights.
It depends on the context. Most often I try to keep the explanation as close to the code as possible, so a docblock at the top of a method, or an inline comment block right next to some code that seems clear what it is doing, but maybe not the REASON for it being there.
This can help a lot later too, when it comes time to refactor. For example, you might have some code that is used to work around some odd bug in an API or something. That is a great place to comment about WHY it is there, and when you might be able to retire it. I do this a lot when I have to work around bugs in other systems I am integrating with but don't have code access to.
All that said, I do keep a pretty extensive evernote collection. This is most useful when hunting down weird bugs or issues, as you can quickly outline what the problem was and the steps you took while investigating and fixing.
These have BOTH saved my bacon numerous times, and I highly recommend getting in the habbit of doing both.
I stick with Evernote because it is synced everywhere, and can be quickly pulled up and saved. Though there is one caveat there: The latest version (10.x) is significantly worse than the 6.25.x line. They moved to an electron type app and lost all the global hotkeys and direct note linking and such.
@Ekanem, On Pull Requests!
Following this template here in our company(skore.io):
What?
Change something...
Why?
Because...
Link to the card/ticket.
I appreciate your detailed feedback
And great developer produces code which is self-documented, so he spares time with "document the code" step.
That is great when you can do it, but there are a lot of places (domain knowledge for instance) where documenting WHY this code exists is important I think. That and in general it feels like we should be documenting the "why" instead of the "what" if that makes sense.
Agreed.
That would be a great developer, a good one could explain their code to a rubber duck.
I think rubber duck debugging is a different thing. Generally you explain your code to the "rubber ducky" to help you find a problem you are looking to fix. There is something about doing that that really does help, and if you don't have to bother someone else, you can save time and use less human time. 8)
Pardon me if i explained something different than you meant. Just thought that concept deserved some more info.
Yes it is a different concept, originally I was going to say "explain to another developer" but decide to take it to the debugging idea.
This is so true.
Interesting thought, Thomas! π€
True when you are capable of doing that then you reach the level of Sensei. π§
I would also add, knowing when to NOT write code to try to solve a problem.
As people trained to, and love to, solve problems with technology: its easy to forget that a new, or modified piece of software may not be the best tool to solve the problem.
Often in my career I've come across problems that the business clients have thought needed to be solved with a new software tool. However after some real analysis, the root problem was a business process problem or people problem. Often these are solved by a) removing legacy business processes that no longer served a purpose (It's how we've always done it), training people on the correct way to do things, or often simply having people talk to each other.
Any bit of code that is NOT written is another bit of code that doesn't need maintenance, doesn't incur technical debt, and doesn't hide implementation (and eventually becomes part of the organizational magic.)
I'm often asked to help automate business processes. The clients bring a flow diagram many feet across describing the process they currently follow. They usually believe they need to automate it exactly as it is. My first job is to help them walk through and evaluate the utility of each box, line, and all other items in the process. We can usually, after a few rounds, cut out about 1/4 to 1/2 of the process as followed while maintaining the same utility, well before any code has been written.
Valid point but I think that is really high level and something for a great developer. We still need room for improvement. π
Also: a good developer has internalized that it's not about code.
The root cause of that task on the kanban board is to solve someone's problem, or allow a person to do more than before; even though that one task may seem to be all about coding, the deeper motivation for the task has nothing to do with code. If there was an easy way to achieve the same core thing without code we'd likely do that instead.
When on the clock, we're coding as a way to get to that end, not to play with our toolchains.
It's a kind of eyes-on-the-prize mentality that's an essential part of being a good dev imo.
</10c>
Like that point very much!
Great article, I would add some Clean Code issues that fit here too, it is great to apply the KISS and DRY principles but you have to take great care in the details, produce readable and elegant code.
To me a great professional developer (I think "professional" is the appreciation that might be missing here) loves what he/she does, tries to come up with a solution differently if necessary and is empathetic enough to think about other developers and users when writing code.
This really covers almost everything you need to be a great developer. The never stop learning and want to be better are probably the most important things. Anyone with those two qualities will eventually get the other things and become an excellent developer.
Totally agree.
Want to add comment in the communication and works in teams part, more often than not there are multiple approach/idea to solving a problem, a good developer I think is the one that willing to test those ideas by share and explain it to others.
Just to throw another acronym, has good understanding of SOLID principles.
Thanks for your feedback. Interesting point. I would say: yes and no. I think this is something a great developer should master easily. But you need some sort of experience to feel yourself certain in that field. This can be the case for a good developer, but it is not a must in my eyes.
Interesting
What makes a good developer? Besides all that has been said, I'd say passion.
Practice, practice practice makes a good developer
Some comments may only be visible to logged-in visitors. Sign in to view all comments.