Panel Discussion: Code Quality

This ad is not shown to multipass and full ticket holders
JSNation US
JSNation US 2025
November 17 - 20, 2025
New York, US & Online
See JS stars in the US biggest planetarium
Learn More
In partnership with Focus Reactive
Upcoming event
JSNation US 2025
JSNation US 2025
November 17 - 20, 2025. New York, US & Online
Learn more
Bookmark
Rate this content

FAQ

Quality code is characterized by its functionality, ease of readability, and maintainability. This means the code works not only on a developer's local machine but also for its intended users. It should be easy for all team members, including new ones, to understand, contribute to, and refactor without fear of breaking the system.

Testability is a significant indicator of code quality. Code that is easy to test tends to be well-organized and clear. High testability allows for easier maintenance and debugging, ensuring that each component functions correctly both individually and within the system.

A style guide ensures consistency in coding practices across a development team, which is crucial for maintaining code quality. Consistent code is easier to read, understand, and maintain, regardless of the team size. It also helps avoid issues in code reviews and reduces the cognitive load when developers switch between different parts of the codebase.

Integrating quality considerations throughout the development process helps prevent technical debt and ensures the software is built to standards from the start. It reduces the need for extensive refactoring and leads to more stable and reliable software, improving user satisfaction and reducing maintenance costs.

Pull requests are crucial for maintaining code quality as they allow for peer review before changes are merged into the main codebase. This process helps identify potential issues, ensures code adheres to established standards, and encourages knowledge sharing among team members.

Developers new to coding should start by learning to write and understand unit tests, as this practice introduces them to the basics of software testing and its impact on code quality. Engaging in code reviews and examining how experienced developers handle testing and refactoring can also provide valuable insights.

John Papa
John Papa
Angie Jones
Angie Jones
Jason Palmer
Jason Palmer
Anna Backs
Anna Backs
39 min
10 Jun, 2021

Comments

Sign in or register to post your comment.
Video Summary and Transcription
Discussion on quality in JavaScript projects with insights from John Papa, Angie Jones, and Jason Palmer. Insights on identifying and measuring quality in code development, emphasizing testability and clean coding principles to maintain high-quality code. Recommendations for evaluating code quality through the 'seven D's,' emphasizing design, development, documentation, testing under adverse conditions, demos, deployment, and review processes. Emphasizing the importance of understanding the user for each test to avoid testing the implementation. Highlighting the importance of creating separate pull requests for distinct features to ease the review process. Emphasizing the importance of full CI, CD, and staging server testing for confident production deployment. Addressing challenges when switching to a company with anti-quality culture. Highlighting the importance of demonstrating quality through practical experiences. Discussing the balance between quality and business goals, especially in startup environments. Discussing the importance of automated rules for code consistency and structural integrity. Incorporate refactors into feature development, avoid viewing code quality as a separate task. Advocate for sustainable pace in development, prioritize quality and thorough testing efforts to ensure reliable software deployment.

1. Discussion on Quality in JavaScript Projects

Short description:

Discussion on quality in JavaScript projects with insights from John Papa, Angie Jones, and Jason Palmer.

Thanks for having me. I'm Anna, and joining me here are three awesome people to discuss quality. We have John Papa, who is a professional web and mobile developer and currently works as a developer advocate for Microsoft. He's also very active in the open source community and is also active on the podcast Real Talk JavaScript. We also have Angie Jones with us, who is a principal developer advocate at ApliTools and specializes in test automation strategies and techniques. She is also a very creative inventor and volunteers with Black Girls Code. Last, but not least, we have Jason Palmer here with us, who is a Jest core contributor and the creator and maintainer of JestJUnit. He is also an engineer and technical product manager at Spotify, where he focuses on infrastructure, CI, CD and test automation. Matthew already said we're going to talk about quality. Quality is indeed a topic that is discussed a lot, and where many people have many different opinions. But I would like to start and talk about what quality actually is. What are aspects of quality that we should consider? And I'd like to make a round, and let's maybe start with Jason.

Jason, what do you think quality actually is when it comes to JavaScript projects? I think that there's a lot of different ways to look at it. But at the end of the day, if people outside of your team can easily contribute to your software, and you're confident that it's not going to break, and if you're able to continuously deploy to production, so you make a commit to the main branch, and that's able to go directly to production, and you're confident about that, you know you've done a good job. So that's at least when you know you've developed something of high quality. Yes, if you can leave the office Friday afternoon, just push to prod shortly before and then leave for the weekend, that's definitely a good feeling you can do that.

