> If you immediately set out with the mindset "your spell checking service shouldn't also be an autocomplete service" as if this is some sort of wisdom (it real

> If you immediately set out with the mindset "your spell checking service shouldn't also be an autocomplete service" as if this is some sort of wisdom (it really, truly isn't), then you're hamstringing yourself from getting these kinds of easy wins. It's not "immediately setting out with a mindset", it's looking back on coming-up-on-2-decades of software development experience and noting that every time I think bolting a second responsibility onto a unit is an easy win, that decision comes back to bite me. It seems like an easy win now, but everything you change in that area of the code from now on needs to consider two different, disparate responsibilities it needs to maintain. If you're seeing this as an easy win, it's likely that your software didn't see much use that played out the problems, or you didn't stick around long enough to see the problems arise, or someone else did the work to fix it and just didn't tell you. > Nobody who was using its old features; they don't have to change at all. Not yet, but if you assume they'll never have to change, you're going to have a bad time. What's the longest you've ever worked on a codebase? Have you ever been the sole developer on a large codebase, where you had to pay for your own mistakes?