The Pragmatic Programmer – Investing in Your Knowledge Portfolio

Podcast: Play in new window | Download

Subscribe: Apple Podcasts | Spotify | TuneIn | RSS

We begin our journey into the wisdom of The Pragmatic Programmer, which as Joe puts it, it’s less about type-y type-y and more about think-y think-y, while Allen is not quite as pessimistic as Joe, and Michael can’t wait to say his smart words.

If you’re reading these show notes via your podcast player, you can find this episode’s full show notes and join in the conversation at https://www.codingblocks.net/episode105.

Sponsors

• Datadog.com/codingblocks – Sign up today for a free 14 day trial and get a free Datadog t-shirt after creating your first dashboard.
• Clubhouse – The first project management platform for software development that brings everyone on every team together to build better products. Sign up for two free months of Clubhouse by visiting clubhouse.io/codingblocks.
• Stellares.ai – The AI-powered talent agent that does all the work and screening for you to find your next great opportunity outside of your network. Find the job that’s just right for you.

Survey Says

News

• We give thanks to everyone that left us a review:
  • iTunes: dziekuje, Angel Filev, dnsbtchr, Galal Hassan, Brains eat zombies, strangulatedhernia
  • Stitcher: Ralzes, GrayMath Technology, VladOS, Sammiches
• Allen found his new favorite escape game experience at Odyssey Escape Game. (odysseyescapegame.com)
• Come kick Allen in the shins June 24th at the Atlanta Intelligent Devices Meetup where he’ll be giving his talk on Kafka. And doughnuts. Or donuts? (Meetup)

A Pragmatic Philosophy

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:
    • What do you want them to learn?
    • What is their Interest?
    • How Sophisticated are they?
    • How much Detail do they want?
    • Whom do you want to Own the info?
    • How can you Motivate 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)