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.

A Mismatch Between Expectations and Practices

We want performant, scalable, and quality software. We wish to build and test applications that our customers profess their love to and share to their friends.

And yet:

  • We have nonexistent to little unit, performance, API, and integration tests
  • The organization do not closely monitor feature usage statistics
  • Some of us do not exactly feel the pains our customers face
  • We don’t have notifications for outdated dependencies, messy migration scripts, among other failures
  • Some are not curious about understanding how the apps they test and own actually work
  • We have not implemented continuous build tools
  • It is a pain to setup local versions of our applications, even to our own programmers
  • We do not write checks alongside development, we lack executable specifications
  • Some still think that testing and development happen in silos
  • It is difficult to get support for useful infrastructure, as well as recognition for good work
  • Many are comfortable with the status quo

It seems that we usually have our expectations mismatched with our practices. We’re frequently eager to show off our projects but are in many instances less diligent in taking measures about baking quality in, and therefore we fail more often than not. What we need are short feedback loops, continuous monitoring, and improved developer productivity, ownership, and happiness. The difficult thing is, it all starts with better communication and culture.

If You Want To Change

Then start small. Really, small.

Sure, write your big goals on (physical or digital) paper, and dream about all the great things you can do when you’re slimmer and healthier, more skillful in your art, more financialy secure, or more social, but please don’t expect those changes to just magically happen because you listed and thought about them. They’re necessary steps for the new you that you’re excited to be, but incomplete. All artists want to draw better, all musicians dream of playing music in the grandest stage, all writers think about being successful authors, all of us want to be fit, want to be less socially awkward, and want to travel more. We all want to make a living where we both have fun and generate enough income for our families. Big goals are fun to think of, but they can be overwhelming. Vague goals are easy to list but they are difficult to implement in our lives.

So start small. Pick the most important goal that you have in your list, and if it is big, split, slice, break it down to incredibly tiny, specific, chewable pieces. Instead of drawing better, you could re-write your goal to draw one portrait (or landscape or idea) for an hour every Saturdays of January in your favorite place. If you want to lose some pounds, you could start by religiously running every morning of every other day of this month just for 30 minutes in a park somewhere near, before everybody else wakes up. If you want to write a novel, you could timebox yourself to writing something about it every day for one month just for an hour right after you wake up, before going to work. If you want to learn a new skill, give yourself 30 minutes to research and practice it everyday at work. Test yourself, experiment for a month without excuses, see if you can do these small things and like your results. If you do, then do them again. If you don’t, ask yourself why. The thing to remember here is that in order to make big stuff come true, you need to make small changes first, no shortcuts. You should make few but bold decisions, you need to re-build your systems of working, you must review and replace habits that don’t work with ones that do, because that’s where it all really starts.

Data-Driven Testing

For new apps and software features, it’s perfectly normal to exhaustively test the matrix of all possible scenarios with equal importance before release – the happy path, the confused path, the forgetful or greedy paths, etcetera – whenever the tester can. After all, no one knows yet how exactly the new application will behave in Production, and it is always better (and cheaper) to find problems and fix them early instead of reacting as they occur.

For small software that are already in the wild and which do not change often, it is still a good rule of thumb to test everything with equal priority, if the budget allows for it. It’s still nice to catch bugs before the next version release rather than have a client surprise us at odd times with a system failure.

For complex legacy systems which frequently change and usually do not automatically test themselves, it is still a great idea to test features in full-scale, if we can, if it’s possible to perform all those complicated use cases within hours before the deadline. That’s a noble but a hugely difficult task for testers, if not impossible to accomplish, and something that might be a complete waste of time and creativity, or a foolish thing to do, even if it is very important for teams to have confidence in the stability of their applications. For such systems it might be better to re-evaluate what goals does our testing need to reach, re-think what sort of stuff do we want to find, re-learn what services do we want to keep providing to our customers as well as how effectively do we want to provide those services, and go from there. It might be better to spend some of our time on data monitoring and analysis, on understanding how our clients actually use our products and focus our testing those usage scenarios. It might be better for us to amplify testing and developing the features that our clients love. And it might be more worth it to regularly identify the riskiest parts of the system and improve their design and testability, rather than trying to keep up with the matrix we know we couldn’t possibly deal with everytime.

Apps evolve, and I think that the testing that we perform needs to change too according to our current contexts.

Fine-Tuning The Software Development Process

Lately I’ve been thinking about the software development process we have at work, the stuff that has been keeping us in shape for the past few years. It’s a system of smaller systems, which in turn makes up a flow – requirements gathering, sprint planning, sprint iteration and monitoring, demo and retrospectives, testing, project release. Good flow helps deliver quality service, bad flow makes it difficult to produce value.

I actually think we’re actually doing good so far on the flow. 🙂

Still, there are some areas in our current process where I believe we could be many times better in the near future, such as tasks estimation, business rules presentation and documentation, sprint data analysis, testing (especially unit testing), and continuous integration. It’ll take a while, of course. The challenge is for everyone in the team to keep seeking the possible small improvements we can easily implement, baby steps that makes our good flow better than ever. Delivering quality has always been a team effort, not a task reserved to testers (nor to any one person) alone.


As an automation tester, I’ve been spending the last two months or so refactoring tests I’ve written before, trying to make them more flexible to change (because tests do tend to change as user interfaces and business rules often get refined) and more efficient (because tests need to run as often as possible in a  continuous integration software development environment), and with refactoring code I’ve been looking at what’s already been composed and asking myself if these tests continue to be relevant. It feels a lot like reflection; it reminds me of what I have, what I do with them, and why they exist. Sometimes there’s stuff that you don’t need anymore, other times there’s things you want to change for the better because you understand them better now than weeks, months, or years before. A few probably gets left alone as it is because you’ve come to terms of how they are and how they keep working for you, and you like them just like that.

And now I realize that I’ll do more refactoring as I add new tests to the suite and it will take up some of my time. Code reviews are vital, just like how necessary regular contemplation on one’s life are.

About Other Things That Are Good For The Soul

Drawing, writing, and reading are some of the important things I’d like to keep doing in my life that do not always involve sitting in front of a computer, unlike software test automation. These can be done digitally of course (which many of my peers do) but I’ve found out that they’re really difficult to pursue when I’m already comfortable in my computer chair and starting back at a monitor, with movies and series episodes wanting to be played or the world wide web egging me to log on. And in my heart and in my mind I know that these stuff that I value are of greater importance than these distractions, yet they’re really hard to ignore when I’m already there looking at a computer screen, tired from the day’s worth of work and my body telling me it’s alright to relax. The next thing I know, my willpower is down to zero and minutes later I am surfing pages and pages of the internet and responding to notifications or watching Game of Thrones or The Big Bang Theory.

So now I am trying to find times of the day when I can do these things that I love, times of the day when I have the highest chances of success of saying “No!” to the pull of the PC, and get things done, doing one small thing I’m going to be proud of at a time. I find out that it’s usually in the morning before breakfast that I have the most resolve and control over my actions, and I’ve decided to maximize that option, especially during weekends. On weekdays, I must review the structure of my day, of when and where I can haggle a tiny piece of my time, maybe 30 minutes or so, and create a new habit that lets me focus on valuable projects bit by bit. I’ve already found a process that works for my software testing endeavors (easy, because my job sort of requires me to use my own projects) so there’s no reason I can’t find a method or two that makes it possible for me to do these other activities that are good for my soul.