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.
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!
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.
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. 😊
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.
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.
Latest comments (69)
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.
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!
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.
Try and error is often how the AHA moments are made.
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. 😊
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.
don't bullshit.
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.
Everyone's indentation is correct.
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.