Angie, what do you think? Yeah, I definitely agree with that. I think the key here is, one, that it works. That's very obvious. But that it works for your users, right, not your own local machine and only the various happiest of paths. But, you know, it works for your users, and a key part of what Jason said is that the team members are able to contribute to that. So that means we're able to read it, we're able to refactor if needed. No one is scared to touch certain modules, and that's when you know you're in bad shape, when it's like, oh, I don't want to touch that. So those are the characteristics I feel of quality code. Yes, definitely. If just everybody, even new team members, can just participate in it.

2. Insights on Code Quality and Testability

Short description:

Insights on identifying and measuring quality in code development, emphasizing testability and clean coding principles to maintain high-quality code.

John, what's your take on quality? First, I think that the characteristics, that's the key word, I think Angie just mentioned. This is one of those topics where it's hard to describe code quality, but you know it when you see it, and you absolutely know it when it's not there. So it's easy to spot those kind of things, but it all comes down to what Jason and Angie said is more about, does it work? Does it meet the business needs? And I look at the long term viability of a project as being a big sign of code quality. If the project lives for the term it's supposed to live, for example, once it goes live, we all know there's issues and maintenance and things to work on, which is where we get to the contributions that we all talked about here. That's got to be something that keeps the project moving. The sign for me of really bad code quality is when people start talking about, wow, we just deployed this thing, we have an update. It's too hard to update it. Let's just redo it from scratch. And that happens far too often in the business world out there. And I want to say that it's really evident without even looking at the code when it's of poor quality. And I think we all can attest to situations where we've used some product as an end user and you just know that what's underneath here is not of quality. You can see it even from the outside. Yeah, definitely. You can easily spot bad code, but is there also a way to spot or measure good quality code? You're nodding. Feel free to just elaborate on that. Yeah, there's lots of, you know, clean coding principles and things like that, that are out there that kind of gives us all some direction on how we should go about developing good quality code, you know? As far as like, you know, things are not too big, or too long, or too abstract. You know, there are these certain principles that I followed throughout my career and that's typically led to good quality code. Other ways I think is, how testable is your code? Right? And I feel like that's one that's glossed over quite a bit, but it gives so much insight when you think about your coding from that angle. Whether you practice TDD, which is test driven development, or if you test your code after you've written it, that's fine too. That is legal. But how testable your code is, is a really good indicator I've found in how well it's written. Yes. 100% I've met this experience as well. I agree 100% on testability. And spam calls. So, I agree 100% on testability there. One thing I really like about Sign for Code Quality is when things become testable, I hear a lot of folks say I can't write code that's testable. And I do a lot of coaching sessions with them and a lot of times we'll ask, why? Like, why isn't it testable? What it really comes down to quite often is the code is, as you mentioned Angie, too long. What's too long? I think that's subjective. But when your code is doing multiple things, when a function, for example, is doing seven things and you've got tons of comments explaining what all the ifs and thens and switches and for loops are doing, that's a great sign for maybe these things should be separate because then I can test each individual thing on its own instead of wondering where in this long journey did something go wrong.

3. Seven D's of Code Quality Evaluation

Short description:

Recommendations for evaluating code quality through the 'seven D's,' emphasizing design, development, documentation, testing under adverse conditions, demos, deployment, and review processes.

The other thing I look for in code quality and I recommend to folks is I because I like Disney I came up with a thing called the seven D's and none of them stand for Disney. But Disney, we do these weird things. But I used to work there and the seven D's I think of code quality and these seven areas. You've got to design your application and you must handle that well. You must develop it well with code quality and styling and your guidelines. But you also must have a documentation of some kind in your company for that. I also another D in there is Destroy. Can you destroy it? Can you test it? You know, make sure that your code works under the bad conditions, not just the happy path.

There's also going to be a demo. How many of us write some kind of a test harness to make sure the thing works in a separate app somewhere. Why not include that as part of your repo so people can do an end to end test on that feature or integration as well? And then you also get down to things like deployment. Can you deploy your code out to production? So the final one is I couldn't come up with a good D's for review. So I called it Dereview because I'm Italian. So Dereview. You got to do Dereview because you got to make sure you can appear review from other people. If I write code, Angie and Jason have to review it, not me, not the person who writes it.

It's a great point, I think the way that I look at quality is how are you kind of constructing the automation that goes into every code change? So giving some really good thought around how much do I want to test before code is merged into the main branch, how many things am I okay testing while it's in production? The form of monitoring to understand how my users are interacting with the system, how it's performing out there in production. So I think basically having like a conscious thought around this and planning ahead for what would make the most sense for you and your team and what kind of velocity you want to have makes a whole lot of sense. So that's a sign of quality in my view.

4. Learning Path for Code Quality Beginners

Short description:

