Solve Problems So They Remain Solved...But If They Aren't Changing, You Aren't Solving ThemThat's the conclusion I've come to after four years in a startup. The kinds of problems seems to go through several phases.First are the feature debts, things your code should be doing but isn't yet and you had no idea originally that you'd need to do that, so you work hard on that and to meet deadlines you accrue technical debt.The technical debt will continue to accrue until it either causes a fire or you've satisfied all feature needs for a while, and then you can go clean up the code, but again to meet deadlines you'll take some shortcuts and focus on clarity over speed and accrue performance debt.This is the right choice as most code can stay here indefinitely, nowadays, and easily-understood code is easier to develop new features on without accumulating as much tech debt as before. But sometimes the performance debt comes to bite you, especially if the debt is not just at the algorithm-level but the architecture-level (the distinction is mainly on how many LOC are needed to modify it and if it has to cross executable boundaries). It is very easy to replace this performance debt with new feature debt, optimizing the code to only handle the current featureset and then running into a wall the next time you're asked to add in new features and starting this cycle all over again.Capacity planning can help here, by forcing you to run into performance problems early, but I'm not sure if the cycle ever ends until the software has actually matured and no new significant feature development is required.In any case, once some set of software has reached the maturity stage, I'm not the right person for that job. I won't move on to another project until it shows that level of stability (minimal-to-no alerts, feature development that has no architectural impact at all, and predictable capacity planning) but once proven, I will. There are always new problems to solve.
Listed skills include Device Characterization, Software Development, Characterization, Simulations, and 27 others.