I'll start. A colleague would be politely suggesting designs or changes, but rolling with the punches when people disagreed. They were always proven right eventually, and it was usually because someone wandered into a module they had written and loved it.
They changed a lot about how I worked, and by far their main characteristics were patience with us and a sort of completeness to whatever they wrote. It just arrived, maybe with one small adjustment or bugfix, bug never with a rearchitecture or major refactor required.
It’s been a decade or so since I worked with Isaac and I looked him up to find he is at OpenAI. Fitting.
I'll throw out Mr. Hedger Wang from Yahoo! as my nominee, he basically had the IE6 browser renderer in his head, and even though I never worked with him directly, just being able to ping on Y!M was an incredible help.
What made it special (2010-timeframe) was that we would do without thought what other companies struggled to do at that time (hot-hot failover, multi-region, "3 machine minimum" deployments), processing traffic for ~500M monthly users when spinning rust and 32gb of ram was considered "a lot".
My perspective on what happened is reeeally smart people solved really tough problems, then would either bail to Google (and later FB) to write the "v2.0" and solve those same problems but "better" or they'd go and start a full-blown company to sell that solution.
The tide rose around Yahoo! and both business-wise (and tech-wise), they didn't keep pace once their competitive advantage of "we can scale" dissipated.
I stopped caring too much about who the best in the room was after 7-8 rounds of this. As Nietszche would say these are not Ubermensches but the last men in a nihilistic swamp. Creatures who have attacked and destroyed older moral frameworks without replacing them with anything new. For their own comfort and survival.
The kind of people who pretend they have mastered complexity, but in reality its just survival theater and political/power games. Ubermensches haven't emerged yet.
They knew when to write code or when to stitch existing software together. The code they wrote wasn't easy to understand nor did it follow any good "software engineering" practice. But they could get an MVP out the door faster and better than a 5-7 developer team. This person was never arrogant and everyone from developers, customers and managers loved them.
Then one day, he gives me freestanding C code that was superbly written, with some macros for benchmarking, etc. For the most part it worked but needed some massaging for edge cases and such, but it was so beautiful and solved my immediate needs. I was unblocked but the whole ordeal has since been imprinted in my mind. He didn't give any context when handing the code, but I later figured out he implemented the algorithm as described in RFC 815. Deep in the annals of history and literature in networking that isn't really covered by any contemporary networking text books or sources.
Anyways now that I'm a mentor/tech lead these days, I'm always looking for my opportunity to help unblock someone by writing some very specific hard to implement code.
1. Information is meant to shared. 2. Never do manually what can you write shell script to do.
I started at $MEGACORP on the help desk. One day I noticed one of our AIX servers had a volume filling up. So I send him an IM that says "Hey I noticed that the log partition on server BLAH is filling up". He immediately called me and told me that the server does partitions, but instead used logical volumes. He then spent the next two hours explain in detail how logical volume manger worked, how to manage volumes and the implications it had with our SAN. At the end of the call I made a comment that I was surprised he was sharing all this information with me. He responded that he didn't want the type of job security you get by hoarding information. He instead wanted by job security by enabling the team to preform at its best, and he believed you achieved that by sharing knowledge. That phone call was only the first of many such calls.
The second thing is that he believed in automating everything you could. Using knowledge he shared with me, I quickly automated most of my help desk duties. Because of this I started working more with the system administration team and was moved onto it after just a few months. In my 20 year career every job I've had has revolved around automation. I really enjoy it and without his influence I would have never gone down this path.
When you explain a concept to another human you have to provide context and a certain level of detail. It can be hard to calibrate based on who you talk to. What always blew me away about this guy was he needed like almost 0 context, even for non-programming subjects. He understood within seconds what you were doing, even for complex problems. I had to recalibrate my entire approach to explanation with him because he got things instantly.
- Whimsical, child like attitude. "Sure, I can do that" was almost always the answer.
- Would come in on the weekend when nobody was there and you'd see them cooking. Then on Monday, they'd reveal their work and it'd be something that seemed impossible last week.
- Had deep understanding of the hardware so that diving in and writing some specific assembly-like (or literal assembly) code was part of their toolkit.
- Were treated as a Goose That Laid The Golden Egg by management. Could do whatever they wanted, but they loved to work and code so it wasn't ever out of balance.
- After a few years of working at the studio they started to have mental health issues because there was a never ending stream of needs and problems, many of which were solved with them. Planning projects started to include several technical miracles they would pull off. It started to be expected.
Nowadays writing straight to the metal in video games is less common, so I think these types of guys have largely migrated to other fields. We used to write our own engines and there was more need for them. Now there's a lot more use of third party engines so there's less opportunity (and need).