Recommendation for beginners: Start by learning how to write unit tests early to understand testing impact and code development. Emphasize the importance of testing and reviewing others' code to enhance testing skills and quality mindset.

Okay, and say I'm a person who just started coding. What do you think is a good way to learn about quality and to get into this whole topic? Where should I start? I think it's probably pretty easy to learn how to write unit tests right away. That's usually something, you know, soon after you're getting a hang of writing code and getting something working. You know, it's not too much of a stretch to take it a little bit further and be able to write that first unit test. And I think that that's a great first thing that you can do just to get a feel for what testing is like and how much of an impact it can have on your code as you develop it.

Yeah, unfortunately, testing is one of those things that isn't typically taught when we're learning a code, whether that be traditional university pass, whether it be bootcamp self-taught, whatever. It's one of those kind of side notes, if you even get it at all. So it's very much still a kind of on the job thing that you learn. I strongly recommend people review other folks' code, as John mentioned. So for code reviews, don't just look at the feature, look at the unit tests that were checked in as well, and this kind of gives you some insight into how other people are approaching their testing.

Challenge yourself then as well. Did they miss a case? Can you think of anything else that's, you know, not so far out there that we don't want to bother with including it, but, you know, something that would be a value that was missed in the unit test. So this kind of gets you into the thought process. You step away from construction mode and you're more thinking about for lack of a better word, what John said, destroying. But no, you think about like how to exercise this code and what are other various scenarios that are, you know, legal scenarios that your code should definitely cover. And in that you start thinking more in this kind of quality mindset and then you can leap into what Jason said and start, you know, contributing unit tests, maybe for that other feature or some of your own as well.

5. Testing Value and Style Guide Importance

Short description:

Highlighting the importance of testing value and the significance of a style guide for code quality maintenance. Emphasizing the need for understanding what to test and the benefits of comprehensive test coverage to prevent costly bugs.

I'll give a, I agree testing is really, really important and I don't want to diminish it by what I'm about to say, but I want to give a little devil's advocate to testing. I think one of the reasons testing is difficult today and not in the past because we have great tooling now, uh, for a while, that was a problem years ago and now we've got great tooling. Is when we test, we all teach when people do teach or they teach how to test, but we don't always teach what to test and that becomes a problem because yes, I can write a test that does something, but is there value in that test and that's the real thing that this panel will we have not nearly enough time to get into, but that is far more important than the how. Because you can have a hundred percent test coverage. And anytime when somebody tells me that usually I'm looking at them going, what are you actually testing? Cause that's like, how far did you go? Cause the most important things are probably, you know, the business features and whatnot.

I'll have one different aspect as well, which is a style guide. And obviously I'm biased because I like creating these things, but it doesn't matter who writes it or what it says. Very bluntly. Doesn't matter what it says, as long as your team follows it, a big piece of code quality is when you have three people or you've got 3000 people on your dev teams, having a style guide that you can enforce through some kind of linting rules and whatnot, is critically important for so many reasons and. Consistent code is far easier to maintain. As we talked in the beginning, then let's say Jason makes a pull request and he changed one line of code, but he has three spaces instead of two inside of his code files, which would be crazy, right? But if he does something like that, all of a sudden I've got 8,000 files and a pull request that I have to review and I'm not doing it. So things like this, I'm exaggerating on, but it really is important to have a style guide that your team can follow. And again, the rules are not as important as consistency.

No, that's really good. The style guide part, yes, the linters and all of that, but more specifically the part about what are you testing? I find people really miss this. Again, I don't really fault them much because it's not something that we teach very well. Shameless plug. I have a free university that's dedicated to testing. It's called Test Automation University. It's online, all the courses are free, so you can take courses there to learn this stuff better, but I can't tell you how many times, and that's why I stressed to not just review the features and code reviews, but also review the test. I can't tell you how many times I've seen unit tests. I'm going to give an example, let's say it's testing some API request, and the assertion is literally, make sure the response is not no. That's not really testing what we should be testing. Having just something come back is not the same as having the right thing come back, for example. Really get some thought into the coverage that you're adding because these tests, the tests are really there to save you. There's multiple benefits to having tests. But the biggest one, in my opinion, is the fast feedback and to save you from really ugly, nasty, costly bugs that we can catch. We can catch this before it goes to prod, if we test this appropriately. These are all really important points. One thing I just wanted to add to this was, a test should always represent a user, in my opinion.

QnA

User-Centric Testing and Pull Request Reviews

Short description:

Emphasizing the importance of understanding the user for each test to avoid testing the implementation. Discussion on the significance of thorough pull request reviews, including steps, time investment, and workflow, highlighting the need for running tests and aligning the implementation with business requirements.

