DEV Community

Discussion on: What are the unwritten rules of development?

Collapse
 
ignoreintuition profile image
Brian Greig

When you are looking over someone else’s code, before you criticize, recognize that they likely did what they did for a reason.

Collapse
 
nektro profile image
Meghan (she/her) • Edited

You can't make a decision with information you don't have.

Collapse
 
rhymes profile image
rhymes

Great point! A corollary: don't judge the person by the quality of the code.

Collapse
 
raphael_jambalos profile image
Raphael Jambalos

That's true. People get better over time. And maybe the person who wrote that code is so much better now. I look down on the code I wrote 2 yrs ago, and that's just mark on the progress I made thus far.

Collapse
 
ben profile image
Ben Halpern

Damn that's a good rule.

Collapse
 
miku86 profile image
miku86 • Edited

I have an easy rule: Always start with a honest "Awesome, ...".
"Awesome, your code is very readable."
"Awesome, your layout is great."
"Awesome, your site looks great."
...

Collapse
 
nssimeonov profile image
Templar++

What if it's not?

Thread Thread
 
miku86 profile image
miku86

I think there's always one small thing.
"Awesome, you put some hard effort into it."

Thread Thread
 
nssimeonov profile image
Templar++

I appreciate your sarcasm :)

(in case it was not - read below)
I had two colleagues, who used to make me scream when seeing their code. First was so completely incompetent, that whatever he touched made significant regress, but he tried hard. Damn hard. He used to work for 10h/day and read tutorials for another few in his free time, but still 1 year and a half later he produced such unimaginable things, that I had to delete 80% of his code (and usually replace 10 lines with a single statement if at all).

The other one was competent, but sort of lazy and usually handed me code, where 60% of it was commented tests, some was incomplete and poorly tested. When asked to clean up his code he usually deleted the commented code... and a few lines of non-commented code inside them (yeah one can hardly spot them sometimes) and didn't even test before marking the task as complete.

Thread Thread
 
twigman08 profile image
Chad Smith

The first person is usually the type of person that I PERSONALLY will take time out of my day to sit next to and help out. Maybe code review the stuff together. I find that helps me fully get their thought process and I can explain my thought process more verbally and not just written. I personally have helped a few people that fit what you described (and I think more people who code review should do it).

The 2nd person should be brought up with to upper management in my mind. That's not fulfilling your job duties and his hurting the project and the company in the long run.

Collapse
 
thomasjunkos profile image
Thomas Junkツ

100% ACK. Additionally:

»the idea is not "why did you do this wrong" but "what made this seem like the right thing to do at the time to a reasonable and intelligent person in the situation?" -- Hard on systems. Soft on people.«

twitter.com/tottinge/status/105072...

Collapse
 
bob_at_bh profile image
Bob Koon …amatata

100% this! When I do code reviews, I remember to always ask for clarification in a format like "what was the intent/your intention here?" instead of something like "why did you do it that way?"

As soon as one starts anything with "why", the receiver feels the need to be defensive. "Why" is an aggressive word and should be avoided.

Collapse
 
webreaper profile image
Mark Otway

Sorry, but "why" is not an aggressive word. Asking somebody why they did something is no more aggressive than asking what their intent was.

If "why" is coming across as aggressive in a code review, then it's because your overall code review experience is too adversarial, and needs to be reoriented to be more about achieving quality code, and less about blaming people for mistakes.

Collapse
 
devtlk profile image
Shaprieh

I love this! In the words of Erykah Badu "I'm and artist and I'm sensitive about my..." Coding is definitely an extension of creativity. Sound advice to keep defensive feelings out of it.

Collapse
 
siwalikm profile image
Siwalik Mukherjee

Also an advise for code newbies, however stupid your code might look after reviews, never take review comments personally.

Your mentors have achieved a lot in their career and at some point, written crappy code too. So rather learn from their comments and be awesome. 🙌