Chapter 1 - The Pragmatic Philosophy

🚀 The chapter 1 in 3 sentences

I love the analogy of the broken window and also the frog in a boiling water. In this industry I am in, i think i need to evolve as a software developer and invest more on my knowledge and skills.

🎨 Impressions

I love it so far. On to chapter 2

Chapter 1: A Pragmatic Philosophy

• It's your life
  you can change your organization or change your organization. - Martin Fowler

  • be proactive, and take them

• Take responsibility - The cat ate my source code

  • In a healthy environment based in trust, you can safely speak your mind, present your ideas, and rely on your team members who can in turn rely on you.

• Provide options, don't make lame excuses

  • Don't say it can't be done; explain what can be done to salvage the situation
    • Prototypes
    • post it notes
    • test to code

• Software Entropy (Technical Debt)

  • Entropy is a term from physics that refers to the amount of “disorder” in a system
    Don't leave “broken windows'' (bad designs, wrong decisions, or poor code) unrepaired. Fix each one as soon as it is discovered.

• Stone Soup and Boiled Frogs

  • Show them a glimpse of the future and you'll get them to rally around.
  • Work out what you can reasonably ask for. Develop it well. Once you've got it, show people, and let them marvel. Then say “of course, it would be better if we added…'' Pretend it's not important. Sit back and wait for them to start asking you to add the functionality you originally wanted. People find it easier to join an ongoing success. Show them a glimpse of the future and you'll get them to rally around.

• Be the catalyst for change

  • Systems drift from their specifications feature by feature, while patch after patch gets added to a piece of code until there's nothing of the original left. It's often the accumulation of small things that breaks morale and teams.

• Remember the big picture

  • the frog and the boiling water
  • Keep an eye on the big picture. Constantly review what's happening around you, not just what you personally are doing.

• Good-Enough Software

  • you can discipline yourself to write software that's good enough—good enough for your users, for future maintainers, for your own peace of mind. You'll find that you are more productive and your users are happier. And you may well find that your programs are actually better for their shorter incubation.

  • Involve your users in the trade off

    • The scope and quality of the system you produce should be discussed as part of that system's requirements.

• Make quality a requirements issue

  • Great software today is often preferable to the fantasy of perfect software tomorrow.
  • Don't spoil a perfectly good program by over embellishment and overrefinement. Move on, and let your code stand in its own right for a while. It may not be perfect.

• Your knowledge Portfolio

  • Ben really hit the nail on the head. Your knowledge and experience are your most important day-to-day professional assets.
  • Your knowledge becomes out of date as new techniques, languages, and environments are developed. Changing market forces may render your experience obsolete or irrelevant. Given the ever-increasing pace of change in our technological society, this can happen pretty quickly

• Your knowledge Portfolio

  1. Invest Regularly - Serious investors invest regularly—as a habit.
  2. Diversify - Diversification is the key to long-term success. (The more technologies you are comfortable with, the better you will be able to adjust to change. And don't forget all the other skills you need, including those in non-technical areas.)
  3. Manage Risk - Smart investors balance their portfolios between conservative and high-risk, high-reward investments. (Don't put all your technical eggs in one basket)
  4. Buy low, sell high - Investors try to buy low and sell high for maximum return. Learn emerging technology before it becomes popular
  5. Review and rebalance - Portfolios or technical knowledge should be reviewed and rebalanced periodically.

GOALS

1. Learn at least one new language every year
   • can help broaden your thinking and avoid getting stuck in a rut
2. Read a technical book each month
3. Read Non-Technical books each month
4. Take classes
5. Participate in local user groups and meetups
6. Experiment with different environment
7. Stay Current

Critically Analyze what you read and hear

• Who does this benefit?
• What's the context?
• When or where would this work?
• Why is this a problem?

Communicate

• Treat English (or whatever your native tongue may be) as just another programming language

• Know your audience

  • The meaning of your communication is the response you get.

• Know what you want to say

  • Write an outline

• Choose Your Moment

• Choose a style

• Make it look good

• Involve your audience

• Be a listener

• Get back to people

• Documentation