Ciao!
What's your experience with legacy code?
It's a humbling struggle, isn't it? At the same time, I believe it makes you not only a better programmer, but it also teaches how to improve as a professional.
In a greenfield situation, you are free to deploy all your skills to solve a problem. In a brownfield context, you need to maneuver around the legacy code's constraints.
Focusing too much on quality is an excellent way to get stuck. You cannot undo months of accrued spaghetti in a few days. At the same time, this kind of software, as bad as it is, provides value. Otherwise, we would call it trash.
This is why the inversion principle makes so much sense when dealing with legacy code: do not try to achieve success, but focus on avoiding failure.
Code that needs changing will require multiple interventions. Do not shoot for perfection. Just make it less awful for the next round of changes.
Do it enough times, and it will magically be so less legacy you might start to like working with it.
How to Terminate Legacy Code without Getting Stuck — Embracing the inversion principle with legacy code: don't try to make it perfect; just make it less awful for the next round of changes.
Elsewhere on the Web
elm-graphql by Elm Radio Podcast (Riccardo: Elm is cool. GraphQL too. This is worth double points! Be sure to check the show notes, it's a treasure trove of links.)
Growing a Language by Guy Steele — Guy Steele's keynote at the 1998 ACM OOPSLA conference on "Growing a Language" discusses the importance of and issues associated with designing a programming language that can be grown by its users. (Riccardo: One of the best and gripping technical talks I've ever seen.)
cheat.sh by Igor Chubin — Unified access to the best community driven cheat sheets repositories of the world (Riccardo: Thanks Andy for sharing it with me.)
