DEV Community: Enrique Lopez

Learner, Thinker, and Doer: Unlocking Your Engineering Superpower

Enrique Lopez — Sat, 28 Sep 2024 16:52:20 +0000

As engineers, we all wear different hats during our work. Sometimes we're in learning mode, absorbing knowledge like a sponge. Other times, we’re deep in thought, pondering over the perfect solution to a complex problem. Then, there are moments where we’re in execution mode, getting things done efficiently. These are the three core operating modes we frequently shift between: Learner, Thinker, and Doer.

While each mode has its strengths, most of us lean naturally toward one or two of these modes more than the others. The key to maximizing your effectiveness as an engineer lies in understanding these modes and how to balance them, not only within yourself but also by finding teammates who complement your strengths and weaknesses.

Let’s dive into each of these modes, their benefits, downsides, and how you can leverage them—whether you’re working solo or as part of a team.

1. The Three Modes: Who Are You?

Learner

The Learner is someone who thrives on acquiring new knowledge. Whether it’s keeping up with the latest tech trends, reading up on cutting-edge algorithms, or simply diving into a new language, the Learner finds joy in growth. If you consider yourself to be in this mode frequently, you’re likely the go-to person when the team needs someone to explore new tools, research better frameworks, or stay on top of the latest innovations.

For example, as a young engineer, I found myself obsessed with mastering every new framework that came my way—Node.js, Selenium, Playwright, AstroJS, you name it. I loved digging into documentation, experimenting with beta features, and building test projects just to get a feel for how they worked. I realized quickly, though, that while I was always excited about the learning process, I wasn’t great at finishing things. I needed to shift gears at times to balance the time spent in learning mode with actually doing.

Benefit: Lifelong learning can give you a competitive edge, especially in an industry as fast-moving as software. You’ll always be ahead of the curve.
Downside: Constant learning without practical application can lead to a form of intellectual procrastination. Too much time spent in this mode might mean fewer finished projects.

Thinker

The Thinker loves strategy. This mode kicks in when it’s time to solve complex problems or develop long-term solutions. If you're the type to spend hours drafting out flowcharts, architecting new systems, or working out edge cases, you probably spend a lot of time in this mode.

One of my closest colleagues, Pablo Aversa, was the exact opposite of me when it came to thinking. I’d analyze a problem, consider multiple approaches, and try to come up with the most elegant solution. Pablo? He’d sketch out a quick plan and start executing immediately. I remember when we worked on optimizing a real-time data pipeline for a streaming service. I had all these brilliant ideas on how to refactor it for better scalability, but I also spent so much time refining the plan that Pablo had already built a prototype while I was still ironing out the details.

Benefit: Thinkers can spot issues others miss, and they can devise solutions that are scalable, efficient, and elegant. This is especially useful in preventing technical debt.
Downside: Overthinking can lead to decision paralysis. You can spend so much time planning or worrying about the "perfect" solution that you fail to deliver on time.

Doer

Then, there’s the Doer—the person who loves getting things done. In many teams, this person is the engine that drives productivity. They don’t waste time over-analyzing or procrastinating; they execute. Whether it’s completing user stories, pushing code to production, or fixing bugs, Doers thrive on crossing tasks off the list.

I remember how Pablo’s drive would propel our team forward. He’d take an idea and run with it. While I was still crafting the ideal solution, Pablo was already shipping features. At first, I was a bit envious of how quickly he could move. But over time, I came to appreciate the balance between us—my long-term thinking paired with his ability to execute quickly made us an unstoppable duo.

Benefit: Doers ensure that work gets completed. They’re the ones driving projects forward and ensuring deadlines are met.
Downside: Without enough planning or learning, Doers can fall into the trap of cutting corners or producing solutions that require more fixes down the line. They can also burn out without taking enough time to recharge or think things through.

2. Benefits and Downsides of Each Mode

Each mode offers its unique advantages, but they also come with potential pitfalls if overused. Here’s a quick breakdown:

Benefits and downsides of each mode
Let’s consider a real-world example. Imagine you’re working on a startup. You and your team have a million-dollar idea for a new SaaS product. You, the Learner, spend weeks diving into frameworks and architectures, trying to figure out the perfect stack. Your teammate, the Thinker, spends time sketching out the ideal product roadmap and planning how it will scale once the product takes off. But neither of you have made much tangible progress yet.

