Kyle d'Oliveira

By the 100th, there's maybe some problems. And by the thousands, thousands commit on it, right? You've stopped because now you have to completely refactor and rebuild a lot of this technical debt that you introduced. So my talk was talking about some of the lessons that we've learned.

By the 100th, there's maybe some problems. And by the thousands, thousands commit on it, right? You've stopped because now you have to completely refactor and rebuild a lot of this technical debt that you introduced. So my talk was talking about some of the lessons that we've learned.

And although the lessons are very specific to specific problems, there's kind of a generalized idea of what some approaches that you can take to dealing with technical debt in your own projects. If you are able to, for instance, keep if you're able to automate technical debt away entirely, well, there's a whole classification of problems you no longer need to think about.

And although the lessons are very specific to specific problems, there's kind of a generalized idea of what some approaches that you can take to dealing with technical debt in your own projects. If you are able to, for instance, keep if you're able to automate technical debt away entirely, well, there's a whole classification of problems you no longer need to think about.

And you can feel confident that those are just automatically protected. And if you are cleaning up after yourself as you go and making it easier when there are curveballs being thrown at you, fixing technical debt and dealing with it when you hit scale doesn't have to stop you entirely. It just becomes a constant small tax that you pay.

And you can feel confident that those are just automatically protected. And if you are cleaning up after yourself as you go and making it easier when there are curveballs being thrown at you, fixing technical debt and dealing with it when you hit scale doesn't have to stop you entirely. It just becomes a constant small tax that you pay.

But if you invest in the tools, you can actually start moving faster even as you scale.

But if you invest in the tools, you can actually start moving faster even as you scale.

I would say technical debt is like accumulation of decisions that are made while coding that you eventually need to correct in the future. And as developers, I think we're always making these decisions. Can we cut a corner here to deliver a feature out a little bit early? And I think those are like technical debt isn't bad.

I would say technical debt is like accumulation of decisions that are made while coding that you eventually need to correct in the future. And as developers, I think we're always making these decisions. Can we cut a corner here to deliver a feature out a little bit early? And I think those are like technical debt isn't bad.

I think when you are willing to get something in front of the users and deliver value earlier by incurring a little bit of this technical debt that you then have to clean up, I think that's totally okay. But I think technical debt often comes in the situation of Developers making a decision that a framework needs to be super generic and it's a little bit speculative.

I think when you are willing to get something in front of the users and deliver value earlier by incurring a little bit of this technical debt that you then have to clean up, I think that's totally okay. But I think technical debt often comes in the situation of Developers making a decision that a framework needs to be super generic and it's a little bit speculative.

And then they come to implement something in the future and it's just really difficult to deal with because it's so generic and hard to understand that new developers have to then unpack that and wind it back just to implement something new in it. Some things that I think are not necessarily technical debt can kind of come from...

And then they come to implement something in the future and it's just really difficult to deal with because it's so generic and hard to understand that new developers have to then unpack that and wind it back just to implement something new in it. Some things that I think are not necessarily technical debt can kind of come from...

maybe decisions that actually made sense at the time and aren't necessarily any cutting a corner. So, I mean, it may make sense to build a system that is very generic and maybe that is the correct choice and you build through and then things change. And when things change, that's when you might have to have the technology that comes back. But until the things change, it actually might not be.

maybe decisions that actually made sense at the time and aren't necessarily any cutting a corner. So, I mean, it may make sense to build a system that is very generic and maybe that is the correct choice and you build through and then things change. And when things change, that's when you might have to have the technology that comes back. But until the things change, it actually might not be.

I think that's a bit of like a generic answer, but it's hard to pin down a concept like technical debt because almost everything we write is debt of some form.

I think that's a bit of like a generic answer, but it's hard to pin down a concept like technical debt because almost everything we write is debt of some form.

One of the things that popped up is actually something that we decided on because the Rails community pushes for, and this is what comes out of the box.

One of the things that popped up is actually something that we decided on because the Rails community pushes for, and this is what comes out of the box.