From: Mat Schaffer <schapht@...>
Date: 2007-01-03T23:18:05+09:00
Subject: Re: where to begin?


On Jan 3, 2007, at 1:35 AM, Tim X wrote:
> It usually takes a bit of time to get across any project you join  
> which has
> been running for a while. Don't look at all the lines of code to  
> start with as
> you will get  overwhelmed. My recommendations are
>
> 1. First, find a project you are really interested in. don't worry  
> about the
> complexity or size. It is far more important to get involved in  
> something you
> have an interest in if you don't want to lose momentum too quickly.
>
> 2. Start by offering to provide testing support. All projects need  
> testers. The
> advantage of starting off here is that you will get to understand  
> the project,
> the objectives and how the application works. This high level  
> conceptual
> understanding is critical for getting to understand the lower level  
> aspects.
> Most projects also require people to write documentation. While  
> this is often a
> bit boring and doesn't have the cred of being a code contributor,  
> its important
> and a good way to verify you have the concepts and proper  
> understanding of the
> app. Projects will often succeed or fail based on the quality and  
> relevance of
> the documentation.
>
> 3. As you get to understand the app through testing, start doing  
> some simple
> basic debugging of problems you find. Initially, just start with clear
> documentation of the problem, providing test cases which can  
> reproduce the
> issue and then start providing additional infora\mation and  
> tracking down the
> specific module/file and then the code. Apart from allowing you to  
> get more
> familiar with the application, you will also get familiar with the  
> coding
> conventions, learn additional techniques and slowly develop your  
> own code
> knowledge.
>
> 4. Once you are comfortable with the app, its code etc, select some  
> problems
> from the bug tracking system for the project and try to solve them.  
> Provide
> your solutions to others in the team for their comment and  
> suggestions. don't
> be too thin skinned - some people tend to be very blunt when providing
> criticism of code. Put your ego aside as much as possible and try  
> to appreciate
> what the basis of their criticism is. Sometimes, you may just  
> disagree with
> their analysis, but try to understand where they are coming from  
> and don't be
> too defensive.
>
> 5. Finally, be patient. Most interesting applications/projects are  
> fairly
> complex and it will take a while before you really understand many  
> of the
> finer points. Don't bee to embarrassed to ask for criticism and  
> provide your
> work for others to review. Above all, get involved in something you  
> find
> interesting rather than just something you think will be easy and  
> be prepared
> to take a while before you feel as though you are providing valuable
> contributions.
>
> HTH
>
> Tim
>
> -- 
> tcross (at) rapttech dot com dot au

And a hearty +1 to that!  Nice work, Tim.  That's probably one of the  
best primers I've seen so far.  You should blog that, assuming you  
haven't already.  Maybe see how it fares on digg :)
-Mat