How to win friends and influence people. Helped me solve some approaches to handling people in general and highlighted a few approaches that I had been taking that were actively causing me problems.

The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully by Gerald Weiberg. [1] Helped me understand why technical problems are rarely just technical.

Working effectively with legacy code by Michael Feathers [2]. Practicing some of the techniques in this helped me get my foot in the door in a job long ago where one of the interview scenarios was "This is broken, go ahead and fix it.". I recommend reading this for anyone working on a code base that's been around for a while.

--

[1]: https://www.amazon.com/Secrets-Consulting-Giving-Getting-Suc...

[2]: https://www.amazon.com/Working-Effectively-Legacy-Robert-Mar...

> An objection I hear to this is that you're not just writing tests for yourself, you're writing tests for the others who will need to help maintain your code, perhaps after you're gone. I'm somewhat sympathetic to this, but I would also say that if someone else needs to modify my code, they damn well better first understand it well enough such that they could write tests before changing it (if they deem it necessary). Anything else is just irresponsible.

As someone who has had to fix plenty of legacy code, I have truly appreciated the people who have left me at least some working test suites to run - or just look at - and cursed many others. At the same time, I have generally been handed over code bases with tens or hundreds of thousands of lines, some of which had no useful tests.

If it is irresponsible to try to refactor or fix a codebase without first understanding all of it, it may be even more irresponsible to expect that those who follow in our footsteps will be able to do that, even if they are "gods of programming".

The reason why this is so was hammered home very strongly in Peter Naur's "Programming as Theory Building"[1].

Unless a code base is trivially small or simple, leaving it without meaningful tests instantly creates legacy code. I'll close with an excerpt from the back cover of "Working Effectively with Legacy Code[2].

> Is your code easy to change? Can you get nearly instantaneous feedback when you do change it? Do you understand it? If the answer to any of these questions is no, you have legacy code, and it is draining time and money away from your development efforts.

[1]: https://news.ycombinator.com/item?id=10833278

[2]: https://www.amazon.com/Working-Effectively-Legacy-Robert-Mar...

> That doesn't even address the hard part.

Fair enough. I did write a book on the other parts, though. https://www.amazon.com/Working-Effectively-Legacy-Michael-Fe...

Working Effectively With Legacy Code: http://www.amazon.com/Working-Effectively-Legacy-Robert-Mart...

http://www.amazon.com/Working-Effectively-Legacy-Code-ebook/...

http://www.amazon.com/Refactoring-Improving-Addison-Wesley-T...