Takeaways from Timothy Ferriss’ “The 4-Hour Workweek”

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:
    1. It is predicated on the assumption that you dislike what you are doing during the most physically capable years of your life.
    2. 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.
    3. 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:
    1. Define a short to-do list
    2. 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.

An Experiment on Executable Specifications

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.


  1. Join a software development team for one sprint duration.
  2. Discuss project tasks for that sprint with everyone.
  3. Ask about requirements examples and create executable specifications for those tasks as the application is being written.
  4. Refine the specifications when necessary.
  5. Continuously update the specifications until they pass.
  6. 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.

Experiment Realizations:

  • 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.

Lessons from Gojko Adzic’s “Specification By Example”

Automated checking is not a new concept. Gojko Adzic, however, provides us a way to make better integration of it in our software development processes. In his book titled “Specification by Example”, he talks about executable specifications that double as a living documentation. These are examples which continuously exercise business rules, they help teams collaborate, and, along with software code, they’re supposed to be the source of truth for understanding how our applications work. He builds a strong case about the benefits of writing specifications by example by presenting case studies and testimonials of teams who have actually used it in their projects, and I think that it is a great way of moving forward, of baking quality in.

Some favorite takeaways from the book:

  • Tests are specifications; specifications are tests.
  • “If I cannot have the documentation in an automated fashion, I don’t trust it. It’s not exercised.” -Tim Andersen
  • Beginners think that there is no documentation in agile, which is not true. It’s about choosing the types of documentation that are useful. There is still documentation in an agile process, and that’s not a two-feet-high pile of paper, but something lighter, bound to the real code. When you ask, “does your system have this feature?” you don’t have a Word document that claims that something is done; you have something executable that proves that the system really does what you want. That’s real documentation.
  • Fred Brooks quote: In The Mythical Man-Month 4 he wrote, “The hardest single part of building a software system is deciding precisely what to build.” Albert Einstein himself said that “the formulation of a problem is often more essential than its solution.”
  • We don’t really want to bother with estimating stories. If you start estimating stories, with Fibonacci numbers for example, you soon realize that anything eight or higher is too big to deliver in an iteration, so we’ll make it one, two, three, and five. Then you go to the next level and say five is really big. Now that everything is one, two, and three, they’re now really the same thing. We can just break that down into stories of that size and forget about that part of estimating, and then just measure the cycle time to when it is actually delivered.
  • Sometimes people still struggle with explaining what the value of a given feature would be (even when asking them for an example). As a further step, I ask them to give an example and say what they would need to do differently (work around) if the system would not provide this feature. Usually this helps them then to express the value of a given feature.
  • QA doesn’t write [acceptance] tests for developers; they work together. The QA person owns the specification, which is expressed through the test plan, and continues to own that until we ship the feature. Developers write the feature files [specifications] with the QA involved to advise what should be covered. QA finds the holes in the feature files, points out things that are not covered, and also produces test scripts for manual testing.
  • If we don’t have enough information to design good test cases, we definitely don’t have enough information to build the system.
  • Postponing automation is just a local optimization. You might get through the stories quicker from the initial development perspective, but they’ll come back for fixing down the road. David Evans often illustrates this with an analogy of a city bus: A bus can go a lot faster if it doesn’t have to stop to pick up passengers, but it isn’t really doing its job then.
  • Workflow and session rules can often be checked only against the user interface layer. But that doesn’t mean that the only option to automate those checks is to launch a browser. Instead of automating the specifications through a browser, several teams developing web applications saved a lot of time and effort going right below the skin of the application—to the HTTP layer.
  • Automating executable specifications forces developers to experience what it’s like to use their own system, because they have to use the interfaces designed for clients. If executable specifications are hard to automate, this means that the client APIs aren’t easy to use, which means it’s time to start simplifying the APIs.
  • Automation itself isn’t a goal. It’s a tool to exercise the business processes.
  • Effective delivery with short iterations or in constant flow requires removing as many expected obstacles as possible so that unexpected issues can be addressed. Adam Geras puts this more eloquently: “Quality is about being prepared for the usual so you have time to tackle the unusual.” Living documentation simply makes common problems go away.
  • Find the most annoying thing and fix it, then something else will pop up, and after that something else will pop up. Eventually, if you keep doing this, you will create a stable system that will be really useful.

