This week's book giveaway is in the Mac OS forum. We're giving away four copies of a choice of "Take Control of Upgrading to Yosemite" or "Take Control of Automating Your Mac" and have Joe Kissell on-line! See this thread for details.
The other I noticed was: What's normal on a project, and what's not. I would think it has to be "what's acceptable on a project and what's not". Somethings' might happen so often on so many different projects (who hasn't been to numerous unproductive meetings?) as to be considered "normal", but may not be acceptable.
Originally posted by Jeanne Boyarsky: One of the blurbs in the book description is: "How to build developers as well as product"
Does this refer to developer training, teamwork, process or something else entirely?
Check out the Key Practices poster. Several of the ideas deal with developer training and teamwork. For example, in Techniques, Code Reviews refers to mini code reviews held several times throughout the day. Intead of holding your code for a grand 50 page review, we suggest reviewing the code very frequently. This helps to share the ideas in your head with other developers (training them), lets the reviewer give you feedback (training you). Here's a quote from the book describing the reviews: (sorry for the formatting... I'm experimenting.)
Don�t wait too long for any one person to have the time to do a review; walk around the shop, and find somebody who�s not deep into a problem. Walk to the other side of the building if you have to, but find someone. If it�s someone you haven�t used for a code review before, this is a great opportunity for them to see what you do.
These quick code reviews promote mentoring without the overhead of a formal program. By varying the developers you work with for code reviews, you get the benefit of a variety of developers� experience and expertise. Each reviewer will point out different ways to solve the same problem. Some better, some not, but all different.
Tip 18: Always review all code
The goal is to learn how to think creatively while also improving your product. Learn to look at your own problems from different points of view. These short code reviews will become second nature over time, and just like microwave ovens, you�ll wonder how you ever survived without them. Practical discussions of algorithm analysis or resource constraints are lessons that are taught (and remembered) because you have a practical and immediate application.
Rather than academic book learning or certifications, you�ll be sitting at the workbench of various craftsmen (some masters, some apprentices) learning a little bit from each one, adding their tricks to your own, until one day you are one of the master craftsmen yourself.
The goal for the code review is both developer training as well as teamwork.
Another Key Practice is Daily Meetings (similar to the Scrum dailing meetings). The idea is to meet very briefly every day (1 to 2 minutes per person). Each team member answers three questions. What did you do yesterday? What problems did you encounter? What do you plan to do today?
When young team members talk about their problems, the more experienced developers have mentoring opportunities, resulting in training.
Everyone meets and talks ~every day~. This type of daily interaction is a great team building exercise.
As to process, check out the bottom of the Key Practices poster. We devote a large portion of the book to Tracer Bullet Development. Tracer Bullets require team interaction at the beginning of the project and throughout the development cycle.
We believe that building software is an holistic process. If you want to build teams and product, you can't do it in a vacuum. Each area (Techniques, Infrastructure and Process) must all play a part.
Check out <b>Ship It! A Practical Guide to Shipping Software</b><br /> <br /><a href="http://www.pragmaticprogrammer.com/titles/prj/" target="_blank" rel="nofollow">http://www.pragmaticprogrammer.com/titles/prj/</a>
Joined: Jun 22, 2005
Originally posted by Pat Hill: The other I noticed was: What's normal on a project, and what's not. I would think it has to be "what's acceptable on a project and what's not". Somethings' might happen so often on so many different projects (who hasn't been to numerous unproductive meetings?) as to be considered "normal", but may not be acceptable.