5 ms·
The top two are on my list as well. The tricky part is that my "good code" is someone else's "bad code" and vice versa. Slowly trying to introduce functional co
by nevon 10y ago
The top two are on my list as well. The tricky part is that my "good code" is someone else's "bad code" and vice versa. Slowly trying to introduce functional concepts into a team of developers who are used to working with what can only very loosely be described as MVC.
- brown-dragon 10y ago> The tricky part is that my "good code" is someone else's "bad code" I feel your pain...
- _virtu 10y agoWhile you're at it a style guide may be in order. Try to convert your team's current patterns into the set of new patterns that you think are better. This would help to give others a sort of rosetta stone while they're making the switch. I always try to add a why after each good vs bad code comparison. Having a document external of your brain helps others to feel like they have a tangible set of goals instead of some arbitrary set of goals that nevon wants to have happen. I made my team's style guides repos on github so it's super easy to edit since it's straight markdown. Keep the pedantic discussions to a minimum. Sometimes it's just best to choose something because it's a single way of doing it.