The first and most important advice I can give you: Give your working week a structure.
That's how I do it:
Mondays: Code Review and Functional Quality Assurance for things that have passed QA
Tuesdays: Preparing Reports for Management and Stakeholders (Code Metrics Development over time, status of current stories/use cases)
Wednesdays: Put functional requirements for a use cases/story in a form that the team can understand (technical spec, column mappings, mandatory fields, ui, implementation design)
Thursdays: Code a little bit, provide support for functional and technical issues
Fridays: Code a little bit, provide support for functional and technical issues
Daily: Ask each developer about status and impediments
I work extensively with Indian Developers at the moment who face real problems coding against a database that is in a foreign language. Also, they have a very hard time understanding the functional requirements. I try to give them technical specifications and encourage them to learn the business. I also found out the hard way that I need to monitor them each day and every day in order to keep code quality high. I get a glimpse on their commits every day in order to kill bad/wrong code and structures as early as possible. I also do detailed code reviews every monday.
Doing Code Reviews
As the code base grows larger, you cannot look at every single file. But for Java I use code quality metrics tools like: sonar, dependometer, ncss, checkstyle and findbugs, load the xml file results into a custom excel file to see the development over time (counts of issues of a certain type). If they reach a threshold, I identify the main source and talk to the developer(s). With these metrics, I can easily spot bad coding practices. Also, I review the code quality of the more important parts manually each monday. I have a custom script to run them all at once and also a custom build setup.
Keeping track of the teammates work results
Supply management with information etc.
Ask the developers daily about the status and current impediments. Those conversations should be short. Once a week you check the stuff marked as quality checked from QA and prepare a document for the stakeholders that includes:
- Current state of work items
- Code Quality Development over time (as
- Next steps
- Current impediments
Further, I always supply them with a document about our coding conventions and a document called "Definition of Done" so every developer knows when something is done and does not bother me to review something that has not been finished properly. The latter contains stuff like "Passes all the tests and statistifies acceptance criteria, code is xhtml compliant, build compiles without warnings and errors etc.";
But perhaps the most important tool for this is a ticket management system, like jira or trac to always have a good overview over the current state.
Have the whole big picture in mind all the time
That's tough but doable. Just have the big picture of the architecture in mind. In fact, you should've created it in the first place. When developer's ask me questions, I mostly consult my specification or my prepared Story/Use-Case documents as well as recent customer communication. Tools like mind maps help a lot. I also use UML every now and then to get a good glimpse on the big picture. But I do not go very much into detail with UML. I use it in a unconventional way, to communicate functional requirements to developers and for myself to lookup. I also use it to get a picture of the domain classes used and their relationsships.
See also this answer of mine for further information:
Standard practices for an architect