The Joel on Software Discussion Group (CLOSED)

A place to discuss Joel on Software. Now closed.

This community works best when people use their real names. Please register for a free account.

Other Groups:
Joel on Software
Business of Software
Design of Software (CLOSED)
.NET Questions (CLOSED)
TechInterview.org
CityDesk
FogBugz
Fog Creek Copilot


The Old Forum


Your hosts:
Albert D. Kallal
Li-Fan Chen
Stephen Jones

Conducting Study group

Hi,
I want to do a study group for a book,Code Complete, in our company.The idea is that,we will meet very 15 days to discuss 1 or 2 chapters(will decide beforehand what chapters will be covered,so that people read-up) from the book.Have anyone of you have any experience of doing such activity? How do you do it?Pls share your experiences.
thanks
vish
Sunday, February 17, 2008
 
 
Never done it, we just read the book, take it in and get on with work.

Sounds like a PHB idea to me.
JFDI
Sunday, February 17, 2008
 
 
Gawd I hate developers. Anything that involves a little interaction with others is a PHB thing.

I've conducted quite a few study groups. In fact, I've just started one on design patterns at my current workplace. We meet weekly, assign a pattern to read, and have one member of the group do a short presentation that includes:

- The purpose of the pattern (what problem does it solve)
- How to code the pattern
- The pro's and con's of the pattern
- Real life examples from existing code, if any

We try to have that covered in 30 minutes or less. We then spent maybe another 30 minutes talking about the nuances of the pattern, our experiences with it, etc.

The response so far seems to be pretty good. If participation in discussions seems slow at first I find it's usually because developers, as a rule, generally hate to admit they don't know everything. If you can make the group a "safe" place to ask questions, some real learning can occur.

Good luck.
Bruce
Sunday, February 17, 2008
 
 
> Have anyone of you have any experience of doing such activity? How do you do it?Pls share your experiences.

Yes but we didn't "meet up": I've done that online.

Choose a book and then, each week:

* Everyone reads a (the same) chapter (e.g. Chapter 1)
* Anyone posts one or more questions/comments about the chapter, on an online forum like this one
* People reply, discussion ensues, questions are answered

Repeat as above for the next chapter the next week. Also, practice what you're studying by applying it to your work.
Christopher Wells Send private email
Monday, February 18, 2008
 
 
I conducted a study group a few months ago on design patterns.  The result was less than ideal.  There was low participation and attendance. 

A few take aways from my personal post-mortem:

Having a written schedule is good.  Its also good to remind the presenter and the group the weekly assignment so they remember.

Make sure the expectations for presenting are clear.  While I stated my expectations, I did not write them down.  The first presenter did not make a power point presentation, which prompted many subsequent presenters to not prepare.

There was no pressure to complete the readings or a proper presentation.  People were lazy and not looking to get anything out of it.  Only half the group was actively engaged.

Have specific goals that you expect people to get out of the course.  The people in the course have to expect those goals and actively want to achieve them.  Otherwise, you'll get poor response.

---

Frankly my experience shows that many presenters will not do well on their own.  Perhaps a group with the correct motivation will not have the problem.

If the group seems like it will be a motivational challange, break presentation duties in groups of two to discourage slacking off.  Further, create a training site to post the resulting presentations (vidio and audio if possible) to encourage better work.

In non-motivated groups (the case in my previous employer and the hospital journal clubs I am aware of) most people will not read the articles.  This can limit discussion. 

If groups are of radically different skill levels on the topic, the people who are worse tend to be more quiet.  If possible, segrigate by skill level.

Beyond that, in the future, if groups are unmotivated, I would avoid a study group.  Instead, I would present the material and then have activites to encourage interaction and use. 

If you have the right people, you don't need to do anything beyond create a schedule.

Monday, February 18, 2008
 
 
The problems is that understanding new material and learning how to present it publicly are two different tasks. If you require everyone to make public speeches, they will be overstressed.
Roman Werpachowski Send private email
Monday, February 18, 2008
 
 
thanks people.Got some good ideas and insight.
vish
Monday, February 18, 2008
 
 
I participate in a study group that is multi-company.  It is an offshoot of our Java User Group meetings.  In fact, we did design patterns not long ago.  The mechanics of our group is to meet once a week on the same night.  We cover about one or two chapters a meeting, depending on the particular subject and chapter length.

What makes a study group enjoyable are the people and level of participation.  If the people in the group are abrasive or just dormant, it isn't going to be much fun.  A few tips:

1. Appoint a facilitator.  He schedules the meetings, sends out the e-mail reminders, and tracks the books and chapters.

2. The facilitator should avoid leading the discussions.  Participation is key.  Different topics flip different passion bits in different people.

3. Make it as democratic as possible.  Vote on your book, on the chapters, and even the meeting times.

4. Avoid having two books back to back from the same category.  In other words, don't feature a book on Scrum followed by a book on XP.  Mix it up.

5. Make it fun, and they will come.
Knight Who Says Ni
Monday, February 18, 2008
 
 
"first presenter did not make a power point presentation"

Glad to hear it.
Wes Groleau Send private email
Monday, February 18, 2008
 
 
Powerpoint presentations are fine. When they are done correctly.

Think Overhead projector dot points of the older days. As soon as you start using punctuation on a presentation, your "dot points" are too long and people will start reading your sentences instead of listening to you speak.
... Send private email
Monday, February 18, 2008
 
 
There was a study done a few years ago on how they put people to sleep.  I am inclined to agree with it, regardless of how the bullet points are put together.  In fact, if they mostly consist of bullet points you're not putting anything in the preso that I can't already hear coming out of your mouth.
http://www.informationweek.com/news/showArticle.jhtml?articleID=198800871
midwesterner
Monday, February 18, 2008
 
 
I liked Joel's PowerPoint presentation on the World Tour.

First slide:

Name, Company, Title of presentation etc.

Errmmm ... that's it! Then dive into the Application ...
Krispy Send private email
Tuesday, February 19, 2008
 
 
"first presenter did not make a power point presentation"

Perhaps you should be studying a different book.
How about "Introduction to Best Software Writing I" by Joel Spolsky starting at p261.

 http://www.joelonsoftware.com/articles/BestSoftwareWriting.html
Dipstick Send private email
Tuesday, February 19, 2008
 
 
Coding examples are best served visually.  Writing context and solutions on the white board is distracting.  Power point presentations work better than hand drawing many times when you need visual accompanyment to speech.

Further, it serves as a good record for later review.

Tuesday, February 19, 2008
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz