Takeaways from Elisabeth Hendrickson’s “There’s Always A Duck”

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.

Some takeaways:

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

Team Questions I

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?

Lessons from Timothy Ferriss’ “Tools of Titans”

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

Pitching a Small Tool

Last week I told our technical writer, a music expert, a video games enthusiast, a good father to his young daughter, and a loving husband to his wife, that I could build him a small tool that could quickly update a master file of local translations, so he could focus his precious time on more important matters other than the job of laboriously cross-referencing and manually updating such a document. That was a passing comment while some of us were suddenly randomly discussing the process of how he was currently maintaining the file. However, the passing comment also felt like a pitch to a software development project that had some sort of value to a very specific customer, and an easy one at that. It was a fascinating experience; it makes you think about how caring for the well-being of someone is very much a part of building software of value, and that good software connects people for the better.

Let’s see how that tool works out this week.

Where the Fun and Challenge Is

Ultimately what makes software testing fun and challenging is because it needs you to interact with people. You have to talk to both the software development team and the application users. You have to understand what they care for and why. You have to ask questions and the answers to those questions guide what you do when you test. You can test in a silo but that doesn’t help you learn anything deeper, you can’t thrive if you stick to the things you already know. You grow because you take in all these perspectives and beliefs that other people have and test them against your own, for the goal of making better judgments about how to test the thing your testing and why you’re testing them in the first place. It’s not easy, because you have to care. The challenge is that you have to learn a great deal of many things, you have to regularly check the landscape of where you are, and you often need to reflect about what you’ve done and what you want to do next. And on the journey of overcoming the challenges you set for yourself is where the fun is.

Being Reminded of All the Phases I’ve So Far Had in Writing Automated Checks

I’m currently in the midst of a test code overhaul, a re-writing project of sorts. It started about a week ago and so far I’ve made considerable progress on what I’ve wanted to achieve with the rewrite, which is basically cleaner and more maintainable code, mostly in the sense of test data management and test description language. The number of tests running everyday in our Jenkins system has grown noticeably and I’ve felt that it’s been difficult to add certain tests because of how I structured the test data in the past, which I have not upgraded since then. The two possible avenues for running tests – on the UI and HTTP layers – also adds a bit of complexity and it’d be nice if I can integrate the two smoothly. It’s an interesting development because I did not plan on any re-writing to be done anytime soon but I guess at the back of my mind I knew it’ll happen eventually. And so I decided to take a step back from writing more tests and do some cleanup before it gets tougher to change things. I plan to finish everything in about a month or so.

At the moment, I’m reminded of the phases I’ve gone through in learning to code and writing automated checks in the past few years:

  • Early 2014. It all begins with Selenium IDE, with giving the self some time to study the basic Selenese commands for writing automated checks and (more importantly) understand how to properly retrieve the page elements you want to manipulate.
  • Mid 2014. Test management in Selenium IDE becomes difficult as the number of tests grow, hence the decision to switch to Selenium WebDriver. The only programming language background I had back then was C++, which was limited to only functions and logical/conditional operators, so I chose Java to work with to lessen the learning curve.
  • Late 2014. Familiarized myself with Git, which hooked me on making daily commits and appreciating version control. Along the way I learned the concepts of classes and objects.
  • All of 2015 up to Early 2016. I was in a trance, writing code daily and pushing myself to create all the automated checks that I wanted to run for our apps before every release. Tests run on the Eclipse IDE using TestNG and I was happy with what I had, except that those end-to-end tests are really slow. Running everything took overnight to finish, which was okay for my employer but annoying for me personally.
  • Mid 2016. Re-writing existing tests in Ruby with Cucumber integration started off (when I found Jeff Morgan’s “Cucumber & Cheese” book online) as a side project for fun and testing my skill level in programming. And I did have buckets of fun! The experiment told me that there’s still a lot I need to practice on if I want to write better code, and it also told me that I can be more productive if I switch programming languages. There’s a bit less code to type in when writing code in Ruby than Java and I liked that, plus all the interesting libraries I can use. I switched to Sublime Text and used both Jenkins and the command-line interface more extensively too.
  • Late 2016. As I was looking for ways to speed up end-to-end tests total execution, which by then takes about 4 hours to complete, I ended up exploring testing apps in the HTTP layer instead of in the UI. That took a lot of studying of how our apps actually behave under the hood, what data are being passed around, how images are actually sent, how to view pages without a browser, how redirections work, among other things. After years of testing apps via the user interface, this was such a refreshing and valuable period, and I completely wondered why I never knew such a thing existed until then. It wasn’t being taught extensively to testers, perhaps because it all depends on how the app was structured to run through an API.

And these phases brings me to now, where there’s a healthy dose of API and UI layer tests all checking major app features. It’s all good, just several pieces needing a cleanup, a little parallelization, better test description language, and great documentation. It’s all good, because the lessons in both programming and testing keep piling. The two practices differ in mindset but I think they complement each other, and I think that there’s no reason anyone can’t do both.

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.