DEV Community

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

Are you a good developer already?

Paul Facklam on February 16, 2021

As a trainer at click solutions, I regularly supervise trainees and students. Through appropriate onboarding and the teaching of technical content ...
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. 💪