Names and enlightenment

There was a time I thought I was bad at names.

Then, I learned it was a skill, and I was just being lazy: to commit a name to memory, repeat it out loud in a sentence after hearing it at least once, and also think it several time inside your head. Then remember to think about it again a minute later, and five minutes later. Then you got it!

There came a time I thought I got good at the skill – learning thousands of names at tango festivals, and remembering the name of every Lyft driver at the end of a ride after conversation. One culmination of the art of remembering names was after a day of interviews at a company with 5 different people, followed up with an hour-long demo of the product, in the debrief with the HR – I told him about my experience interviewing using the names of all the 5 people who had interviewed me.

And then, I went to physical therapy, and met my therapists: Sarah Plumer-Holzman for the shoulder, and Sarah Edery-Atlas for my hip. Good luck! I truly felt like a basic noob at names all over again.

From Zen Buddhism: “Before I sought enlightenment, the mountains were mountains and the rivers were rivers. While I sought enlightenment, the mountains were not mountains and the rivers were not rivers. After I reached satori, the mountains were mountains and the rivers were rivers” – Dōgen


Understanding is one of the deepest things we do as humans. Once something is understood, it becomes easy, or even enjoyable, to deal with – and it’s nearly impossible to forget something you truly understand.

For most of my life, it’s been an intuitive process.

However, as I’ve had to get better and better at understanding complex subjects quickly, I’ve developed at least some approaches to it that I’m more aware of.

One way I understand something is in terms of questions about it. Some basic ones:

  • What is it?
  • How does it come to be?
  • When should it be?
  • Where is it?
  • Why does it need to be?
  • Who made it? Who intended it?
    (tenses may vary)

Some slightly more elaborate ones:

  • What is its history, its current state, its future?
  • How does it change? Where is it flexible, where is it rigid?
  • Who is responsible for it?
  • Who can it benefit and how?
  • What’s related to it?
  • How important is it?

Depending on the subject, the questions may change in subtle ways. Simple questions help illuminate the silhouette of a problem/solution/project/idea/proposal/theory/situation/relationship/thing. Deeper understanding relies on the art of asking the right questions: great illuminating answers start with a great question.

Another way I feel I understand something is in terms of how to build it or do it. Sometimes, even though I am unable to find a good question, or a satisfactory answer to a reasonable question I do have, I am still able to create something – and I feel like I understand it in some sense, because I am able to reason about it sufficiently to bend it to my will for whatever purpose I may have. Of course then all my basic questions will be future tense!

I still rely on intuition a lot. More types of understanding reinforce each other; first, having answers to basic questions, then to deeper questions, then being able to express my understanding through creation, and still always having intuitive imagery for what it is I think I’m understanding.

The Socratic tragedy is the feeling of incompleteness of understanding, no matter how deep or broad – a puzzle piece always seems to be missing. Enlightenment comes, and becomes mundane, as master Qingyuan Weixin famously wrote: “Before I had studied Ch’an for thirty years, I saw mountains as mountains, and rivers as rivers. When I arrived at a more intimate knowledge, I came to the point where I saw that mountains are not just mountains, and rivers are not just rivers. But now that I have got its very substance, I am at rest. For now I see mountains once again as mountains, and rivers once again as rivers”.

Code as art

Artistically, a codebase is an expression of a Software Engineer’s understanding of a real world problem (including the people working on it and their relationships) and its solution.

Most code is written by many engineers, so actual production code can be dissected by who wrote it – the entire codebase is a representation of how well each contributor understood the entire problem and the role contribution they’re making plays in solving the grand real world problem.


To me, multitasking means a very specific thing, and I thing a lot of people get the meaning wrong. Maybe I’m wrong! You tell me.

When I multitask – I’m aware of multiple problems that exist, and I have singular focus on a specific solution that addresses multiple problems.

The way I’ve seen people understand the concept is that they are doing multiple things simultaneously. That’s impossible. You only do one thing at a time, there’s only one you, but you can multitask if you solve multiple problems with the brush of a single stroke.

The art of building

A few years ago, I consulted with one of my mentors.

I said I’m miserable living in San Francisco, and I think the only thing keeping me here is the ridiculous opportunity that’s been bestowed upon me by fate – and that I think I should stay, but maximize what I’m getting out of my time here.

We discussed 2 options: getting into venture capitalism, and trying to make money by convincing people with money that I know how to best make a return on their wealth – or, actually building something. Obviously, in his mind actually building something and being able to personally shape the future was a lot more interesting than just trying to make a buck.

So we drilled into that.

At the time, I was leading a team of engineers – which seemed like a great opportunity to learn the leadership skills I’ll need to propel a company I’m building towards success. I tried to inquire in how I should take advantage.

