• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

ship it: building developers

 
Jeanne Boyarsky
author & internet detective
Marshal
Posts: 34074
337
Eclipse IDE Java VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?
 
Pat Hill
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Jared Richardson
author
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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?


Yes.

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.
 
Jared Richardson
author
Ranch Hand
Posts: 113
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.


Great point! Can I blame the publisher?
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic