I'm going to embarrass my friend and plug his leanpub book, Scary Large Code Surgery with Pivots, because it was so similar to your story, except he wasn't new

I'm going to embarrass my friend and plug his leanpub book, Scary Large Code Surgery with Pivots, because it was so similar to your story, except he wasn't new in his career. Step 1 of rewriting a code base that doesn't have any tests: commit to not rewriting anything until you've covered it with tests and understand all the moving parts well enough to be sure you know what you've broken. Chorn asked me to make sure that nobody pays for this book, so I (...won't provide the link... edit: free link below), it's on Leanpub. The idea of a "pivot" is to invent a mechanism that lets you treat each line of code the same. You need to have a process that you can use to catalog, understand, and test everything objectively and without getting hung up. If you removed any arbitrary line of code, or changed it to call a different method, that should cause a test to fail. The most important part (and it's been a while since I read the book, but...) commit that you are not going to fix anything until you have tested everything. It will be grueling. The net effect of this hell should be that you will never question, or allow anyone to question, the value of automated testing at build-time ever again. The tests are what allow you to refactor with confidence. If the management is on board with this strategy, then you have already won half the battle. They may already know they did a bad thing, but your outlook on a piece of code is different before it has been made successful and people are using it. "What am I gonna need that test for? That shit is a waste of my time, I don't even know if this is gonna work in the first place." That might not even have been wrong at the time. There are plenty of ways that people can convince themselves not to write tests. Some are external pressures. If you build a great piece of code and are late to market, beat there by your competitors, that could be an even more serious problem. If the code is poorly designed, but it is working and people are using it, now you have a different problem. The main idea of the book is that when your code has become successful and is in use by hundreds of people, the game changes. You can't responsibly make major changes to code you don't understand fully. Take the time, that's the job! And good luck. Edit: I found the coupon link, coupon price $0.00 https://leanpub.com/scary-large-code-surgery/c/ohai https://leanpub.com/scary-large-code-surgery/c/ohai