The Pragmatic Programmer (Sept/Oct 2021)

[kldickenson]

Schedule:

• Sept 1-6 — Chapter 1 - Topics 1-7 (26 pgs)
• Sept 7-12 — Chapter 2 - Topics 8-11 (23 pgs)
• Sept 13-19 — Chapter 2 - Topics 12-15 (23 pgs)
• Sept 20-26 — Chapter 3 - Topics 16-22 (30 pgs)
• Sept 27-Oct 3 — Chapter 4 - Topics 23-27 (26 pgs)
• Oct 4-10 — Chapter 5 - Topics 28 & 29 (18 pgs)
• Oct 11-17 — Chapter 5 - Topics 32-32 (22 pgs)
• Oct 18-24 — Chapter 6 - Topics 33-36 (22 pgs)
• Oct 25-31 — Chapter 7 - Topics 37-40 (23 pgs)
• Nov 1-7 — Chapter 7 - Topics 41-44 (29 pgs)
• Nov 8-14 — Chapter 8 - Topics 45-48 (20 pgs)
• Nov 15-21 — Chapter 9 - Topics 49-53 (22 pgs)

[kldickenson]

Chapter 1

Respond in this comment thread (if we can) and lead your answers with T1, T2, etc.

Topic 1 (T1) It's Your Life

How do you keep yourself open to change and growth within our industry?

Topic 2 (T2) The Cate Ate My Source Code

When you take responsibility for an error, how many corrective options do you like to provide?

Topic 3 (T3) Software Entropy

"Software Rot" or "Technical Debt", which term do you like better and why?

Topic 4 (T4) Stone Soup and Boiled Frogs

How can you stay motivated (and motivate others) to make small changes that can help keep code "viable"?

Topic 5 (T5) Good-Enough Software

What does good-enough software mean to you? How can your users keep you in check?

Topic 6 (T6) Your Knowledge Portfolio

What new coding skills are you learning now? Are you learning something relevant to your day-to-day work or expanding to different horizons?

Topic 7 (T7) Communicate!

Are you more proficient at verbal or written communications? How could you improve your weaker skill?

[kldickenson]

Chapter 2 - A Pragmatic Approach

Ch 2 T8 - The Essence of Good Design - Is your code easy to change (ETC) or are there side effects to your code fixes? The key is to modularize your code so that a change remains scoped to that one module.

Ch 2 T9 - DRY (Don't Repeat Yourself), the Evils of Duplication - Have you run into duplication in your code, APIs, or data sources? Would regular and open communication within your development team help to avoid some of the duplications?

Ch 2 T10 - Orthogonality (modularization) - The independence or decoupling of code (UI does not rely on Database and vice-versa the Database does not rely on the UI). What are some of the benefits of modularization?

Ch 2 T11 - Reversibility - How can relying on third-party products or a specific type of database schema can make your code too rigid to change? What other "roadblocks" might cause this issue? How can you use modularized code to prevent this issue?

Ch 2 T12 - Tracer Bullets - How can tracer code provide you immediate feedback during development?

This one stumped me. (Is tracer code ?= minimum viable product.) Here are some links that might give a clearer view:

• https://blog.themainingredient.co/are-companies-agile-enough-the-tracer-bullet-approach-441e90e491b4
• https://concisecoder.io/2018/11/11/tracer-bullet-programming/
• https://growsmethod.com/practices/TracerBullets.html
• https://builtin.com/software-engineering-perspectives/what-are-tracer-bullets
• https://antjanus.com/blog/thoughts-and-opinions/prototypes-dont-get-thrown-out-write-tracer-bullet-code-instead/

Ch 2 T13 - Prototypes and Post-It Notes - What is the main benefit of prototyping? What can you learn by prototyping one small piece/functionality/UI at a time?

Ch 2 T14 - Domain Languages - Would you prefer to work on an internal coding language or use an external language to compile to your codebase's language?

Ch 2 T15 - Estimating- Do you keep a formal log of your project estimates? Do you keep estimates vague or do you outline parameters that would change your estimate?

[kldickenson]

Chapter 3 - The Basic Tools

Ch3 T16 - The Power of Plain Text- How do you like to store/write your knowledge?

Ch3 T17 - Shell Games - Do you feel more comfortable in a GUI or the shell? Are there times when you turn to the shell over a GUI? Are there times you prefer the focus of the GUI over the expanded functionality of the shell?

Ch3 T18 - Power Editing - Have you learned any new quick-keys in your IDE of choice lately? Is there a functionality that you need on a regular basis that has no quick-key or do you have a hard time recalling it?

Ch3 T19 - Version Control - Besides code, is there anything else you use version control for? Of GitHub's services (issues, pull requests, projects, discussions, actions, wikis, insights, gists, books...) which do you use currently, and which would you like to add to your development process? If you use a different version control system, what services do they offer beyond just a code repository?

Ch3 T20 - Debugging - Process: reproduce the bug, use binary chop to pin-point the "culprit", review logs, rubber duck, testing code and expand boundary conditions. Which of these steps do you consider yourself strong at and which of these would you like to strengthen?

Ch3 T21- Text Manipulation - Have you had a chance to use a text manipulation language? Which language did you use and what did you have it do?

Ch3 T22 - Engineering Daybooks -Do you currently use an engineering daybook or something similar? What have you found it most useful for? If not already doing so, would you accept a challenge to keep a daybook starting today till we finish reading this book?

[kldickenson]

Chapter 4 - Pragmatic Paranoia

Ch4 T23 - Design By Contract (DBC) - How can you document and verify your code to make sure it does no more or no less than it claims?

Ch4 T24 - Dead Programs Tell No Lies - What methods do you use to make sure your bug fixes do no damage?

Ch4 T25 - Assertive Programming - How can you verify your assumptions as you are coding? How can your assertions test for those "should never happen" cases? Make sure your inputs are what is expected.

Ch4 T26 - How to Balance Resources - What can you do to make sure that you open and close resources? Can you compartmentalize your code by isolating the opening and closing of resources in its own module l, calling additional functionality from other modules (separation of powers)?

Ch4 T27 - Don't Outrun Your Headlights - How far ahead are you willing to "look", one sprint (two weeks) or farther? How often does your development cycle get "interrupted" with changes or with unexpected changes to the project scope?