Lessons from Bernadette Jiwa’s “Difference”

Bernadette Jiwa does not specifically write about software testing or about software development but her writings always talk about how we should perform our work or how to run our businesses, general concepts that seem applicable to what we do too. Reading “Difference” was a treat, and the lessons she shares about what marketing really is are a bonus.

Some favorite lines from the book:

  • Do you need to have a brand new idea or invent something radically different in order to create difference? No, not necessarily. Starbucks didn’t invent coffee, and Apple didn’t invent the smartphone; these companies simply created new experiences of them, which in turn created a whole new set of meanings that we attached to what were once commodities.
  • Today the shortcut to more is to matter. It isn’t the person with the best idea who wins; it’s the person who has the greatest understanding of what really matters to people.
  • Perhaps it’s time to get comfortable with the fact that if we want to change the world, we need to stop being afraid to tell better true stories. Maybe the time has come to stop trying to convince people and to invest time instead in showing them what we stand for, so that they can choose the stories and brands they want to believe in.
  • The truth is that people don’t fall in love with ideas at all. They fall in love with how those ideas, products, services and places make them feel.
  • When you go the extra mile, people will know, and that knowing changes everything about how they feel about what you do. Emotional points of difference, the things that are less obvious and sometimes not even articulated, matter.
  • When return on investment is measured by delight instead of sales or conversions, there’s a lot more freedom to be creative, to be bold, or maybe even to be creative and bold.
  • You might not be able to change how the world values your profession, but you can change how you are valued by doing work that matters. Work that changes how people feel, not just what they think. We have two choices. We can stand around looking at the train wreck of what was, or we can design our own futures.
  • Love. It turns out that what applies to creating great drama, good storytelling, and life also applies to business. We sometimes forget that.
  • We are living in a unique moment in time. An age where we can bring things to the world without having to own a factory or an office building. A digital age that gives us more opportunities to really listen and to learn how to see what people are longing for.
  • If you want to make something new, start with understanding. Understanding what’s already present, and understanding the opportunities in what’s not. Most of all, understanding how it all fits together.
  • The truth is that what really moves us is feelings, not facts. There are a thousand ways for you to get noticed, but there’s only one way to really touch someone. And that’s to give them a reason to care, a story they can believe in. Great stories are woven, not told. They come to us in whispers, as goosebumps. A wry smile playing on our lips, a vigorous nod, a feeling we can’t explain. Or as a number scribbled on the back of a napkin, a shared link accompanied by a message that says, ‘you gotta see this’, which really means ‘I want you to experience this with me’.

Practicing Awareness

It’s easy to learn something when you’re genuinely curious about it, no need to look for any other external motivation. On the other hand, it’s terribly difficult (often a waste of time) to teach something to someone who is not interested in the subject at that given point in time.

Software tester and programmer pairing in bug fixing or feature-writing situations is supposed to be a fun experience for both parties. Either of them getting frustrated at what they’re doing means something is blocking them from being able to perform well as a duo. Maybe they don’t know enough about the needs of the other person or how to fulfill those needs, maybe they don’t understand enough about the thing they’re building or how to build it in the first place.

If the people using the software have qualms regarding a feature update, maybe there happened to be a miscommunication between clients and developers about what feature the customers really want built. Solving that communication problem matters, maybe more than writing feature code quickly, definitely more than pointing fingers and blaming other people after the update’s been released.

Testing with deep understanding of why the application exists the way it is and how features actually work in both user interface and code helps us perform our testing more effectively, especially in situations with time constraints.

Pair testing happens more often than I initially thought it does, only not as explicit as how I imagine it happening.

