DEV Community

loading...
Cover image for Are you a good developer already?

Are you a good developer already?

pfacklam profile image Paul Facklam ・3 min read

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?

A good developer? - Cat on a notebook

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!

Discussion (44)

pic
Editor guide
Collapse
steinhoefel1 profile image
Thomas Kohler ☑️ Online-Marketing-Expert

Let's add one more: good developers can explain the code they create to people who are not developers themselves.

Collapse
beernutz profile image
beernutz • Edited

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.

Collapse
tripol profile image
Ekanem

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.

Thread Thread
beernutz profile image
beernutz • Edited

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.

Thread Thread
marcosribeirojesus profile image
Marcos Ribeiro

@Ekanem, On Pull Requests!
Following this template here in our company(skore.io):

What?
Change something...

Why?
Because...

Link to the card/ticket.

Thread Thread
tripol profile image
Ekanem

I appreciate your detailed feedback

Collapse
paugustinak profile image
Peter A.

And great developer produces code which is self-documented, so he spares time with "document the code" step.

Thread Thread
beernutz profile image
beernutz

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.

Thread Thread
paugustinak profile image
Peter A.

Agreed.

Collapse
jessekphillips profile image
Jesse Phillips

That would be a great developer, a good one could explain their code to a rubber duck.

Collapse
beernutz profile image
beernutz

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.

Thread Thread
jessekphillips profile image
Jesse Phillips

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.

Collapse
arvindsridharan profile image
arvindsridharan

This is so true.

Collapse
pfacklam profile image
Paul Facklam Author

Interesting thought, Thomas! 🤔

Collapse
andrewbaisden profile image
Andrew Baisden

True when you are capable of doing that then you reach the level of Sensei. 🧘

Collapse
ryencode profile image
Ryan Brown

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.

Collapse
pfacklam profile image
Paul Facklam Author

Valid point but I think that is really high level and something for a great developer. We still need room for improvement. 😉

Collapse
dastasoft profile image
dastasoft

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.

Collapse
kevinhickssw profile image
Kevin Hicks

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.

Collapse
pfacklam profile image
Paul Facklam Author

Totally agree.

Collapse
willsmart profile image
willsmart • Edited

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>

Collapse
pfacklam profile image
Paul Facklam Author

Like that point very much!

Collapse
faridzif profile image
Faridzi

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.

Collapse
solarisregulus profile image
Alex Rashkov

Just to throw another acronym, has good understanding of SOLID principles.

Collapse
pfacklam profile image
Paul Facklam Author

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.

Collapse
bacloud14 profile image
bacloud14

🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣🤣

Collapse
pfacklam profile image
Paul Facklam Author

What's so funny? 😄

Collapse
bacloud14 profile image
bacloud14

The gif 🤣🤣

Thread Thread
pfacklam profile image
Paul Facklam Author

That's very true. I love this meme!

Collapse
msk61 profile image
Mohammed El-Afifi

What makes a good developer? Besides all that has been said, I'd say passion.

Collapse
prgbono profile image
Paco Ríos • Edited

Great article. Congrats Paul!

Collapse
pfacklam profile image
Paul Facklam Author

Thanks Paco. Glad that you like it! 😊

Collapse
vijayvenkatanarayan profile image
VijayVenkataNarayan

good one! Thanks

Collapse
dsouz profile image
D-souz

Practice, practice practice makes a good developer

Collapse
shamshadzaheer profile image
Shamshad Zaheer

Good developer write readable code.

Collapse
muzammilaalpha profile image
muzammilaalpha

Interesting

Collapse
rahil28288 profile image
rahil28288

Agreed, good developers write code with future vision.

Collapse
peppesilletti_4 profile image
Giuseppe Silletti

Great article! I'd also add: understands the impact of his/her work on the business.

Collapse
pfacklam profile image
Collapse
rammahe1110 profile image
Ram Maheshwari

Very helpful

Collapse
vince_amstz profile image
Vincent Amstoutz

So intresting, good job ! 🙂

Collapse
pfacklam profile image
Paul Facklam Author

Thanks! Glad that you like it. 😊

Collapse
gijinih381 profile image
gijinih381

Definitely not

Collapse
pfacklam profile image
Paul Facklam Author

One day you will be. I am very sure about that. 💪