Read: The Dance of the Possible

I’ve just consumed Scott Berkun’s newest book, The Dance of the Possible. As promised by the author, it was a short book intended so that we can get what we can out of it, get it out of the way, and dive into actually creating something. It was divided into three parts — each of which I consumed in one sitting of around an hour. You can breeze through it in less, but I liked reflecting on points raised by the author and recalling experiences where I can relate them (or could have related to them).

If I were to describe the 3 different parts of the book, I’d say part one is about the generating ideas. Part two is when you’re already developing your ideas. And part three is when it’s getting extra challenging to keep going and you need that extra boost.

He captures in writing some of the things I personally go through in my own creative process which made me just virtually nod in agreement and think “Oh yeah, that was what I was doing!” And I guess in making me aware, I could be more intentional in applying them and accepting when I feel like I’ve hit some sort of slump (that I will get over, of course).

I’ve long been intending to read a book on creativity (among many other things). Having Scott’s book come along with the invitation to do a book review really pushed me. When he described one of the seven sources of fuel for why people create the things they do (i.e., “Deliberately put yourself in situations where you have no way out but through.”), I couldn’t help being amused and thinking “Yeah, that happened!” I think even without the book review aspect, I’d have enjoyed reading his book as I’ve enjoyed some of his other writings. It just adds another dimension and it feels like it’s full circle because the book on creativity actually prompted me to create!

[Edit: Same content is posted as an Amazon book review over here.]

Are you interested in software testing?

So yesterday I shared a link to 30 Things Every New Software Tester Should Learn in some other social network. Now I know it says “new” and I’m not exactly new anymore. But still, I don’t know everything so I’m sure I’ll pick up something new. Besides, whether you learn something or not depends on your willingness and openness to the possibility of learning.

Anyways, that post consisted of a series of tasks, and the first of which was to do an introspection. It asks this key question:  Are you interested in software testing? I guess it’s pretty safe to say that I am. I’ve been in testing for a long time now and I do enjoy it. I tweet and blog about it. I like finding bugs, figuring things out, working with fellow testers and the devs, and essentially just helping in making our product better (and maybe our project too).

Now this is something I also wonder about whether fellow testers are actually interested in software testing. I totally understand that for some it’s a 9–5 job, and for some their interests lie in their personal pursuits (be it art, sports, pets, other hobbies) — after all, there is more to life than just work! I don’t take it against anyone if they’re not in love with their work (so very few are and that’s in general) or so gung-ho with software testing pride (pumps fists up in the air). But interest is critical. It could mean the difference between just getting by with the motions and excelling or exceeding expectations. And it could mean the difference between drudgery and enjoyment. At the very least, I do hope people like their work and not just for the reason that it pays the bills.

I know there are some folks who fell into software testing by chance — it happened to be an opportunity that was available, or they had to shift from another part of software engineering to testing. Some folks got into testing because they took a programming course in college but aren’t too keen on doing coding. And inversely, there are some who got into testing with the hopes of shifting into coding. But regardless of how you got here and whether you’re still testing the waters to figure out if testing is really for you or not, please exercise diligence. Testing might turn out to be something you can excel in so give it its fair chance.

And maybe to be interested in software testing, the first step is to make a conscious decision to be interested in it.

“The very first step towards success in any occupation is to become interested in it.” – William Osler

Read: Leading the Transformation

Our product owner is one of the rare few individuals I know at work who actually still reads books. Last month, he recommended that we read Leading the Transformation: Applying Agile and DevOps Principles at Scale by Gary Gruver and Tommy Mouser. It’s a thin book with only 112 pages on paperback and around a 3-hour read. It’s intended for leaders/executives so it gives a high level overview of the changes teams and the organization need to make and the benefit of those changes, and it repeatedly emphasizes management’s role in pushing for those changes. In particular, the changes that they want to drive at center around Agile, DevOps and Continuous Delivery (CD).

At work, small teams have now been shifting to Agile, our own team has been in this Agile project since January of last year, and I’ve heard of proposals wherein the methodology they suggest is already Agile instead of Waterfall. But then, I pick up from the book that trying to scale up Agile adoption across the board with small teams as the starting point doesn’t quite work for large organizations. Whoops. The book suggests that if you want an enterprise-level change, you have to plan for it and drive it from the management level down to us lowly minions. A key difference though is that within our organization (at least locally that I know of), we don’t really have hundreds of developers working on the same product or code base. And in our case, we’re only under 20 in the team, but even so the book still offers a good introduction to a lot of mature development practices that we need to look into.

Key items highlighted in the book that I’d like to reiterate further:

Importance of having quick feedback loops

Unit tests and static analysis tools can already weed out a lot of problems so that defective code won’t even get committed to the repository to begin with. And having those fixes done even before passing it to the test team — instead of fixing them only after the code has been deployed and testers found issues that were caused by those defects — will definitely help reduce the turnaround time.

Quick feedback loops will also help the team work and resolve issues while the code or user story is still relatively fresh in their heads. It’s more difficult for both the devs and testers to fix and retest an issue on a behavior that they’ve pretty much forgotten about.

Having builds as release- or production-ready as possible

With regular and stable builds in place, it’ll be easier to identify when a commit breaks the build. Since you don’t have to backtrack through days or weeks of commits, it’ll be easier to narrow down and identify the problematic commit.

Having dev/test environments as close to production as possible

One problem that we’ve personally encountered in not having a test environment in sync with the production version was that whenever we encountered an odd behavior in the test environment we had to double check whether the issue was also in prod. We also had to be mindful of issues that were already resolved in prod but not in the test environment. But I guess this problem is a combination of why it’s good to have the test environment as close to prod as possible and the next item related to why it’s good to have good deployment procedures in place.

Having repeatable build, deploy and test processes

From experience and the example above, having a reliable and repeatable deployment process could’ve saved us all effort and heartache. It could be so frustrating to test the same build (supposedly) but then get different outputs even if you’ve done the same steps using the same test data. In the same vein, you’d hate for a feature not to work in prod even if it had already been thoroughly code reviewed, tested and signed-off in UAT/PO review.

And last, but not the least, having test automation

You simply will never achieve the full benefit of Agile development until you get your automated testing properly built out and integrated into the development pipeline.

Test automation is key to the first item I mentioned since it enables quick feedback loops. It also allows repeatable tests to be executed across the different environments, and it allows repeated execution of the regression tests which you might not be able to afford to do so manually.

Having test automation, by itself, will not suffice. Tests have to be designed such that it’ll be easy to localize the cause of failed tests should any be encountered. Maintainability of the automated tests also have to be considered. Otherwise, the benefits of test automation won’t be realized since the team ends up ignoring the test results on account of being not sure whether the issue encountered is a code issue or a test issue.

One last thing… it’s a cultural shift

You can’t just invest on tools for CD or test automation or announce “Let’s do the Agile thing”, and expect the benefits to magically follow right away. This kind of thing takes time because there’s the technical learning overhead, plus shifting to a new way of doing things requires discipline and resolve so that folks won’t revert to the old habits that they’re trying to change.

It is important for executives to understand early on if the organization is embracing this cultural change, because if it doesn’t, all the investments in technical changes will be a waste of time.

It’s not going to be enough for the project team alone to be invested in the changes. The management and executives need to be aligned with this. In fact, they should help drive it. Otherwise, they might give demands that would bypass the adoption of change and instead force people back to their old habits (just because it might appear faster but only in the short term).

The book, after all, isn’t entitled “Leading the Transformation” for nothing. Management’s presence and push isn’t merely a suggestion; it’s a necessity. Sure, the project teams are the ones making the technical changes; but management needs to understand and support the changes. Essentially, people need to be in the same page in order to move in the same direction.

Finished reading: Managing the Test People

It’s a quick and easy read as it promised to be. I’m not a manager and it’s not something I’m planning to be. But I am somewhat in a position of leadership so the book is still quite relevant to me. Judging by how much I’ve highlighted in the book, it’s undeniably quite relevant.

I’m also working with younger folks who I believe have great potential to be leaders. They can be even better leaders than who we have at the moment, but only if they’re positively influenced by the right mindset on both leadership and technical aspects.

I’d go recommend this book to them since the author really paints a great picture of a leader (or manager) to aspire to be. And with its focus on testing teams — or technical teams in general — it’s a perfect fit for us. Reading the book raises the bar for our expectations on managers but only as it should be because we can’t expect nothing less than for our managers to lead and empower their people. You also get insights on how managers should (better) deal with things. But more than that, and I guess what’s most important, you also get to pick up and be reminded on how you should be as a leader (even if not by title).

In closing, the author shares:

Stay on the right path by frequently asking yourself, “Am I being honest? Am I being consistent? Would I want to work with* me?”

*Originally “for”. But since we’re not bosses or managers, “with” seems more relatable.

Maybe that simple level of introspection — especially on that last question — is what we all need to remind us to be first and foremost good colleagues or team mates before even rising to becoming good leaders.

On valuing your time, Maker’s and manager’s schedules

Time and again, my hate for useless meetings seems to keep on drawing me to Paul Graham’s essay “Maker’s Schedule, Manager’s Schedule”. (And also, I did tell a friend I’ll go share this link with her). Every time I read it, I couldn’t help but agree to a lot of the things he said. So much so that I find it hard to cite just one particular line to quote here in this post. You really just have to read the whole thing yourself.

To me, this essay is a pretty good reminder of what we should all be doing (just in case I’ve lapsed, and have been setting meetings or following up like there’s no tomorrow), and that is to respect my own time and other people’s time. In doing that, you make a more conscious effort to (well, if i can help it):

  • avoid interrupting or disturbing people unnecessarily
  • express gratitude when someone obliges you with their time
  • be present in meetings where your inputs or feedback are actually needed
  • set up meetings with the implicit target of not wasting people’s time
  • decline meetings I’m pretty sure I won’t be engaged in
  • decline meetings when they’re in conflict of personal commitments — Those are just as important (and sometimes even more) as work commitments
  • honor commitments to yourself — Ages ago, I had to block of time just for my lunch or dinner, and I even missed that because of work. That just isn’t healthy. Also when you block off time to work on something, then use that time to be productive.

Discipline on how you manage your time or own your own calendar starts with one’s self. And how badly your time gets mistreated by others (and even by yourself) highly depends on how much you’d allow it. So for your sake, start respecting and managing your time.

Reads: The Myth of Epiphany

The myth of epiphany is that great ideas dawn upon you in an a-ha moment. Take for example the popular story of an apple falling on Newton’s head when he discovered gravity or Archimedes’ eureka moment in the bathtub. But what those stories seem to miss out is the significant amount of work that they’ve poured into solving related problems, and that it’s only when they took a break and let their minds wander that the answer came to them. We mustn’t overlook that there is work that leads up to those a-ha moments. There is a period of incubation where we try to digest the information that we’ve observed as we work on things, and our brains are catching up with all that’s been observed. Then if we’re lucky, the answer or the great idea comes to us at an instance that seems so out of the blue that it makes for a good story.

One quote from Ted Hoff (inventor of the first microprocessor, Intel’s 4004) said it best:

“… If you’re always waiting for that wonderful breakthrough, it’s probably never going to happen. Instead, what you have to do is keep working on things. If you find something that looks good, follow through with it.”


The Myth of Epiphany is from a chapter in Scott Berkun’s book, The Myths of Innovation.

TED Talk: Why work doesn’t happen at work

Excerpts:

