ReactJS

REACT NEWS : Update in Redux-Observable, GraphQL, Mobile Centre, TC39, Webpack, React Fiber, and More

Published Oct 28, 2019

Updated Feb 14, 2023

6 min read

This article was written over 18 months ago and may contain information that is out of date. Some content may be relevant but please refer to the relevant official documentation or available resources for the latest information.

Developers such as Samer Buna, Parashuram N, Neehar Venugopal, Cameron Westland, and Jay Phelps recently discussed with our team new developments in JavaScript.

The videos featured will give you an idea of what’s been going on with GraphQL, Redux-Observable, React Fiber, the TC39 Import Proposal, and an introduction to the new term “Extensible React”.

GraphQL and ReactJS

Samer Buna on The Value of GraphQL, GraphQL Subscriptions, ReactJS

Samer Buna speaks about GraphQL and gives us an idea about how great it is to work with the query language and how perfectly matched it is for React. The language describes exact data requirements very clearly and optimizes the process of data communication between front-end applications and the server. Overall, it a better language and replacement for than the REST API.

Samer also introduces GraphQL subscriptions which offer real-time communication, Samer also talks about emerging applications which allow for the retrieval of immediate graphical API from the cloud. If an individual is looking to cloud host their data, there are now applications that can be used to define models and get the immediate graphical API required. This development removes entry barriers to beginner developers as they no longer have to write complete server applications to use GraphQL for their front-end applications, instead, they can simply generate an API in the cloud.

React proves itself to be a great framework to work with as it is both specialized and flexible. Unlike Angular or Ember, it doesn’t have ready-made design decisions or offer complete solutions that may limit developers from experimentation.

Samer recommends that once developers become confident with the ins and outs of React, that next steps should be to explore Node. He reasons that because React’s ecosystem and a lot of the new tools are node-based, React developers can gain a lot of power in knowledge by understanding the tools within the community.

{% youtube Oio0dfSvIYs %}

Mobile Centre, Browser Performance, and Tools for React Fiber from Microsoft

Parashuram N describes working on Mobile Centre, browser performance, and tools for React Fiber at Microsoft

At Microsoft, Parashuram N works on a number of projects as the program manager. One example includes the Visual Studio Code (VS Code) extension made for React, which allows authors to debug applications right from their VS Code. Experiments are being done to open up the possibility of testing reactive applications on the cloud.

Mobile Centre is another project that came from Microsoft. It is a system that runs alongside VS Code so individuals can choose whether they want to use one over the other or combine the two. Mobile Centre lets developers pick the Github repositories they want to work with, these are then signed, built, tested on the cloud, and distributed to end users.

Being a web developer comes with a many perks, one of which is having the ability to bring about change to users immediately. There is no lag in the process to present alterations or new features, and JavaScript fatigue is usually not an issue. Individuals who deploy code, are able to continuously do so without setbacks. Development practices and technologies such as LiveReload, Hot Module Replacement, and Browser Sync also make web creation easier to manage. All of these benefits are unique to the web development world, and are reasons why React fits so well with the web.

Although apps are really native and web-specific, moving into react native in the mobile development space is fairly easy to do. Reason being, ideas can be deployed instantly to customers using things like Code Push, and a number of tools such as the time travel debugging feature in ChakraCore are made available to help with the process.

Many performance-related projects have also emerged, such as browser-perf which enables automation of web performance or monitoring systems; and tv monster application which tracks the performance of React.js library. The app automatically collects performance data for all frameworks and all versions of react. It runs on Chrome and a number of mobile browsers. What makes these tests different from React’s existing performance tests, is that they are from a browser’s perspective, as opposed to JavaScript specific.

Parashuram also discusses the philosophy at Microsoft, RxJS, and building dev tools for Redux Observable on VS Code.

{% youtube pq38dSL7ZVk %}

The TC39 Import Proposal and Webpack 2

TC39 Import Proposal, Webpack 2, and the React Community in the East with Neehar Venugopal

In current times, Neehar’s primary focus as a software engineer is to provide a solution to developers that would help make building apps more efficient. He is one of the authors behind the import-proposal, which helps authors ship less code and emphasize the important ones to optimize performance (especially in mobile).

Import proposal is available in Webpack 2 and is in stage 3 proposal of TC39, meaning it hasn’t made an appearance in browsers. However, individuals do agree that it works so it will be implemented very shortly.

The commencement of import-proposal was inspired by talks about mobile for CSS and mobile for UI/UX. Seeing as mobile for javascript was yet to be discussed, but mobile app speed and performance needed to be improved, the topic finally began to surface. The question of “how can I send just the minimum amount of javascript required to show user what’s on the screen” emerged. Dynamic import was also introduced so lazy loading and code splitting could happen in webpack.

