7 ms·

I thought I would make an addendum: > We all know at least one developer who ... will always insist on following “best practices” without understanding why tho

I thought I would make an addendum: > We all know at least one developer who ... will always insist on following “best practices” without understanding why those practices are considered “best” (there is no such thing as best practices that adapt to every team) For any developers out there recently starting on your path, I cannot stress the importance of taking the time to seek out best practices for new skills and technologies you pick up. Find all the "best practices" you can, then ignore some of them for a while with some pilot code, then try to follow a combination of the ones that make most sense to you. Compare the two modules for legibility, clarity, maintainability and conciseness. If, however, your team already has an entrenched way of doing things, don't be that jerk who comes to the party blasting their own music. Follow the existing style guides to a T and only offer advice for improvement after you've spent some time working with them. Even if you immediately recognize a glaring problem in the way things are done, no one is going to take you seriously and you'll just come across as arrogant unless you already have rapport as a perceptive and helpful team member. Take time to understand the culture around you, but don't, as this author suggests, ignore the tried and true devices of other cultures.

jlokier 8y ago
I agree. I'd like to add, in my experience some developers firmly (and sometimes loudly, judgementally) join a working environment and espouse best practices they've acquired from a cultural background they've worked in so far. Or read about, or watched a training course about. And they don't know (or care if) they are pushing things which are advertised as "best practice" in some domain or other, but aren't half as universally agreed upon as they think, and aren't half as effective or appropriate as they think in the new job. My point is: Some "best practices" aren't as universally agreed upon as people think, and people are often thinking in a bubble. If you're at a new job, and you see a glaring lack of what you've learned is "essential" best practice, I'd urge caution in assuming your new team are ignorant or that your managers are as clueless as you think at first, even if it looks messy and disorganised. Of course they might be clueless! But it takes time and deep questioning to be sure. Of course your experience should be brought into each new place you work. You're hired to bring in what you know, not just to fill a seat. By all means talk about your experience, about things you have actually done which worked well, and about what industry leaders are currently talking about. But if you feel the need to "teach" everyone straight away how to work better, give it time and consider the possibility that people might have given it considerable thought and experience of their own. They might even be familiar with much of what you're talking about, and rejected it or found a different approach. (Or they might not - that's to be discovered.) I say this because I've seen people turn up and, in effect, try to start fights long before they have spent the time to figure out (a) others in the team are quite experienced and familiar with the same practices but have decided on something else, (b) different industry bubbles actually do have different best practices for similar problems, and (c) they can't see some kinds of development strategy that are in use, because subtlety.

jlokier 8y ago

I agree. I'd like to add, in my experience some developers firmly (and sometimes loudly, judgementally) join a working environment and espouse best practices they've acquired from a cultural background they've worked in so far. Or read about, or watched a training course about. And they don't know (or care if) they are pushing things which are advertised as "best practice" in some domain or other, but aren't half as universally agreed upon as they think, and aren't half as effective or appropriate as they think in the new job. My point is: Some "best practices" aren't as universally agreed upon as people think, and people are often thinking in a bubble. If you're at a new job, and you see a glaring lack of what you've learned is "essential" best practice, I'd urge caution in assuming your new team are ignorant or that your managers are as clueless as you think at first, even if it looks messy and disorganised. Of course they might be clueless! But it takes time and deep questioning to be sure. Of course your experience should be brought into each new place you work. You're hired to bring in what you know, not just to fill a seat. By all means talk about your experience, about things you have actually done which worked well, and about what industry leaders are currently talking about. But if you feel the need to "teach" everyone straight away how to work better, give it time and consider the possibility that people might have given it considerable thought and experience of their own. They might even be familiar with much of what you're talking about, and rejected it or found a different approach. (Or they might not - that's to be discovered.) I say this because I've seen people turn up and, in effect, try to start fights long before they have spent the time to figure out (a) others in the team are quite experienced and familiar with the same practices but have decided on something else, (b) different industry bubbles actually do have different best practices for similar problems, and (c) they can't see some kinds of development strategy that are in use, because subtlety.