That’s what happens at the office.You don’t have a workday anymore. You have work moments.It’s like the front door of the office is like a Cuisinart, and you walk in and your day is shredded to bits, because you have 15 minutes here and 30 minutes there, and then something else happens and you’re pulled off your work,and you’ve got to do something else, then you have 20 minutes, then it’s lunch. Then you have something else to do. Then you’ve got 15 minutes, and someone pulls you aside and asks you this question,and before you know it, it’s 5 p.m., and you look back on the day, and you realize that you didn’t get anything done.I mean, we’ve all been through this. We probably went through it yesterday, or the day before, or the day before that. You look back on your day, and you’re like, I got nothing done today. I was at work. I sat at my desk. I used my expensive computer. I used the software they told me to use. I went to these meetings I was asked to go to. I did these conference calls. I did all this stuff. But I didn’t actually do anything. I just did tasks. I didn’t actually get meaningful work done.

And what you find is that, especially with creative people –designers, programmers,writers, engineers,thinkers –that people really need long stretches of uninterrupted time to get something done. You cannot ask somebody to be creative in 15 minutes and really think about a problem. You might have a quick idea, but to be in deep thought about a problem and really consider a problem carefully, you need long stretches of uninterrupted time. And even though the workday is typically eight hours, how many people here have ever had eight hours to themselves at the office? How about seven hours? Six? Five? Four? When’s the last time you had three hours to yourself at the office? Two hours? One, maybe? Very, very few people actually have long stretches of uninterrupted time at an office. And this is why people choose to do work at home, or they might go to the office, but they might go to the office really early in the day, or late at night when no one’s around, or they stick around after everyone’s left, or they go in on the weekends, or they get work done on the plane, or they get work done in the car or in the train because there are no distractions.

… Just silence, that’s it. And what you’ll find is that a tremendous amount of work actually gets done when no one talks to each other. This is when people actually get stuff done, is when no one’s bothering them, when no one’s interrupting them. And you can give someone — giving someone four hours of uninterrupted time is the best gift you can give anybody at work. It’s better than a computer. It’s better than a new monitor. It’s better than new software,or whatever people typically use. Giving them four hours of quiet time at the office is going to be incredibly valuable.

Reads: How to destroy programmer productivity

Not a programmer, but a lot of what he said somewhat applies.
Excerpts:
Whatever I can control, I should control. That means:
  • Turning off notifications on my iPhone (this has the added benefit of  increased battery life)
  • Giving myself a reward for 3 hours of continuous coding [or testing, in my case] (usually in the form  of “internet time” like checking Hacker News or twitter)
  • Working from home when I really, really, need to get something done
  • Scheduling ‘no meeting’ times on my calendar. These are times shown as busy  to everyone else. It’s my work time.
  • Not getting into programmer arguments around the office; people have strong  opinions, and the programmers who have arguments love to argue. If  there’s an actual business problem that needs to be solved, let’s grab a  conference room and come up with the advantages and disadvantages of each  approach. Let’s get some data. Let’s not just argue.
  • Position my desk in such a way that passersby aren’t distracting. [Well, i slouch so that i can’t see passersby. That’s not so healthy but that’s another topic.]
  • Taking a first pass at the problem, and *then* asking another developer to  walk me through the problem so that I can get a better understanding of what to  do. This accomplishes two things: First, it allows me to get the ‘lay of the  land’ so that I’ll at least have a basic understanding of the forces at work.  Second, it allows me to ask more intelligent questions when I ask for  help

Reads: Creating a Modern Mentoring Culture by Randy Emelo

I finished a couple of books last week, though I’m not sure if the 20-page “infoline” counts. So anyways, one is this infoline I read on “Creating a Modern Mentoring Culture” by Randy Emelo over at Books24x7. Here are just some of the stuff that I’ve highlighted for myself and for sharing:

Modern mentoring is connecting people across an organization to share critical knowledge and skills. Everyone has something to learn and something to teach, regardless of age or title, and people can be both mentees and mentors at the same time.

