Chapter 1: A Pragmatic Philosophy

Originally Due November 19, 2019

The book stresses that this book is about you. It’s your life so own it.

1: It’s Your Life

:grey_exclamation: Tip 3: You Have Agency

You can be the agent of change in your own life. If you don’t like something, then change it.

you can change your organization or change your organization

If you’re falling behind tech, catch up. If you don’t like your job, quit. You can make the changes you want to see.

2: The Cat Ate My Source Code

You are accountable and your team needs to be able to trust you above all else. If you aren’t reliable and don’t claim responsibility, it will cause friction on the team.

:grey_exclamation: Tip 4: Provide Options, Don’t Make Lame Excuses

Use the rubber duck technique to make sure whatever excuse you’re about to give isn’t a bad one. If you know the person is going to ask questions be prepared to answer them. Provide options and solutions to the problem.

3. Software Entropy

The book disregards the term “technical debt” since it implies that it will eventually be paid off; it’s not going to be paid off. Instead they prefer the term “software rot”.

:grey_exclamation: Tip 5: Don’t Live with Broken Windows

If a building has a broken window for a long period of time, it will lead to more vandalism and neglect until the building becomes derelict. A “broken window” can lead to faster decay. If you let one thing fall apart, the rest of the building (or application) will follow quickly.

Don’t rush to solve a problem and leave more problems. There’s always time to do things right; better to fix the issue slowly and properly than rush to get a messy solution out. This fix will snowball like the broken window and eventually lead to more software rot.

4. Stone Soup and Boiled Frogs

:grey_exclamation: Tip 6: Be a Catalyst for Change

Don’t ask for the farm all at once; work your way up progressively. Get a result with the minimum, then you can always ask for more once others are able to see the benefits.

of course, it would be better if we added…

:grey_exclamation: Tip 7: Remember the Big Picture

Always think about what is going on around you. You aren’t working in a vacuum so remember to review what is going on around you , not just what you are doing.

5. Good-Enough Software

Make software that meets all the specifications and nothing more. Don’t overly polish a product before you have consumer feedback. Be sure to discuss time frames realistically; it’s OK to set later deadlines and deliver a better product.

:grey_exclamation: Tip 8: Make Quality a Requirements Issue

Discuss the scope and quality of a system before you start working on it.

If you give your users something to work with early, they can guide later development better. Don’t over engineer before you know what the consumer actually wants. Don’t spoil a program by adding too much or fixing things that don’t need fixing.

6. Your Knowledge Portfolio

:grey_exclamation: Tip 9: Invest Regularly in Your Knowledge Portfolio

Your knowledge in this field slowly expires; new technology is released and your current knowledge becomes outdated. It’s important to keep up with the latest and greatest, but to not invest too heavily on fads.

When you find a problem that you don’t know the answer to, dig into it. Look up the answer. If you can’t find it yourself seek help from someone who can.

:grey_exclamation: Tip 10: Critically Analyze What You Read and Hear

Be aware of bias in articles and sources. Someone most likely paid to get that information to you. Think about the motivations behind it before blindly following what it says.

7. Communicate

:grey_exclamation: Tip 11: English is Just Another Programming Language

You should strive to be an effective communicator. Honor the same principles you would follow in OOP (DRY, automation, etc.).

Know your audience and what kind of knowledge they have. Don’t over explain; don’t under explain. Tailor your message to your recipient, especially when pitching new ideas.

Know what you want to say ahead of time. Write an outline, and even potentially involve your audience in the draft.

Be aware of the environment when pitching an idea. Take notice of your boss’s mood and circumstances; what time of day is it, were they just in a meeting? Are they on their way home? Think about the best time to ask something before you ask it.

Take time to format your ideas in an appealing way. Use templates and graphics to make things more enjoyable to read. Don’t do the bare-bones reports.

Involve your audience in the draft process and in the pitch; listen to their concerns and respond.

:grey_exclamation: Tip 12: It’s Both What You Say and the Way You Say It

If you are going to be late getting back to someone, tell them.

I’ll get back to you later

Keeping people informed makes them more forgiving of the occasional slip.

:grey_exclamation: Tip 13: Build Documentation In, Don’t Bolt It On

Documentation should be a part of your code. Your code should be well commented and descriptive. However, use comments within reason; not everything needs a comment. Non-API commenting should discuss why something is done, its purpose, and its goal. Not how something is done; the code already does that.

Additional Reading