Test Architects Hub

Probably, one of the biggest discrepancies I’ve seen in IT so far is a mismatch between how much companies want their engineers to know and how much time they are ready to allocate for that. The imbalance usually shifts towards the latter, meaning little to no time is officially allocated to learning new things.

There are several reasons why this happens but I have no intention of analysing them in today’s article. Instead, let’s talk about how much time a quality specialist should spend learning new things to stay up-to-date and in good shape.

Prologue (or rather harsh reality)

First, let’s accept this truth – time flies. There is nothing we can do about it but try to do more meaningful things within our limited time frame. This isn’t just about software testing. Most “brilliant” time management ideas are built around spending time more efficiently so that people waste as little of it as possible.

As quality assurance engineers, we work on various tasks such as solving technical challenges, designing frameworks, writing tests, creating documents, and more. These tasks are generally geared towards benefiting the team, the project, and the company. However, due to a shortage of time, activities like browsing software testing blogs and watching technical talks from peers worldwide are often neglected.

In the short term, this still does make sense since this workflow still results in successful releases, users receiving new and well-tested bug-free features, and the company making a profit.

From a long-term or even a mid-term perspective, I believe, there is an issue. Information becomes outdated, and as a result, a significant part of our knowledge becomes outdated too. Moreover, nowadays information becomes outdated much faster than it did 10 or 20 years ago. What does it all lead to?

We need to be up-to-date. But why?

If you’d wake me up at night and ask about one of the must-have qualities of an engineer (along with technical excellence), I’d probably say it’s the ability to adapt to changes and challenges. Many technical specialists that I have learned from and who have inspired me, share this quality. And you know what’s interesting? They all spend a decent amount of time connecting with peers, reading blogs, and industry news, watching workshops, following release notes, and so on.

If I were to generalize the connection, it seems to me that adaptability to changes and challenges stems from how wide an engineer’s technical horizon is. The broader our knowledge base and the more up-to-date we keep it, the more we can explore different ways of approaching and rethinking a problem.

Thoughts on numbers (and a bit of Feng Shui)

In The Clean Coder book author Robert C. Martin, suggests that we need approximately 20 hours per week to practice and learn a new skill. When I think back to my early years in the IT industry, I was actively studying Python and automated testing of Android applications at that time.

I can’t fully agree with the author’s statement about 20 hours. For those of us who work and have family commitments, dedicating 60 hours a week (40 hours working + 20 hours studying) may not be sustainable in the long run. It may be feasible for a couple of weeks, but eventually, something else will suffer.

On the other hand, if we put ourselves into the shoes of engineering managers, a request of allocating half of our weekly working time for learning is highly likely to be rejected. Thus, learning something completely new may have to occur during our own personal time or may not progress as quickly as we’d like.

When it comes to staying up-to-date with industry trends, news and developments, I’ve experimented with different approaches. In my opinion, the most efficient one, is to spend 4 hours every Friday afternoon reading high-quality software testing blogs, following the latest release notes of the libraries and frameworks you work with, and watching advanced-level technical conference talks. It’s definitely not enough to cover everything but should be sufficient for keeping up with the most relevant topics and materials.

The end of the week seems to be a good choice for this activity since most writers tend to publish their materials during working days, and new releases often occur during the week as well. Additionally, according to my observations, an engineer’s productivity tends to decline after working 4.5 days. Therefore, taking some time to focus on a different activity can help balance things out.

Why are engineering managers hesitant to allocate explicit learning time?

The answer, in my opinion, can be found in Parkinson’s Law. One of its corollaries states that “Work expands to fit the time available for its completion”. Applying this to our example, we can conclude that no matter how much time is allocated for learning, it is most likely to be fully consumed, even if there is no real need for knowledge development.

Moreover, if a crew is officially given 4 hours every Friday afternoon to spend on learning, it does not really guarantee that learning is going to happen. Of course, keen engineers will utilize that time the most. But many team members might perceive this as an opportunity to finish their working week earlier (which is not that big deal but does not serve the original goal either).

Epilogue (perhaps a happy one)

So, what is the solution?

I believe it’s a smart balance between making everyone aware of the learning goals and tracking the outcome. It’s naturally okay for an engineering manager to know that the time budget is spent efficiently. If it is, it’s a win-win situation.

Test engineers, on the other hand, should be more conscious about their learning time, have a plan of action, a decent list of resources to check, and constantly seek opportunities to apply new knowledge in their projects and improve things.

It seems like a good deal to me, doesn’t it?