DEV Community: Gary Lu

The Hidden Truth: Quality Issues Are Often Just Quantity Problems

Gary Lu — Fri, 14 Jun 2024 09:46:55 +0000

As a software engineer with nine years of experience, I've had the privilege of working with some truly exceptional developers. These colleagues have mastered the art of coding and consistently deliver high-quality software. However, I've also seen many others remain average and unremarkable. This disparity intrigued me, and I set out to understand the underlying reason.

A Simple Concept

After observing and analyzing my experiences, I discovered that the key difference often boiled down to a very simple concept: quantity. More specifically, the amount of practice, iterations, and exposure these experts had compared to their average counterparts. It wasn’t necessarily about innate talent or intelligence; it was about the sheer volume of work they put in.

Quantity: The Key to Quality

What we often think of as quality problems are actually quantity problems. It's usually just a matter of not having enough, sometimes by several orders of magnitude. Let me explain with a few examples:

Iteration and Improvement: In my early years, I was part of an Android application development team. I noticed that the best developer in our team, who later became one of my best friends and mentors, constantly iterated on his work. The Android ecosystem is continually evolving, and every time Google introduced new features, he would enthusiastically go through all of them and pick a few to apply in our application. He never settled for the first solution; instead, he would write, test, refactor, and improve his code multiple times, always incorporating the latest technology. It was this relentless cycle of iteration that honed his skills and led to higher quality outcomes.As a result, he grew faster than any other engineer I knew and eventually joined VIVO, one of China’s largest smartphone brand.
Exposure to Challenges: The more projects and diverse problems a developer tackled, the better they became. Those who sought out additional projects, participated in hackathons, or contributed to open-source projects accumulated a wealth of experience. This varied exposure enabled them to approach problems from multiple angles and devise more effective solutions.
Feedback and Learning: Developers who actively sought feedback and learned from their mistakes improved rapidly. In contrast, those who did the bare minimum and avoided critique stagnated. Regular code reviews, pair programming sessions, and mentorship were invaluable in accelerating their growth.

Misconception: Quantity vs. Quality

The biggest misconception is thinking a quantity problem is a quality problem. This leads to the false hope that we can achieve our goals with clever tricks or cutting corners instead of increasing quantity.That's when pseudoscience, superstition, and unnecessary complaints start to appear. Many think that producing a large volume of work means sacrificing quality. However, my experience has shown that the opposite is often true.

When I started picking up my English, I noticed Ruri Ohama, a successful English learner on YouTube. In her video "How I learned English by myself for free without studying" Ruri describes how she mastered English through consistent practice and exposure. She watched English movies, listened to music, and engaged in conversations with native speakers. This relentless practice and immersion significantly improved her fluency and the quality of her language skills. Ruri’s experience shows that the more you immerse yourself in an activity, the better you become at it.

Another example is my favorite author, Keigo Higashino. Known for his captivating mystery novels, Higashino writes every day. This disciplined approach has produced a prolific body of high-quality work. His consistent writing practice allows him to explore new ideas and refine his storytelling techniques. Higashino’s daily writing habit demonstrates that the more you practice, the better you get, and the higher the quality of your output.

Conclusion

Quantity is the key to quality. Most quality issues boil down to not having enough of something on a smaller scale. Understanding that can really change the way we approach learning anything. Instead of getting frustrated or anxious when you don’t meet your goals right away, remember that it often just takes more practice. Think about how Ruri Ohama improved her English by immersing herself in it every day, or how Keigo Higashino writes daily to hone his craft.

So, next time you feel like giving up, just remember that sometimes, it’s simply a matter of putting in more reps. Keep at it, and the quality will come.

Why I Choose WebStorm Over VSCode

Gary Lu — Thu, 13 Jun 2024 10:08:07 +0000

As a front-end developer with four years of experience, I've often found myself as the odd one out in my team for my choice of IDE. While the majority of my colleagues surf the waves of Visual Studio Code (VSCode), I remain steadfastly committed to WebStorm. This decision is not a matter of stubbornness or resistance to change but is rooted in a decade-long journey of software development that has shaped my preferences and workflows.

A Decade with JetBrains IDEs

My journey with JetBrains products began long before I delved into front-end development. From 2015 to 2021, I utilized Android Studio for developing Android applications. In the realm of Android development, it remains the top choice even today, and my preference was established during that period.
Over the next two years, I ventured into backend and frontend development. For Java programming, IntelliJ IDEA was my first and unquestionable choice. However, in the frontend arena, while most of my colleagues use VSCode, my experiences have instilled in me a profound appreciation for the interaction design and feature set of JetBrains IDEs.
As a result, I use WebStorm for developing frontend projects.
Here are the key reasons why I continue to choose WebStorm over VSCode:

1. Seamless Transition from IDEA Products

Having spent six years immersed in the JetBrains ecosystem, switching to WebStorm was a natural progression. The familiarity with the interface, shortcuts, and overall design significantly reduced the learning curve. The muscle memory and workflow efficiency I've developed over the years transferred seamlessly to WebStorm, allowing me to focus on coding rather than relearning an IDE.

