Last week I had a lovely time reading “How to Fail at Almost Everything and Still Win Big” by cartoonist Scott Adams. His views on success and happiness, and his formula for increasing the odds of success through failures are intriguing, based on his life experiences. He shares ideas about goals and systems, skills, happiness, priorities, and personal energy, which provides a guide for living well. Some of those ideas are ones I already exercise, while others have provided answers to goals that have failed me in the past as well as reasons to why I’ve acted a certain way before. It’s refreshing to learn something new about existing patterns of behavior.
Here are some favorite quotes from the book:
- A goal is a specific objective that you either achieve or don’t sometime in the future. A system is something you do on a regular basis that increases your odds of happiness in the long run. If you do something every day, it’s a system. If you’re waiting to achieve it someday in the future, it’s a goal. Goal-oriented people exist in a state of continuous pre-success failure at best, and permanent failure at worst if things never work out. Systems people succeed every time they apply their systems, in the sense that they did what they intended to do. The goals people are fighting the feeling of discouragement at each turn. The systems people are feeling good every time they apply their system. That’s a big difference in terms of maintaining your personal energy. Goals only make sense if you also have a system that moves you in the right direction.
- One of the most important tricks for maximizing your productivity involves matching your mental state to the task. For example, when I first wake up, my brain is relaxed and creative. The thought of writing a comic is fun, and it’s relatively easy because my brain is in exactly the right mode for that task. I know from experience that trying to be creative in the mid-afternoon is a waste of time. By 2:00 PM all I can do is regurgitate the ideas I’ve seen elsewhere. At 6:00 AM I’m a creator, and by 2:00 PM I’m a copier.
- The way I approach the problem of multiple priorities is by focusing on just one main metric: my energy. I make choices that maximize my personal energy because that makes it easier to manage all of the other priorities. Maximizing my personal energy means eating right, exercising, avoiding unnecessary stress, getting enough sleep, and all of the obvious steps. But it also means having something in my life that makes me excited to wake up.
- It’s useful to think of your priorities in terms of concentric circles, like an archery target. In the center is your highest priority: you. If you ruin yourself, you won’t be able to work on any other priorities. So taking care of your own health is job one. The next ring – and your second-biggest priority is economics. That includes your job, your investments, and even your house. You might wince at the fact that I put economics ahead of your family, your friends, and the rest of the world, but there’s a reason. If you don’t get your personal financial engine working right, you place a burden on everyone from your family to the country. Once you are both healthy and financially sound, it’s time for the third ring: family, friends, and lovers. Good health and sufficient money are necessary for a base level of happiness, but you need to be right with your family, friends, and romantic partners to truly enjoy life.
- There’s a formula for success. You can manipulate your odds of success by how you choose to fill out the variables in the formula. The formula, roughly speaking, is that every skill you acquire doubles your odds of success. Good + Good > Excellent. If you think extraordinary talent and a maniacal pursuit of excellence are necessary for success, I say that’s just one approach, and probably the hardest. When it comes to skills, quantity often beats quality.
- I find it helpful to see the world as a slot machine that doesn’t ask you to put money in. All it asks is your time, focus, and energy to pull the handle over and over. A normal slot machine that requires money will bankrupt any player in the long run. But the machine that has rare yet certain payoffs, and asks for no money up front, is a guaranteed winner if you have what it takes yo keep yanking until you get lucky. In that environment, you can fail 99% of the time, while knowing success is guaranteed. All you need to do is stay in the game long enough.
- The single biggest trick for manipulating your happiness chemistry is being able to do what you want, when you want. I’m contrasting that with the more common situation, in which you might be able to do all the things you want, but you can’t often do them when you want. The timing of things can be more important than the intrinsic value of the things. It’s hard to become rich enough to buy your own private island, but, relatively speaking, it’s easier to find a job with flexible hours. A person with a flexible schedule and average resources will be happier than a rich person who has everything except a flexible schedule. Step one in your search for happiness is to continually work toward having control of your schedule.
- No one wants to believe that the formula for happiness is as simple as daydreaming, controlling your schedule, napping, eating right, and being active every day. You’d feel like an idiot for suffering so many unhappy days while not knowing the cure was so accessible.
- The happiness formula:
- Eat right
- Get enough sleep
- Imagine an incredible future (even if you don’t believe it)
- Work toward a flexible schedule
- Do things you can steadily improve at
- Help others (if you’ve already helped yourself)
- Reduce daily decisions to routine
- Always remember that failure is your friend. It is the raw material of success. Invite it in. Learn from it. And don’t let it leave until you pick its pocket.
I’ve stumbled over Alister Scott‘s WatirMelon blog some years back, probably looking for an answer to a particular question about automation, and found it to be a site worth following. There he talks about flaky tests, raising bugs you don’t know how to reproduce, junior QA professional development, the craziest bug he’s ever seen, writing code, and the classic minesweeper game. He was part of the Watir project in the past, but is now an excellence wrangler over at Automattic (which takes care of WordPress). He has also written an intriguing book, titled “Pride and Paradev“, which talks about several of the contradictions that we have over in the field of software testing. In a nutshell, it explains why there are no best practices, only practices that work well under a certain context.
Here are a number of takeaways from the book:
- A paradev is anyone on a software team that doesn’t just do programming.
- Agile software development is all about delivering business value sooner. That’s why we work in short iterations, seek regular business feedback, are accountable for our work and change course before it’s too hard.
- Agile software development is all about breaking things down.
- Agile software development is all about communication and flexibility. You must be extremely flexible to work well on an agile team. You can’t be hung up about your role’s title. Constantly delivering business value means doing what is needed, and a team of people with diverse skills thrives as they constantly adapt to get things done. Most importantly flexibility means variety which is fun!
- Delivering software everyday is easy. Delivering working software everyday is hard. The only way an agile team can deliver working software daily is to have a solid suite of automated tests that tells us it’s still working. The only way to have reliable, up-to-date automated tests is to develop them alongside your software application and run them against every build.
- You’re testing software day in and day out, so it makes sense to have an idea about the internals of how that software works. That requires a deep technical understanding of the application. The better your understanding of the application is, the better the bugs you raise will be.
- Hiring testers with technical skills over having a testing mindset is a common mistake. A tester who primarily spends his/her time writing automated tests will spend more time getting his/her own code working instead of testing the functionality that your customers will use.
- What technical skills a tester lacks can be made up for with intelligence and curiosity. Even if a tester has no deep underlying knowledge of a system, they can still be very effective at finding bugs through skilled exploratory and story testing. Often non technical testers have better shoshin: a lack of preconceptions, when testing a system. A technical tester may take technical limitations into consideration but a non technical can be better at questioning why things are they way they are and rejecting technical complacency. Often non-technical testers will have a better understanding of the subject matter and be able to communicate with business representatives more effectively about issues.
- You can be very effective as a non-technical tester, but it’s harder work and you’ll need to develop strong collaboration skills with the development team to provide support and guidance for more technical tasks such as automated testing and test data discovery or creation.
- Whilst you think you may determine the quality of the system, it’s actually the development team as a whole that does that. Programmers are the ones who write the good/poor quality code. Whilst you can provide information and suggestions about problems: the business can and should overrule you: it’s their product for their business that you’re building: you can’t always get what you consider to be important as business decisions often trump technical ones.
- A tester should never be measured on how many bugs they have raised. Doing so encourages testers to game the system by raising insignificant bugs and splitting bugs which is a waste of everyone’s time. And this further widens the tester vs programmer divide. Once a tester realizes their job isn’t to record bugs but instead deliver bug free stories: they will be a lot more comfortable not raising and tracking bugs. The only true measurement of the quality of testing performed is bugs missed, which aren’t recorded anyway.
- Everything in life is contextual. What is okay in one context, makes no sense in another. I can swear to my mates, but never my Mum. Realizing the value of context will get you a long way.
- Probably the best thing I have ever learned in life is that no matter what life throws at you, no matter what people do to you or how they treat you, the only thing you can truly control is your response.
- Problem Solving
There’s so much more to software testing than test cases, bug reporting, and automation tools, and it is sad to see many software testers, even those who have been in the industry for many years, having limited knowledge of their craft. There’s a huge world outside office work, and we can learn about so many things. There are books, podcasts, courses, conferences, blogs. We can talk to people, look for mentors. We have the world wide web. We can be masters, but only if dig deep, only if we care enough.
If I am to be asked to name female software testers who I look up to, I’ll probably say I can only name two so far: Lisa Crispin and Janet Gregory. Why them? Because of the many software testing lessons they’ve shared to the testing community through the books they’ve written, especially ‘More Agile Testing‘, which is a treasure trove. Some favorite excerpts:
About software testing:
- Testing expertise is a lot more valuable at the beginning of any project.
- Testers need T-shaped skills. To be effective on any given team, we need both deep and broad skill sets. Deep knowledge and extensive practice in a single field make sure that we bring something essential to the team. On the other hand, broad knowledge in areas other than our own specialty helps us collaborate with experts in other roles.
- Abilities such as communication, collaboration, facilitation, problem solving, and prioritization can be the most difficult to master, yet they are the most crucial for success in agile testing.
- The most useful thinking skill is to know how to help your team address its problems, rather than going in and fixing the symptoms. And you don’t have to be in a management position to provide leadership for your team and help them improve their problem-solving effectiveness.
- It’s possible to automate lots of tests and still fail to deliver what the customer really wants.
- Testing does not produce quality; it produces information about quality. At a high level, the outcome we want from testing is confidence in our decisions to release software changes. Better testing produces greater confidence in those decisions. Therefore, the valuable product of effective testing is confidence.
- Testing is more than just testing software. It is about testing ideas, helping business experts identify the most valuable features to develop next, finding a common understanding for each feature, preventing defects, and testing for business value.
About being a test manager:
- The role of a test manager extends beyond the scope of the day-to-day work of the agile team. Much of his work involves looking outside of the iteration activities and more at the cultural and strategic needs of the testing operation. A test manager can also be a type of coach for the communities of practice within an organization. The test manager is not there to prescribe but can facilitate learning sessions where interested parties can discuss new ideas. Management and Leadership is the ability to hire and inspire great people, to remove or overcome organizational constraints and impediments that hinder them from doing their best work, to see and exploit the opportunities for people to excel, and to motivate individuals to achieve what is best for the team.
About learning, and agile:
- Our real goal isn’t implementing agile; it’s delivering products our customers want. And when we start asking why the customers want the feature (the problem they are trying to solve), we’re more likely to build the right thing.
- In the software profession (as in many others), people seem to forget that it takes time to learn and practice a new skill.
- Learning is itself an agile process. Learning is not a big bang process: you know nothing, read a book, and two days later you’re an expert. Learning, like features, is something you do in iterations, adding a bit more knowledge at a time, and then building on it the next iteration. It’s not a race to the finish, and there is always something more to learn.
- Empathy is essential for providing good feedback.
- Changing an established culture is difficult.