Ask HN: Tell me about the best programmer you worked with
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.
23 comments
[ 3.0 ms ] story [ 50.8 ms ] threadIt’s been a decade or so since I worked with Isaac and I looked him up to find he is at OpenAI. Fitting.
He taught me that developers are difficult/impossible to control and to not be possessive or emotional about code. He also taught me tools and tricks in Linux that I still use today.
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.
That said, I wouldn't have wanted to work with him in a commercial environment. It was a way of thinking/programming I could never wrap my head around.
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).
Her name is Jalaja Ramanadham. She became my manager.
What I found most interesting about this excellent developer, and of course she was absolutely excellent at her job writing Java as well, was her secrecy. She did not mean to reveal her ability to masterly address CSS and JavaScript concerns to me. She did so because she knew I was super new and it didn't matter. She did not reveal this to anybody else, because she didn't want to compensate for the repeated failures of people around her. In hindsight I can absolutely see why she went out of her way to suppress her capabilities while at the office.
He was brilliant. Could understand a very deep and complex business system and remember all the hundreds of table and convuluted logic built into the system, but it was a bit overwhelming listening to him talk since he would overload so much information in such a short time frame
Maybe the better word is clever or brilliant. I have also worked with other programmers who build such systems, I think the best programmer just builds simple things
This individual, inherently understood that the method with which they communicate, could be different for different individuals. As a result they changed their messaging, their body language, their wording, depending on with whom they communicated. They still said the same thing(s), but it was how.
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.