What underlying rules govern our work?
Which are good and which need to be dropped?
For further actions, you may consider blocking this person and/or reporting abuse
What underlying rules govern our work?
Which are good and which need to be dropped?
For further actions, you may consider blocking this person and/or reporting abuse
dev.to staff -
Lev Nahar -
Sloan the DEV Moderator -
dev.to staff -
Top comments (71)
When you are looking over someone else’s code, before you criticize, recognize that they likely did what they did for a reason.
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.
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.
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.
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."
...
What if it's not?
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.«
twitter.com/tottinge/status/105072...
Damn that's a good rule.
Learning how to ask the right questions (obviously) gets you the right answers BUT also helps you strengthen your understanding.
My mentor once told me 'A senior developer is just a developer that learned to ask the right questions by understanding the problem better'
Sticks with me everyday
I love this! Do you have any suggestions on how to do that — how to ask the ‘right’ questions?
I think the only answer to that is the cliche answer of time and building things. Once you build something unlike what you've built before, you'll find yourself tackling challenges that are new to you.
Your google-kwan-do will strengthen and you'll start to see others who have hit the same wall along with ways they accomplished it.
Don't release on Friday.
That should be a point on every code-producing company's policy.
There's only one, really, but I'm so bad at following it that I had to make it written
Doesn't count anymore. It's written!
From a friend and mentor - "When you get to the top, send a ladder back down"
Words to live by! Namaste!
:) This makes me feel all the feels. I love it.
Sleep a little bit more. You'll squash your current bugs and have less of them to deal with in the next few days
I can definitely relate with this one. Stepping away from your code (not necessarily sleeping), keeps you fresh and gives you a new angle of analyzing that stubborn bug.
I'd extend that to looking after yourself in general - getting enough to eat, drink, exercise and, as you rightly say, sleep! No code is worth losing your health & wellbeing over!
The fastest, safest and cleanest code is that which does not need to be written.
This is a rule I regularly promote.
Todo comments are not for bug fix reminders.
Todos are for acknowledging completed code could be done better but the current code meets requirements and is therefore shippable.
Yeah, we have
// FIXMEcomments to remind us of bugs ;)I am not saving lives.
Some developers write code with a lot of real life consequences, I'm not one of them. So I keep that in mind.
I had a boss who'd been in a Major in the Air Force, and had been wounded in combat. Whenever the debate over some technical point got very heated, he'd interject with, "Calm down. This isn't combat. Nobody is going to die if we pick the quick route over the safe route."
eheh great point :-)
Exactly. I make mobile apps and crud apis and I still get so much anxiety over it. If I were writing code for airplanes, banks etc, I'd have anxiety 24/7. I'm still working on taking care of my anxiety but it's difficult.
take care of yourself Avjinder, that's the most important thing.
I don't have suggestions on how to combat anxiety but I remember this thread which talks about depression and anxiety. Maybe you can find some tips in there:
Depression & Anxiety in programming
Phil Walker
Thank you for the link, it's really helpful. I am working on improving my mental health but the progress has been slow. I've chalked it up to this being my first professional job, and being handed a massive load of responsibility. I expect it to go away with time and experience, but only time will tell. One thing I've been recommended is to leave work at the workplace, and not bring it home with me. That has been helpful for me to a certain extent. Imposter syndrome is a bitch though, and cumbersome to get rid of.
You should read my article about programming and anxiety on DEV
Rule1: Write tests. Explain your processes in this tests.
Rule2: Write comments. Dont explain your code, explain why u wrote this code in this manner.
Rule3: Dont forget to do some research work before start coding. (Refresh your design pattern skills, architecture, dependencies around your projects, etc).
The second assertion is controversial. The developer should not justify himself. He must share knowledge at first.
Stop trying to be clever.
Clever solutions < simple (or elegant) solutions.
I'd take a css solution over a javascript one any day.
You've got that sign backward there :)
Thanks!
There is nothing so permanent as a temporary fix.
More colloquially known here as "fix it in post".
I'm having fun trying to ensure that all features / fixes that we have going into service have a clear statement of what will enable them to be decommissioned, before they go live: giving the more malevolent of us a goal or two :)
I think mine is actually that if there are rules, they should be written or codified somewhere! Strong communication and making no assumptions about what makes sense to other people I think is a must when working on a development team.
Corollary: a colleague will /always/ forget something important when communicating: most likely because it's the context of their issue and they are inside it. Be prepared to live in the dark for a while as you politely ask for explanations and they surface from their silo... sometimes resolving stuff in the process (hello Rubber Duck debugging!)
Oh, yeah, being prepared to ask questions and walk through stuff with people is like a real key underrated dev skill.
Know your weaknesses, and don't be afraid to admit them.
I'm mainly a front end developer, and I have a lot of experience with server side tech (Apache, Tomcat, Node.js/Express/Koa/Sails/etc), as well as several flavors of Linux administration. I'm more than happy to do my best and answer any questions about those topics, as well as provide resources for learning more.
The minute you ask me a database question, I'm going to stop you, and tell you that I don't know enough to provide good or accurate information, and you're better off talking to a DBA. I can read SQL, I can write some (bad) SQL, I can use an ORM library to interact with a DB, and if it's Postgres, I can do enough on the command line to be dangerous. Outside of that, my knowledge of databases is very limited, and I make no attempt to hide this fact. I'm starting to learn more, but the fact of the matter is that for my day-to-day job, it's not needed
Learn how to test
write good tests
test
Be creative. You're allowed to find answers from outside the box.
Stretch. Get up, move around. Learn how to walk away and come back later.
Read the code before you ask! Then ask, ask more, keep asking until you understand.
Learn how to ask good questions
Don't role your eyes
Offer to help when you are needed
Include everyone on the team in new initiatives
And most important of all