Chapter 1. A Pragmatic Philosophy
1. It’s Your Life
Tip 3: You have agency
Invest in your learning outside of work
2. The Cat Ate My Source Code
Effective teams require trust
Take responsibility and be accountable
Tip 4: Provide options, don’t make [bad] excuses
If you need to share bad news, provide options for going forward
Run through the conversation in your mind. What is the other person likely to say? Will they ask, “Have you tried this…” or “Didn’t you consider that?”
- See also: This column will change your life: Are you an Asker or a Guesser?
- What else can be done?
- Be honest if you don’t know
When you find yourself saying, “I don’t know,” be sure to follow it up with “—but I’ll find out.” It’s a great way to admit what you don’t know, but then take responsibility like a pro.
3. Software Entropy
“Tech debt” is a euphemism for “software rot.” It doesn’t get fixed.
Tip 5: Don’t live with broken windows
- Important follow up: “If there is insufficient time to fix it properly, then board it up.”
- Communicate to future readers that you’re on top of the situation
- Even just a FIXME comment linking to a Jira ticket
- Neglect accelerates rot
Don’t break windows even during an emergency.
4. Stone Soup and Boiled Frogs
“People find it easier to join an ongoing success.” Get the ball rolling for other people to join in.
Tip 6: Be a catalyst for change
Conversely, complex systems drift into failure without devs noticing.
It’s often the accumulation of small things that breaks morale and teams.
Tip 7: Remember the big picture
Ways to take stock, get situational awareness:
- test coverage
- hallway usability tests
- user surveys
Can you determine whether you’re making stone soup or frog soup when you try to catalyze change?
both, depends on who you ask
see also: complex systems theory
important to mitigate harm
5. Good-Enough Software
“Good enough” != sloppy or poorly produced code Understand user needs first, then decide where to spend effort
Tip 8: Make quality a requirements issue
Great software today is often preferable to the fantasy of perfect software tomorrow.
note: “Great software” not “shitty duct-tape that breaks the build”
Know when to stop a.k.a “too much surgery kills the patient”
- let your code rest like when cooking steak
- rest != entropy
- novelists need time away from a manuscript before revision. you probably do too
6. Your Knowledge Portfolio
Your knowledge and experience are your most important day-to-day professional assets. and Your ability to learn new things is your most important strategic asset.
- how to learn
- what to learn
Building a knowledge portfolio
- invest regularly: learn continuously in small amounts
The more technologies you are comfortable with, the better you will be able to adjust to change. manage risk
- buy low, sell high: learn an emerging technology before it becomes popular
- review and rebalance
Tip 9: Invest regularly in your knowledge portfolio
- Learn at least one new language a year
- I’m considering Rust or Elixir
- Read a technical book each month
- Read nontechnical books, too
- I have this part covered lol
- Take classes
- not any time soon
- Participate in local user groups and meetups
- instead of user groups I’ve been getting involved in the learningfromincidents.io community
- Experiment with different environments
- I’d like to do this more but I haven’t been able to get over the short-term hit to my productivity
- I mainly work in rubymine and occasionally use vim
- Stay current
- I’m not great at this, I tend to get overwhelmed quickly
The process of learning will expand your thinking, opening you to new possibilities and new ways of doing things.
If you don’t know the answer to something, take initiative to find out.
Tip 10: Critically analyze what you read and hear
You need to communicate to make your project successful
Tip 11: English is just another programming language
Know your audience
- don’t just geek out at them
- answer their “so what?”
Continuously improve your knowledge of your audience as you communicate.
Know what you want to say
- plan what you’re gonna say
- for both writing and for speaking
Choose your moment
“Is this a good time to talk about…?”
what will work for your audience???
Choose a style (for your audience) Make it look good formatting matters reduce friction for your audience it’s a sign of respect
Involve your audience
the documents we produce end up being less important than the process we go through to produce them
can approach it like pairing or PR review
Be a listener
Get back to people
- or say you’ll get back to them later
Tip 12: It’s both what you say and the way you say it
Keep it with the code, it’s a part of the code
Tip 13: Build documentation in, don’t bolt it on
- generate docs from your code comments
- yard, pydoc, etc.
- restrict your non-API comments to the why, the purpose and goal