Content note...

[Kit Plummer]

Sounds great...let's go!

When was the first meeting again?

Cheers,

Kit

On 13 Jul 2001 08:56:34 -0700, Rob Wehrli wrote:
> > Hello all,
> >
> > I just wanted to throw my two cents out there.  As a not-so-experienced
> > Linux developer, or just plain developer, my interest in this new group
> > is a little different than the previous messages.  This is not to say
> > that I expect the function of the group to slow down to my level.
> > Indeed, it is my hope that the content is something that I aspire to
> > catch up to, as I have most of my technical career.
> 
> One of my points was that there is enough to being a "developer" for all of
> us to have plenty to "catch up to."  Additionally, in any project, there are
> tons of work for all skill levels.
> 
> The preferred methods I use for quickly bringing a number of team
> members--each with a varied set of skills and ways of thinking--up to speed
> as a group is through pair programming as described in XP.  However, in our
> world of distributed projects, pairing up is tricky at best and probably
> extremely unlikely for any noticeable portion of the time.  Maybe a really
> good project for us to take on would be something that facilitates "remote
> pair programming."  The complexity of the design is dramatically reduced and
> the obvious usefulness of the resultant application could have a major
> impact on the future of Linux development.
> 
> >
> > With that said, I think it would be prudent to follow the course as
> > close to a realistic project as possible.  I do like the idea of
> > tackling real-world issues, however, this would probably not give
> > someone like me a chance at applying the meeting content.
> 
> I wouldn't be too quick to discount your ability to make meaningful
> contributions.
> 
> What I've found is that developers tend to lump into two general categories.
> Those who are open and those who are closed.  Closed developers already have
> all of the answers.  They already know the right way for everything and
> others with differing opinions are wrong because Mr./Ms. Closed says so and
> that is that.  Closed is oftentimes a Prima Dona who sits alone in their
> cubical offering up a "public" interface only if the requestor knows the
> right buttons to press.  (My term for it is, kisses Closed's ass just the
> way Closed likes it.)  Open developers are pioneers of "space" where space
> is the vast world of all that we can accomplish in software given the right
> approaches and right attitudes.  In space, Open knows that there are a lot
> of unknowns so Open approaches the world with a fresher perspective and an
> "open" mind.  Open doesn't immediately say: This is the way it is.  Rather,
> Open looks around and asks, Hey, do you guys think that this is the way it
> is, too?  Open has people coming and going from her/his cube.  Open values
> and wants other's views and comments.  Open freely says, hey, if I do this
> like this, how will that affect you?  Open says, Let's try it and see if it
> works.  If not, we'll try something else! ...while Closed is telling
> everyone that, Hey, it works for me.  Fix your code.  Mine isn't broken.
> 
> My point here is that with an Open mind toward development, you are free to
> concentrate on the elements of the project and not on trying to figure out
> how Closed likes his coffee so that you can get on his good side enough to
> ask that he add something to his code to make your life a bit easier.
> Everyone tends to basically agree with these generalities about developers,
> yet there still seems to be plenty of "Closeds" out there....  What I've
> found is that Closed is often really trying to hide his lack of knowledge.
> Open is searching, Closed has already found as much as he'll "publicly"
> learn.  Being able to contribute effectively in a good working team
> environment is only partly attributable to having strong developer skills.
> The most important contribution anyone can make on a project, IMHO, is to
> offer their *ideas* openly in a team environment where they're encouraged to
> try ideas out and see, learn, understand where the value in the idea is and
> how it can be utilized.  The idea that anyone should feel ashamed or somehow
> "lesser" in a group of developers because of unknowns in a field where there
> are billions of unknowns is fairly ludicrous to me.  The fact that you
> recognize your limitations is a strong step forward toward Open.  Alerting
> others to that shouldn't require you to wear a big red A on your chest, nor
> should it be necessary in a team environment where others are afforded basic
> respect.  That is not to say that you'd feel comfortable leading the
> architecture of *the* design, but at some point, where you're knocking out
> lines of code, you'll be in the driver's seat of leading the architecture of
> your code.  That's why pair programming works so well.  Pairings can be made
> (in environments where pairs can be paired) where "juniors" are paired with
> "seniors."  What I've found is that seniors aren't always--nor are juniors
> always as "junior" as their length of time "doing it."  What generally
> happens is that the two head down several paths making on-the-spot decisions
> at nearly every semicolon.  The two heads are better than one approach is
> very useful in my experiences at making very decent decisions at critical
> way points while also serving to bring more minds up to speed with the
> design, architecture and implementation details of the code/project.
> 
> I think that paired programming should be a requirement in all companies.
> Prima Donas with attitudes should have to find themselves weeded out or, as
> happens in most cases, becoming OPEN!  There is always at least one point
> during pair programming when you must rely on each other's abilities to come
> up with a working solution.  My own observations of productivity through
> pair programming is that tons of good code happens much, much more quickly
> than through "alone in my cube" code.  And, through it all, each pair learn
> a great deal from each other and form a healthy respect for the unknowns
> still out there from the insightful position of having just whacked a few
> into what is now a piece of code that gives them pride.
> 
> >
> > Might it be possible, given enough members of this group, to create more
> > than one simultaneous project.  Maybe even something that could possibly
> > come together in the end.
> 
> Anything is possible, how probable tends to be the "reality check" of most
> ideas.  The challenges of managing multiple projects and ensuring that
> projects are communicating effectively amongst themselves so that the middle
> grows into the end is at least challenging at best and possibly superhuman
> in a distributed group with relatively little shared "road time."
> Remembering that we're 30 days between sessions, we're not very likely to
> accomplish the regular intervals necessary for multiple "independent"
> projects to converge down the road--without a guiding overall architecture.
> Having just said that, every larger project is probably better thought of as
> several smaller projects.  As long as there is a themed architecture that
> guides decision making at the "lower" levels, well, hey, that's how things
> generally get done.  The thing is that it will take 5 or 6 meetings to
> establish a project, an architecture, the sub-projects, who is taking what
> pieces and so forth.  In the first half a year of this group meeting, what
> will we have learned?  ...what we're going to do?
> 
> Of course, that may be what is required for us to make it happen anyway, so
> don't let me sound like a naysayer!
> 
> >
> > Anyway...I know many of you are experienced developers.  I just want to
> > participate in this group in some way shape or form.  So, in all the
> 
> If you want to participate...just keep posting your opinions, thoughts and
> ideas.  What I find happens A LOT is that a few so-so ideas offered by folks
> ends up working themselves into a "creative juices" frenzy where out pops a
> really good idea that everyone just kinda sits back and says, wow WE thought
> of that!  There are not many better feelings in life than fruitful
> teamwork...especially seeing the fruit of our team work being used by
> thousands of Linux users/developers worldwide.  Being able to contribute
> something back is a powerful sense of accomplishment.
> 
> > technical ramblings that insue here in this discussion please remember
> > me.
> 
> Well now, our lots in life tend to be less charitable than the
> self-fulfilling collisions with destiny we find as we race toward our little
> aspirations--often with heads so far up our okoles that we can't see far
> enough ahead to avoid the results of such "wildness."  In other words, it is
> your job to remind those passing you by to help you catch up a bit...while
> seeking to find that nook/cranny where you may wedge yourself so that you do
> not slip off the vast face of the unknown.  Generally, I find that we're all
> tethered to the same rope on the way down, so we might as well help each
> other find strong footing on the way up.  Find ways you can contribute early
> on and your place is assured.  I don't think that I had anything directly to
> do with making that "rule," it seems to be fairly steeded in human nature.
> In any project, there are a million things where people may find footing if
> they're willing to do the grunt work associated with just about every type
> of task.
> 
> >
> > Cheers.
> >
> > Kit
> >
> 
> Take Care.
> 
> Rob!
> 
> _______________________________________________
> PLUG-devel mailing list  -  PLUG-devel@lists.PLUG.phoenix.az.us
> http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-devel
>