Neehar also talks about the React community in the East. Although far away, developers in this area still feel very much included in the community due to the great involvement of all developers, diversity, and communication between team members. Something that could be improved however in the West, however, is greater focus in performance. Unlike VueJS, React is not as widely adopted because of the performance issues.

{% youtube wEnIKjgmP2Y %}

Extensible React

Cameron Westland presents “Extensible React”

Cameron Westland is a software architect at Autodesk, currently working on a new web version that runs on React. The term “Extensible React” is introduced and can be defined as “a declarative approach to creating pluggable web apps”.

Extensibility is often used in applications. However, when it comes to building applications that are extensible there isn’t much conversation. Cameron and his team at Autodesk strive to spark greater discussion on this topic by giving answers to questions like “If an individual has a toolbar and wants to add an icon to the toolbar using an extension, how would he/she go about doing so if the application is built in React?”. One example of a solution includes the email client known as Annihilus. It is built in React, offers extensions, and allows individuals to add custom parts to their nightless email client.

One of the greatest things about React, is the effect it has on the ecosystem beyond its own community. For instance, before React, a lot of UI frameworks were holistic. They followed conventions and weren’t component-oriented. After React, a number of frameworks began adapting and rewriting their applications to be more similar to React. This ripple effect will surely be seen with the new changes in React Fiber. In addition to this, the React community is also one that is open-minded and encouraging. There is no one person who decides what React is going to be or should be. It has a strong team dynamic, and a lot of the ideas developed by framework authors are driven by the community.

{% youtube UdPx-OVEn28 %}

Redux-Observable and React Fiber

Jay Phelps on Redux-Observable, React Fiber, and ReactJS

The React community is described to be one of the most open communities out there when it comes to accepting new ideas. It brought about radical rethinking and was even assumed to be an antipattern at the time. React was able to rethink how things were done and create new best practices. These new norms have since been shared and adopted by other frameworks like Angular and Ember.

Jay discusses a few open source projects that are taking the lead in the React ecosystem. These include redux-observable, React Fiber, and Jest.

Jay shares the vision of redux-observable, or RxJs, is a middleware for composing or canceling async side effects using Epic as co-author of this library. Jay and Ben Lesh were inspired by other ideas in the community such as redux-thunk and redux-saga.

Jay shares his perspective on React Fiber and how developers can look forward to the ability to prioritize certain elements, such as inputs or animations, in their rendering.

Jest is a unit testing framework creates snapshots or code for a simple testing system. This is an example of a project, like React, that was originally not accepted but has scince been reinvented and is now successful. Today, Jest is emulated in other testing frameworks because it’s been so helpful.

{% youtube _BQL_TGvhqg %}

Don’t miss your chance to be more involved with the community by contributing! You can find the React library here.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

7 Tips to be a Successful Developer in a Remote Company

