To be a good programmer, you need to keep uptodate with:

• Programming books
• Professional experience
• Magazine articles
• Technology references
• Other software books

What's software development?

[-] Problem definition
[-] Requirements development
[-] Construction planning
[-] Software architecture
[-] Detailed design
[-] Coding and debugging
[-] Unit testing
[-] Integration testing
[-] Integration
[-] System testing
[-] Corrective maintenance

Common software metaphors

• Fred Brooks (1995) says writing software is like writing a letter
• David Gries (1981) says writing software is a science
• Donald Knuth (1998) says writing software is an art
• Watts Humphrey (1989) says writing software is a process
• P.J. Plauger (2000) says writing software is like driving a car
• Alistar Cockburn (2002) says writing software is a game
• Eric Raymond (200) says writing software is like a bazaar and a cathedral
• Andy Hunt says writing software is like gardening
• Paul Heckel (1994) says writing software is like filming Snow White and the 7 dwarfs

Key points:

[-] Requirements changes cost 20-100 times as much in the stages following construction as they do earlier
[-] Every programming language has strengths and weakness. Be aware of the specific strengths and weakness of the language you're using
[-] The number 7 has been found to be a number of discrete items a person can remember while performing other tasks (Miller 1956)

• A function like cosine() is perfectly cohesive because the whole routine does only one function.
• A function like cosineandtan() has lower cohesion because it tries to do more than one thing.
• The goal is to have each routine do one thing well and nothing else.

• Performance is only one aspect of overall software quality, and it's usually not the most important.
• Quantitative measurement is a key to maximizing performing. It's needed to find the areas in which performance improvements will really count.

• Programming work is essentially unsupervisable because no one ever really knows what you're working on. Your employer can't force you to be a good programmer, a lot of time your employer isn't event in a position to judge whether you are good. If you want to be good or great, you are responsible for making yourself great. It's a matter of your personal character.

• Wiegers, Karl. Software Requirements, Microsoft Press.
  • Practical focused book that describes the nuts and bolts of requirements activities, including elicitation, analysis, specification, validation and management.
• Robertson, Suzane, James Robertson, Mastering the requirements process
  • This is a good alternative to Wiegers' book for the more advanced requirements practitioner.
• Gilb, Tom. Competitive Engineering Reading
  • This book describes Gilb's requirements language, known as “Planguage”, the book covers gilb's specific apporach to requirements engineering, design, evaluation and evolutionary project management.

Other good alternatives are:

• Lausaesen, Soren, Software Requirements: Styles and Techniques 2002
• Kovitz, Benjamin L. Practical Software Requirements: A manual of content and Style.
• Cockburn, Alistair. Writing Effective Use Cases
• No Silver Bullets: Essence and Accidents of Software Engineering
• Plauger P.J. Programming on Purpose: Essays on Software Design

• Plauger, P.J. Programming on Purpose: Essays on Software design.
• Jon Bentley, “A small matter of programming”

• Bentley, Englewood Cliffs, Writing efficient programs

• Gilb, Tom. Principles of software engineering management.

• Dijkstra Edsger, “The Humble Programmer”
• The Psychology of Computer Programming