The Pragmatic Programmer: Investing in Your Knowledge Portfolio

Coding Blocks just began a new series of podcasts about my favorite all-time programmer-y book: The Pragmatic Programmer. Talking about it helped me focus my thoughts on the subjects, and I hope that you get as much out of the conversation as I did.

Listen to the show and let me know if you can figure out how to tell if you are making stone soup or just boiling frogs.

Here is a snippet of the show notes:

A Pragmatic Philosophy

Note: 20th anniversary edition going into beta May 8th

Written by programmers, not designers of some framework or language, the book presents patterns for developing software.

This book is packed full of greatness even in the foreword:

• There are no perfect tools, methodologies, or solutions. You must pick the best bits for each particular situation.
  • Don’t fall in love with any particular technology or tool.
  • Use your experience to help pick the right solutions for any particular situation.
• Pragmatic programmers get the work done and do it well.

This book is for those who want to be more productive and effective developers.

Traits of a Pragmatic Programmer

How would you rate yourself on these traits?

• Early adopter / fast adapter
  • Instinctive and passionate about trying out new technologies.
  • Confident and grasp new things quickly.

• Inquisitive

  • You ask a ton of questions, you want to know as much as you can about what’s being done.

• Critical thinker

  • Don’t accept whatever is being said or claimed. Use your experience to think through the problem.

• Realistic

  • You understand when something is complex and what that means for timelines.

• Jack of all trades

  • You keep your knowledge broad even if your practice is very focused / narrow.

Tips

• Care about your craft.
• Think about your work.
  • Always evaluate what you’re doing and why.

Just Good Advice

• Embrace individuality and craftsmanship, even on large teams.
• Always be working to sharpen and hone your skills.

The Cat Ate My Source Code

“The greatest of all weaknesses is the fear of appearing weak.” – J. B. Bossuet

• Adopt an attitude, style, and philosophy of approaching problems and solutions where you’re always thinking about the big picture.
• Take responsibility for your actions.
  • Commit to something being done right even though you don’t have control over all aspects of what’s being done.
  • This doesn’t mean you have to fall on the sword. In “impossible” situations, it’s up to your discretion to not accept responsibility for what is happening.
  • Accepting responsibility is being held accountable.
  • If you do make a mistake or there is a shortcoming, be honest and offer options.
    • Vendor didn’t come though? You should have had a contingency plan. Can’t blame things on them.
• Being responsible doesn’t mean being perfect. It means working to prevent mistakes, and then working to fix them when things go wrong.
• Be willing to change, but be cautious at the same time.
• Know how good your software has to be. Define what is good enough?

Tip

• Offer options, not excuses.
  • “Rubber Duck” it. If what you have to say sounds lame, then you should probably save your breath and find some possible solutions.
  • Admit when you need help or more resources.

Software Entropy

• Entropy refers to the amount of “disorder” in a system.
• Also known as “software rot” .
  • Despite best plans and best people working on a project, it can still suffer from this.

Tip

• Don’t live with broken windows.
  • Don’t leave poor decisions or bad code in your code.
  • If you don’t have time to fully fix it, patch it somehow.
  • Neglect accelerates rot, rot begets rot.
  • Don’t let the “the rest of the code sucks” mentality sink in, otherwise it will decline faster than you could imagine.
  • Keeping the codebase clean effectively makes others not want to mess it up.
  • If you don’t have time to do things properly, maybe consider “boarding it up”, i.e. comment the code out or display a warning.

Stone Soup and Boiled Frogs

Tip

• Be a catalyst for change

  • Talking about change often goes nowhere.
  • People want to plan meetings.
  • Then management approvals.
  • Barriers to entry pile up.
  • This is known as “start-up fatigue”.
  • Start making strides in the direction you see the change needs to happen, show people, and they’ll begin to rally around you.
  • People find it easier to join an ongoing success.

Tip

• Remember the big picture, don’t be the frog in boiling water.
  • Constantly review what’s happening around you otherwise you’ll lose sight of what’s happening and things can start to deteriorate without your noticing.

Good-Enough Software

• Users should be able to participate in determining if something is good enough.
• The scope and quality of the system you create should be part of the project specifications.
• Knowing when to stop iterating over the same code is important.
  • Code can never be perfect so leave well enough alone.
  • Don’t over-embellish or over-refine an otherwise perfectly good program.

Tip

• Make quality a requirements issue.
  • Letting your users experience the software now may lead to better overall software in the future, even better than the path of perfecting what is there now.
  • Great software today is better than perfect software tomorrow.
  • How can we set standards around quality? Test coverage, code reviews, static code analysis, etc. maybe?

Your Knowledge Portfolio

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

• Your knowledge portfolio is all the knowledge you’ve gained programming both in the technical as well as domain specific bits you’ve picked up over time.
• Your knowledge and experience are your most important professional assets … but are expiring assets.
• Consider investing in your knowledge portfolio like you would make financial investments:
  • Invest regularly, as a habit.
  • Diversify.
  • Manage risk.
  • Buy low, sell high.
  • Review and Rebalance.

Tip

• Invest regularly in your knowledge portfolio
  • Learn at least one new language a year.
  • Read a technical book each quarter.
  • Read nontechnical books, too.
  • Take classes.
  • Participate in user groups.
  • Experiment with different environments.
  • Stay current by subscribing to trade magazines, journals, newsletters, or similar.
  • Join and participate in online communities and read white papers for technologies of interest.
  • Be on the lookout for opportunities. If you can’t answer a question … don’t let it go!

Tip

• Critically analyze what you read and hear.
  • Try to think critically about what you read and hear, don’t take it for truth.
  • Beware of zealots, or any time somebody can confidently tell you “the way”.

Communicate!

• Ideas are worthless unless you can communicate it
• Meetings, tickets, wikis, and code are all forms of communication.
• Understand what you want to say.
  • Jot down your high level goals.
  • Have a plan for getting it across.
• Know your audience.
  • The WISDOM acrostic:
  • W hat do you want them to learn?
  • What is their I nterest?
  • How S ophisticated are they?
  • How much D etail do they want?
  • Whom do you want to O wn the info?
  • How can you M otivate them to listen to you?
• Choose your moment wisely and make what you’re saying relevant in time.
• Communicate with your audience the way they want to be communicated with.
• Make your message look good.
  • Presentation is as important as the content itself.
  • Which is easier to read? One full page of text? Or two pages of text broken apart into sections with section headers?
• Get people involved in your documents early and often.
  • Involving your audience builds relationships and creates better documents.
• Be a listener. If you don’t listen to others, they won’t listen to you.
• Get back to people. People hate when you don’t reply, even if it’s just an “I’ll get back to you later.”

Tip

• It’s Both What You Say and the Way You Say It.

Resources We Like

• The Pragmatic Programmer by Andrew Hunt, David Thomas (Amazon)
• The Pragmatic Bookshelf (pragprog.com)
• Programmers’ Build Errors: A Case Study (at Google) (static.googleuserconent.com)
• Broken windows theory (Wikipedia)
• How ‘Broken Windows’ Helped Shape Tensions Between Police And Communities (www.wnyc.org)

Tip of the Week

• Git the source code for your favorite old games. (GitHub)
• Learn about all of your favorite design patterns using The Catalog of Design Patterns. (refactoring.guru)
• Learn VS Code tricks you didn’t even know about. VS Code can do that?! (vscodecandothat.com)
• Sharpen your Azure skills with these self paced labs provided by Microsoft:
  • Acquire the cloud skills you need, at your own pace (handsonlabs.microsoft.com)
  • Welcome to Self-paced Labs (www.microsoft.com)