Key Pillars of Modern Mentoring

  • Open and Egalitarian
    • everyone has something to learn and something to teach
  • Diverse
    • different perspectives within mentoring communities and relationships help novel ideas and approaches arise in answer to organizational problems or issues people are facing
  • Safe and Judgment-Free
    • people don’t want to show perceived weaknesses by asking for a mentor
  • Independent and Autonomous
    • no need to try to control the amount of time people spend engaged in mentoring, the topics they connect around, or the people with whom they connect.
    • Too much rigid control will only create unwanted barriers to knowledge flowing from those who possess it to those who seek it.
    • Once you have created an enabling structure for modern mentoring, let your employees take the reins of their own learning.
  • Asynchronous
    • technology-enabled communication (email, online communities of interest, business social networks, mentoring and social learning software) is only on the rise and is a key enabling structure that supports modern mentoring
  • Self-Directed and Personal
    • Self-directed learning also allows individuals to learn what is applicable to them right now, gain skills that can help them with their unique work context, and make them more productive.
  • Technology-Centric
    • means to connect with others and a space to collaborate and communicate
  • Flexible
    • allowed and encouraged to shift in and out of your mentoring program and of the mentee-mentor roles themselves, as learning needs and knowledge strengths evolve

If the open nature of modern mentoring is compromised by too much organizational involvement, the quality of mentoring connections and the caliber of learning that takes place as a result of these connections will be degraded.

Creating a Modern Mentoring Culture

  • Re-Educate Leaders
    • need to help organizational stakeholders understand the expanded and broad vision of modern mentoring and its associated benefits
    • must be re-educated to understand that modern mentoring is a productive activity that won’t detract from employees’ effectiveness, but rather will help to strengthen it.
  • Get the word out
    • webinars or e-briefings, various media (podcasts, webinars, or newsletters), brief “commercials” at other training events
    • Sponsor roadshows or lunch-and-learns where mentoring participants share their experiences. Offering a venue for mentoring participants to meet and mingle can help energize your program and provides another opportunity for people to network and make learning connections.
    • Leverage employee resource groups, town hall meetings where a brief presentation could be followed by a question and answer session, Leverage your program’s evangelists.
  • Modernize Current Mentoring Programs
    • expanding your current mentoring programs and making them modern
    • Onboarding – new hires
    • High-potential development
      • brightest talent pull from an array of mentors and knowledge resources [instead of just one mentor]
      • allow high-potentials to be mentors themselves and share their knowledge with others while concurrently learning how to be a leader
    • Augment your formal training initiatives with mentoring cohorts
      • alumni of training programs mentor and advise a group of people currently going through training
      • Peers going through the same training can also connect and share stories around application of concepts learned in class to help cement the newly attained knowledge.
  • Amplify Using Technology
    • Let employees use technologies you have available to communicate and collaborate.
    • Make online employee directories or other skill profiles available to help participants see who would be a good mentoring connection.
    • Allow people to join your mentoring program at any time.
    • Acknowledge the efforts of those in the program.

Slideshare: 26 Time Management Hacks I Wish I’d Known at 20 by @egarbugli

I stumbled upon this deck again and it’s really something that I want to share to the younger ones. Time management wasn’t exactly something I learned when I was starting out. I came from projects where OT would become the norm at certain points, and we even had Saturday work. I was so time-poor. As I grew older, I came to realize how valuable my time is. How I could make up for losses for some things, but I can never get back time I have lost or wasted. And that the more efficiently I manage my time will allow me to spend it on things that matter more.

Saved myself some time by not writing my own presentation covering the same topic.

One of the points I like is #18 which had a quote from Jason Cohen (@asmartbear):

Only ever work on the thing that will have the biggest impact.

I think most especially for the younger ones, we often get sidetracked by initiatives or other non-project related tasks. We fill up our plate with a lot of things. We say “yes” to this and that. But then you have to think about it, step back and look at the big picture, and reflect whether the things that you are doing are really the things that you need to grow or achieve your goals. As an aspiring tester/technologist, are these tasks really relevant to making myself more technical and capable in my craft?