Working in a team where the policy is "never left any tech debt behind" it is surprising the amount of tech debt we already have accumulated. In fact, you can argue that what we are cleaning is not tech debt, but cruft code, I agree.

For the shake of this conversation, we are going to assume that such code is impossible to avoid entirely. So, if we always clean it before closing a user story, how can we have any of it.

You know when a code is a bad code, you have a gut feeling, so you feel the necessity to critics that code and propose changes. Ok before doing that, let's do an exercise, why do those changes make the code any better?

Is it because you like it more and somehow that does it make better? Do you have any measurable argument that justify such a change? After a code review, the code is simpler because it is better or because you have more context?

Last episode of @progesunam remainded me that time when I asked someone about an offer they published on the slack of @VigoTechAllianc. In that time, I thought the best way I can help new people getting to this industry was making the questions they weren't able to make.

So, as this offer didn't include a salary range, I asked for it. The main excuses I received were these:

Pair programming is great, but only if you do it right. You can do it wrong and still get good things from this practice, but at the same it could be very frustrating. I start thinking on this after read some people complaining about it on Twitter.

Usually, the big problem to implement this kind of practices are far from the developer team.  However, in those tweet seemed to be something more. After practicing it steadily during 8 months,

Keep changes small. I think there is a lot of misunderstanding about what a parallel change is and how to approach it, and some confusion when it comes to use it next to feature flags.

You don't need feature flags to do a parallel change, so if you feel you need them, that is a good symptom that you are doing something wrong.

Interruptions kills your baby steps

To create software in small batches is hard. Progress taking small steps require finding the right increment and focus on reach it with the simpler solution. Sometimes I boycott myself, including more thing than those inside the scope.

Coding, sometimes, is like land a plane in the middle of the night in an unknown airstrip without lights. You know what you want, but you are going to discover how to do it at the same time you do it. It could be must easier if at least you have a light at the end of the airstrip

A driver is something like that, something that keep you in the right track in spite of the all the other problems you find during the landing.

In this talk, https://www.youtube.com/watch?v=SfWCRl75Kas&t=924s @DocOnDev says that cruft code is the result of incompetence or a lack of professionalism.

But what is to be unprofessional or incompetent? How does it look?

Context is key, but I have to admit that outside-in approach has worked better for me much of the times. Usually it associated to London approach since starting from outside requires to use some mocks to substitute the component you have not implemented yet.

However, my approach is different. Start from outside writing just enough code to make the test pass, paying attention to the API you are exposing and less on the internal implementation.