When the pandemic hit in March of 2020, most companies were forced to go remote and millions of workers had to learn how to work from home. Two years later, a lot people now prefer the work from home option, and many job seekers are looking for remote-only companies to work for. For software developers, there are many advantages to working from home and still effectively working as a team to produce high quality results. But how can you be successful in a remote company? In this article, I will provide 7 tips on what it takes to be a successful developer in a remote company. Communication is key It is now more important than ever to communicate effectively with your team. Now that everyone is working from home instead of being in one physical office, you have to be very conscious to reach out to teammates and share your progress on a project. In a physical office, you are surrounded by other co-workers all day, which makes it easier to walk over to someone's office and share what you have been working on. It also makes it easier to have impromptu meetings with other team members throughout the day. But in a remote setting, it is very easy to become isolated and get carried away with work without reaching out to anyone all day. This becomes an issue for your team, because now they are no longer keeping up to date on the latest changes you have been contributing to the project. My tip would be to post periodic updates throughout the day of what you have been working on. If your company is using something like Slack or another chat server, make sure to post a detailed update on what you have been up to the past few hours. Here is an example of one of the status updates I would post to my team. Status update: - finished making changes to xyz case study and put it up for review - reviewed a couple of PRs - ran accessibility audits for the homepage and working on increasing the performance score I would usually post this in the middle of the day to update the team on what I have been working on. I also try to ask questions throughout the day to ensure that I don't get blocked on a particular issue for to long. This method of communication helps me stay connected with the team and helps my manager know where I am at in the project. Find a separate space in your home just for work When you are working in an office, there is a clear separation between work and home. This makes it easier to end your day and leave your work at the office. But with remote work, sometimes these lines between work and home become a little bit blurry. This is why it is important to designate a separate work space in your home. In my situation, I have a small desk in another room where I do all of my work. That space is only used Monday through Friday for work purposes. I have found that by creating a work space, it allows me to be in the moment and fully concentrate on my duties. Then at the end of the day, I logout out of everything and leave the work space just like I would leave a physical business. That has given me freedom to relax in my home when I am not working and fully recharge for the next day. I understand that everyone's living situation is different, and you might not have room for a designated work area. In those cases, do the best you can to carve out some space in your living situation just for work. The more you can do to separate home and business, the more productive you will be at work. Set consistent work hours When you are working in an office, you have set hours for when you are going to be there. It might be 9-5 or 8-3 with breaks throughout the day. But when you are working from home, it is very easy to work without a set schedule and put in more time outside of the standard work hours. This can quickly lead to burnout which is a huge issue within the developer community. It is really important to set a consistent work schedule so your team knows when you are available, and when you are off work. This also forces you to work within a time frame which will lead to better focus, time management and productivity. I have personally found that setting that time frame from 8-5 with breaks helps me structure my day better and get more done than if I had an open schedule. Take breaks throughout the day Developer health is another huge issue within the community. Many developers, including myself have gone for hours hunched over their computers trying to get something to work. In these situations, it is very easy to lose track of time and develop back, neck, shoulder, and eye problems. One of the key advantages of working from home is being able to take breaks and leave your work space. Take ten minute breaks throughout the day and make sure to walk around, stretch, go outside, and drink water. Taking breaks from the computer will give your body and brain a chance to rest and recharge. When I first started working remotely, I would be glued to the computer for hours at a time. But I quickly felt the negative health effects and started becoming more intentional about taking breaks. Now, I have developed a healthier work situation and can see the difference in the quality of work I am producing. Dress appropriately for important meetings We all enjoy the relaxed dress code that often accompanies working from home. In an office, you will typically be in a more work appropriate attire especially when it comes to meetings with clients. But when you are at home, it is very easy to work in some sweatpants and a t shirt. If you don't have any meetings that day, then coding in your casual attire is fine. But if you are meeting with clients or interviewing remotely, it is important to dress appropriately. Remember that it is still a business and you want to be as professional as possible, even in a remote setting. Avoid mixing personal tasks and work tasks When you are in an office, you don't worry about personal chores like doing laundry or taking the trash out. But when you are working from home, it is very easy to get distracted and mix personal tasks with work tasks. It is very important that while you are working, you are focused on work. Then during breaks, you can take care of personal items. In my situation, I make sure to finish up the task I was working on and then take a break to put a load of laundry on or take care of another personal chore. There are definitely times where something has come up and I will make sure to communicate that with the team so they know I will be unavailable for a certain amount of time. But just try to do the best that you can separating personal tasks and issues from your work tasks. Time management and structuring your day In order to work productively, it is important to plan out your day as best you can and structure your time accordingly. For example, as I am writing this blog today, I made sure to set aside time for writing the first draft, revising it and submitting it for review. During that time block, I am not focused on other PR's or other work responsibilities. That ensures I am focused 100% on writing a high quality article. Once I complete a large task, then I make sure to take a break, hydrate, walk around and eat something. That allows me to energize and gear up for the next task in my day. I found that breaking up my day into manageable tasks has provided me the opportunity to focus and produce good work. Conclusion Those are my 7 tips on what it takes to be a successful developer in a remote company. I encourage you to give each of those tips a try and see how it affects your work productivity....

May 16, 2022

7 mins

General

International Women's Day Recap

