Advocating for technical work, pair programming FAQs, and threat modeling 💡

Monday Ideas — Edition #97

🐺 QA Wolf — get automated E2E test coverage

Testing is an ever-controversial topic, and I write a lot about it on the newsletter. Different types of tests have different ROI, and E2E ones are particularly tricky.

E2E tests are complex to write, expensive to run, and painful to maintain. Yet, they deliver a ton of value in securing your most important workflows, without blocking releases with manual QA.

I have known the founders and the team at QA Wolf for a long time, I am a fan of their product, and I am happy to promote it on the newsletter this week.

For 1/3rd the cost of a full-time hire, QA Wolf automates, maintains, and runs your team's test suite in 100% parallel and provide unlimited runs.

You can look at multiple case studies where they build 80% automated E2E test coverage in just 4 months, saving $200k+/year in QA engineering and infrastructure costs.

Back to this week’s ideas! 👇

---

1) 🔨 Advocating for technical work

Two weeks ago we had the first of our Community Mastermind sessions.

The Masterminds are monthly sessions where members of the Community meet and tap into each other’s expertise and support, to work through the challenges that they are facing.

One of the topics we discussed is how to make the case for technical investments.

Here are some insightful pieces of advice that were shared:

1. 💭 Decision process — sometimes we decide on a course of action and then try to make the case to justify it to others. This can come across as disingenuous. What if, instead, building the case was part of us deciding whether we think it is the right time to invest more in resolving technical debt?

2. 🪴 Level of investment — How do we know what the right level of investment is? If we are not sure, then making small investments and demonstrating the value is one way to build our (and others’) confidence in making bigger investments.

3. 🤝 Building trust — It is really important that the rest of the business trust engineering in the decisions that they make around investing in technical debt. Starting small and demonstrating value is a great way for us to build that trust.

We will hold the next session on April 16th. You can learn more about the sessions and how to join below 👇

Introducing the Refactoring Mastermind! 🧠

You can also find more ideas about tech investments and technical debt in this previous piece:

How to Manage Technical Debt 🦠

---

2) 👯 Pair Programming FAQs

A few weeks ago I interviewed Farhan Thawar, VP of Engineering at Shopify, on the podcast.

Farhan is a big proponent of pair programming, and we spent a good chunk of our conversation answering FAQs about it. Here they are:

1) When should you pair program vs when is it not worth it?

Pair programming is best when it allows you to produce high quality software and share knowledge in the process. Kent Beck says:

Pairing works when there is sufficient uncertainty in the problem be solved and the approach to solving it.

Viceversa, pairing might not bring much value for mechanical or trivial tasks that both members could accomplish by themselves. If the work doesn't require taking any decisions, and there is no learning involved, you might as well avoid pairing.

2) Is pair programming effective remotely?

Absolutely! Pairing is one of the best ways two remote engineers can spend their time. Other than being effective per se, it is a fantastic way to build strong relationships, which is especially important in remote teams.

3) Should managers pair program?

For engineering managers who want to stay technical and hands-on, pairing with engineers is one of the best ways to do so. Way better than doing code reviews pretending that you know what you are doing!

4) How do you allocate resources for pairing?

This is a popular one, that the answer is simple: you just assign two people to the task. That’s it.

5) How often should you pair?

This depends on many factors: familiarity with pairing, complexity of tasks, engineers preferences, and more.

If you want to build the habit, you may start by intentionally pairing ~20% of the time, on the most challenging tasks. So, for each dev cycle, you may create the habit of picking the top, most complex item, and assign it to two engineers.

6) Can you pair in more than two people?

Yes, and it’s usually deemed mob programming. Shreyas Patil, Senior Software Engineer, told his experience in the community:

We have set aside a Friday every two weeks where we gather to work on a problem or tech-debt.

Our use cases have mainly involved tackling tech-debt, spread knowledge within the team, and in certain cases KTLO activities which could be long and tedious to be executed by a single person.

We encourage team members to bring problems that would benefit from the spread of knowledge or represents a significant tech-debt. The session is moderated by our EM, as they maintain the list of problem statements deemed as a mob programming candidate.

I recently wrote a full guide about why you should pair program and how to do it well 👇

The Power of Pair Programming 👯‍♀️

---

3) 🔒 Threat Modeling

A threat model is the description of an application and its environment through security glasses.

So, threat modeling is a family of activities you pursue to identify threats, vulnerabilities, and design countermeasures to prevent or mitigate such threats.

Historically, designing for security has often followed the security sandwich approach: you address security during design, and you test things at the end. This waterfall-ish approach, though, clashes with reality: specs often change during development, so you end up testing for things that are 1) incomplete, or 2) not relevant anymore.

Good threat modeling should be applied continuously throughout the whole development lifecycle.

You can check the dedicated OWASP page for more details about how to perform it, complete with practical examples.

I wrote a primer last year on how to secure the whole development lifecycle 👇

How to Write Secure Code 🔒

---

And that’s it for today! If you are finding this newsletter valuable, consider doing any of these:

1) ✉️ Subscribe to the newsletter — if you aren’t already, consider becoming a paid subscriber. 1500+ engineers and managers have joined already! Learn more about the benefits of the paid plan here.

2) 🍻 Read with your friends — Refactoring lives thanks to word of mouth. Share the article with your with someone who would like it, and get a free membership through the new referral program.

I wish you a great week! ☀️

Luca