re: What are the unwritten rules of development? VIEW POST


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


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


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


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.


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. 🙌


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."


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

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.

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.


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.«


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.


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.


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.

code of conduct - report abuse