Things to Ponder

1. What does it mean when projects are created in the "cathedral" versus the "bazaar"?
Typically, the cathedral model is based on having a select group of trained professionals working on a project and closely monitoring its progress.  This approach would likely be very controlling and not just anyone would be able to contribute.

The bazaar model would be open to all with little to no oversight and not as much control or management.  People would be free to make changes at will and there wouldn't be a clear system of accountability.

2. Which system does an open source project typically look like?
As it turns out, it's a lot more like the cathedral model than people predicted.  Most open source projects have a group of people that administrate and monitor changes to the system.  They are the ones that give permissions for people to join the project, usually after demonstrating a certain level of professionalism and skill, who can then update and make changes to that system.

3. Why is it good for every programmer to get involved in an open source project?
Being accepted into an open source system as a developer is great for a number of reasons.  It establishes a public example of the kind of code you are capable of writing, shows that you have a certain level of proficiency and professionalism, and it shows that you can coordinate in a lucid team environment with people from all over.


4. How many "learn to program in 10 days" books do you need to become a good programmer?
None.  The 'best' way to become a 'good' programmer is to get a little experience each day.  There are plenty of resources online such as language tutorials, API documentation, discussion forums, etc. that you can learn from.  The idea that you can read a few "learn language such-and-such" in a short amount of time and be proficient at it is an error.  You really need to take continual steps over a long period of time, closer to 10 years or so, before you really develop a lot of proficiency in a field.  It is also good to continually push yourself further in your understanding by challenging yourself as you learn.

5. What are some basics that will be necessary for an interview as a programmer?
First of all, you should not be afraid to write some code in your interview!  Be able to at the very least demonstrate a firm understanding of languages that you list on your resume, which means being able to write syntactically correct code from memory without references.  One site recommends that you should be able to write code for various abstract data types and implement basic algorithms in each of your "proficient" languages.  It is also helpful to know a variety of language types.  Somethings are much more difficult to implement in an interview with an imperative language like C++ or Java, but can be accomplished easily with a scripting language like Perl or JavaScript.  Also, be sure to know the basics of Object Oriented Programming and the primitive data types.  (It also helps to dress for the interview, don't forget to present yourself as a professional in person)