I have a few pieces of advice. The general theme, always focus on making other people successful, and make sure things are meaningfully organized with both current and future team members in mind.
1. Checklists make everything easier. What needs to be in the checklists should be the most common issues that come up during code review or have been related to defects that made it past the dev environment.
2. Good agile documentation means all business rules/application behavior requirements should be in the story/task and in a centralized wiki. This makes it possible for new team members to familiarize themselves with application behavior quickly, and that list of behaviors is also the documentation on what needs to be tested so QA can implement integration and regression tests.
3. Every major code review needs an organized explanation of code changes per business rule. I've got my team using a OneNote where they initially write down each stories business rules at a high level for non-technical people in a list format and add sub items that describe an architectural overview of changes like design patterns and technologies used, and an addition sub level briefly describing code changes. I also have them provide links to an articles they used to make decisions or that describe design patterns used rather than needing to rewrite them. This rarely takes longer than an hour for a large story and it provides a semantic map between business logic and technical terminology for non-technical people and a sort of historical stream of consciousness that can be looked back at to get a feel for the history and direction for a given project.
4. Assess how team members are doing with technologies they use and get them whatever training they need.
5. No matter how experienced a developer might be before they join your team, new team members should always start out by getting the project to run and fixing bugs. Expecting too much too fast is a guaranteed way to lose high quality talent.
6. Always keep your ego out of everything and if someone is getting defensive about code, remind them that there is no such thing as perfect code. There is always room for improvement, and the focus on any changes or development/architectural decisions must always be about the potential future cost of each decision. Principals like Dry and Solid are important, but over implementing them will always result in difficult to maintain code. Abstraction is only good if it doesn't lock you into a design pattern that might not apply to the future state of all application behaviors you might need in the future. Also, reflection based code is cool to implement and a huge pain to get right let alone maintain or update.
7. Always beware implementing anything you're excited about. Code should always be focused on efficiency and maintainability, never on how cool or familiar a specific tool is. This is sort the same as keeping your ego out, but more about keeping your excitement out of things.
8. Developers should talk to customers, and logging should be implemented in ways that enable analyzing feature usage and user feedback. Many feature request come from managers, but the end users are the people that really need to feel like your software improves their lives.
9. Beware any list that has a psychologically pleasing number of items because it is definitely padded out or shortened to reach that number.
1. Checklists make everything easier. What needs to be in the checklists should be the most common issues that come up during code review or have been related to defects that made it past the dev environment.
2. Good agile documentation means all business rules/application behavior requirements should be in the story/task and in a centralized wiki. This makes it possible for new team members to familiarize themselves with application behavior quickly, and that list of behaviors is also the documentation on what needs to be tested so QA can implement integration and regression tests.
3. Every major code review needs an organized explanation of code changes per business rule. I've got my team using a OneNote where they initially write down each stories business rules at a high level for non-technical people in a list format and add sub items that describe an architectural overview of changes like design patterns and technologies used, and an addition sub level briefly describing code changes. I also have them provide links to an articles they used to make decisions or that describe design patterns used rather than needing to rewrite them. This rarely takes longer than an hour for a large story and it provides a semantic map between business logic and technical terminology for non-technical people and a sort of historical stream of consciousness that can be looked back at to get a feel for the history and direction for a given project.
4. Assess how team members are doing with technologies they use and get them whatever training they need.
5. No matter how experienced a developer might be before they join your team, new team members should always start out by getting the project to run and fixing bugs. Expecting too much too fast is a guaranteed way to lose high quality talent.
6. Always keep your ego out of everything and if someone is getting defensive about code, remind them that there is no such thing as perfect code. There is always room for improvement, and the focus on any changes or development/architectural decisions must always be about the potential future cost of each decision. Principals like Dry and Solid are important, but over implementing them will always result in difficult to maintain code. Abstraction is only good if it doesn't lock you into a design pattern that might not apply to the future state of all application behaviors you might need in the future. Also, reflection based code is cool to implement and a huge pain to get right let alone maintain or update.
7. Always beware implementing anything you're excited about. Code should always be focused on efficiency and maintainability, never on how cool or familiar a specific tool is. This is sort the same as keeping your ego out, but more about keeping your excitement out of things.
8. Developers should talk to customers, and logging should be implemented in ways that enable analyzing feature usage and user feedback. Many feature request come from managers, but the end users are the people that really need to feel like your software improves their lives.
9. Beware any list that has a psychologically pleasing number of items because it is definitely padded out or shortened to reach that number.