For whatever you wish to be master of, it pays to have mentors, people you follow and respect and trust and provide feedback. If there aren’t any in your place of work, find them online.

Notes from Jeff Nyman’s “Test Description Language” blog post series

What is a test description language? How do we use that language to effectively write tests? In a series of blog posts, Jeff Nyman talks about what TDL is and how to write better tests with them. The posts are mostly written in the sense of how Cucumber checks are being used for writing tests for automation, but the lessons can also be applied in writing test cases if ever there is a need to write them for clients.

Some notes from the series of posts:

  • It’s very easy to confuse the essence of what you’re doing with the tools that you use.
  • Just because I’m using TestLink, Quality Center, QTP, Cucumber, Selenium, and so forth: that’s not testing. Those are tools that are letting me express, manage, and execute some of my tests. The “testing” part is the thinking I did ahead of time in discerning what tests to think about, what tests to write about, and so forth.
  • Testable means that it specifically calls out what needs to be tested.
  • When examples are the prime drivers, you are using the technique of specification by example and thus example-driven testing. When those examples cover business workflows, you are using the technique of scenario-based testing.
  • Requirements, tests, examples — they all talk about the same thing. They talk about how a system will behave once it’s in the hands of users.
  • The goal of a TDL (test description language) is to put a little structure and a little rigor around effective test writing, wherein “effective test writing” means tests that communicate intent (which correspond to your scenario title) and describe behavior (the steps of your scenario)
  • It is now, and always has been, imperative that we can express what we test in English (or whatever your common language is). This is a key skill of testers and this is a necessity regardless of the test tool solution that you use to manage and/or automate your testing.
  • So many tests, and thus so much development, falters due to a failure to do this simple thing: make sure the intent is clear and expressive for a very defined unit of functionality.
  • Software development teams are not used to the following ideas: The idea of testing as a design activity. The idea of test specifications that are drivers to development. The idea of effective unit tests that catch bugs at one of the most responsible times: when the code is being written.

Thoughts After a Recent Software Feature Release

Having a feature released to the customers does not mean I won’t have to test that feature anymore.

When a feature is released months later than it’s initially estimated, it could mean that the project was just a complex thing. Or it could mean that we did not give the thing enough attention to have it broken up and released into possibly much smaller chunks.

It’s terribly challenging to find confidence in releasing a new massive functionality which took months to finish, especially when the feedback you have about its quality is limited. I am being reminded that a part of testing is solving the problem of having good enough test coverage of product risks. What are those risks? What tests do I want to perform in order to cover those risks?

Just like how meetings that take hours get extremely boring, it gets annoyingly tiring for teams to spend more than a month of time building a feature before publishing it in public.

If we don’t spend some of our time now tinkering with systems that could possibly help us accomplish things better in the future, we’ll end up doing the same things as before and that reflects into our ability to grow.

Just because a defect happens to quietly slipped its way into production code does not mean the team did not work their asses off in bringing the best work they could possibly do to the project, under the circumstances. And just because a team worked hard does not guarantee they will write code free of any bug. What matters is what people do when those flaws are found. And there will always be flaws.

Some people, even testers, are unnecessarily loud when they find problems in production after a feature release. This just means that they did not have any idea how that part of the feature was built in the first place and did not care to explore it either before the release. They only assumed that everything is ought to be working. They forgot that quality is a team responsibility.

It’s important that we understand why a problems exists in production code (and maybe who did it) but I’m not sure if it’s particularly helpful that we leave the problem fixing later to the person who made the defect when we have the time and the know-how to fix it ourselves now. What’s the boy scout rule again for programmers? Yes, leave the code better than you found it.

Just because a shiny new feature is released to the public does not mean it has actual value to customers. And if we don’t find ways of getting user feedback, we’ll never find out whether what we built amounts to something or not.

Feature releases are always short-lived, like the physical store opening day launch.  There’s always a celebration, an attraction, but it’s not what really matters in the long run. What matters are the lessons learned in the duration of building the feature, what we intend to do with those lessons, the people we worked with, and building things that our customers love.