Re: Advice on best practices

[davido]

This blog by MJD changed how I feel when I see what seems at first to me like crazy bad code. Give the people who wrote what's already in place the benefit of the doubt. They may simply have landed on an inelegant approach to solving a more difficult set of issues than you're considering. Early on, learn about what is in place, why it is there, what decisions led to it, and how it solves the problems that you may not be weighing yet.

Only after you've taken the time to fully understand the thought process that led to the code you now see will you be able to maximize your own contributions. And at that point hopefully your patience and open mindedness will have won the respect of your team.

[stonecolddevin]

I really really really like this post. This is one of those things where the person is pretty smart, but they're working in a vacuum. I think communication is the overall key here, and code reviews. I've been introduced to so many tools 3/4 of the way through a project that quite often replace almost all of what I was working on. Part of that is my fault for not communicating enough and part of it is serendipity, getting in touch with the right person at the right time.

Regardless, more communication lends itself to more chances for these encounters.