DEV Community

loading...

Discussion on: Are you a good developer already?

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