Team management : your advice...
-
Yes and I respect that, thats why I am a bit confused about : if I should introduce an extra learning day or go forward with some alternative. Encouraging them to give weekly presentation - in working hours, not from their personal time - on any topic of their choice is not working.
Have you thought of having the team do a book study: > give each team member a copy of a book that discusses the ideas you want the team to learn > each week, the team reads a chapter (or a smaller or larger chunk of content - whatever is appropriate for the topic at hand) of the book (everyone reading the same chapter, of course!) > each week, the team meets (on company time) to discuss the pros and cons of the idea(s) presented in the chapter. The last step can be very effective if, each week, a different team member is asked to find a situation in their current project where they could apply the idea presented in the book. This provides for a useful discussion of the difficulties and benefits of using the idea; it also helps make the idea concrete for everybody, in a way that is often hard when you're just reading from the book. Sometimes, holding the meeting over lunch, and providing food (pizza and beer soft drinks commonly being the food of choice in the US), is both popular and effective. HTH, Chris
-
Code review. Some good tools are Code Collaborator by SmartBear and Crucible by Atlassian (Crucible is only $10 for small teams).
Jason, What has your experience with code reviews been? While I accept that code reviews can have some benefits, I've found that there are ways that help and ways that don't. One-on-one code reviews are often the most helpful at teaching new concepts to junior developers. There's plenty of room for question and answer, for showing how the design concept turns out in actual real-life code, etc. And it's a 'safe' environment where 'stupid' questions can be asked without embarassment! Team-based code reviews, where everyone scrutinizes a piece of work done by one of their peers, are (in my experience) really not so good as teaching tools - there are too many people in the room, and with people come opinions. Too many opinions leads more to confusion than to learning. I guess with a strong leader conducting the session, its possible that this wouldn't happen - but then team members can end up feeling suppressed and denied being able to fully participate / contribute. Further, such code reviews often get bogged-down in nit picking about coding style, use of comments / use of #region / variable names / adherence to (and value of) coding standards, etc. If teaching new coding ideas in a team setting is the preferred approach, I would recommend something more structured than a code review. (More structured meaning something ilke formal training, but a structured in-house presentation / classroom / workshop is equally useful if the resources are available.) The only time I was in a team-based code review that worked was (years ago) on a real-time project coded in C. Being real-time (without a user interface) it needed to be extremely reliable. The code review was a very appropriate mechanism to get many eyes on the code, looking for holes in the implementation of the algorithm, the error handling, etc. Being C code with no UI, it was also a relatively small body of code - making it feasible to do such a code review. Chris
-
My team compromises of me + 5 developers + 1 designer. They have experience ranging from 6 months to 2 years. Although we are producing good results and have satisfied clients, but I want developers to get a better understanding of program flow, logics and OOPS concepts. So I need your advice about how to groom them. I give them flexi-timings, two days a week off and personal guidance whenever wherever required. I am thinking about converting a week-off as learning day - no work just study.But not sure if this would be right move. ** all are singles and doesn't care much about work-life balance.
I would suggest lunch and learns. You provide the food. Schedule one per two weeks at a minimum. Determine what topics need to be covered (you list what you think the knowledge/skills gaps are and then ask them for their lists too). Ask for volunteers then assign the remaining topics so everyone has a couple of topics. Schedule the most useful topics first. Presentations should be white board. Don't necessarily need a PowerPoint if the presenter knows the topic. If the presenter doesn't know the topic then he/she gets to research/learn it and present it. Everyone is involved, learns, and shares.
-
Also, hold design sessions with them so you can see how they think and they can see how you think. I once had a team leader who did this and I think we both got something valuable from the experience. He might say, "all of our objects should be serializable so we can easily store them to the audit log." I might agree, and ask, "should we use binary serialization, or XML?" He could then go on, "I'd go with XML, that way we can open the logs without a special tool." I might concur, "that makes sense, especially since these are local files and space is not a big concern." He might go on, "not only that, but XML compresses very well, so we might adopt that for our network protocol as well." You get the idea. Design sessions are sort of like a pleasant way of teaching without anybody being the teacher.
Friedrich Nietzsche wrote (proof that trolls predate online forums):
These [philosophers] always become in the end [...], perhaps without being themselves aware of it, sophisticated vengeance-seekers and poison-brewers.
Then, I might ask, why use XML if you are thinking of compressing the data. Wouldn't the binary data be smaller? It too can be compressed. That is, since XML is a larger (human readable) representation of the data.
-
Have you thought of having the team do a book study: > give each team member a copy of a book that discusses the ideas you want the team to learn > each week, the team reads a chapter (or a smaller or larger chunk of content - whatever is appropriate for the topic at hand) of the book (everyone reading the same chapter, of course!) > each week, the team meets (on company time) to discuss the pros and cons of the idea(s) presented in the chapter. The last step can be very effective if, each week, a different team member is asked to find a situation in their current project where they could apply the idea presented in the book. This provides for a useful discussion of the difficulties and benefits of using the idea; it also helps make the idea concrete for everybody, in a way that is often hard when you're just reading from the book. Sometimes, holding the meeting over lunch, and providing food (pizza and beer soft drinks commonly being the food of choice in the US), is both popular and effective. HTH, Chris
A good place to start is Design Patterns by the GOF. Each chapter is a design pattern and it would be noteworthy for the members to find a situation where the pattern is used. Also, it would encourage a good design vocabulary and possibly, think more in design rather than programming. Thus, it would be easier to see the intended result from a higher level. I do think that the best way of learning is by doing. And, actually applying the concept and discussing it (including written analysis) allows the 'student' to measurably gain the knowledge and make use of it. Your thoughts?
-
Then, I might ask, why use XML if you are thinking of compressing the data. Wouldn't the binary data be smaller? It too can be compressed. That is, since XML is a larger (human readable) representation of the data.
XML serialized data is isomorphic with binary serialized data, so is in theory just as compressible. Perhaps even generally more so for compression algorithms that assume a byte boundary. Or so I might say. :)
Chris Maunder wrote:
Fixign now.
But who's fixing the fixign?
-
Step 1: Tell your team that their promotion and salary increases will depend on their taking up these concepts, as you have decided that the team needs to have more professional education in these areas. Step 2: Meet with the team. Allow the team to prioritize the professional development activities you perceive as valuable, and brainstorm what time, materials, and experitse the team needs to take them up. Set a schedule, using your existing training time. Step 3: Be sure the team is putting their training into practice. Bring up problems in the design or code that were either solved by concepts they are learning or caused by lack of sophistication. Consider doing heavyweight code reviews with the team. Make sure every team member knows they will have a turn to have their code reviewed. Let them nominate code for review, either because they're proud of it or because they're worried. Step 4: At performance review time, reward team members who are working hard to bring better practices, and those who already have good practice. Reward any kind of leadership in bringing new practice. Don't give raises (or even reduce salary) for team members who obstruct this process. Tell them why. Make it a goal for their next performance review to improve their training in these areas. I guarantee this will focus their attention. It will also cause team members who dib't want to get with the program to remove themselves from the team, which honestly is what you want. It's less stressful than letting them go. This is called "putting your money where your mouth is." Teams alwasy do what they get rewarded for doing. They always do what they perceive is important to their management, because they want to get a good performance review and a raise. As management, you need to tell them what is important, and then you need to follow up so they can *see* that it is important, because teams can tell the difference between words and actions.
Awesome, clear, suggestions!
-
Jason, What has your experience with code reviews been? While I accept that code reviews can have some benefits, I've found that there are ways that help and ways that don't. One-on-one code reviews are often the most helpful at teaching new concepts to junior developers. There's plenty of room for question and answer, for showing how the design concept turns out in actual real-life code, etc. And it's a 'safe' environment where 'stupid' questions can be asked without embarassment! Team-based code reviews, where everyone scrutinizes a piece of work done by one of their peers, are (in my experience) really not so good as teaching tools - there are too many people in the room, and with people come opinions. Too many opinions leads more to confusion than to learning. I guess with a strong leader conducting the session, its possible that this wouldn't happen - but then team members can end up feeling suppressed and denied being able to fully participate / contribute. Further, such code reviews often get bogged-down in nit picking about coding style, use of comments / use of #region / variable names / adherence to (and value of) coding standards, etc. If teaching new coding ideas in a team setting is the preferred approach, I would recommend something more structured than a code review. (More structured meaning something ilke formal training, but a structured in-house presentation / classroom / workshop is equally useful if the resources are available.) The only time I was in a team-based code review that worked was (years ago) on a real-time project coded in C. Being real-time (without a user interface) it needed to be extremely reliable. The code review was a very appropriate mechanism to get many eyes on the code, looking for holes in the implementation of the algorithm, the error handling, etc. Being C code with no UI, it was also a relatively small body of code - making it feasible to do such a code review. Chris
I did heavyweight design and code reviews (those involving a team actually meeting to go over paper listings) that were successful in teaching OO design, providing the team a shared standard for coding practices, and disseminating knowledge about the system we were building. Notices of code reviews were published in advance. We required at least three people at each review, but didn't require the whole team. What happened was that reviews of important parts of the system got more attendees, so the system was self-regulating and self-limiting. At design time, we reviewed 100% of all base class definitions, mostly for good interface design. Toward the end of coding, we reviewed about 75% of the code, starting with modules having high cyclomatic complexity as measured by a tool we found on the net, and those nominated by team members as needing review. The team credited these design and code reviews for our high delivered quality level. I'd institute this process again in a heartbeat if I was leading a team of new devs. One-person-glancing-at-the-checkin code reviews are not thorough enough. Preparing code for a formal review causes the developer to look at their own code with reviewers eyes; adding comments, tidying things up, checking their work, because nobody wants to be busted for poor practice during the review. It adds a degree of discipline that encourages good practice.
-
I did heavyweight design and code reviews (those involving a team actually meeting to go over paper listings) that were successful in teaching OO design, providing the team a shared standard for coding practices, and disseminating knowledge about the system we were building. Notices of code reviews were published in advance. We required at least three people at each review, but didn't require the whole team. What happened was that reviews of important parts of the system got more attendees, so the system was self-regulating and self-limiting. At design time, we reviewed 100% of all base class definitions, mostly for good interface design. Toward the end of coding, we reviewed about 75% of the code, starting with modules having high cyclomatic complexity as measured by a tool we found on the net, and those nominated by team members as needing review. The team credited these design and code reviews for our high delivered quality level. I'd institute this process again in a heartbeat if I was leading a team of new devs. One-person-glancing-at-the-checkin code reviews are not thorough enough. Preparing code for a formal review causes the developer to look at their own code with reviewers eyes; adding comments, tidying things up, checking their work, because nobody wants to be busted for poor practice during the review. It adds a degree of discipline that encourages good practice.
Buried in your response was a gem:
Member 2941392 wrote:
At design time, we reviewed ...
! People (myself included, sadly) often think of code reviews, but fail to think of design reviews - which are probably of equal (but different) value than code reviews. For a review with, say, presenter plus three reviewers, do you have a sense of how much content (design ideas being very different content from (nearly) finished code) could be reviewed in an hour / two hours. Also, what was your experience of the maximum workable duration of a review session, and does it vary with the number of particpants?
-
Buried in your response was a gem:
Member 2941392 wrote:
At design time, we reviewed ...
! People (myself included, sadly) often think of code reviews, but fail to think of design reviews - which are probably of equal (but different) value than code reviews. For a review with, say, presenter plus three reviewers, do you have a sense of how much content (design ideas being very different content from (nearly) finished code) could be reviewed in an hour / two hours. Also, what was your experience of the maximum workable duration of a review session, and does it vary with the number of particpants?
I think design reviews are even more valuable than code reviews. They happen earlier in the design process, and defects caught earlier are less expensive to remove. The subject of the reviews is more interesting and less tedious, so people want to come. We would review a .h file containing a single large and well-commented class definition, ypically 100-200 lines, in an hour. Presented alongside the .h file was a CRC Card, a lightweight text document of 1-3 pages. Rebecca Wirfs-Brock has written two books about CRC Cards, which I also really like for their bervity and informality. Sometimes we would review the skeleton of the .cpp file too if the presenter thought that would be interesting. By the time we had done half a dozen design reviews, we realized there was a standard list of questions that were always going to be asked unless the design explicitly accounted for them. We wrote these questions down and made the document available to the whole team, so that each team member would pre-review their class against the questions. This greatly streamlined the review process. As lead, I arranged for the first couple of reviews to be on my code, because (1) I thought I could bear up under the scrutiny without becomming defensive, and (2) I was an experienced developer, so I thought my code would be a shining beacon of reason and elegance. To my slight chagrin, the reviewers, inexperienced though they were, were capable of finding defects even in my beautiful interfaces. I learned a lot about my own practice. This turned out to be fortunate. We were able to establish that nobody was so good that they didn't need reviewing. We also established a polite and professional team demeanor for pointing out issues in other peoples' code. I was careful to point out during the first couple of reviews that we would all have a turn in the hot seat, and payback was a bitch, so that politeness and selflessness were good attitudes to practice. We also had architectural design meetings. These would be familiar to any dev who has been in on a project during design. We drew interaction diagrams and class diagrams. We had an electronic whiteboard that copied onto fax paper. I highly recommend some such aid. The technique we did that was most helpful was structured walkthroughs, in which we would try to follow a thread of execution through each objec and method call. The technique is valuable during design, precisely because you have to say, "main() constructs the foo object and then calls foo::init() to initialize it. foo