2. Robust Out-of-the-Box Features

One of the standout features of WebStorm is its comprehensive set of tools and features available right out of the box. Unlike VSCode, which relies heavily on extensions to achieve similar functionality, WebStorm provides a robust environment that includes:

Advanced JavaScript and TypeScript support
Comprehensive code refactoring tools
Built-in debugging and testing tools
Seamless integration with version control systems
Excellent support for modern frameworks like React, Angular, and Vue.js

These features significantly enhance productivity and reduce the need to hunt for and manage multiple extensions.

3. Superior Code Analysis and Refactoring

WebStorm excels in code analysis and refactoring capabilities. The IDE provides intelligent code completion, on-the-fly error detection, and powerful refactoring tools that are a cut above what VSCode offers through its extensions. This level of code insight is invaluable for maintaining high code quality and accelerating development.

4. Integrated Development Tools

WebStorm's integration with build tools, task runners, and package managers is seamless. Whether it's Webpack, Gulp, npm, or Yarn, WebStorm handles these integrations with ease. The built-in terminal, database tools, and REST client further consolidate the development environment, making it a one-stop shop for all development needs.

5. Consistent Updates and Support

JetBrains is known for its regular updates and excellent support. WebStorm receives frequent updates that bring new features, improvements, and bug fixes. The active community and responsive support team ensure that any issues are quickly addressed, providing a stable and reliable development environment.

Conclusion

While VSCode is undeniably a powerful and popular IDE, my preference for WebStorm is deeply rooted in my extensive experience with JetBrains products. The seamless transition, robust out-of-the-box features, superior code analysis, integrated development tools, and consistent updates make WebStorm the ideal choice for my development needs.

That said, I remain open to using VSCode if the need arises. For now, WebStorm satisfies all my work requirements and aligns perfectly with my workflow, giving me no compelling reason to switch. By sticking with WebStorm, I can leverage a decade's worth of familiarity and efficiency, enabling me to focus on what I do best—writing high-quality code.

Why Have You Chosen to Use a Message Queue?

Gary Lu — Mon, 29 Jan 2024 06:20:40 +0000

Sometimes during an interview, the interviewer might notice on your resume that you have experience using a message queue like Kafka, and then ask you why you chose to use a message queue. Before you answer this question, you should understand that what the interviewer really wants to know is your company's business scenario, the technological challenges you faced, how you addressed those challenges, and why you chose the solutions you did. After you provide the project background, you can then delve into the technology. There are three key points for using a message queue:

Decoupling
Asynchronous processing
Peak shaving

Decoupling

Consider this scenario: System A sends a message to Systems B, C, and D using an API interface. What happens if System E also needs this message? Conversely, what if System C no longer requires the message? In this situation, the developer of System A may become overwhelmed.

In this scenario, System A is tightly coupled with the other systems. However, if we use a message queue (MQ), System A can produce a message and send it to the MQ, completing its task. Regardless of which system needs the message, they can retrieve it from the MQ. If a system no longer requires the message, it can simply unsubscribe from it. None of these actions require System A's direct involvement.

Asynchronous Processing

In this scenario, when a user initiates a request from the frontend page, it takes 100ms in System A, 200ms in System B, 250ms in System C, and 300ms in System D. Consequently, the total processing time for this request is nearly 900ms, resulting in a poor user experience.

Ideally, every operation initiated by the user should be handled within 200ms to ensure a seamless experience.

By using a message queue (MQ), System A can receive the user request, process it in 100ms, and then send the result to the MQ, allowing Systems B, C, and D to handle the message asynchronously (within the bounds of business requirements). This approach reduces the overall processing time to just 100ms, transforming the user experience from awful to awesome.

Peak Shaving

Every day from 12 AM to 12 PM, System A operates peacefully, with a query-per-second (QPS) rate of 50. However, at 12 PM, the QPS suddenly spikes to 5000 or more. This surge in requests places significant stress on the database queries.

When using MySQL, a single MySQL architecture can handle 2000+ queries per second, which represents its upper limit. A QPS of 5000+ would cause the system to break down. However, after the peak, the QPS returns to a lower rate, around 50+ QPS.

In this scenario, if we use a message queue (MQ), during the peak time of 5000 requests per second, the system can handle 2000 requests per second, leaving 3000 requests to be stored in the MQ. Over the course of an hour, the MQ would store millions of messages, preventing the system from breaking down during peak times. After this period, System A would process the remaining messages until all have been handled.

Conclusion

While message queue (MQ) offers several advantages as discussed above, it introduces complexities and potential new issues. Apart from the mentioned benefits, its implementation can reduce system availability. Once integrated into your system, MQ becomes a core component, necessitating measures to ensure its stability and prevent breakdowns.

Another challenge that may arise is the issue of consistency. Due to the decoupling and asynchronous nature of systems, it's possible for some components, such as Systems A and C, to process successfully while others, like Systems B and D, encounter failures. In such cases, a compensation mechanism may be necessary to address this situation, although the specific approach will depend on the nature of your project.

Ultimately, as with any technology, there are both positive and negative aspects to consider when implementing a message queue.