Takeaways from Scott Berkun’s “The Dance of the Possible: The Mostly Honest Completely Irreverent Guide to Creativity”

How does one become a creative person? Are we only being creative when we’re delving into the realm of the arts? Why do we say that some people are more creative than others? Does creativity contribute to success? We admire accomplished illustrators, actors, programmers, singers, writers, painters, dancers, poets, and designers of all kinds because of their creativity in their chosen fields of endeavor, because we feel they have good taste in whatever it is that they do, and often we desire to be like them, wishing to churn out great pieces of work too in our lifetimes. But what does it really take to be creative? Scott Berkun gives his take on his latest book,  “The Dance of the Possible: The Mostly Honest Completely Irreverent Guide to Creativity“.

Personally, I don’t think much about what it means to be creative. I feel that thinking about its meaning doesn’t practically help me, because I’ve learned through experience that that only way to create good work is to do it, failing multiple times, learning along the way, and then succeeding. That’s what creativity has always meant for me – building things or solving problems that matter (to me or to other people I provide service to), whenever the itch is there or if the problems bug me enough. And reading Scott’s book felt like a confirmation of some sort of the beliefs I’ve had about creativity, plus a reminder to handle some of my habits better.

Here are some favorite lines from the book:

  • It’s far wiser to think about the effect you want an idea to have. If the goal is to make someone laugh, fix their car or increase the revenue of the widgets their company makes, that matters far more than how “creative” an idea is or is not.
  • We always have more freedom than we think, we just forget. We spend so much time trying to be efficient that doing anything interesting feels like a waste of time. And in this tendency is another misconception: creativity is rarely efficient. It always involves taking chances and trying things that might work but might not. The question then is: are we willing to spend time to be interesting, to think interesting thoughts and make interesting things? We all have the power, but perhaps not the willingness.
  • To create means to make something new, at least for you, and to do something new is like going off of the map, or more precisely, deliberately choosing to go to a part of the map that is unknown. In this case it rarely matters where or how you start.
  • You will, no matter how talented you are, have your finished works challenged and called not-so-good names. Good is surprisingly subjective, and the more creative the domain you work in, the more subjective it is.
  • The ability to see an idea, or a thing, from many different perspectives is among the greatest assets a thinking person can have. Of course you don’t have to agree with someone else’s perspective, but you owe it to yourself to try to see what they do. They may see something important you’ve never noticed before, however small, that can improve what you’re making or what you make in the future.
  • I don’t know a single productive creative person who doesn’t have a scrap pile of unfinished projects at different states of completion. This is not waste, but a precious archive of projects that might need to breathe, or of spare parts that may be perfect for other projects.
  • Some movies and books are poorly received when they’re released but become popular decades later. Others are big hits at first but fade over time. What is good? The answer depends on what your goals are and what problems you choose to solve.
  • No matter how great your idea is, there will be energy you have to spend, often on relatively ordinary work, to deliver it to the world.
  • Take pleasure in making things for the sake of making them: what a gift to have the time to make at all! If you were born 200 years ago, or to different parents in a different country, you wouldn’t have the time to feel bad about your work, because you wouldn’t have the wealth and time required to try. If you feel love for your craft, honor it by showing up, even when it’s hard. Especially when it’s hard. Working when it’s hardest often teaches rare lessons that will earn you easy rides now and then. Take pleasure in small progressions when you see them, and know those hard-won gains are the only way anyone in history has ever achieved anything noteworthy—for themselves or for the world.
  • If you truly love your craft, there is an infinite number of projects in your future. There will be other chapters. There will be other canvases and other songs. Perfection is a prison and a self- made one. Whatever you’re making, it doesn’t have to be perfect. Perfection is an illusion.
  • Expect to be rejected. You will be. It will happen no matter how successful you are.
  • Do one project for commerce and one for art. It’s an interesting approach: maybe the best work can only be made if it serves only one master at a time. It’s a healthy exercise to both make something entirely for yourself and entirely for other people. In each case you will stretch your boundaries for what you are capable of, as so often those conflicting desires of satisfying ourselves and satisfying other people bind us to conservative choices.
  • Too often we are distracted away from what we say is important by things that are more pleasurable or convenient. This means a central skill any creative person needs is a mastery of time, which means a mastery of habits. There will always be easier things in our lives than creative work. There will always be demands on our time that are more logical and lucrative than chasing an idea. If you are truly passionate about something you must be willing to make sacrifices to make it possible. What good is that passion if you can’t use it to help you do the work? Merely saying you are passionate, or feeling passionate, is not enough.
  • The simplest habit is to work on your project every day. If you don’t have a project, go to your private journal or drawing notebook daily until you do. It can be for ten minutes or an hour, but you must touch the work at least once a day. It can be in the morning, or late at night, or during your lunch break at work. At first when and where won’t matter. All that counts is that you commit to the discipline of honoring your ideas.
  • We all have the same time limit of 24 hours every day, which means the difference between a productive creative person and an unsatisfied dreamer is in how they choose to use it. Most of us forget how much of our time goes to entertainment, things we do purely for pleasure. We have plenty of time—it’s just we have to protect it for the things we claim are most important.
  • “Will anyone care about my work?” people often ask. Yes—you. It starts with you.

Favorite Talks from Agile Testing Days 2016

