| > If they find an issue along the way, they make a note of it and come back to fix it. Or they might fix in as they go. One consistent tension is that the old-hand developers have a "mental issue queue" that is enormous, but without fail, every time, they just can't be transferred. These can't be made into issues and farmed out to other people. Inconsistencies in the data model, for instance, might exist, but a better solution isn't obvious. You can hand it to someone fresh, and after significant effort (on both of your parts) they agree with the inconsistency, but they won't propose a solution that's any better. Once you've contributed enough of the main functions of a code base, you just never lack for something to do. All code is bad, because the business focus is on expansion of responsibilities over refinement of the existing ones. Those ghost issues are best communicated with a code change, at which all observers say WOW WHY DID WE NOT SEE THIS?! But the issue without the code change gets gawking blank stares. EDIT: but fixing unrelated issues as you go is bad, don't do it! |
> a better solution isn't obvious. You can hand it to someone fresh, and after significant effort (on both of your parts) they agree with the inconsistency, but they won't propose a solution that's any better
> Once you've contributed enough of the main functions of a code base, you just never lack for something to do.
Hello, friend, I see we know each other well.