Mat Schaffer <schapht / gmail.com> writes:

> 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
>
>
Thanks. However, I'm embarrassed to admit I still don't have a blog! Just one
of those "to do" items that doesn't seem to rise to the top.

Tim

-- 
tcross (at) rapttech dot com dot au