I think it's important to understand and think about what user am I testing for? A much lower-level test, a unit test, or integration test, the user you probably have in mind in this case would be another development team, so you may be writing a test against an API, or against a function call, or a class, or something like this, and keeping in mind that the user in this situation is another development team that might be interacting with this function, interacting with this class, and what have you. And then, an end-to-end test could be an actual user out there, interacting with your web app, with your back-end service, whatever it is that you're developing, but I think it's important to keep in mind what your user, who your user is for each test that you're writing, and I think doing that, you're going to do a much better job avoiding testing the implementation, which is sort of what we call like a white box test, or a gray box test, and generally speaking, that's something you should try to avoid.

Yes, definitely. We've already talked a little bit about reviews, and we actually have a question for that. Borlock asks, how do you feel about pull request reviews? What are your steps? How much time do you put in? What's the work flow? I think we all probably have opinions on how to do reviews, and I don't think there's a lot of wrong ways. There's a lot of right ways to do it for sure. One of the things that's a wrong way is to look at the code in GitHub, not run it, not pull it locally, not make sure it works, and just go, oh yeah, I trust Jason. Jason does good work, and merge. A big thing for reviews I like to do, I have multiple processes, on some teams, I go to GitHub, and I open up the review process right there.

That's really good, because a lot of people get caught there, right? You're basically becoming the human linter, and you're checking for things that the linter has already checked for, and you like, ah, looks good to me, you know, very minor, minor suggestions. But no, just like you said, run those stuff. I said this to a colleague one time, and their mind was blown, like they literally never thought, oh, maybe I should actually run it, right? Another thing I love to do is to pull the issue, right? Pull the issue and see what the requirement actually was, and determine if this implementation meets that requirement. Because it could be implemented, you know, great, all the code is beautiful, code quality, yes, but it doesn't meet the business need that was requested.

Effective Code Review Practices

Short description:

Emphasizing the importance of running tests to ensure the implementation meets business requirements. Highlighting the need for readability and inheritability of code for effective code review processes and the significance of aligning code changes with business goals.

Yeah, that is so important. That's really good, because a lot of people get caught there, right? You're basically becoming the human linter, and you're checking for things that the linter has already checked for, and you like, ah, looks good to me, you know, very minor, minor suggestions. But no, just like you said, run those stuff. I said this to a colleague one time, and their mind was blown, like they literally never thought, oh, maybe I should actually run it, right? Another thing I love to do is to pull the issue, right? Pull the issue and see what the requirement actually was, and determine if this implementation meets that requirement. Because it could be implemented, you know, great, all the code is beautiful, code quality, yes, but it doesn't meet the business need that was requested.

So that's where I usually start. I run it. Again, I look at tests, make sure we have, you know, some good coverage there. And I also take a step back and think about, okay, if this person won the lottery tonight, and I had to inherit this, what does that mean for me? Meaning, is it readable? You know, would I be able to take this over if I had to? And if not, let me call out the issues that would prevent me from doing that.

That's a very good point. I think that that's really, really good. I agree with everything that's been said so far. I mean, especially what you said, Angie, around, you know, does this meet the business goals? I think I'm imagining a slightly hypothetical situation, you know? So, let's assume that your code already has really good test automation and linting, and you're very confident with anybody being able to make contributions. Sort of at that point, what is left for you to review, right? And so, I think everything that's meant or that's been said here is perfect. I don't really have much to add there. Something I'd like to just pull onto this, because I, Angie, you made me think of it while you were talking, was pull requests and commits.

Effective Pull Request Practices

Short description:

Highlighting the importance of creating separate pull requests for distinct features to ease the review process. Emphasizing the need for consistency in code quality definitions and tool usage to maintain high standards and reduce errors. Stressing the significance of comprehensive deployment testing beyond end-to-end tests for production confidence and the necessity of having contingency plans for unexpected outcomes.

I think we're all making a few assumptions here because we live in the worlds we live in. Sometimes I see pull requests where people do, I'll make an analogy to the political system of many countries. A bill, for example, in the United States goes out for, we're going to paint all the streets purple, just picking something weird. That's the bill. And that's the feature that Angie's talking about in this case, that's what the code's supposed to do. But then I sneak in, well, let's add this button. And Jason sneaks in, well, let's add this thing. All these little things get snuck into the bill or the code in this case. It makes a pull request really difficult to review because you can't really separate all these features.

Think about the person looking at the code. They are now looking at the feature like Angie said, and said, all right, that's what it's supposed to do, but why is all this other stuff happening? It causes a lot of friction and swirl. So it's much better to create separate pull requests and separate issues. I know it's more process, but it's a lot easier for somebody else to look at, and you have a lot fewer errors.

Kevin asked, you talked about deploying. Do you think end-to-end testing is primordial to be confident of your deployment? No. What was it? What is it required? Primordial is the word that was used. I think it's helpful. End-to-end testing, I love it. I think it's very helpful, but it is, I wouldn't be confident if I did end-to-end test if it worked, that it would still deploy to production properly. Even then, I think all of us have shipped something to production where with all of that something didn't go right. Always, always, always have a backup plan, always have one.

Ensuring Code Quality Consistency

Short description:

Emphasizing the importance of full CI, CD, and staging server testing for confident production deployment. Advocating for consistency in defining code quality to eliminate subjective opinions. Highlighting the necessity of tools like SonarQube for metrics generation and the rule of never doing harm to maintain code quality.

I think it's very helpful, but it is, I wouldn't be confident if I did end-to-end test if it worked, that it would still deploy to production properly. I'd still want full CI, CD and I'd want to see it on a staging server with as much like the environment and staging as it is in production, including SSL and certificates and environment variables and everything else too. As close as you can get there. Even then, I think all of us have shipped something to production where with all of that something didn't go right. Always, always, always have a backup plan, always have one.

Gene asked, do you recommend tools like Zona to measure the quality or to help with spotting good and bad code? I think to what some of the other panelists said earlier, as long as you're consistent with what your definition of good code is and what your winting setup is and things like that, I think that that's what matters. In my view, there isn't any one tool that is going to be absolutely perfect for defining code quality, but consistency is really crucial here. Yeah. And I think more than anything, it gives a framework for the team to have a discussion on, you know, what does good quality code mean for us? What are the rules here? That we all agree to. And that way, you remove a lot of this back and forth and opinionated comments from code reviews, right? You kind of get all of that out the way so that we can focus on what truly matters.

I agree 100% and you're right, the tools don't really matter and the consistency does. One thing I like about SonarQube in general is that company I've worked at, it creates metrics, right? And the metrics don't really mean anything. It's just a number. But the rule we had at that company, as part of the consistency was never do any harm. So every time you put new code in, whatever that metric is, that number, it should never go lower. As your code gets in, it should always either stay where it is or go higher. So you can't just go in there and destroy the application because, oh yeah, you know, I feel like that today. That sounds like a very good rule to have.

Overcoming Resistance to Quality Investments

Short description:

Addressing challenges when switching to a company with anti-quality culture. Advocating for demonstrating the impact of focusing on tech debt, tests, and automation to leadership. Emphasizing the need to provide clear metrics and incentives to drive change and overcome common resistance to quality investments.

That sounds like a very good rule to have. We've talked a lot about how to get into quality now. But say I switch companies, I took a new job and the company is kind of anti-quality. It doesn't see the value of quality, or as Johan asked, the other team members don't see the added value of having quality code. How would you handle this situation? How would you convince your team and your boss that quality is something you should invest time in? I think, if I could start, I mean, I would start and try to lead by example, of course. I mean, you know, that's always going to be an impactful personal thing that you can do and hopefully others see the results in what you do.

Kind of like a bigger, longer-term answer to this is something that I've been working on recently. And I think it is important for teams to do their best to basically be able to tell leadership what kind of an impact they're going to have by focusing time on tackling tech debt, on writing tests, on writing more automation. If you can tell a greater story around that, for instance, being able to say, you know, I think that we can speed up our development process by 20% if we invest in a CICD pipeline, right. These are conversations that you can have that have a very clear impact and the business responds to impact. So those are the two things I would recommend really trying to do. That's, that's it right there.

Business or just not in the, our companies are not in the business of just doing things because, oh, this is the right thing to do as much as we want them to. They just, listen, it just doesn't work. Okay, so you have to, you have to provide like this is the benefits. Like, we'll be able to move faster, you know, this will increase or decrease X by Y, but you have to give these, these metrics and these incentives to get any change done I've found. And unfortunately, this is very common where, you know, people are, we don't have time for this, we, you know, we don't know how it's a million different excuses. I've been doing this long enough that I can advise folks on like I see the train coming. Like I'm like, okay, you continue down this path. This is what's going to happen next. And, you know, I try to give a lot of warnings and as they start seeing those things happen, then people start, okay, maybe she knows what she's talking about and try to adjust. But unfortunately, lots of times it had to be some kind of catastrophe, like some money lost or something like that. That gets people to buy in. So, everybody out there who's thinking about this, these are fantastic points and we can tell people these stories. We're storytellers. That's what we do, presentations. We've had these experiences. But somewhere in your life, somebody told you something and you completely just ignored it. We've all done this.

Balancing Quality and Business Goals

Short description:

Highlighting the value of experiential learning and its impact. Emphasizing the significance of demonstrating quality through practical experiences. Discussing the balance between quality and business goals, especially in startup environments.

We've all done this. When I was a kid, my grandmother told me not to put my hand on the hot stove. I got mad and said, yeah, whatever, it's not that hot. What happens, I put my hand on the hot stove and had a nice big burn on my hand as a little kid. You don't do it again after that. My point is, you can tell somebody something 20 times. But until you actually experience it, you don't really get it. Those are the real experiences that drive us.

What I do with companies, a lot of times, last company I worked with on this was they had hundreds of apps in production, and instead of trying to really work it into everything right away, what we did is we picked a small mission-critical project, which had smaller scope. We did this with full code quality, all the things that we're talking about here. Then it went live. It was the first app that that company had put live in many years that had no bugs after it went live. They had no 24-hour maintenance for the weeks and weeks and weeks afterwards.

Showing that scorecard to the executives was like, OK, maybe you implemented a few less features because you did more quality, but nothing broke. And the customer experience was great. That experience, by them touching that hot stove and knowing all the other past experiences, was far more valuable than me standing there saying, I told you so. Yes, experiencing the pain is often the best teacher. Do you think there are situations where quality doesn't matter? Like, my experience is that often, especially in the startup scene, quality gets completely thrown out the window in the beginning to just push the product and make money. Do you think that's a viable way to go? Or are there other situations where you think it's OK to just say, tests not needed? Quality doesn't matter? I think it always matters. But it's a degree. There's always a sliding scale of how much you need to do. And the ultimate thing for all of us to have jobs is business. The business goals and values. And the companies have to make money.

Quality Considerations in Development

Short description:

Discussing the importance of quality considerations in balancing project constraints. Highlighting the common scenario of prototypes becoming live products. Addressing audience questions on software structural sustainability and consistency in development practices.

That said, there's a, you know, you aim for the most quality you can get. And then you start figuring out what's the reality of the time, the budget, the resources, and everything else we have. We can do things to mitigate this. Like I mentioned before, nothing we can do is become better communicators with our business stakeholders. So we can if we can really talk about the value of the quality, and why we need scope creep not to happen and keep the scope where it is, so it's not a moving target. These things help. But in the end, yes, there are things that always slip, because this is a business world. You just have to very carefully weigh. If this slips, these are the things that you might be risking.

I agree with that. I think that the only other situation I can think of where quality or testing isn't like the most important thing would be if I'm developing a prototype I intend to throw away. Although, careful with that, because I've personally been in so many situations where that prototype never got thrown away. So be aware that that's a pretty common pattern. You got some prototypes that are live out there, Jason? Hundreds. We have one more question from the audience. Niels says, I love the distinction between functional quality and structural quality. Of course, it must do what the user needs, but is it sustainable under the hood? Any thoughts on that? I think that's a tough one to answer for me, but I'll try to break the ice and talk a little bit. I think everyone has a different thought around how you should structure your software.

In my view, and maybe I'm happy to be wrong, and for folks to disagree with me, I haven't seen any clear advantages from one pattern to another, for the most part. I think the thing that's important is that you're consistent, like we've talked about so far. As long as you have identified what pattern you and your team prefer using, and how you're constructing the software, take the extra time to build in some automation so that people outside of your team or new joiners to the team can understand how to contribute to that pattern and that you don't need a manual review each time. In my view, that's the most important thing, apart from any other pattern that there is. I don't subscribe to anyone in particular. I think a big key is a friend of mine, Brian Holt, had a good saying, and I won't mess up his exact saying, but it's basically, if you can't automate it, it's not worth it.

Automated Rules and Refactoring Integration

Short description:

Discussing the importance of automated rules for code consistency and structural integrity. Addressing the integration of refactoring into development processes and the challenges of dedicated refactoring cycles. Emphasizing the need to incorporate code quality practices seamlessly into feature development to avoid separate quality tasks.

So, if you come up with a rule, and I'll make up a silly one, like curly bracket cuddling. A good friend of mine years ago saying, should the curly bracket be in the same line as the if or the next line? And I'm like, I don't care. Just pick and make a rule and automate it, and we'll all do it, you know? And this was about 10 years ago when linters really weren't that great. But that's the kind of thing where if you can automate your rules, it's much better and much easier to have these kind of guidelines and consistency and keep your structural integrity.

Pedro asked, should we incorporate refactors into our current stories or create technical chores for those kind of more extensive refactors? I mean we already talked a bit about pull requests becoming like just a puddle of all sorts of stuff that's being made. What are your thoughts on this question? In my experience, you don't really get the cycles dedicated to refactoring something. Like you have to squeeze it in where you can. Like that doesn't mean you get some muddy, like, you know, features. With a whole bunch of refactoring. But I like to tackle it as it's needed.

Yes, I totally agree. I think, to build on that, even as you're asked to implement new features or launch things by the business, do your best to basically incorporate these refactors into your changes as you go along. So ideally, an iterative refactor is the way to go. Well, we only have a few minutes left. Are there any last pieces of advice, any last words of wisdom that you want to share with the audience? I want to say, oh, I'm sorry. No, go ahead, Angie. Okay. I just wanted to say that, folks, you really need to get out of the habit of thinking of code quality as this separate task. And this should be something that you're taking with you as you develop your features.

Quality Practices and Sustainable Development

Short description:

Incorporate refactors into feature development, avoid viewing code quality as a separate task. Emphasize upfront process creation and communication with teammates for quality assurance. Advocate for sustainable pace in development, prioritize quality and thorough testing efforts to ensure reliable software deployment.

I think, to build on that, even as you're asked to implement new features or launch things by the business, do your best to basically incorporate these refactors into your changes as you go along. So ideally, an iterative refactor is the way to go. Well, we only have a few minutes left. Are there any last pieces of advice, any last words of wisdom that you want to share with the audience? I want to say, oh, I'm sorry. No, go ahead, Angie. Okay. I just wanted to say that, folks, you really need to get out of the habit of thinking of code quality as this separate task. And this should be something that you're taking with you as you develop your features. It breaks my heart when people say things like, oh, we don't have time or the client doesn't want to pay for testing and stuff like that. When you go and buy a car, you didn't ask anything about, okay, do I need to pay extra for the test to see if it works? You expect this to be included with it, right? Same goes for our software. People are not looking for a separate line item that says make sure the thing I'm paying you for actually works. This needs to be in our minds and exercised with everything that we do in development.

Yeah, I'd say my final thought is not only is it good to create a style guide, but to create your process upfront. Before you start a project with a team, this doesn't take hours. This is a very short meeting usually of, what is our process going to be when we create features? How do we decide on the features? And are we going to have testing and CI, CD and setting those things up takes a while? Yes. But the decisions to do those in the beginning of a project are really important. So everybody's on the same page and can really avoid later, somebody like me saying, Jason, why didn't you do X? Well, we never discussed that, blah, blah, blah. That's the kind of thing where you communicate with your teammates right up front and it's just a lot easier and it really helps quality.

My view will be controversial, but what I would say is double your estimates and look up agile sustainable pace for when you're going to talk to leadership, because this is basically the practice of moving at a sustainable pace instead of moving in sprints and fits like we usually do in the software development field. Take the time to write software that's of quality that you're proud of and that you're confident that it works. It's important and these are some ways that you can maybe try to sneak that in. And then you can deploy with the security on a Friday afternoon and leave in the weekend. Thank you so much Jason, Angie, John. It was delightful to talk to you about quality. And that's the end of this panel. All right. Thank you. Bye bye. Bye bye.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

Panel Discussion: Future of React
React Summit US 2024React Summit US 2024
39 min
Panel Discussion: Future of React
Watch video: Panel Discussion: Future of React
Kent C. Dodds
Shruti Kapoor
Mark Erikson
Eli White
Mofei Zhang
Theo Browne
Tom Occhino
7 authors
We're going to be doing a future of React panel discussions. React 19 is in RC stage and we're excited to hear when it will be stable. The React compiler is here to stay and is the future of developer experience and tooling. React 19 brings exciting features like RSCs and consolidation of the framework. React's commitment to community and innovation is commendable. The React team values feedback and actively engages with the community. React's future includes supporting the community and enabling smooth migrations. There's a need to teach underlying concepts and educate AI systems. Teaching and adapting to React can be challenging. The React compiler changes default re-rendering behavior. Collaboration with Next.js and Vercel has been valuable for React's development. Appreciation for the community and partnerships with Vercel and Microsoft.
React 19 Panel Discussion
React Summit 2024React Summit 2024
27 min
React 19 Panel Discussion
Ryan Carniato
Evan Bacon
Sathya Gunasekaran
Tim Neutkens
Brooks Lybrand
5 authors
The Talk revolves around React 19 and the React compiler, highlighting its new APIs, optimizations, and impact on frameworks like Next.js. The React compiler has undergone multiple iterations, resulting in improved performance and alignment with developers' expectations. The integration of React with Next.js simplifies rendering and offers free optimizations. There is excitement about the opt-in approach of React Server Components and the potential of underrated features like suspense and transitions. Overall, React's influence on the JavaScript ecosystem and UI libraries is acknowledged and appreciated.
Fire-Side Chat with Kent C. Dodds
React Summit Remote Edition 2021React Summit Remote Edition 2021
31 min
Fire-Side Chat with Kent C. Dodds
Kent C. Dodds discusses various topics including migrating projects to TypeScript, Next.js and Remix, testing libraries, RTL testing with React Testing Library, integration testing for component libraries, testing design systems, writing tests, communication resources, and the popularity of Hooks in React development.
Scaling Fast – Engineering Lessons From ~15 Years of Tech Startups
React Advanced 2024React Advanced 2024
27 min
Scaling Fast – Engineering Lessons From ~15 Years of Tech Startups
Hey, we'll discuss scaling fast and engineering lessons learned in the last 15 years of tech startups. Scaling involves three things: business, team, and tech. Business scalability relies on sales and customer acquisition costs. Engineering is a tool the business uses. Scaling the team is vital as tech problems are often people problems. Team structure affects architecture and product development process. Organize teams based on purpose, not technology. Spend less time being blocked by other teams. Ship features without getting blocked. Own your own mess. Focus on product engineering partnership. Build faster using feedback cycles. Build appropriate solutions for your use case. Let go of ego and experiment with different approaches. Engineers own their own mess. Avoid work in progress. Finish the work and focus on fixing it later. Have a conversation before writing code. Scaling the tech is easier than you think. Pick an off the shelf design. Save innovation for core parts. Pick existing solutions. Focus on solving the problem. Don't waste time trying to predict future scale. Scale will surprise you. Do what works for your business. Push back on unnecessary complexity. Understand the cost of ideas. Modify the situation to fit existing design. Architecture is like a dependency graph on your code. Reduce architectural complexity by organizing code based on what it does. Use vertical models and avoid creating excessive dependencies. On the client, use vertical modules. On the back end, consider a service-oriented architecture. Start with a monolith and transition to microservices if necessary. Use folders instead of microservices when you have a small team. Use vertical models and contract or type-driven development to define clear APIs and interfaces. Avoid highly interconnected code and duplication. Focus on data structures to avoid complexity and the need for translation layers. Building translation layers can lead to slow user experience. Vertical teams aligned with vertical code allow for fast problem-solving, full control of features, and efficient data handling. Understanding the entire domain enables faster development with fewer bugs.
How I Automated Code Changes for 100 Repositories: Getting Started With Codemods
React Day Berlin 2022React Day Berlin 2022
28 min
How I Automated Code Changes for 100 Repositories: Getting Started With Codemods
This Talk discusses automating code changes for Android repositories, utilizing tools like JSCodeShift and Abstract Syntax Tree. The speaker shares a real use case example of maintaining a design system library and making changes to a component. The talk emphasizes the importance of automating repetitive tasks and using the power of abstract syntax tree for code changes. The Q&A session covers topics like source code formatting, TypeScript support, and cultural embedding of code mods. The talk concludes with insights on when automation is worth it and the limitations of code mods for monorepo changes.
Next Generation Code Architecture for Building Maintainable Node Applications
Node Congress 2023Node Congress 2023
30 min
Next Generation Code Architecture for Building Maintainable Node Applications
Today's Talk focused on code architecture, modularization, and scaling in software development. The speaker discussed the benefits of separating code by domain and using tools like NX to improve productivity and enforce modular architecture. They also highlighted the importance of automating library creation and configuration. Additionally, the Talk covered code scaling and deployment strategies, including caching and automated code migrations. The speaker emphasized the flexibility and scalability of Fastify and the advantages of using a monorepo for front-end and back-end development.

Workshops on related topic

Production-Ready Apps with AI Agents
React Summit 2025React Summit 2025
102 min
Production-Ready Apps with AI Agents
Featured Workshop
Alex Shershebnev
Alex Shershebnev
Coding assistants are already changing the way we develop code, and in several years they are expected to completely change how developers interact with code and write it. In this workshop, I'll share tips and best practices on using such tools as we develop the production-ready app with Zencoder.
Bring Code Quality and Security to your CI/CD pipeline
DevOps.js Conf 2022DevOps.js Conf 2022
76 min
Bring Code Quality and Security to your CI/CD pipeline
Workshop
Elena Vilchik
Elena Vilchik
In this workshop we will go through all the aspects and stages when integrating your project into Code Quality and Security Ecosystem. We will take a simple web-application as a starting point and create a CI pipeline triggering code quality monitoring for it. We will do a full development cycle starting from coding in the IDE and opening a Pull Request and I will show you how you can control the quality at those stages. At the end of the workshop you will be ready to enable such integration for your own projects.