International Women's Day Event For this year's International Women's Day, we hosted a live event with Women Techmakers, featuring talks and a panel discussion on this year's topic: progress over perfection. It was a great conversation on what it's like to be a woman in tech, and how you can help yourself and others thrive in our industry. In case you missed it We have the full event on YouTube if you'd like to watch it yourself (which I highly recommend)! Here's a recap of everything that happened. Getting started in DevRel - Pachi Parra Pachi Parra was up first, sharing her journey into DevRel, and tips on how you can get started too! Some highlights include: - Roles that are available - What a day in the life might look like - Her journey into DevRel - What a DevRel professional actually does - things like public speaking, live coding, writing blogs, and giving talks at conferences. Her best tip for getting started? Find the type of content you like doing, and focus on doing that well! In DevRel, it's easy to spread yourself too thin between all the different types of content available, so focus on the one you like most, find a supportive community, and get yourself out there. :) Breathing Fire: Success and Growth as a Technical Woman - Stacy Devino Stacy Devino was up next, providing all kinds of insight into the cycle women go through in their career, as well as tips for each stage of the journey. She opened with an amazing quote: > Assume all women are technical and capable of breathing fire. - Jessie Frazelle Other highlights: - Igniting your world through learning, timing, your network, and leadership. - Staying warm by managing your focus and chores, recording your achievements, maintaining relationships, and researching ideas. - The key to avoiding burnout - keeping a long-term perspective, doing things for yourself, and allocating time for the things you enjoy and the people who support you. Riding the imposter wave to senior - Jessica Janiuk Jessica Janiuk wrapped up our talks today, providing insight into her journey through tech and the ways we can think about imposter syndrome and allowing ourselves to grow. Some highlights from her talk: - A few things to consider: what being "senior" means to companies and to yourself, if you're in the right place, and what you want in your career. - A great diagram of the imposter wave - the balance between our confidence and feeling like an imposter from this post by Ricardo Luevanos. - Considering how often we're comfortable, and that there's an inverse correlation between feeling comfortable and feeling like an imposter (they're opposite each other). - We have two choices: we can let it control us, or use that discomfort as a tool. - Looking back on our growth and realizing that our current lows are higher than our past highs. - Some senior advice: Be authentic, be proud of your work, have good mentors, remember that your work is not your life, and stay uncomfortable. She wrapped up with a brilliant reminder for us all: > You are capable. You are valid. You are important. Please take care of yourself. People care about you. If you're struggling, you're not alone. Panel Discussion We rounded out the day with a panel discussion featuring these accomplished women: - Erica Stanley - Amal Hussein - Deborah Kurata - Katerina Skroumpelou - Jessica Janiuk - Stacy Devino - Jae Bach Hardie - Linda Thompson The conversation flowed naturally, each panelist feeding off of each other's ideas, and we covered some very powerful and helpful tips and reminders for women in today's developer world. Here's a few of my favorite topics or ideas we talked about: What did you learn in the past year? - Have hobbies that don't involve tech. - Learning to let go of your previous tools. - How valuable close personal friends are - people you can trust and rely on. - Listen to yourself, and take time to introspect and evaluate. - Don't over commit! Finding a community and actively contributing to it - Women Techmakers! (Our joint sponsor) - Make use of social media. - "Reach one teach one" - always be willing to share your knowledge, and be the person you needed when you were getting started. - Engage people who align with your goals and values - reach outside your level of age, career scope, experience. - The interconnection between you and your people is not exclusive, it's inclusive! The more expansive your sphere is, the better you are at your job. - Also - we can find community in open source! The way people comment, commit, and support each other within a project counts too. Foundational knowledge vs tooling - Understand what problems you're actually solving and what to reach for, more than worrying about the specific tech stack itself. - This helps you build your own knowledge map, and pick up skills as you grow. - For more senior folks - realize when you've mastered something, and focus on clearing the road for those who come next. - Learning to delegate - if you always do something yourself, you're taking that opportunity away from someone else. - Knowing when to ask for help, and that asking is NOT a weakness or failure! It's a strength to know when you need to ask for help. Find your learning method - Ask multiple people if you need to until you find the answer that clicks for you! Ask why. - Not understanding the answer someone gives you is also not a failure - it's different viewpoints. - Also learn how the people around you learn - so you can help them in the way that best suits them. Communication and collaboration - Have compassion for everyone on your team. - When you collaborate, you get more done. - Being able to communicate and collaborate is a HUGE strength. Don't let anyone make you feel bad for being strong in those! - Being the person who's able to "glue" the team together is foundational to a strong team. Fighting stereotypes - Things that are commended in men and reprimanded in women, and fighting against those biases - Being authentic is the best way to lead your team - don't play into a stereotype you don't fit. - You don't have to sound "nice" or "pleasing" - you're still a strong woman and you're going to be judged a certain way, so don't compromise! - Unpacking all the social conditioning and learning to be comfortable with yourself all the time, in all the situations we find ourselves in. Wrapping Up The entire event was filled with wisdom, laughter, and camaraderie. We're so thankful to the ladies who came to speak with us, and hope to see you at the next one!...

Mar 10, 2022

5 mins

GeneralEvents

“Music and code have a lot in common,” freeCodeCamp’s Jessica Wilkins on what the tech community is doing right to onboard new software engineers