While true that leadership is inevitable in an endeavor like building a company, I humbly heeded his wisdom: he said in fact, I should be doubling down on my engineering skills if I intend to truly build a technology company.

Today, knee deep in both leadership and code, his wisdom rings true.

Past/experience future/math

There are 2 ways to approach flow-like thinking.

(1) Past/experience or (2) Future/math

When you’re improvising music – how do you figure out what the next note is? How do you know what the best next thing to say is? What the next best improvised dance move is?

(1) One way to think about it is – well, I know this is how it will sound like, and here’s the sound I want. How do I know? Based on my experience, on the past.

(2) Another way to think about it is – I think this will work well, even though I don’t have experience with this exact transition, because of my understanding of how things work in general.

(1) leads to expectations
(2) leads to predictions

Aladdin was a thief

Aladdin was a thief.

How inappropriate. What an awful lesson to teach kids – that stealing is okay. He’s charming, sure. But in the real world, thieves are criminals! Predators, attacking innocent, hard-working humans.

Is it so black and white?

Virtue is about building a marvelous future. Building is key – nature flourishes, and the environment improves, and humans thrive, there’s room for happiness and bliss.

So suppose you’re a builder. You wish to build this marvelous future. Is stealing still bad?

Actually, what aspects of the mind are required to steal? What are you training for? Could thievery be a game to help one understand a virtue due to the skills required? Is thievery fun?

How do you do it? Ok, I need to create a distraction, sleight of hand, manage other people’s focus while still maintaining my own focus on the goal. Focus. Everything is at stake. Can you summon that focus to build castles?

Dancing and Programming

Learning a dance is quite like learning a language.

Learning a programming language is also quite like learning a language.

Programming languages are actually quite similar to dances. There are first principles, from which order is built, and ultimately – structure. There’s a community behind each programming language, and behind each dance. You go through a unique language/dance-specific learning curve, and ultimately come to be able to express yourself in a new medium.

Learning to dance, and then engaging in that dance – mirrors learning a programming language and writing in it.

Ballet is like Assembler. Get to the metal, think in terms of the underlying mechanics of the body.

Tango is like C – you can go as deep into the hardware as you like, even down to assembly; but it’s a new way of thinking that helps humans connect. The jedis who have figured out Tango or C are an elite group, so it’s easy to be a tango snob or a C snob

Yoga is like NAND gates – because it’s not even dancing or programming, it’s the stuff that dancing and programming is made out of, man.

Fusion is like Python – because it embraced positive influences from many different branches of language it was exposed to, and arrived at something new, familiar, with recognizable roots, found a way to make it all work together, and of course there’s always work to get rid of the things that weren’t working well in your roots.

Zouk is like Ruby – because it’s just so nice to program. It’s already been thought of before you even needed it – you are taken care of. This move is allowed, and this language construct also. Igotchu. Take some of the best ideas around, and just make them work together in a bowl. Then, somehow, through the wonder of the sense they both make at their high level of abstraction, complex moves and concise multi-functional single-line commands – somehow you are more intimately connected with where you came from than ever before.

Ballroom is like Java. There are rules, man, and they’re very explicit, it’s a very competitive environment. Everything is specific, your thinking is structured for you, and you have to jump through a lot of hoops to get to where you’re going – but it’s a steady, trodden path, with a lot of support. A lot of innovation, leadership, good foundations… and a lot of legacy.

West coast swing is like C#. You’re just having fun doing it, it’s light, not too heady, gives you what you need really… It’s fast, energetic even. Many of the wild moves or code constructs you dreamed of – are possible.

Salsa is like Javascript. It’s the most popular dance/programming language. There are many different kinds of salsa and javascript. There are good salseros, and there are mediocre javascripters, and even bad ones. It’s so popular, it has everything. The highs can be high, the lows are low, and at this point it’s human nature in a blender.

Zouk is also sometimes Javascript ES6. The problems of being the most popular and trying to fit every need across every platform/culture/nation is apparent. But maybe it’s possible to unite and dance anyway!

Bad Habits

I think we’re born with “bad habits” – that is, random habits. For every type of thing we try to do there’s a natural, random, solution we first figure out – and all the little differences in the specificities of how it’s done are usually sufficiently inconsequential for the problem to be solved regardless of the inanity of the first attempt.

The process of mastery is attaining awareness of the humanly features that comprise a skill, then understanding a correct way of doing it, and ultimately with repetition establishing habits that replace the de facto preexisting random “bad” habits. I think ultimately, a bad habit is just a bunch of otherwise good habits munged together, it’s just noise in the neural wiring. There are several independent different great ways of achieving a particular class of results. Mastering each way, and then deliberately choosing the most elegant one for the situation is ultimate mastery.