Recently I read an interesting book about software development - “The Pragmatic Programmer, From Journeyman To Master“. I highly recommend it to all programmers. As a summary, following is a list with the highlights:
- Invest regularly in your portfolio
- Diversify your knowledge (the more things you know the more valuable you are)
- Manage risk when investing in knowledge (are you learning useful things?)
- Learn a new programming language every year
- Read a technical book every few months
- Experiment with different environment
- Stay up to date with technical news
- When you have something to communicate, make a plan
- Know what to say
- You must know the audience
- Choose the right moment
- Pay attention to aesthetics (if you write a document, or make a presentation)
- Involve the audience
- Listen
- Provide answers
- Do not duplicate (code, functionality, comments, anything)
- Develop orthogonal (independent) systems
- Develop closed components (do not let other components to change its state)
- Use prototypes to try something experimental, such as:
- Architecture
- A new functionality into an existing system
- The structure and content of external data
- Component or 3rd party tools
- Performance
- UI / design
- When you make a prototype, you can omit:
- Correctness
- Completeness
- Robustness (error handling)
- Style (comments, documentation, writing clean code etc.)
- Implement your own mini-language when you need it
- Do not panic
- Always use source control
- Learn a text manipulation language.
- Use code generators
- Write “shy” code – do not reveal too many details and do not interaction with many modules
- Minimize coupling
- When writing methods, use parameters of primary types
- Develop configurable systems
- Consider concurrency when you design
- Always be aware of what you do
- Developing something you don’t understand or working with technology that you are not familiar with is an invitation to make mistakes or wrong decisions
- Work with a plan
- Do not make assumptions. If you have to assume, consider the worst case
- Document the assumptions and talks to them
- Do not just test code, test assumptions too
- Prioritize efforts and tasks
- Do not let existing code dictate future code
- Complexity of algorithms, in descending order of performance:
- O (1) – access to array elements, simple instructions
- O (log (n)) – binary search
- O (n) – simple loops, computing min/max in arrays
- O (n * log (n)) – quick sort, heap sort
- O (n ^ 2) – two nested loops, selection and insertion sort
- O (n ^ c) – combinatorial problems
- Always test an algorithm for worst case before you start improving it (is it absolutely necessary, has it reached its limits?)
- Consider refactoring in case of:
- Duplications
- Dependent components
- Code that is expired due to modifications to the requirements
- Bad performance
- When you discover that something needs refactoring, acts immediately or as soon as possible
- Don’t do refactoring and add functionality at the same time
- Make sure you have rigorous tests before you begin refactoring
- Take small steps and test often
- Write code that is easy to test. Tests help to develop orthogonal systems
- Test all possible input/output
- Write tests before implementing
- Unit tests illustrate how to use the module being tested
- When gathering requirements for a project, spend time with users to better understand their needs
- Use use-case diagrams when writing requirements documents
- Do not overload requirements
- Keep track of changes in the requirements
- Use a glossary to identify clearly each term used in the project
- In most cases, a problem seems more complicated than it actually is. Approach it systematically. Ask yourself the following questions:
- Is there a simpler way?
- Are you trying to solve the correct problem?
- Why is it a problem?
- What makes it so difficult?
- Must it be done this way?
- Is it needed?
- Automate everything.
- Generate documentation from comments in the code
- Comments say what is implemented; they don’t explain how
- Expectations should be communicated and exceeded only slightly
Advertisement
