3 Career Guidelines from The Pragmatic Programmer

The Pragmatic Programmer by Andrew Hunt provides practical suggestions on all aspects of software development.

Guideline 1 – Develop a Knowledge Portfolio

“An investment in knowledge always pays the best interest.” Benjamin Franklin

Programming is an intellectual activity and the value of a programmer is based on their knowledge portfolio. The portfolio must be built and maintained with regular investment and diversification:

  1. Read at least one technical book per quarter
  2. Learn a new programming language every year
  3. Keep up-to-date with emerging technologies

Local user groups are a good way to improve your knowledge portfolio and provide an environment to hear about career opportunities.

Guideline 2 – Communicate Well

Strong communication skills help programmers to build influence in an organization.

  • Choose when to communicate based on audience needs
  • Adjust your message to suit the level of understanding
  • Listen first, then respond

Use the WISDOM framework to target your presentations:

  1. What do you want them to learn?
  2. What is their Interest in what you’ve got to say?
  3. How Sophisticated are they?
  4. How much Detail do they want?
  5. Whom do you want to Own the information?
  6. How can you Motivate them to listen to you?

Guideline 3 – Pick the Right Tools

Tools amplify talent. Aim to:

  • Use a single editor well
  • Understand the command shell
  • Use source code control
  • Automate the build process

5 Technical Guidelines from The Pragmatic Programmer

The Pragmatic Programmer by Andrew Hunt provides practical suggestions on all aspects of software development.

Guideline 1 – Write Understandable Code

Code is read more times than it is written so spend time writing clean code with clear variable names. Add comments when it is necessary to explain why the code is written that way and the decisions behind the implementation.

Each software module should be responsible for a single aspect of the system. When software modules are written to act independently, the system can provide more combined functionality as a whole. A module should not delve into another module’s implementation (Law of Demeter). Ask for what you need directly instead of digging through the module hierarchy.

Guideline 2 – Refactor Early

Refactor early to prevent existing code dictating future code. Refactoring is a process that must be undertaken slowly, deliberately and carefully. Always take short deliberate steps and have good test coverage before you begin.

Refactor when there is:

  1. Duplication
  2. Nonorthogonal design
  3. Outdated knowledge
  4. Improve performance

Every piece of knowledge in a system should have a single authoritative representation (DRY principle). Developers will often duplicate code in the short term to ship faster, at the expense of duplicating effort to update that code in the future.

Guideline 3 – Expect Errors

Everyone writes bugs. Do not trust or expect yourself to write perfect software and do not blame third-party libraries for your mistakes.

When you find a bug, try not to panic and concentrate on fixing the problem. The best way to start fixing a bug is to make it reproducible. This will also tell you when it is fixed. If you feel stuck, explain the problem to someone else as the act of explaining often reveals the solution.

Try to fail early at the site of the problem. Errors should not leave the system in an inconsistent state, for instance charging a credit card but not processing an order.

Guideline 4 – Test from the Start

Projects with automated tests have a better chance of success. Accessible test code is an invaluable example of code use, with crucial benefit of alerting you of regressions as you make changes to the system.

Build testing into the software from the beginning. Test each piece of the project independently with unit tests, then together with integration tests. When you design a module or even a single routine you should design both its contract and the code to test that contract.

Guideline 5 – Use Configuration Files

Put abstractions in code and details in configuration files. Configuration files allow an application to be customized without recompilation. This is extremely important in critical live systems which need to dynamically reload metadata while running to prevent downtime. Another use-case is distributing the same core app to different clients and enabling features based on their specific configuration.

3 Project Guidelines from The Pragmatic Programmer

The Pragmatic Programmer by Andrew Hunt provides practical suggestions on all aspects of software development.

Guideline 1 – There are No Final Decisions

“It’s easier to ask for forgiveness than it is to get permission” Grace Hopper

There are no final decisions in software construction. Some requirements will turn out to be easy and some impossible. Product managers that ignore this fact will always be shocked when the future arrives and they are left wondering what went wrong.

Teams become less aligned on decisions when there are more people involved in the decision making process. Separating responsibilities between team members helps teams to make decisions faster.

Guideline 2 – Requirements Will Change

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to cut away.” Antoine de Saint-Exupéry

Recognize which requirements are long-lasting and which are short-term. Business policies like shipping freight every two weeks can change, but the fact that the system is about freight shipment will not. Document these changeable business policies away from the more generic requirement and recommend they are implemented as metadata or configuration in the final application.

Try not to be a slave to formal methods like UML because these methods often require additional explanation to both programmers implementing the specification and the end users buying the software. It is far better to iterate on a technical blog post that can be shared with both users and developers.

Guideline 3 – Estimate from Experience

Estimate to avoid surprises. The best estimate comes from someone who has already created a similar project. Take time with estimates instead of producing them off-the-top of your head.

A simple technique to improve your estimates is to:

  1. Break the software application into components
  2. Estimate the duration to create each component
  3. Compare the actual durations to the measured durations
  4. Use this knowledge to iterate your estimations

Anything critical or difficult should be first implemented as as prototype. This helps to reduce the cost for correcting design mistakes by analyzing and exposing risk at the start of a project.