#4 The Effective Engineer & Software Quality
How to leverage your efforts to make a meaningful impact & What is software quality anyway?
This week, I share with you some notes on two different resources: the first is a YouTube talk about the Mindset of Effective Engineers, and the second is an article about Code Quality.
Good reading!
The Effective Engineer
Edmond Lou decided to conduct a survey in which he interviewed engineers, managers, and leaders from various Silicon Valley companies, such as Google, Facebook, Dropbox, Instagram, and others, to understand some questions like:
What sets the most efficient engineers you've worked with apart from others?
What is the most valuable learning you've had in the last year?
What activities have great potential for leveraging engineers?
The result of this survey is the publication of the book "The Effective Engineer: How to Leverage Your Efforts in Software Engineering to Make a Disproportionate and Meaningful Impact." In the "Effective Engineer" talk, Edmond presents five topics from the book that can help us grow as professionals and change the culture of the company we are in.
Here are some ideas from his talk:
Optimize Your Learning
The learning process is compared to compound interest in financial investments. What you learn today will prepare you for other opportunities and further learning you may have in the future. Invest in what you will learn early on!
Invest in delivery speed
How quickly can you make things happen? Engineers should focus on understanding and even developing tools that aid in development processes, building, monitoring, ease of debugging, etc., instead of trying to build/use the latest technology.
Validate your ideas quickly and constantly.
Not only how to get things done quickly but how to get the right things done quickly.
Minimize operational burden
Have you ever found yourself in a situation where all effort and time are spent operationalizing the product instead of building new features? If we work daily on actions to minimize the operational burden, we will be able to focus on actions that will actually make an impact.
Software Quality
Developer Productivity for Humans, Part 7: Software Quality is a short and interesting read on the topic of code quality, presenting quality attributes in four different pillars: process, code, system, and product quality. Authors Collin Green and Ciera Jaspan conducted a literature review and interviews at Google to consolidate ideas on the subject.
The following text consists of direct quotes from the original article, highlighting some points that caught my attention and that may motivate you to read the full original content:
Software quality means different things to different people:
To the vice president concerned about their business, high software quality means having a product that people want to use, pay for, and recommend to others.
To the developer, high software quality means the code is maintainable and easy to work with.
To operations, high software quality means a site that is reliable, fault-tolerant, and resilient to security threats.
If these three people enter into a conversation about “how will we increase software quality” they’re likely to find disagreement in how they approach the problem and measure success.
Based on these interviews and reading the prior literature on software quality, we’ve created a “theory of quality” that posits that there are four types of quality that influence each other.
Our theory is that when an organization has higher process quality, it does lead to higher code quality.
Interviews defined code quality as primarily relating to maintainability, and they viewed testability, comprehensibility, complexity, and readability as subcategories of maintainability.
Maintainability is important because, as one developer put it, “Code is written once and read many many times—everyone within the system has to understand and be able to make changes to it.”
System quality is where we shift from “quality as the developers see it” to “quality as the business sees it.
Executives and product managers, they’re more interested in product quality.
Most discussions between these groups at Google result in a focused discussion about system quality.
The impact of code quality on reliability and fewer defects was more tenuous.
Outages are (and should be!) a very rare event. This means that if a team had only two small outages in a year, and then they had no outages in the next year, we can’t really tell for certain whether system quality improved.
If stakeholders interpret a low defect rate as a guarantee of high-quality code, they may encourage a more exclusive focus on launching features to improve product quality without allocating sufficient resources to improve a potentially high-risk system.
We do theorize that there’s a connection between these—that process quality affects code quality, which affects system quality, which affects product quality.
Do you have reading references on these subjects? Feel free to share in the comments!
I would also like to thank all the subscribers for supporting this initiative, and I hope it's as helpful to you as it is to me.
See you next week!