ch 1 - A pragmatic philosophy

Pragmatic

An attitude, a style, a philosophy of approaching problems and solutions

It’s your life

I’m not in this world to live up to your expectations and you’re not in this world to live up to mine. [Bruce Lee]

• You have agency
• If you want remote work, if you think you’re getting underpaid, if you think your team is toxic, remember, you have the capability to b e proactive for yourself

The Cat Ate My Source Code

Take responsibility for yourself and your actions in terms of your career advancement, your learning education, your project, and your day-to-day work

• Take charge of your own career, and don’t be afraid to admit ignorance or error
• Team trust
  • Your team needs to be able to trust and rely on you, and you need to be comfortable relying on each of them as well
  • Trust in a team is essential for creativity and collaboration
  • In a healthy environment, you can safely speak your mind, present ideas, and rely on team members
• Provide options, don’t make lame excuses
  • Don’t just say it can’t be done; Explain what can be done to salvage the situation.
    • Code has to be deleted? Include better testing? Automation?
  • Flush out the lame excuses before actually voicing them
• challenges
  • if someone comes up to u with a lame excuse, what would you think of them and their company as a result?
  • When you say “I don’t know”, be sure to follow up with “-but I’ll find out”.

Software entropy

No broken windows

• Both technical debt and rot can spread like a virus - entropy
• Don’t leave “broken windows” (bad designs, wrong decisions, or poor code) unrepaired
  • Fix each one as soon as it is discovered
• By the same token, if you find yourself with code that is beautiful (clean, well designed, etc) you will likely take extra care to not mess it up
• challenges
  • survey your project and discuss w/ your team that the problems are and what could be done to fix them
  • can you tell when a window first gets broken?

Stone soup and boiled frogs

Be a catalyst for change

• Build the thing you want first, and show people a glimpse of potential, and they will follow along
• Remember the big picture
  • dont be like the frog trapped in the boiling pot, not realizing that it’s in hot water if the water started out cold and ended hot
• get in the habit of really noticing your surroundings

Good-enough software

• Not perfect, but good enough
  • Discipline yourself to write good enough for your users and future maintainers
• the scope & quality should be discussed in the system’s requirements
• Great software today is often preferred than the fantasy perfect software next year
  • if u give users something early, often their feedback will lead to better outcome
• don’t over-polish a program, know when to stop (it might do more harm)