Before she was a software developer at freeCodeCamp, Jessica Wilkins was a classically trained clarinetist performing across the country. Her days were filled with rehearsals, concerts, and teaching, and she hadn’t considered a tech career until the world changed in 2020. > “When the pandemic hit, most of my gigs were canceled,” she says. “I suddenly had time on my hands and an idea for a site I wanted to build.” That site, a tribute to Black musicians in classical and jazz music, turned into much more than a personal project. It opened the door to a whole new career where her creative instincts and curiosity could thrive just as much as they had in music. Now at freeCodeCamp, Jessica maintains and develops the very JavaScript curriculum that has helped her and millions of developers around the world. We spoke with Jessica about her advice for JavaScript learners, why musicians make great developers, and how inclusive communities are helping more women thrive in tech. Jessica’s Top 3 JavaScript Skill Picks for 2025 If you ask Jessica what it takes to succeed as a JavaScript developer in 2025, she won’t point you straight to the newest library or trend. Instead, she lists three skills that sound simple, but take real time to build: > “Learning how to ask questions and research when you get stuck. Learning how to read error messages. And having a strong foundation in the fundamentals” She says those skills don’t come from shortcuts or shiny tools. They come from building. > “Start with small projects and keep building,” she says. “Books like You Don’t Know JS help you understand the theory, but experience comes from writing and shipping code. You learn a lot by doing.” And don’t forget the people around you. > “Meetups and conferences are amazing,” she adds. “You’ll pick up things faster, get feedback, and make friends who are learning alongside you.” Why So Many Musicians End Up in Tech A musical past like Jessica’s isn’t unheard of in the JavaScript industry. In fact, she’s noticed a surprising number of musicians making the leap into software. > “I think it’s because music and code have a lot in common,” she says. “They both require creativity, pattern recognition, problem-solving… and you can really get into flow when you’re deep in either one.” That crossover between artistry and logic feels like home to people who’ve lived in both worlds. What the Tech Community Is Getting Right Jessica has seen both the challenges and the wins when it comes to supporting women in tech. > “There’s still a lot of toxicity in some corners,” she says. “But the communities that are doing it right—like Women Who Code, Women in Tech, and Virtual Coffee—create safe, supportive spaces to grow and share experiences.” She believes those spaces aren’t just helpful, but they’re essential. > “Having a network makes a huge difference, especially early in your career.” What’s Next for Jessica Wilkins? With a catalog of published articles, open-source projects under her belt, and a growing audience of devs following her journey, Jessica is just getting started. She’s still writing. Still mentoring. Still building. And still proving that creativity doesn’t stop at the orchestra pit—it just finds a new stage. Follow Jessica Wilkins on X and Linkedin to keep up with her work in tech, her musical roots, and whatever she’s building next. Sticker illustration by Jacob Ashley....

Apr 25, 2025

3 mins

JavaScriptSoftware Engineering

The Importance of a Scientific Mindset in Software Engineering: Part 2 (Debugging)