One of the great ways to be updated with what’s happening in the testing community is to attend software testing conferences, talk to the speakers and attendees, and ask questions. But if you don’t have the budget to fly over to where the conference is (like me), the next best thing is to wait for the conference recordings to be uploaded online. That’s how I’ve kept up with the latest news in test automation, following both the Selenium Conference and Google’s Test Automation Conference. All these recordings on YouTube paints a picture of what experiences and opportunities are currently out there for software testers.

And recently, I decided to free some time to follow Agile Testing Days and see what went on over at Potsdam, Germany. It was my way of checking out what’s happening in the agile testing community someplace far away from where I am. And today I’d like to share some of my favorite talks from that event:

  • Designed to Learn (by Melissa Perri, about testing product ideas, experiments and safe spaces for them, and learning what customers want and need)
  • Snow White and the 777.777.777 Dwarfs (by Gojko Adzic, about factors that may likely change testing policies and practices in the coming years as a result of computing power getting cheaper, such as third party platforms, per-request payments, multi-versioning, machine learning, mutation and approval testing, testing after deployment and failure budgets)
  • Continuous Delivery Anti-Patterns (by Jeff ‘Cheezy’ Morgan, on eliminating branches, test data management, stable environments, and keeping code quality high)
  • NoEstimates (by Vasco Duarte, about leaving out estimation in software development projects)
  • From Waterfall to Agile, The Advantage Is Clear (by Michael ‘The Wanz’ Wansley, on software testers being gatekeepers of quality, growing up in a waterfall system, and the wonderful experience that is software testing)

Lessons from Richard Bach’s “Illusions: The Adventures of a Reluctant Messiah”

Richard Bach’sIllusions: The Adventures of a Reluctant Messiah” is a most treasured book from all the books I have read so far. It is a short book, something that can definitely be digested for an hour or a few, but it doesn’t fall short of inspiring and thought-provoking passages, and questions. I have always kept a copy close because it’s what I often choose to rummage through whenever I feel totally sluggish or disheartened, never failing to provide a good pick-me-up or occasionally giving a disapproving eye when needed.

Here are some favorite lessons from the book, which I remind myself every now and again:

  • Learning is finding out what you already know. Doing is demonstrating that you know it. Teaching is reminding others that they know just as well as you. You are all learners, doers, teachers.
  • The simplest questions are the most profound. Where were you born? Where is your home? Where are you going? What are you doing? Think about these once in a while, and watch your answers change.
  • You are led through your lifetime by the inner learning creature, the playful spiritual being that is your real self. Don’t turn away from possible futures before you’re certain you don’t have anything to learn from them. You’re always free to change your mind and choose a different future, or a different past.
  • There is no such thing as a problem without a gift for you in its hands. You seek problems because you need their gifts.
  • The bond that links your true family is not one of blood, but of respect and joy in each other’s life. Rarely do members of one family grow up under the same roof.
  • If you learn what this world is, how it works, you automatically start getting miracles, what will be called miracles. But of course nothing is miraculous. Learn what the magician knows and it’s not magic anymore.
  • Isn’t it strange how much we know if only we ask ourselves instead of somebody else?
  • If you will practice being fictional for a while, you will understand that fictional characters are sometimes more real than people with bodies and heartbeats.
  • Like attracts like. Just be who you are, calm and clear and bright. Automatically, as we shine who we are, asking ourselves every minute is this what I really want to do, doing it only when we answer yes, automatically that turns away those who have nothing to learn from who we are and attracts those who do, and from whom we have to learn, as well.
  • The world is your exercise-book, the pages on which you do your sums. It is not reality, although you can express reality there if you wish. You are also free to write nonsense, or lies, or to tear the pages.
  • Within each of us lies the power of our consent to health and to sickness, to riches and to poverty, to freedom and to slavery. It is we who control these, and not another.
  • There is no good and there is no evil, outside of what makes as happy and what makes us unhappy.
  • If you want freedom and joy so much, can’t you see it’s not anywhere outside of you? Say you have it, and you have it! Act as if it’s yours, and it is!
  • We are game-playing, fun-having creatures, we are the otters of the universe. We cannot die, we cannot hurt ourselves any more than illusions on the screen can be hurt. But we can believe we’re hurt, in whatever agonizing detail we want. We can believe we’re victims, killed and killing, shuddered around by good luck and bad luck.
  • Why are we here? For fun and learning. It’s the same reason why people see films, for fun or for learning or for both together.

Fun fact: One of Richard Bach’s sons is James Marcus Bach, a software tester.

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.

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.

Interesting Talks from Google Test Automation Conference 2016

There’s a lot of stuff going on in the software testing community at the moment, specifically in the field of automation, because of how software is now being deployed into various other platforms besides personal computers. Google needs to worry about testing their eyeglasses, virtual reality headsets, and cars. Others care about testing robots and televisions. This is why it is fun to watch talks from conferences, like the Selenium Conference or the recently concluded Google Test Automation Conference: I get to find out what problems they’re facing and see how they try to solve them, and maybe learn a thing or two. Sometimes I get to pick up a new tool to try for my own testing too, a great bonus.

Some favorite talks from the conference are:

Notes from Alister Scott’s “Pride and Paradev: A Collection of Agile Software Testing Contradictions”

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.