DEV Community

Cover image for Philosophy of a Good Developer

Philosophy of a Good Developer

Sarthak Sharma on November 28, 2019

It’s been a long time since we talked about something philosophical. So I thought I'd write a new post for you all, this time going back to basics....
Collapse
 
jmfayard profile image
Jean-Michel 🕵🏻‍♂️ Fayard • Edited

you make a lot of good points
I especially agree with 1) no blame game 2) look at the bigger picture 3) thinking about others 4) write stuff down.

I have some caveats, but they probably only mean the we work in different contexts

  • when writing things down for yourself - as opposed to for the team-, I would recommend to use pen and paper instead of yet another app.
  • I treat comments as code smells. if my code does not speak for itself, I should make it simpler instead of adding soon to be obsolete comments. if something needs to be documented, then in the team wiki or issue tracker, not in the code
  • I don't agree with the no shortcut rule. I choose the simplest way to solve today the problems that I have today, and I'm a big fan of waiting for future problems to materialize instead of fixing them preemptively
Collapse
 
kmwill23 profile image
Kevin

I somewhat agree on self-commenting code, but there are always cases were having the comment right there in another Dev's face is the right way to go.

If a bit of code is non-intuitive, a comment detailing it so other Dev's don't try to "fix" it may be appropriate. My personal example are coding patterns which solve major performance issues, but are not intuitive or self-documenting. Having that info in-context and not in a wiki is very important.

Collapse
 
sonicoder profile image
Gábor Soós

Totally agree. Good points in the article, but the second one is a big no-no.
Comments make the code harder to read, not to mention obsolete comments.

Collapse
 
leob profile image
leob

Regarding comments, there's one thing that I often do:

When I've found a solution to a particularly hard or obscure problem via StackOverflow or another internet resource, I almost always include the URL to that resource as a comment above the piece of code where I'm implementing it in my app's source code.

This way, whenever another dev (or myself) revisits that piece of code they're never left scratching their head "what the heck is this supposed to do", they can simply visit that link and read about the background.

Collapse
 
sarthology profile image
Sarthak Sharma

Wow, that’s so thoughtful. ❤️

Collapse
 
leob profile image
leob • Edited

Well at some point it came naturally. Solutions sourced from SO or anywhere else can be pretty opaque and hard to understand when you're missing the context. To solve that I could copy/paste the text of the SO post as a comment, but just pasting the URL is easier and makes more sense. At the same time I'm sort of building up a little knowledge base. It's just become a habit and I'm pretty much always doing it (unless the solution is really obvious/trivial).

Collapse
 
murrayvarey profile image
MurrayVarey

Don't play the blame game

100% agree. To put a positive spin on it: Accept collective responsibility. (I admit it's not as catchy.) It's awesome to feel that your team has your back, and you theirs. I can't imagine collaboration and open discussion happening any other way!

Just to add: collective responsibility is not easy. It takes constant work from everyone. It requires you to stay empathetic towards others feelings. Make the wrong seemingly-innocent comment, and you might have played The Blame Game without realising. This happens (we're only human), but you have to fix things before the trust is gone.

I recommend using a tool like Todo Plus

Great tip -- I'll look into this. I often come across TODOs, shake my fist at it not being done ... and then realise I put it there.

Thanks Sarthak!

Collapse
 
joemaffei profile image
Joe Maffei • Edited

One of the teams I’ve worked with used to blame most code blunders on a long gone developer by calling it “___ code” (insert dev’s name in the blank). git blame often revealed some of us were actually the culprits. We started calling it “us code” because, even though it may have originally been written by another developer, we all looked at and touched that code every day, and did nothing to fix it.
We also encourage devs to turn off VSCode extensions that continuously show git blame output, as they can encourage a silent animosity amongst developers. Once it’s been reviewed, merged and tested, it’s all “us code”.

Collapse
 
murrayvarey profile image
MurrayVarey

Exactly! Everyone owns the code. Collective responsibility is a wonderful thing -- literally speaking, it means that everyone has the ability to respond. It also means less scowling at other developers.

That's an interesting point about git blame. I think the term itself is unhelpful. Why does it have to be blame? Sure, it probably started out as a joke, and I chuckled first time round ... but still it sets the tone. Maybe it should be changed to thank. Or hug. Or compadre.

Collapse
 
sarthology profile image
Sarthak Sharma

Interesting 🤔

Collapse
 
meatboy profile image
Meat Boy

Great article Sarthak! From my perspective developers sometimes forgot about socializing with friends. It's easy to forget because late-night programming is very fun ;) However, we are still people and even introverts need sometimes to talk with others.

Collapse
 
sarthology profile image
Sarthak Sharma

Can’t agree more

Collapse
 
ascaliko profile image
Ascaliko

a lot of Uwwuuu Points, I like that 😄

Collapse
 
dapptech profile image
Dapptech

So true.. Unfortunately, i realised the importance of good comments after suffering from few mistakes