The Importance of a Scientific Mindset in Software Engineering: Part 2 (Debugging) In the first part of my series on the importance of a scientific mindset in software engineering, we explored how the principles of the scientific method can help us evaluate sources and make informed decisions. Now, we will focus on how these principles can help us tackle one of the most crucial and challenging tasks in software engineering: debugging. In software engineering, debugging is often viewed as an art - an intuitive skill honed through experience and trial and error. In a way, it is - the same as a GP, even a very evidence-based one, will likely diagnose most of their patients based on their experience and intuition and not research scientific literature every time; a software engineer will often rely on their experience and intuition to identify and fix common bugs. However, an internist faced with a complex case will likely not be able to rely on their intuition alone and must apply the scientific method to diagnose the patient. Similarly, a software engineer can benefit from using the scientific method to identify and fix the problem when faced with a complex bug. From that perspective, treating engineering challenges like scientific inquiries can transform the way we tackle problems. Rather than resorting to guesswork or gut feelings, we can apply the principles of the scientific method—forming hypotheses, designing controlled experiments, gathering and evaluating evidence—to identify and eliminate bugs systematically. This approach, sometimes referred to as "scientific debugging," reframes debugging from a haphazard process into a structured, disciplined practice. It encourages us to be skeptical, methodical, and transparent in our reasoning. For instance, as Andreas Zeller notes in the book _Why Programs Fail_, the key aspect of scientific debugging is its explicitness: Using the scientific method, you make your assumptions and reasoning explicit, allowing you to understand your assumptions and often reveals hidden clues that can lead to the root cause of the problem on hand. Note: If you'd like to read an excerpt from the book, you can find it on Embedded.com. Scientific Debugging At its core, scientific debugging applies the principles of the scientific method to the process of finding and fixing software defects. Rather than attempting random fixes or relying on intuition, it encourages engineers to move systematically, guided by data, hypotheses, and controlled experimentation. By adopting debugging as a rigorous inquiry, we can reduce guesswork, speed up the resolution process, and ensure that our fixes are based on solid evidence. Just as a scientist begins with a well-defined research question, a software engineer starts by identifying the specific symptom or error condition. For instance, if our users report inconsistencies in the data they see across different parts of the application, our research question could be: _"Under what conditions does the application display outdated or incorrect user data?"_ From there, we can follow a structured debugging process that mirrors the scientific method: - 1. Observe and Define the Problem: First, we need to clearly state the bug's symptoms and the environment in which it occurs. We should isolate whether the issue is deterministic or intermittent and identify any known triggers if possible. Such a structured definition serves as the groundwork for further investigation. - 2. Formulate a Hypothesis: A hypothesis in debugging is a testable explanation for the observed behavior. For instance, you might hypothesize: _"The data inconsistency occurs because a caching layer is serving stale data when certain user profiles are updated."_ The key is that this explanation must be falsifiable; if experiments don't support the hypothesis, it must be refined or discarded. - 3. Collect Evidence and Data: Evidence often includes logs, system metrics, error messages, and runtime traces. Similar to reviewing primary sources in academic research, treat your raw debugging data as crucial evidence. Evaluating these data points can reveal patterns. In our example, such patterns could be whether the bug correlates with specific caching mechanisms, increased memory usage, or database query latency. During this step, it's essential to approach data critically, just as you would analyze the quality and credibility of sources in a research literature review. Don't forget that even logs can be misleading, incomplete, or even incorrect, so cross-referencing multiple sources is key. - 4. Design and Run Experiments: Design minimal, controlled tests to confirm or refute your hypothesis. In our example, you may try disabling or shortening the cache's time-to-live (TTL) to see if more recent data is displayed correctly. By manipulating one variable at a time - such as cache invalidation intervals - you gain clearer insights into causation. Tools such as profilers, debuggers, or specialized test harnesses can help isolate factors and gather precise measurements. - 5. Analyze Results and Refine Hypotheses: If the experiment's outcome doesn't align with your hypothesis, treat it as a stepping stone, not a dead end. Adjust your explanation, form a new hypothesis, or consider additional variables (for example, whether certain API calls bypass caching). Each iteration should bring you closer to a better understanding of the bug's root cause. Remember, the goal is not to prove an initial guess right but to arrive at a verifiable explanation. - 6. Implement and Verify the Fix: Once you're confident in the identified cause, you can implement the fix. Verification doesn't stop at deployment - re-test under the same conditions and, if possible, beyond them. By confirming the fix in a controlled manner, you ensure that the solution is backed by evidence rather than wishful thinking. - Personally, I consider implementing end-to-end tests (e.g., with Playwright) that reproduce the bug and verify the fix to be a crucial part of this step. This both ensures that the bug doesn't reappear in the future due to changes in the codebase and avoids possible imprecisions of manual testing. Now, we can explore these steps in more detail, highlighting how the scientific method can guide us through the debugging process. Establishing Clear Debugging Questions (Formulating a Hypothesis) A hypothesis is a proposed explanation for a phenomenon that can be tested through experimentation. In a debugging context, that phenomenon is the bug or issue you're trying to resolve. Having a clear, falsifiable statement that you can prove or disprove ensures that you stay focused on the real problem rather than jumping haphazardly between possible causes. A properly formulated hypothesis lets you design precise experiments to evaluate whether your explanation holds true. To formulate a hypothesis effectively, you can follow these steps: 1. Clearly Identify the Symptom(s) Before forming any hypothesis, pin down the specific issue users are experiencing. For instance: - "Users intermittently see outdated profile information after updating their accounts." - "Some newly created user profiles don't reflect changes in certain parts of the application." Having a well-defined problem statement keeps your hypothesis focused on the actual issue. Just like a research question in science, the clarity of your symptom definition directly influences the quality of your hypothesis. 2. Draft a Tentative Explanation Next, convert your symptom into a statement that describes a _possible root cause_, such as: - "Data inconsistency occurs because the caching layer isn't invalidating or refreshing user data properly when profiles are updated." - "Stale data is displayed because the cache timeout is too long under certain load conditions." This step makes your assumption about the root cause explicit. As with the scientific method, your hypothesis should be something you can test and either confirm or refute with data or experimentation. 3. Ensure Falsifiability A valid hypothesis must be falsifiable - meaning it can be proven _wrong_. You'll struggle to design meaningful experiments if a hypothesis is too vague or broad. For example: - Not Falsifiable: "Occasionally, the application just shows weird data." - Falsifiable: "Users see stale data when the cache is not invalidated within 30 seconds of profile updates." Making your hypothesis specific enough to fail a test will pave the way for more precise debugging. 4. Align with Available Evidence Match your hypothesis to what you already know - logs, stack traces, metrics, and user reports. For example: - If logs reveal that cache invalidation events aren't firing, form a hypothesis explaining why those events fail or never occur. - If metrics show that data served from the cache is older than the configured TTL, hypothesize about how or why the TTL is being ignored. If your current explanation contradicts existing data, refine your hypothesis until it fits. 5. Plan for Controlled Tests Once you have a testable hypothesis, figure out how you'll attempt to _disprove_ it. This might involve: - Reproducing the environment: Set up a staging/local system that closely mimics production. For instance with the same cache layer configurations. - Varying one condition at a time: For example, only adjust cache invalidation policies or TTLs and then observe how data freshness changes. - Monitoring metrics: In our example, such monitoring would involve tracking user profile updates, cache hits/misses, and response times. These metrics should lead to confirming or rejecting your explanation. These plans become your blueprint for experiments in further debugging stages. Collecting and Evaluating Evidence After formulating a clear, testable hypothesis, the next crucial step is to gather data that can either support or refute it. This mirrors how scientists collect observations in a literature review or initial experiments. 1. Identify "Primary Sources" (Logs, Stack Traces, Code History): - Logs and Stack Traces: These are your direct pieces of evidence - treat them like raw experimental data. For instance, look closely at timestamps, caching-related events (e.g., invalidation triggers), and any error messages related to stale reads. - Code History: Look for related changes in your source control, e.g. using Git bisect. In our example, we would look for changes to caching mechanisms or references to cache libraries in commits, which could pinpoint when the inconsistency was introduced. Sometimes, reverting a commit that altered cache settings helps confirm whether the bug originated there. 2. Corroborate with "Secondary Sources" (Documentation, Q&A Forums): - Documentation: Check official docs for known behavior or configuration details that might differ from your assumptions. - Community Knowledge: Similar issues reported on GitHub or StackOverflow may reveal known pitfalls in a library you're using. 3. Assess Data Quality and Relevance: - Look for Patterns: For instance, does stale data appear only after certain update frequencies or at specific times of day? - Check Environmental Factors: For instance, does the bug happen only with particular deployment setups, container configurations, or memory constraints? - Watch Out for Biases: Avoid seeking only the data that confirms your hypothesis. Look for contradictory logs or metrics that might point to other root causes. You keep your hypothesis grounded in real-world system behavior by treating logs, stack traces, and code history as primary data - akin to raw experimental results. This evidence-first approach reduces guesswork and guides more precise experiments. Designing and Running Experiments With a hypothesis in hand and evidence gathered, it's time to test it through controlled experiments - much like scientists isolate variables to verify or debunk an explanation. 1. Set Up a Reproducible Environment: - Testing Environments: Replicate production conditions as closely as possible. In our example, that would involve ensuring the same caching configuration, library versions, and relevant data sets are in place. - Version Control Branches: Use a dedicated branch to experiment with different settings or configuration, e.g., cache invalidation strategies. This streamlines reverting changes if needed. 2. Control Variables One at a Time: - For instance, if you suspect data inconsistency is tied to cache invalidation events, first adjust only the invalidation timeout and re-test. - Or, if concurrency could be a factor (e.g., multiple requests updating user data simultaneously), test different concurrency levels to see if stale data issues become more pronounced. 3. Measure and Record Outcomes: - Automated Tests: Tests provide a great way to formalize and verify your assumptions. For instance, you could develop tests that intentionally update user profiles and check if the displayed data matches the latest state. - Monitoring Tools: Monitor relevant metrics before, during, and after each experiment. In our example, we might want to track cache hit rates, TTL durations, and query times. - Repeat Trials: Consistency across multiple runs boosts confidence in your findings. 4. Validate Against a Baseline: - If baseline tests manifest normal behavior, but your experimental changes manifest the bug, you've isolated the variable causing the issue. E.g. if the baseline tests show that data is consistently fresh under normal caching conditions but your experimental changes cause stale data. - Conversely, if your change eliminates the buggy behavior, it supports your hypothesis - e.g. that the cache configuration was the root cause. Each experiment outcome is a data point supporting or contradicting your hypothesis. Over time, these data points guide you toward the true cause. Analyzing Results and Iterating In scientific debugging, an unexpected result isn't a failure - it's valuable feedback that brings you closer to the right explanation. 1. Compare Outcomes to the hypothesis. For instance: - Did user data stay consistent after you reduced the cache TTL or fixed invalidation logic? - Did logs show caching events firing as expected, or did they reveal unexpected errors? - Are there only partial improvements that suggest multiple overlapping issues? 2. Incorporate Unexpected Observations: - Sometimes, debugging uncovers side effects - e.g. performance bottlenecks exposed by more frequent cache invalidations. Note these for future work. - If your hypothesis is disproven, revise it. For example, the cache may only be part of the problem, and a separate load balancer setting also needs attention. 3. Avoid Confirmation Bias: - Don't dismiss contrary data. For instance, if you see evidence that updates are fresh in some modules but stale in others, you may have found a more nuanced root cause (e.g., partial cache invalidation). - Consider other credible explanations if your teammates propose them. Test those with the same rigor. 4. Decide If You Need More Data: - If results aren't conclusive, add deeper instrumentation or enable debug modes to capture more detailed logs. - For production-only issues, implement distributed tracing or sampling logs to diagnose real-world usage patterns. 5. Document Each Iteration: - Record the results of each experiment, including any unexpected findings or new hypotheses that arise. - Through iterative experimentation and analysis, each cycle refines your understanding. By letting evidence shape your hypothesis, you ensure that your final conclusion aligns with reality. Implementing and Verifying the Fix Once you've identified the likely culprit - say, a misconfigured or missing cache invalidation policy - the next step is to implement a fix and verify its resilience. 1. Implementing the Change: - Scoped Changes: Adjust just the component pinpointed in your experiments. Avoid large-scale refactoring that might introduce other issues. - Code Reviews: Peer reviews can catch overlooked logic gaps or confirm that your changes align with best practices. 2. Regression Testing: - Re-run the same experiments that initially exposed the issue. In our stale data example, confirm that the data remains fresh under various conditions. - Conduct broader tests - like integration or end-to-end tests - to ensure no new bugs are introduced. 3. Monitoring in Production: - Even with positive test results, real-world scenarios can differ. Monitor logs and metrics (e.g. cache hit rates, user error reports) closely post-deployment. - If the buggy behavior reappears, revisit your hypothesis or consider additional factors, such as unpredicted user behavior. 4. Benchmarking and Performance Checks (If Relevant): - When making changes that affect the frequency of certain processes - such as how often a cache is refreshed - be sure to measure the performance impact. Verify you meet any latency or resource usage requirements. - Keep an eye on the trade-offs: For instance, more frequent cache invalidations might solve stale data but could also raise system load. By systematically verifying your fix - similar to confirming experimental results in research - you ensure that you've addressed the true cause and maintained overall software stability. Documenting the Debugging Process Good science relies on transparency, and so does effective debugging. Thorough documentation guarantees your findings are reproducible and valuable to future team members. 1. Record Your Hypothesis and Experiments: - Keep a concise log of your main hypothesis, the tests you performed, and the outcomes. - A simple markdown file within the repo can capture critical insights without being cumbersome. 2. Highlight Key Evidence and Observations: - Note the logs or metrics that were most instrumental - e.g., seeing repeated stale cache hits 10 minutes after updates. - Document any edge cases discovered along the way. 3. List Follow-Up Actions or Potential Risks: - If you discover additional issues - like memory spikes from more frequent invalidation - note them for future sprints. - Identify parts of the code that might need deeper testing or refactoring to prevent similar issues. 4. Share with Your Team: - Publish your debugging report on an internal wiki or ticket system. A well-documented troubleshooting narrative helps educate other developers. - Encouraging open discussion of the debugging process fosters a culture of continuous learning and collaboration. By paralleling scientific publication practices in your documentation, you establish a knowledge base to guide future debugging efforts and accelerate collective problem-solving. Conclusion Debugging can be as much a rigorous, methodical exercise as an art shaped by intuition and experience. By adopting the principles of scientific inquiry - forming hypotheses, designing controlled experiments, gathering evidence, and transparently documenting your process - you make your debugging approach both systematic and repeatable. The explicitness and structure of scientific debugging offer several benefits: - Better Root-Cause Discovery: Structured, hypothesis-driven debugging sheds light on the _true_ underlying factors causing defects rather than simply masking symptoms. - Informed Decisions: Data and evidence lead the way, minimizing guesswork and reducing the chance of reintroducing similar issues. - Knowledge Sharing: As in scientific research, detailed documentation of methods and outcomes helps others learn from your process and fosters a collaborative culture. Ultimately, whether you are diagnosing an intermittent crash or chasing elusive performance bottlenecks, scientific debugging brings clarity and objectivity to your workflow. By aligning your debugging practices with the scientific method, you build confidence in your solutions and empower your team to tackle complex software challenges with precision and reliability. But most importantly, do not get discouraged by the number of rigorous steps outlined above or by the fact you won't always manage to follow them all religiously. Debugging is a complex and often frustrating process, and it's okay to rely on your intuition and experience when needed. Feel free to adapt the debugging process to your needs and constraints, and as long as you keep the scientific mindset at heart, you'll be on the right track....

May 9, 2025

13 mins

JavaScript

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.