Education Plan (how to skill up a young team)
zd...@yahoo.com
I'm trying to come up with some ideas for skilling myself and my co-
workers up. I'm in a small company with 6 developers. Most of us have
between 2-6 years experience. Not many people here keep very up to
date in the dev community. Folks here seem interested in learning
more, but as a team we haven't been very good at the ad-hoc learning,
so I want to bring some structure. I want to come up with something
sustainable so that we can start to change the culture here. Since we
don't have any very experienced people here any activities we did
would have to involve everyone doing the learning, we have no
"teacher". Also any activities I come up with would have to fit into
our work load (realistically I could get 1 - 2 hours a week of
peoples time).
I've had a few idea and I'd love some feedback on them and any ideas
for other activities:
1) Do a "lecture" series - There are a lot of great talks from
different conferences. We could listen to a talk then have a short
discussion about it afterwords
2) Have discussion sessions - Someone leads a discussion on a more
philosophical topic, like DRY or SRP or Technical Debt.
3) Book group - I'm a little hesitant about that, because it takes a
big commitment from everyone to do work before we meet. Without a lot
of effort I feel it would be difficult to get that kind of commitment
from the team.
4) Brown bags - Each week (or month) someone gives a technical
presentation.
That's all I got right now.
Any suggestions would be welcomed.
-Zach
Ironic Buddha
Curtis Cooley
> Coding Dojo with a ping-pong approach to a code-kata.
> Get half the number of computers for people in the room.
> Pick a code-kata from http://codingdojo.org
> Have people pair up and the first person starts with writing the first test
> Pass the keyboard to the partner
> Have them write enough code to pass the test
> They write a test
> Pass the keyboard to the first person
> Switch partners
Don't forget to refactor after each passing test. Keeping the code
clean and readable is the reason we put so much effort into software
development. If code was naturally easy to maintain, we'd not need all
this craftsmanship stuff in the first place :)
--
Curtis Cooley
curtis...@gmail.com
home:http://curtiscooley.com
blog:http://ponderingobjectorienteddesign.blogspot.com
===============
Leadership is a potent combination of strategy and character. But if
you must be without one, be without the strategy.
-- H. Norman Schwarzkopf
Steve Donie
I first saw this described at http://davenicolette.wikispaces.com/TDD+Randori+and+Fishbowl which has some good materials to go along with it.
Steve
Zach Shaw
Sukant Hajra
>
> I'm trying to come up with some ideas for skilling myself and my co-workers
> up. I'm in a small company with 6 developers. Most of us have between 2-6
> years experience. Not many people here keep very up to date in the dev
> community. Folks here seem interested in learning more, but as a team we
> haven't been very good at the ad-hoc learning, so I want to bring some
> structure.
> I want to come up with something sustainable so that we can start to change
> the culture here. Since we don't have any very experienced people here any
> activities we did would have to involve everyone doing the learning, we have
> no "teacher".
> Also any activities I come up with would have to fit into our work load
> (realistically I could get 1 - 2 hours a week of peoples time).
I don't mean to be needlessly pessimistic. But I feel I was in a similar
situation in a previous job and reached huge frustrations. I reached a point
personally where I was taking a much more active interest in process
management, testing strategies, flexible design, and other software pragmatics.
I was enthused about how much was out there, and hoping to get others equally
excited. I tried all kinds of communication strategies to engage my peers,
including side conversations, setting up a blog, writing up wiki pages, and
hosting educational brown-bag sessions. Ultimately, my cohorts were at best
only interested in non-invasive spoon-feeding. Management was pretty much
disinterested, and the organization as a whole reflected that leadership.
The only solution that really panned out was to look for another job. I found
a job by networking with groups that were likely to have like-minded people,
and overall I think it paid off.
I'm just worried when I hear things like "not keeping up," "not good at
learning," and "can only give 1-2 hours a week." Especially, with limited
expertise, I feel there's some abrupt limitations you might run into.
Something has to give. Here's some options:
- Management can advocate software craftsmanship, which I don't think
should feel like a small allocation of time, but something that's
integral to the whole process.
- Developers can be motivated to learn more in their personal time.
Obsolescence makes for a nice fear-based motivator.
- Expertise can be hired into the organization. It's just amazing how much
can be learned on the job when pairing with an expert.
Perhaps there's most options out there. Those are just what came to mind.
-Sukant
Esko Luontola
> I tried all kinds of communication strategies to engage my peers,
> including side conversations, setting up a blog, writing up wiki pages, and
> hosting educational brown-bag sessions. Ultimately, my cohorts were at best
> only interested in non-invasive spoon-feeding.
Al Tenhundfeld
Ken Auer
(Thursday lunch... company paid to have lunch brought in) and people
took turns presenting.
Most of the people there worked 40ish hours per week, and would find
time to get enough info together to present. Everyone benefitted from
getting "forced exposure", and the people presenting had to dig deeper
(if you want to learn something, teach it). The company buying lunch
gave the message that technical growth was important.
YMMV.
Ken
Markus Gaertner
Whelan. Gojko Adzic made a fine review of the session:
http://gojko.net/2009/10/15/how-to-promote-learning-in-software-teams/
He had a similar presentation at Agile 2009.
The key ideas here are etudes (http://thiagi.com/games.html) combined with the
practices from Fearless Change and Agile Retrospectives books. Personally I
found the model behind the Fifth Discipline overwhelming.
Personally I made great experiences with Brown bags and lecture series as you
mentioned them down there. Since I'm working in a "busy" company, it's hard to
bring in such activities. Usually invitees come to the brown bags or coding
dojos, but after 3 or 4 of these less and less come there until the approach is
dropped. It's a bit depressing, but you can't force anyone to learn something
new...
Kind regards
Markus Gärtner
Zach Shaw
Thanks for the links they look really helpful.
>
> Personally I made great experiences with Brown bags and lecture series as you
> mentioned them down there. Since I'm working in a "busy" company, it's hard to
> bring in such activities. Usually invitees come to the brown bags or coding
> dojos, but after 3 or 4 of these less and less come there until the approach is
> dropped. It's a bit depressing, but you can't force anyone to learn something
> new...
>
I've done brown bags at previous companies, it was permitted by management, and I had the same experience, attendance petered out. What ever we do here I plan on getting more formal management support. I hope that support will help alleviate the issue (but maybe I'm just being naive) . It's also my belief that folks (okay at least the folks at my company) are really interested in learning more, so I don't think I'll need to do too much wrangling, it's more of a finding the time / getting the support. Oh... and having good topics.
-Zach
Ikenna
So my question is : How can we keep brown bags from 'petering out' ?
How can we keep busy people interested in attending brown bags? I
would like answers to this.
In the past I have sometimes been guilty of shying away from brown
bags because they took up my lunch time (especially if I had planned
to use my lunch time for some personal errand). I am usually happy to
attend brown bags if they are not during lunch time, and take no
longer than an hour (We got permission from management to do that on
one project, and it worked out pretty good).
--ikenna nwaiwu
Dave Hoover
company pay for lunch. As long as the time is used effectively, it's
a relatively cheap investment for the employer, and should pay for
itself over the course of 6 months (as new knowledge is acquired and
leveraged).
Arnaud Bailly
I second Dave's advice. I have set up a weekly coding dojo session in
the company I currently work with and the management agreed to pay for
the sandwiches. We manage to gather 5-10 people each week, not always
the same one, and it has been lastin since June.
But of course, you cannot really prevent "petering out". It is a
constant thing I found over the course of my professionnal life that
whatever group you are in and whatever project you start, there always
will be 10-20% people enthusiastic, 60-70% passive followers and
10-20% reluctant opponents. The only way to prevent such an initiative
from losing too much steam is to be endurant: Even if you happen to
run session with 2 other people, keep going and talking about it. You
have to outrun natural exhaustion of the novelty effect to reach the
steady-state where people start incorporating the session's objectives
and rules and it becomes normal part of your business.
Good luck
Arnaud
Simone Busoli
Arnaud Bailly
with my sentence. Maybe this is due to my poor command of english
language? Could you please elaborate ?
Regards,
Arnaud
SimoneB
statement:
> You have to outrun natural exhaustion of the novelty effect
fundamental to bring in people not looking just for the novelty-ring
effect.
On Nov 9, 8:56 am, Arnaud Bailly <arnaud.oq...@gmail.com> wrote:
> I am not quite sure of how this quote shall be understood in relation
> with my sentence. Maybe this is due to my poor command of english
> language? Could you please elaborate ?
>
> Regards,
> Arnaud
>
> >http://blogs.stpcollaborative.com/matt/2009/11/02/the-inner-ring/
>
Arnaud Bailly
the text, but was unsure. You could also hint at the fact that pushing
such practices in enterprise could be some form of "inner ring"
constructin :-)
regards
Curtis Cooley
>
> Hello,
> I second Dave's advice. I have set up a weekly coding dojo session in
> the company I currently work with and the management agreed to pay for
> the sandwiches. We manage to gather 5-10 people each week, not always
> the same one, and it has been lastin since June.
>
> But of course, you cannot really prevent "petering out". It is a
> constant thing I found over the course of my professionnal life that
> whatever group you are in and whatever project you start, there always
> will be 10-20% people enthusiastic, 60-70% passive followers and
> 10-20% reluctant opponents. The only way to prevent such an initiative
> from losing too much steam is to be endurant: Even if you happen to
> run session with 2 other people, keep going and talking about it. You
> have to outrun natural exhaustion of the novelty effect to reach the
> steady-state where people start incorporating the session's objectives
> and rules and it becomes normal part of your business.
>
George Leonard addresses this phenomenon very well in his book
"Mastery". You're butting up against homeostasis, the strong natural
desire for people and systems to want to resist change. His advice:
1. Be aware of how homeostasis works
2. Be willing to negotiate with your resistance to change
3. Develop a support system
4. Follow a regular practice (like what Arnaud is saying above)
5. Dedicate yourself to lifelong learning
danielrehner
Have a short series (2 to 4 meetings) on a particular topic and then
"restart" the group by changing your focus.
People often feel uncomfortable jumping into an established group.
Even loyal attendees get board. This strategy of "rebooting" the group
provides natural points when all the members of the group can get
excited about something new and can invite others. Then you can send
out messages like this:
Hey guys, we spent the last 3 weeks looking at NHibernate and here are
a few things we learned.
Join us next week as we start a new series on TDD. Here are some of
the things we'll be covering. It's gonna be sweet.
And there will be free food.
See you there!
You can apply the Reboot Principle (yes, I'm coining that term right
now) for your individual learning and life in general. If I focus on
one area or topic for a long period of time, eventually I will get
board. Every 60 days, I come up with 3 areas of life I'm going to
focus on. That focus allows me to get things done in those areas in
that period of time. Then I'm ready to move on to something new.
danielrehner
(dnrtv.com is a good place to start)
and following it up with a 10 to 15 minute discussion of how you can
apply things you learned to the projects you're currently working on.
You don't even have to have a projector. Find someone with a good size
monitor and some speakers and make it work.
Asking people to watch videos during their lunch hour every now and
then is really low pressure and fairly low effort for everyone.
It has the added benefit of bringing in ideas from outside the group
and expanding your horizons.
Raoul Duke
> now) for your individual learning and life in general.
yup. e.g. i think it has worked well for the Silicon Valley Patterns
Group for many years now.