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.
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.
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."
...
(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.
»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.«
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.
I've been a professional C, Perl, PHP and Python developer.
I'm an ex-sysadmin from the late 20th century.
These days I do more Javascript and CSS and whatnot, and promote UX and accessibility.
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!
I have over 20 years experience primarily developing line of business applications, for a UK clothing retailer. My mantra is good naming convention trumps everything!!
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.
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."
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:
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.
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).
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
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 :)
Alyss has been working in tech since 2012, with diverse experience in Sales Engineering, Developer Advocacy, and Product Marketing with companies such as GitHub, Box, Atlassian, and BigCommerce.
Alyss has been working in tech since 2012, with diverse experience in Sales Engineering, Developer Advocacy, and Product Marketing with companies such as GitHub, Box, Atlassian, and BigCommerce.
never met a part of the stack I didn't like. sr. engineer at clique studios in chicago, perpetual creative hobbyist, bird friend, local gay agenda promoter. she/her. tips: https://ko-fi.com/carlymho
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.
30+ years of tech, retired from an identity intelligence company, now part-time with an insurance broker.
Dev community mod - mostly light gardening & weeding out spam :)
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!)
never met a part of the stack I didn't like. sr. engineer at clique studios in chicago, perpetual creative hobbyist, bird friend, local gay agenda promoter. she/her. tips: https://ko-fi.com/carlymho
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
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
Sure - it's possible that there's a bug in the library that 1,000 other people are using - but it's faaaar more likely that you're using it wrong, making an assumption you shouldn't, or even simply have a typo.
Bugs in other people's code do exist. But you're far more likely to see a bug in your own code that in someone else's. Blame your code first.
The continuous learning and sharing knowledge mentality. I believe the exponential'boom' of the last 10 years in our sector, is due to that, at one point of another.
For example, the ML popularity rise that happened, when Google chose to open source tensor flow
A rule that shall be abandoned:
Being labelled as anti social guys/girls. It is a bit unfair, but it is up to us to change it.
Push code relatively often, definitely at least before you go home for the day. This is the "you could get hit by a bus" rule.
If that's too dark... perhaps we could change it to the "you could get abducted by aliens" rule. Would hate for them to sweep you up after a long day of productive coding, only to leave your team with no way to access your latest changes!
Code with empathy. First for the customer, then for the team. Always think of the impact your work has on your teammates. If it's unstable, who are you keeping up at night to fix it? If it's unusable, no one will be there to pay your salary.
Keep learning. Be aware of current trends. Learn new technologies, even if you're not using them professionally. No position is guaranteed to last forever and your knowledge can help you stumble onto better opportunities.
Crafts UXs and UIs for digital tools by startups and bigger companies. Currently building a better way to give employees and employers a central hub for making their work life kickass.
Already a lot of good ones. "When you point one finger, there are three fingers pointing back to you.", comes to mind. It's easy to blame others or kick downwards on colleagues who might not be as good as you think you are. If you do, you better be that much better yourself. Better yet, replace the blaming/high-horse-sitting altogether with humble understanding, teaching and helping people improve. 😊
Hi, I'm Thomas, chief developer of the SBTCVM project, and all around artist and programmer. I do have more of an understanding of balanced ternary than most i would say.
Visuals<functionality.
Its much better to have an ugly UI, and a fully functional backend, than a backend that's in shambles and a UI that looking good is all it actually does.
Start where the project revolves
When you start with the center-most aspects of your project, it will usually wind up much more on-center oddly enough.
For example, with Desutezeoid, my point and click adventure game engine, i started with the core screen data format (XML) and some basic clickable text items that jump between screens, and worked from there. sure, it wasn't pretty at first, but now Desutezeoid has a solid plugin API, an animation system, inventory management, and a host of other features. and you know what? It even looks halfway decent.
As a continuation, never use images in test that may offend a client. Even in local testing. Nobody as has ever been offended by a photo of a cute kitten.
A coworker had needed the show the client something on his laptop unexpectedly because the client environment was down for updates. Having Nick Cage gifs for every image didn't sit overly well with the client.
Born, raise in Tijuana, MX. With a degree in Philosophy, have worked as janitor, sales person, pizza delivery boy, teacher, press operator, prepress, desktop Publisher, and for the last 19 years dev
Developers are problem solvers. You should always question the need to solve it with software. Think how would you do it without a computer; maybe is a better solution.
Write code in such a style that you are able to understand the code even if you are suffering of partial amnesia. Leave waymarks in your code about your intention.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
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"
:) This makes me feel all the feels. I love it.
Words to live by! Namaste!
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.
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 :)
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!
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.
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
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
Blame your code first.
Sure - it's possible that there's a bug in the library that 1,000 other people are using - but it's faaaar more likely that you're using it wrong, making an assumption you shouldn't, or even simply have a typo.
Bugs in other people's code do exist. But you're far more likely to see a bug in your own code that in someone else's. Blame your code first.
Freelance Coder Rules To Live By...
Nothing gets pushed to production after lunchtime Thursday....
Do not schedule meetings on Fridays.
Don't take calls from clients until after lunch Monday.
Enjoy coding but remember, it's your profession, not your life.
That feature you build today maybe removed in the future. Once you realize this, it will allow you to iterate quicker. 😀
So true!
A rule that shall be kept:
The continuous learning and sharing knowledge mentality. I believe the exponential'boom' of the last 10 years in our sector, is due to that, at one point of another.
For example, the ML popularity rise that happened, when Google chose to open source tensor flow
A rule that shall be abandoned:
Being labelled as anti social guys/girls. It is a bit unfair, but it is up to us to change it.
great comment! Sometimes people seem anti social when they are nervous about making new friends. Reach out and make someone else feel welcome.
For me, the only rule is
I find that developers that say “never do xyz” tend to over complicate things when xyz becomes the best solution.
Push code relatively often, definitely at least before you go home for the day. This is the "you could get hit by a bus" rule.
If that's too dark... perhaps we could change it to the "you could get abducted by aliens" rule. Would hate for them to sweep you up after a long day of productive coding, only to leave your team with no way to access your latest changes!
Code with empathy. First for the customer, then for the team. Always think of the impact your work has on your teammates. If it's unstable, who are you keeping up at night to fix it? If it's unusable, no one will be there to pay your salary.
Everyone's indentation is correct.
Keep learning. Be aware of current trends. Learn new technologies, even if you're not using them professionally. No position is guaranteed to last forever and your knowledge can help you stumble onto better opportunities.
The best code is a code what is not written.
Already a lot of good ones. "When you point one finger, there are three fingers pointing back to you.", comes to mind. It's easy to blame others or kick downwards on colleagues who might not be as good as you think you are. If you do, you better be that much better yourself. Better yet, replace the blaming/high-horse-sitting altogether with humble understanding, teaching and helping people improve. 😊
Visuals<functionality.
Its much better to have an ugly UI, and a fully functional backend, than a backend that's in shambles and a UI that looking good is all it actually does.
Start where the project revolves
When you start with the center-most aspects of your project, it will usually wind up much more on-center oddly enough.
For example, with Desutezeoid, my point and click adventure game engine, i started with the core screen data format (XML) and some basic clickable text items that jump between screens, and worked from there. sure, it wasn't pretty at first, but now Desutezeoid has a solid plugin API, an animation system, inventory management, and a host of other features. and you know what? It even looks halfway decent.
Write clean, simple and easy to read code, instead of fancy pancy :)
don't bullshit.
Don't embed non-constructive comments, profanity or inside jokes
As a continuation, never use images in test that may offend a client. Even in local testing. Nobody as has ever been offended by a photo of a cute kitten.
A coworker had needed the show the client something on his laptop unexpectedly because the client environment was down for updates. Having Nick Cage gifs for every image didn't sit overly well with the client.
Try and error is often how the AHA moments are made.
Developers are problem solvers. You should always question the need to solve it with software. Think how would you do it without a computer; maybe is a better solution.
Write code in such a style that you are able to understand the code even if you are suffering of partial amnesia. Leave waymarks in your code about your intention.