Then, the Doer on your team steps in. They don’t care if the framework is bleeding-edge or if the architecture is perfect. They just want to get a prototype up and running. By doing this, the Doer ensures that there’s actually something to show for all the planning and learning.

The truth is, without each of these modes working in concert, you could be stuck in a loop of indecision, constant revision, or unpolished results.

3. Finding Teammates Who Complement You

Here’s where things get interesting: while it’s possible to shift between these modes, most of us naturally excel in one. The key to building successful teams is to recognize your strength and find teammates who complement your weaknesses.

For example, I’ve come to accept that I’m a Thinker. I enjoy planning things out and coming up with innovative ideas, but I’ve struggled with taking quick, decisive action. When I partnered with Pablo, it became apparent that his Doer mindset filled the gaps where I fell short. He could quickly build the things I was envisioning, and together, we produced incredible results.

The magic happens when a Learner, a Thinker, and a Doer come together. The Learner brings fresh knowledge and innovation, the Thinker ensures that the team is heading in the right direction, and the Doer gets things moving, ensuring that deadlines are met and that tangible progress is made.

As an engineering lead, I’ve seen teams struggle because they were unbalanced—too many Thinkers without Doers led to slow execution, and too many Doers without Thinkers led to technical debt. On the flip side, when teams are well-rounded, they’re like a well-oiled machine, capable of producing not only high-quality work but doing so efficiently and thoughtfully.

Final Thoughts: Embrace Your Role, Respect Others

In the world of engineering, none of these modes is inherently better than the others. Each brings something valuable to the table, and it’s the interplay between them that drives innovation, progress, and success.

So, who are you? A Learner, Thinker, or Doer?

Whichever role you naturally gravitate toward, own it. Embrace it. But don’t forget to seek out teammates who balance you out. When you surround yourself with the right people, you not only grow but also unlock your team’s full potential.

The engineering world moves fast. By understanding where your strengths lie and how to complement them, you can ensure that you’re always moving forward—no matter which mode you’re in.

"I HATE QA" - A Perspective from a Senior QA Engineer

Enrique Lopez — Tue, 24 Sep 2024 16:48:22 +0000

Introduction

In software development, Quality Assurance (QA) is often misunderstood as simply catching bugs or performing tests. However, as a Senior QA Engineer with 10 years of experience, I can tell you that QA goes far beyond that. It is not just about finding defects; it’s about building processes, strategies, and systems that lead to higher-quality products. In this article, I will break down what I call “I HATE QA,” where HATE is an acronym representing key pillars of QA:

H - Human Factor

A - Adjust Constantly

T - Tech Mastering

E - Embrace Good Practices

This title, though provocative, comes from a deep-seated philosophy:

“We are humans, and humans are not perfect. Humans make mistakes. Since we aren’t perfect, we must find strategies to come close to perfection. And that’s what QA is for.”

Let’s dive deeper into these four blocks and explore how each of these plays a crucial role in helping us move from average to excellence in software development.

1. Human Factor: The Root of the Problem and the Key to Success

There’s a famous saying:

“The problem isn’t technical; the problem is people.”

In my experience, this statement couldn’t be more accurate when it comes to building a product. Software systems, no matter how complex, are designed and built by people. People, however, are prone to biases, miscommunication, and misunderstanding. We often say the problem is people because elements like communication, language, misconceptions, alignment, and bias are incredibly hard to handle.

Software engineers, more than anyone, must recognize that we’re paid to think. Anything that distracts us from this core purpose — such as poorly defined requirements, misaligned expectations, or communication gaps — takes us away from the essence of our job. A QA engineer’s role isn’t just to find issues in the product but to ensure the team is thinking effectively.

Here are some questions that every QA engineer should ask themselves to find paths that help developers and teams improve beyond just technical output:

How can I help developers think better?
How can I improve communication within the team?
How can I make developers listen better?
How can I encourage adaptability?
How can I promote better imagination?

QA engineers act as a bridge between different departments, advocating for clear communication and collaborative improvement. We need to ask ourselves these questions daily to broaden our perspectives and make a difference beyond standard QA tasks.

These are some thoughts around previous questions:

