DEV Community

loading...

Discussion on: Are you a good developer already?

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
pfacklam profile image
Paul Facklam Author

Interesting thought, Thomas! 🤔

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
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
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
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
andrewbaisden profile image
Andrew Baisden

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