Topic 5 - 8 - HackMD

# Topic 5 - 8 ###### tags: `The Pragmatic Programmer` ## Topic 5: Good-Enough Software > When good-enough software is best Good enough for: - Your users - Future maintainers - Your own peace of mind Lead to: - Being more productive - Your users are happier - You may find that your programs are "actually better" for their shorter incubation >Advocating: >Users be given an opportunity to participate in the process of deciding when what you’ve produced is good enough for their needs ### Involve Your Users in the Trade-Off :no_entry: ignore these users’ requirements simply to add new features to the program or polish up the code just one more time #### :bulb: Tip 8: Make Quality a Requirements Issue - Users would rather use software with some rough edges today than wait a year for the shiny, bells-and-whistles version - If you give your users something to play with early, their feedback will often lead you to a better eventual solution ### Know When to Stop - Programming is like painting: If you add layer upon layer, detail over detail, the painting becomes lost in the paint. - Don’t spoil a perfectly good program by overembellishment and overrefinement. - It may not be perfect. Don’t worry: **it could never be perfect**. ### Discussion: Challenges :::spoiler Question 1 Look at the software tools and operating systems that you use regularly.Can you find any evidence that these organizations and/or developers are comfortable shipping software they know is not perfect? As a user, would you rather (1) wait for them to get all the bugs out, (2) have complex software and accept some bugs, or (3) opt for simpler software with fewer defects? ::: :::spoiler Question 2 Consider the effect of modularization on the delivery of software. Will it take more or less time to get a tightly coupled monolithic block of software to the required quality compared with a system designed as very loosely coupled modules or microservices? What are the advantages or disadvantages of each approach? ::: :::spoiler Question 3 Can you think of popular software that suffers from feature bloat? That is, software containing far more features than you would ever use, each feature introducing more opportunity for bugs and security vulnerabilities, and making the features you do use harder to find and manage. Are you in danger of falling into this trap yourself? ::: :::spoiler My personal working experience - Preview before GA - P0/P1/P2 ::: --- ## Topic 6: Your Knowledge Portfolio > - Your knowledge and experience are your most important day-to-day professional assets > - Your ability to learn new things is your most important strategic asset :bomb: The **expiring** assets ### Your Knowledge Portfolio & Building Your Portfolio > Managing a knowledge portfolio is very similar to managing a financial portfolio: 1. **Invest regularly**: Serious investors invest regularly—as a habit. 2. **Diversify**: Diversification is the key to long-term success. 3. **Manage risk**: Smart investors balance their portfolios between conservative and highrisk, high-reward investments. 4. **Buy low, sell hig**h: Investors try to buy low and sell high for maximum return. 5. **Review and rebalance**: Portfolios should be reviewed and rebalanced periodically. Form a habit! #### :bulb: Tip 9: Invest Regularly in Your Knowledge Portfolio ### Goals Suggestions: - Learn at least one new language every year - Read a technical book each month - Read nontechnical books, too - Take classes - Participate in local user groups and meetups - Experiment with different environments - Stay current ### Opportunities for Learning Somebody asks you a question. You don’t have the faintest idea what the answer is, and freely admit as much. **Don’t let it stop there**. Take it as a personal challenge to find the answer ### Critical Thinking #### :bulb: Tip 10: Critically Analyze What You Read and Hear - Ask the “Five Whys” - Who does this benefit? - What’s the context? - When or Where would this work? - Why is this a problem? --- ## Topic 7: Communicate! #### :bulb: Tip 11: English (or your native tongue) is Just Another Programming Language > “The meaning of your communication is the response you get.” ### Know What You Want to Say 1. Plan what you want to say. Write an outline 2. Ask yourself: “Does this communicate what I want to express to my audience in a way that works for them?” 3. Loop: Refine it until it does ### Choose Your Moment > Sometimes all it takes is the simple question, “Is this a good tim“Is this a good time to talk about…?’’ ### Choose a Style > Adjust the style of your delivery to suit your audience. ### Make It Look Good > It's a mistake to concentrate solely on content when producing written documents ### Involve Your Audience > Involve your readers with early drafts of your document. ### Be a Listener > Encourage people to talk by asking questions, or ask them to restate the discussion in their own words. ### Get Back to People > Always respond. Keeping people informed > “I’ll get back to you later.’’ #### :bulb: Tip 12: It’s Both What You Say and the Way You Say It ### Documentation > Writing documentation can be made easier by not duplicating effort or wasting time, and by keeping documentation close at hand—in the code itself #### :bulb: Tip 13: Build Documentation In, Don’t Bolt It On --- ## Topic 8: The Essence of Good Design #### :bulb: Tip 14: Good Design Is Easier to Change Than Bad Design - **ETC** principle - **Every design principle out there is a special case of ETC** ### ETC Is a Value, Not a Rule > Values are things that help you make decisions > ETC is a guide, helping you choose between paths *You may need to spend a week or so deliberately asking yourself “did the thing I just did make the overall system easier or harder to change?” Do it when you save a file. Do it when you write a test. Do it when you fix a bug.* When you don't know which of many paths will be easier to change in the future.... 1. Try to make what you write replaceable. Thinking about keeping code decoupled and cohesive. 2. Develop instincts by looking back and giving yourself feedback ### Discussion: Challenges :::spoiler Question 1 Think about a design principle you use regularly. Is it intended to make things easy-to-change? ::: :::spoiler Question 2 Also think about languages and programming paradigms (OO, FP, Reactive, and so on). Do any have either big positives or big negatives when it comes to helping you write ETC code? Do any have both? When coding, what can you do to eliminate the negatives and accentuate the positives? :::