Lisp - It was one of my first few languages, but really learning it damaged my view of everything else. To use a real Lisp machine, Lisp debugging/backtracing, and have code as data was such a huge win over writing ASM, C, Fortran, and the many other languages I used a lot back then. I still feel almost all other languages are catching up, while Common Lisp itself I felt got ruined by a lot of nonsense even though I still use it sometimes. So both excitement and disappointment here. This is where I really learned to use functional programming and became productive. All of my code since, even in OOP takes things I learned here like data first, preferring operations on lists/sets of data, and meta-programming. This is also where I learned that syntax really doesn't matter and people while they might have preferences, they are generally too caught up on syntax for the sake of it and not what it can do for you (ex: code is data, macros).

Smalltalk - Some of the best ideas in CS that were warped, misunderstood, or ignored. Commercialism at its finest killed this and ruined the ideas from it. The productivity in this language was huge for me and the environment was and still is a wow. The aesthetics have almost always been awful though so it really bugged me that no one ever gave a practical instead of theoretical effort to improve here. The day I saw things like Gemstone Smalltalk dumping entire running states into a bug tracker and then clicking on the issue and being thrown into the debugger was one of many incredible moments. A lot could be improved, but like Lisp, lots of imitators and few equals. In terms of impact, this really led to me truly learning OOP at a higher level and made me think about code entirely differently - as a living, breathing, environment that was somehow more real than what Lisp offered. The separations from the OS into its own world made it both incredible (I still feel like using files 1-to-1 for code is nonsense) and a pain to use (ex: integrating proper source control and existing tools because of files issue).

Clojure - Finally a practical Lisp-like experience that I don't feel like a crazy person trying to "sell" to coworkers to use on a project. Lots of things here I don't like, but even the author of the language agrees with me on most of those. I like the pragmatism, honesty, openness about what is good/sucks, and more here. It's really productive for me and I feel less in Smalltalk and Lisp land. The moment was like, "Rich Hickey, OK, this guy totally gets it."

Emacs - I hated it at first, but when the concepts started to sink in for me, it made so much sense. Licensing and politics aside, it's pretty incredible. I wish there was less crust or a way to magically rewrite it and have all the good add-ons also magically rewritten. It truly is its own OS for better or worse like Smalltalk, and can be used and abused accordingly. It just still makes so much sense to me in both Smalltalk and Emacs that I'm writing code and I can use code to do things to my editor, both in terms of add-ons and while it is running (ex: if I need a special toolbar, window setup, whatever).

Acme - It's an ugly editor, but wow it's full of great ideas. I didn't particularly enjoy the mouse chording but everything else is amazing. The relationships it had with the system using it in Plan9 just made it so powerful and full of possibilities.

Overall, my best decision to improve my work was to stop listening to the masses and just try to do my own thing, with confidence. That doesn't mean just anything, rather it means follow my instincts and balance things with a healthy dose of pragmatism and extreme skepticism. That also meant ruling out new and shiny things as well as old and awesome things like Smalltalk and Lisp on many projects. Once I learned the difference of being a contrarian vs. an educated independent thinker, I became both tormented by how terrible most software is and encouraged to think completely differently and abstractly about it all. Still trying to do some great things with that attitude, and it's more the non-technical daily life struggles that are the real challenge.