A well-thought-out test scenario forces developers to reconsider edge cases and the flow of their code.
Are we all using the same vocabulary? Do we understand each other’s assumptions?.
Ensuring feedback is heard and considered is critical to team improvement.
Every release and product iteration demands a fresh approach.
Good QA not only spots errors but inspires new ways to approach and solve problems.

2. Adjust Constantly: Evolving Along with the Role of QA

The software landscape evolves rapidly, and the QA role must adjust just as quickly. In the past, a Manual QA Engineer was the norm — performing human-driven tests to check functionality. As development processes matured and automation technologies became more accessible, the QA landscape evolved toward Automation QA Engineers, capable of writing scripts that could execute tests faster and more consistently.

Today, we’re witnessing the rise of Full Stack Engineers who test, blurring the lines between development and QA. A QA engineer is expected to not only test but to contribute to the overall architecture and development of the system.

The need for constant adjustment doesn’t stop at roles. It also extends to processes. Historically, QA processes were strict and rigid, often following strict guidelines that would sometimes stifle creativity and flexibility. Now, with the rise of Agile and DevOps methodologies, flexibility and adaptability are prized.

In companies like Facebook and other tech giants, we see a clear shift toward a more flexible approach where certain agile layers are removed. Teams are given ownership of the product, and this sense of responsibility drives them to release features faster. Adjusting processes based on the maturity and seniority of the team allows for better outcomes, as developers feel more accountable and motivated to deliver higher-quality work.

QA engineers must adjust constantly, both in their skill sets and in their approach to process. As teams grow in maturity, the need for flexibility becomes more crucial, allowing individuals to contribute in a way that maximizes productivity while maintaining quality.

3. Tech Mastering: Technology is Your Best Ally

In modern software development, technology is your best ally as a QA engineer.

"Mastering technology can elevate your work to another level, enabling you to remove repetitive tasks, reduce the time spent fixing bugs, and devote more time to innovation"

Automation is the cornerstone of tech mastery in QA. Automated tests save time, reduce human error, and provide quick feedback loops to the development team. But automation is just the beginning. To truly master the technology, a QA engineer should be proficient in the tools and frameworks used for:

Continuous Integration/Continuous Delivery (CI/CD): These pipelines allow for rapid deployment, but only if the underlying tests are solid.

Performance Testing: Understanding how to test the system under various loads is critical to ensuring stability and scalability.

Security Testing: Today’s digital world demands software that is not only functional but secure. Mastery of security testing frameworks and tools is essential.

By mastering technology, QA engineers help the team move faster, innovate more freely, and ultimately build more reliable software. Tools can help create order from chaos, automate the repetitive, and help teams focus on solving higher-order problems.

4. Embrace Good Practices: Focusing on Process, Not Just Results

One of the key lessons I’ve learned in my career is that good practices and well-defined processes lead to better results. A strong system of good practices helps remove bias, put everyone on the same page, and create reusable components that allow the team to move faster.

By embracing good practices, we ensure the development process is as clear and repeatable as possible. Some principles to focus on include:

Make it obvious: Testing should reveal issues easily, and the path to fixing them should be straightforward.

Make it simple: Simplicity reduces the room for error. Overcomplicated systems often breed mistakes.

Make it repeatable: Repeatable processes are key to consistent success. Each new iteration should build on the success of the previous one.

Make it concise: Avoid bloat in your testing strategies. Clear and concise processes ensure better understanding and easier execution.

Make it fun: A positive testing culture encourages collaboration and creativity, making the process more enjoyable for everyone involved.

Good practices shift the focus from rushing to meet deadlines to ensuring that the product is being built on a strong foundation. These practices give clarity, reduce misconceptions, and create a roadmap for delivering high-quality software consistently.

Conclusion: QA as a Strategic Role

While the title “I HATE QA” might seem like a contradiction, it’s not. This philosophy reflects a QA engineer's deeper role: helping people — developers, testers, and product owners — think better, adjust constantly, master technology, and embrace good practices.

"QA isn’t about finding bugs; it’s about preventing them. It’s about building a system that supports and enhances human thinking and ensures a product that users love"

If we embrace the Human Factor, adjust to changes, master the technology, and embrace good practices, we can move closer to perfection, not just in the product but in the process. QA is a critical piece in delivering high-quality software, and by focusing on these core aspects, we ensure not just good software but great teams and better experiences for everyone involved.