Being a development lead has its own set of challenges. You know a lot of stuff that can be considered as a best practice, but to ensure that everyone in your team is following them is one such challenge. How do you overcome this?
views:
150answers:
8
+3
Q:
As a Dev Lead, what are the top few things that you ask your developers to consistently follow?
+1
A:
How many people are on your team? Just get your version control system to mail you all the diffs from their checkins, read them, and tell people if they're not doing the right thing.
Carl Norum
2010-03-17 01:58:33
That's a good idea Carl. I don't know how feasible it is though to do this on a regular basis, especially if the team is big. I will try doing this for a couple of guys initially and see how it goes.
Rahul Soni
2010-03-17 04:06:54
+5
A:
Pick your battles. "Best practices" is a broad brush, there any many ways to skin a cat. Hopefully you aren't leading twenty people. Get to know each developer and their individual style. Don't be too rigid. Work with each one to play to their strengths. Earn your developers' trust. Do regular code reviews and form a relationship with your team that allows you give an honest, constructive review without offending.
Dave Swersky
2010-03-17 01:58:57
Tabs for indenting, spaces for alignment. But that's another discussion...
masher
2010-03-17 02:26:51
+1
A:
A good rule is one in which you can objectively measure if someone is following it or not.
One rule I like to make: complete automated test coverage of code inside libraries.
If you have a code coverage tool then verification is simple: use the source control system to detect new lines of code, run the tests, see if any of the recently added line of code are covered or not.
If any of the code is not covered, figure out who wrote the code, then send the issue back and tell the developer to write the test.
Do that every day for a week or two, then you can quietly change to only doing it weekly (without telling the team that you're doing it less often).
Andrew Shepherd
2010-03-17 02:05:53
---Do that every day for a week or two, then you can quietly change to only doing it weekly (without telling the team that you're doing it less often).I really that advise!! Thanks Andrew.
Rahul Soni
2010-03-17 02:47:06
+2
A:
Make your job about helping everyone else kick ass at their job. If you take this perspective, the steps you need to take with each individual becomes obvious.*
One thing I am implementing (YMMV) is a variation on the concept of the "daily standup" - every day we have a technical standup where each developer has ~3 minutes to show the code they are working on. No feedback, no comments. No background info or "progress update" on the task - just pure "this is what I wrote yesterday". This accomplishes a number of things at once:
- Gets developers over their embarrassment of showing unfinished code to others
- Makes "going dark" nearly impossible
- Keeps me aware of anyone going in the wrong direction by no more than a day, and I can address the specific issues with them one-on-one.
- Fosters a collaborative and improvement-oriented environment where everyone expects to get something new from everyone else
- If one day's worth of code is incomprehensible without extended explanation, that's an example of an area of improvement for that individual.
*from one lead to another
Rex M
2010-03-17 02:12:46
+3
A:
Do a partial code review on their work but before that ask them to code review their own work if they comply to the team\company's standard (like naming convention, comments, etc.).
You may also use automated code review software.
Jojo Sardez
2010-03-17 02:47:02