Elisabeth Hendrickson’s book “There’s Always A Duck” has been around for a number of years but I have only been able to read it recently. Now I know what she meant about ducks. They’re literally about ducks, but also about people too. People are different, and yet we share similarities. We experience things, we communicate with each other, and we learn and get better because of those experiences. Her book tells us stories of her adventures and the lessons she’s discovered along the way, and it was nice to have had a glimpse of what she saw and felt with her encounters with software project teams and everyone involved.
- The vast majority of programmers I have met are diligent, capable folk. They truly care about the quality of their work and want the software they produce to be useful. They work hard to make sure they are implementing the right features and writing solid code.
- The next time you’re tempted to think of your programmers as idiots, incompetents, or quality hostile, remember that no matter what else they may be, they’re people first. Even if it seems like they’re hostile or incapable, it is far more likely that they are having a very human reaction to a particularly bad situation.
- And before you blame someone else for a mistake, remember the last time you made one. I’ve made some real whopper mistakes in my time. We all have, whether or not we choose to admit them or even remember them. It may be that some programmers don’t care about users, but it’s more likely that bugs are honest mistakes made under difficult circumstances.
- Even when we are speaking the same language and about the same thing, it’s hard enough to communicate.
- The point wasn’t to catch every possible error. What seems to go wrong most often? What errors are difficult to see at first glance, and thus require concentration to prevent? What causes the most damage when it happens?
- Janet doesn’t know anything about the ins and outs of creating software. She probably doesn’t want to know. She just wants to serve her customers well. And this software is not helping. Back at corporate, the Steering Committee, Requirements Analysts, Designers, Programmers and Testers are congratulating themselves on a solid release. What they don’t see is Janet’s pain. The feedback loop is broken. The team back at corporate has no mechanism to find out whether the software is any good. Oh, sure, they’ll detect catastrophic problems that cause servers to go down. But they won’t see the little things that cause long queues at the front desk of the hotel.
- Testers naturally notice details. Not only do we notice, but we think about what we noticed, we attempt to interpret our observations to explain why things might be that way, we ask others if they noticed, we question our assumptions, and we poke and prod at things to see if our understanding is correct. We use our observations to inform us, and in doing so discover underlying causes and effects we otherwise might miss.
- I sometimes fall into the trap of thinking that the first problem I see must be THE problem that needs to be solved. Perhaps the problem I spotted is indeed worth correcting, but I almost never manage to spot the true critical issue at first glance.
- Both fear and excitement stem not from observable reality but rather from speculation. We are speculating that the bugs that we know about and have chosen not to fix are actually as unimportant to our users as they are to us. We are speculating that the fact we have not found any serious defects is because they don’t exist and not because we simply stopped looking. We are speculating that we knew what the users actually wanted in the first place. We are speculating that the tests we decided not to run wouldn’t have found anything interesting. We are speculating that the tests we did run told us something useful. None of it is real until it is in the hands of actual users. The experience those users report is reality. Everything else is speculation.
- It’s not because Agile is about going faster. It’s because structuring our work so that we can ship a smaller set of capabilities sooner means that we can collapse that probability wave more often. We can avoid living in the land of speculation, fooling ourselves into thinking that the release is alive (or dead) based on belief rather than fact. In short, frequent delivery means we live in reality, not probability.
- Hire the right people. If that means keeping a critical position on the team open longer than anticipated, so be it. It’s better to have an under- staffed team of highly motivated, talented, skilled people than a fully staffed but ineffective team. Remember that hiring mistakes often take only a few minutes to make, and months of wasted time to undo.
- Listen. There are always signs when a project is in trouble: missed milestones, recurrent attitude problems, general confusion about the project. Sometimes these signs indicate a dysfunctional team, sometimes they’re just normal bumps along the road, and sometimes they are early warning signs of major problems. The only way to tell the difference is to listen carefully to what the team members have to say.
- The best way to get people to accept change is to make it more fun, and more rewarding, to do things the new way.
- Choose a path that takes you in the direction you want to go. Don’t choose a path simply because it takes you away from the swamp you want to avoid.
To find out that the programmers in the team are seeking out product owners, stakeholders, and teammates on their own to ask clarifications and start meaningful discussions is a positive thing for me, to notice them initiate communication to whomever they need to talk to is always a major confidence booster about their ability to work on problems on their own. They never need my authority or permission to do what they think is best, they manage their own tasks, they own the responsibility to do the right thing as they see fit. I’m just there to help them perform the best work they can, in the form of suggestions and testing.
That’s why it’s bewildering to see someone get disappointed over a behavior that I deem to be on the plus side. Why would letting developers talk directly to stakeholders make you feel overstepped, if they think it supports better work? It seems to be, at least for me, a shallow use of a leadership position, a certain level of being clingy to power that’s not serving the team mission. It’s an upsetting, controlling reaction that I feel does not do any good.
Focus on empowering the team.
What does our team actually want to accomplish this particular sprint?
Do I know my teammates well enough?
Does everyone in the team feel safe working together with each other?
Can I rely on everybody in the team?
What does a user story mean to us?
Do we even need tickets in order to perform our best work?
Do we truly need this specific document to move forward?
How can I help a teammate feel good with the work he/she is doing?
What’s the minimum amount of input do we need in order to start?
What’s the 20% of activities that contribute to 80% of outputs we desire?
Do we believe in what we are building?
Which rules, in reality, help us become the best versions of ourselves? Which don’t?
“Tools of Titans” is Timothy Ferriss‘ latest book, compiling lessons he has learned from interviewing over 200 world-class performers in his ‘The Tim Ferriss Show’ podcast. It is massive, and the number of takeaways he’s given away in the book is as plenty as it’s size. Like his “The 4-Hour Workweek” title, several of the ideas in it got me thinking deeper into how I’m living my own life, asking myself which projects and goals actually matter. Plus there’s bonus notes on other interesting things, like physical exercises that provide bang for the buck and the profound effects of using psychedelics in healthy doses.
Some favorite lessons:
- The quality of your questions determines the quality of your life.
- Do your kids remember you for being the best dad? Not the dad who gave them everything, but will they be able to tell you anything one day? Will they able to call you out of the blue, any day, no matter what? Are you the first person they want to ask for advice?
- If you don’t do something well, don’t do it unless you want to spend the time to improve it.
- Accept that quality long-term results require quality long-term focus. No emotion. No drama. No beating yourself up over small bumps in the road. Learn to enjoy and appreciate the process. This is especially important because you are going to spend far more time on the actual journey than with those all too brief moments of triumph at the end.
- It’s not what you know, it’s what you do consistently.
- When you’re thinking of how to make your business bigger, it’s tempting to try to think all the big thoughts, the world-changing, massive-action plans. But please know that it’s often the tiny details that really thrill someone enough to make them tell all their friends about you.
- If this were the only thing I accomplished today, would I be satisfied with my day? Will moving this forward make all the other to-dos unimportant or easier to knock off later?
- You can sacrifice quality for a great story.
- People who have plenty of good ideas, if they’re telling you the truth, will say they have even more bad ideas. So the goal isn’t to get good ideas; the goal is to get bad ideas. Because once you get enough bad ideas, then some good ones have to show up.
- The way you teach your kids to solve interesting problems is to give them interesting problems to solve. And then, don’t criticize them when they fail. Because kids aren’t stupid. If they get in trouble every time they try to solve an interesting problem, they’ll just go back to getting an A by memorizing what’s in the textbook.
- Commit, within financial reason, to action instead of theory. Learn to confront the challenges of the real world, rather than resort to the protective womb of academia. You can control most of the risks, and you can’t imagine the rewards.
- Choose projects and habits that, even if they result in “failures” in the eyes of the outside world, give you transferable skills or relationships.
- For anything important, you don’t find time. It’s only real if it’s on the calendar.
- When deciding whether to commit to something, if I feel anything less than “Wow! That would be amazing! Absolutely! Hell yeah!”—then my answer is no. When you say no to most things, you leave room in your life to really throw yourself completely into that rare thing that makes you say, “HELL YEAH!”
- Great creative work isn’t possible if you’re trying to piece together 30 minutes here and 45 minutes there. Large, uninterrupted blocks of time—3 to 5 hours minimum—create the space needed to find and connect the dots. And one block per week isn’t enough. There has to be enough slack in the system for multi-day, CPU-intensive synthesis. For me, this means at least 3 to 4 mornings per week where I am in “maker” mode until at least 1 p.m.
- Don’t try to please anyone but yourself. The second you start doing it for an audience, you’ve lost the long game because creating something that is rewarding and sustainable over the long run requires, most of all, keeping yourself excited about it. Trying to predict what an audience will] be interested in and kind of pretzeling yourself to fit those expectations, you soon begin to begrudge it and become embittered—and it begins to show in the work. It always, always shows in the work when you resent it.
- You can’t blame your boss for not giving you the support you need. Plenty of people will say, ‘It’s my boss’s fault.’ No, it’s actually your fault because you haven’t educated him, you haven’t influenced him, you haven’t explained to him in a manner he understands why you need this support that you need. That’s extreme ownership. Own it all.
- The world is this continually unfolding set of possibilities and opportunities, and the tricky thing about life is, on the one hand having the courage to enter into things that are unfamiliar, but also having the wisdom to stop exploring when you’ve found something worth sticking around for. That is true of a place, of a person, of a vocation. Balancing those two things—the courage of exploring and the commitment to staying—and getting the ratio right is very hard.
- Any great idea that’s significant, that’s worth doing, for him, will last about 5 years, from the time he thinks of it, to the time he stops thinking about it. And if you think of it in terms of 5-year projects, you can count those off on a couple hands, even if you’re young.
- The way you do anything is the way you do everything.
- To blame someone for not understanding you fully is deeply unfair because, first of all, we don’t understand ourselves, and even if we do understand ourselves, we have such a hard time communicating ourselves to other people. Therefore, to be furious and enraged and bitter that people don’t get all of who we are is a really a cruel piece of immaturity.
- It’s better to be in an expanding world and not quite in exactly the right field, than to be in a contracting world where peoples’ worst behavior comes out.
- In any situation in life, you only have three options. You always have three options. You can change it, you can accept it, or you can leave it. What is not a good option is to sit around wishing you would change it but not changing it, wishing you would leave it but not leaving it, and not accepting it. It’s that struggle, that aversion, that is responsible for most of our misery.
- Perhaps I didn’t need to keep grinding and building? Perhaps I needed more time and mobility, not more income? This made me think that maybe, just maybe, I could afford to be happy and not just “successful.”
Timothy Ferriss‘ “The 4-Hour Workweek” might be my favorite book this year. Tons of lessons about how to be productive, as well as how to enjoy life to the fullest, and reading the book has left me excited about the future while reconsidering many of my other choices.
Some favorite takeaways:
- The perfect job is the one that takes the least time. The goal is to free time and automate income.
- ‘If only I had more money’ is the easiest way to postpone the intense self-examination and decision-making necessary to create a life of enjoyment – now and not later. Busy yourself with the routine of the money wheel, pretend it’s the fix-all, and you artfully create a constant distraction that prevents you from seeing just how pointless it is. Deep down, you know it’s all an illusion, but with everyone participating in the same game of make-believe, it’s easy to forget.
- What are you waiting for? If you cannot answer this without resorting to the previously rejected concept of good timing, the answer is simple: You’re afraid, just like the rest of the world. Measure the cost of inaction, realize the unlikelihood and repairability of most missteps, and develop the most important habit of those who excel, and enjoy doing so: action.
- Retirement as a goal or final redemption is flawed for at least three solid reasons:
- It is predicated on the assumption that you dislike what you are doing during the most physically capable years of your life.
- Most people will never be able to retire and maintain even a hotdogs-for-dinner standard of living. Even one million is chump change in a world where traditional retirement could span 30 years and inflation lowers your purchasing power 2-4% per year. The math doesn’t work.
- If the math doesn’t work, it means that you are one ambitious hardworking machine. If that’s the case, guess what? One week into retirement, you’ll be so damn bored that you’ll want to stick bicycle spokes in your eyes.
- If it isn’t going to devastate those around you, try it and then justify it. Get good at being a troublemaker and saying sorry when you really screw up. Ask for forgiveness, not permission.
- Ninety-nine percent of people in the world are convinced they are incapable of achieving great things, so they aim for the mediocre. The level of competition is thus fiercest for ‘realistic’ goals, paradoxically making them the most time- and energy-consuming. So do not overestimate the competition and underestimate yourself. You are better than you think.
- Doing something unimportant well does not make it important. Requiring a lot of time does not make a task important. What you do is infinitely more important than how you do it. Efficiency is still important, but is useless unless applied to the right things.
- Remember that most things make no difference. Being busy is a form of laziness – lazy thinking and indiscriminate action. Being overwhelmed is often as unproductive as doing nothing and is far more unpleasant. Being selective – doing less – is the path of the productive. Focus on the important few and ignore the rest.
- If you haven’t identified the mission-critical tasks and set aggressive start and end times for their completion, the unimportant becomes the important. Even if you know what’s critical, without deadlines that create focus, the minor tasks forced upon you (or invented) will swell to consume time until another bit of minutiae jumps in to replace it, leaving you at the end of the day with nothing accomplished.
- The key to having more time is doing less, and there are two paths to getting there, both of which should be used together:
- Define a short to-do list
- Define a not-to-do list
- Don’t ever arrive at the office or in front of your computer without a clear list of priorities. There should be no more than 2 mission-critical items to complete each day. Never. It just isn’t necessary if they’re actually high-impact.
What: Create executable specifications for an ongoing project sprint. Executable specifications are written examples of a business need that can be run anytime and acts as a source of truth for how applications behave. It is a living documentation of what our software does, and it helps us focus more on solving the unusual and noteworthy problems instead of wasting time with the ones that we know we shouldn’t have been worrying about.
- Join a software development team for one sprint duration.
- Discuss project tasks for that sprint with everyone.
- Ask about requirements examples and create executable specifications for those tasks as the application is being written.
- Refine the specifications when necessary.
- Continuously update the specifications until they pass.
- Keep the specifications running on a preferred schedule.
Why: To see if writing executable specifications alongside development is feasible during the duration of a sprint.
Limitations: Tester writes the executable specifications, programmers work as is.
- Writing executable specifications can be done during actual app development, provided that tester is experienced with the tools for implementing it and understands well why the need for such specifications.
- It is of course more beneficial if everyone in the team learn how executable specifications work and write/run the specifications, and why the need to implement it.
- It will take quite a long while before executable specifications becomes a norm in the existing software development process, if ever. This is a function of whether everyone believes that such specifications are actually useful in practice, and then building the skills and habit of including these specifications in the team’s definition of done.
Here’s one thing about software testing: it is a specialization that’s tough to pursue as a long-term career. It is difficult to know if you’ve become someone that’s remarkable at it. There are no degrees about software testing in school, people seldom discuss what it means (even among software development teams), and it’s hard to find mentors. It is common for software testers to start their profession in testing only by chance, like how I stumbled with the work myself, taking my first job because I wanted to work with computers (but having no experience in both programming and building computer networks) and because I needed some way of earning money. It was fairly easy to get into, but after being in the industry for quite some time I know how perplexing it is to build from the basics, how hard it is to find out where to go next.
Fortunately there are people like Rob Lambert, previously known as the Social Tester, who are concerned about helping other software testers in the industry. He wrote the Remaining Relevant and Employable in a Changing World ebook for software testers who really enjoy what they do and wants to stand out from their peers. It’s a great read, and reading and deeply thinking about other people’s ideas always play a huge role in learning many things connected to software testing as it does too in other fields of work, including how to get better at what what we do.
Some lessons from the book:
- Ensure that each and every day you are shipping something that pushes you towards the end goal.
- Learning and building your skills should be a core fundamental aspect to your life as a software tester. Learn about technology, industries, people, the product under test, yourself or your co-workers.
- Testing isn’t about conforming to standards. It’s about helping to deliver great software. It’s about more than test techniques and approaches. It’s about working with people, communicating clearly, understanding market conditions, embracing technology, understanding end user needs, influencing design, and a whole lot more besides.
- As a minimum, do no less than one hour of learning per day, ideally two.
- It isn’t the company you work for who are in charge of your career. It’s you.