Codrin Andronic

"stop existing and start living" – M. Jackson

Pragmatic programmer tips

on 2011/05/11

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
Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: