You're torn between code quality and new features. How do you strike the right balance?

In my role as a QA lead implemented a structured approach to address this challenge by prioritizing tasks based on their impact and urgency; critical bugs fixed first and technical debt is managed to prevent it from becoming unmanageable and lead to code-rot. By merging incomplete builds into the next development cycle and allocating a buffer week for critical fixes if necessary, we avoided last-minute scrambles. Continuous monitoring through dashboards and aligning priorities with product management helped maintain both code quality and feature development, ensuring long-term project health.

In my opinion, determining what is most important at any given moment should be kept in mind. Sometimes, it is essential to deliver new features quickly, while at other times, focusing on maintaining or improving quality takes precedence. And also, clear and timely communications with the stakeholders, product owners, managers are a must to get aligned on the priorities.

Create work items on all the subjects; new functionality, performance improvements (of existing or new?) etc. Do a refinement (with focus on business priority) and then when sprint planning you can pull in accordance to priority and capacity along with already existing prioritized bugs

There's not really any balancing to be done here, unless you believe that you can sustain your feature delivery over the money term with low code quality. This was the crucial idea at the core of Extreme Programming and it remains through being embedded in Continuous Delivery.

By definition all code that already exists and has a non-zero. Age is and has technical debt and is growing its indebtedness over time. Therefore, in order to avoid getting into a debt trap, make sure that your new code is written to the best standards you can manage at the time. In response to the common proposition that "I don't have time to do it well", reread what I said " to the best standards you can manage." The counter example is not an excuse to drop all standards. The TL;DR; "do your best".

Depending on the bureaucratic nature of your work environment, adopting truly agile practices can be difficult. In that case, it's important to manage your client's expectations about what can reasonably be delivered in any given timeframe. Overdelivering in the short term can lead to disappointment as code quality declines and throughput slows to a crawl. Instead, make sure you are continuously taking time to address tech debt, establish the resulting rate of delivery as the baseline, and you will be in a much better place to support the longevity of your project - ultimately delivering more in the long-term than you would otherwise.

An example I've seen is implementing a buddy system for code reviews, where each developer is paired with another. This not only improves code quality but also fosters a culture of collaboration and continuous learning within the team.

Code reviews can reduce bias if constructive feedback is given and applied. Something to look out for is who is doing the reviews. Often bias from those with louder voices flow down. Generally it will save your organization a lot of pain in the long run if these are conducted properly and consistently

Why do we call it technical debt? Because it's a cost that was not paid in the past that has to be made good on at some point. That's the direct analogy. If something does not need to paid back then it's arguably not a debt, so I would strongly recommend identifying things that are nice to have versus things that are necessary.

One thing that I feel can help to reduce the technical debt is to maintain a clear backlog of the technical debt items and align them alongside the new features that ae being worked upon.

One issue with Continuous Integration and Continuous development is the lack of maintenance on said CI/CD pipelines. Developers will become accustomed to the pipelines and often not be aware of how to trouble shoot broken builds. From both on their local and the CICD build. Another common issue is troubleshooting builds in general. What sets apart better developers is the ability to troubleshoot why the build is failing but succeeding else where. From a DevOps perspective I see many lazy developers having monolithic package locks. Often I’m asked to fix their problem and 99% of the time it turns out to be packaging issues. Simply saying “it builds on local” is insufficient today, especially if you’re deploying to cloud.

Customers who are passionate and patient enough about your (early) product to shoulder knowingly some of your testing obligation are among your company's most valuable ones. Ideally, you can manage your QE cycle to incorporate feedback from these "privileged" users on a release candidate concurrent with in-house testing. That can uncover issues earlier which indicate engineering rework is preferable to continued testing of the current candidate.