Content note...

[Rob Wehrli]

> 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!