Team management : your advice...
-
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.
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.
-
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.
I concur. :thumbsup:
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
-
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 concur. :thumbsup:
Luc Pattyn [Forum Guidelines] [My Articles] Nil Volentibus Arduum
Please use <PRE> tags for code snippets, they preserve indentation, improve readability, and make me actually look at the code.
Way to lead by example. ;)
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.
-
My advice: lead by example. If you find a particularly useful example in your own code base of, say, the factory pattern, then send out an email to your coworkers with a link to an article describing the factory pattern and explain how you've employed it in your code base. When they do something that perhaps could have been done another way, point out how they can improve what they've done. Start a wiki with coding guidelines and general guidance (e.g., "avoid global variables, use web.config/app.config for variables which may change between dev and prod systems").
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.
Yes I do this, we discuss each and every project design before we start and each change and its impact. Does work with them on their code with them implementing known best practices, sharing shortcuts providing tools I can afford. But I want to strengthen their base more, but I always feel lack of time on my part as I have to deal with multiple projects and clients simultaneously,so I want to built-in something autonomous. I know it need a change in behavior of the team so that they feel that they have to study and share for their own benefit - yes they know it, instead everybody knows it but there is a lack of action. Behavior change is a very delicate process and you can't change it by command, it has to be something from within and with right kind of motivation. I know if I do something wrong here and support / motivate in wrong direction it may cost a career. So am bit conscious about the same. As adding a day per week may give out a message that they are loosing their freedom and they may take it negatively. Current atmosphere of team is very healthy and I don't want to ruin that. And I still want to improve their skill levels. That's why I am here for more suggestions and advice. :)
-
There has to be a balance between nuture and discipline and, as already been said, leadership by example.
Join the cool kids - Come fold with us[^]
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.
-
There has to be a balance between nuture and discipline and, as already been said, leadership by example.
Join the cool kids - Come fold with us[^]
I think this "lead by example" thing is BS. I tried it at one job, what a disaster! It ended up with everyone down the pub. I had to find a new watering hole to get some peace and quiet.
Henry Minute Do not read medical books! You could die of a misprint. - Mark Twain Girl: (staring) "Why do you need an icy cucumber?" “I want to report a fraud. The government is lying to us all.” I wouldn't let CG touch my Abacus! When you're wrestling a gorilla, you don't stop when you're tired, you stop when the gorilla is.
-
There has to be a balance between nuture and discipline and, as already been said, leadership by example.
Join the cool kids - Come fold with us[^]
When those fail, fear still works pretty well. :rolleyes:
Will Rogers never met me.
-
When those fail, fear still works pretty well. :rolleyes:
Will Rogers never met me.
-
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.
Stone Soup[^]
-
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 work in a similar setup, less the designer, but have worked earlier on with two (graphics) designers in the team, for much more visually demanding projects than we do now. I assume when you say designer you mean the same as I do. Occasionally we get a specialized SW tester assigned. Programmers and designers need to learn mostly different things, so you can't treat them all the same. Giving programmers time for study and not telling them what to study is in most cases not really efficient - one must know what to study, in order to spend this time efficiently. Telling them what to research is likely to piss them off, and isn't necessarily efficient, if you don't assign different research topics to different people and find a way for the people to share the results. What I have seen working, and what is IMO a very nice way to spread and equalize knowledge among team members: designate subjects for presentations, assign time to one team member only to research the subject in depth, and have him do an in-depth presentation of the matter. Let people come up with their own topics of interests for presentations. Assign the person preparing the presentation three days or a week for preparations, but designate different persons for each presentation. Assign half a day or so for the presentation plus questions and answers. Have the presentations archived on the intranet. Occasionally review old subjects and reschedule them, to see (and to make everybody aware of) how they changed. The presentations don't have to happen weekly, in fact if you do them too often it's possible that people start perceiving them as counterproductive. Once or twice a month, depending on how much effort is available and what interesting subjects are on the list, should be enough. Only very few presentations will be interesting for programmers and designers alike. Don't try to force people to participate in all presentations - you'll just piss off the designer if you force him to assist in a presentation of spring.net, for instance, although basic notions about colors or interaction design might be interesting for programmers. One other thing that I have done, and which IMO works excellently, not only because it builds knowhow, but also because it builds a common way of doing things, is to have one person, and one person only, do software design for projects, and have the whole team criticize this, then have the initial designer do the revisions which are agreed upon by the whole team, and restart the process. At least in the beginni
-
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.
-
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.
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.
-
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.
Code review. Some good tools are Code Collaborator by SmartBear and Crucible by Atlassian (Crucible is only $10 for small teams).
-
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?