REIN: This episode is brought to you by PagerDuty. In an always-on world, teams trust PagerDuty to help them deliver a perfect digital experience to their customers every time. With PagerDuty, teams spend less time reacting to incidents and more time building for the future.

From digital disruptors to Fortune 500 companies, over 12,000 businesses rely on PagerDuty to identify issues and opportunities in real time and bring together the right people to fix problems faster and prevent them from happening again. We're like the central nervous system for a company's digital operations. We can analyze digital signals from virtually any software enabled system, and help you intelligently pinpoint issues like outages, as well as capitalize on opportunities, while empowering teams to take the right, real time action. To see how companies like GE, Vodafone, Box and American Eagle Outfitters rely on PagerDuty to continuously improve their digital operations, visit PagerDuty.com.

ARTY: Hi everyone. Welcome to Episode 150 of Greater Than Code. I'm Arty Starr and I'm here with my fabulous co-host, Rein Henrichs.

REIN: Thank you. And I'm here with my friend, Jessica Kerr.

JESSICA: Good morning. I'm here with John Sawers.

JOHN: Good morning and I'm here with Avdi Grimm.

AVDI: Hello. And joining us today is Amir Rajan, who is a pretty decent dev and he is someone who's constantly trying to improve his craft. He is a jack of all trades. He is comfortable with a number of platforms and languages, a mercenary coder for hire, the CEO of DragonRuby, otherwise known as RubyMotion, and an indie game developer. His claim to fame is A Dark Room for mobile and Nintendo Switch, an RPG which conquered the world and took the number one spot in the app store and placed in the top number 10 paid apps across 70 countries. It has been downloaded over 4 million times. Wow! Cool. Hello.

AMIR: Hey, how's it going?

REIN: I would say that you're more than decent possibly.

AMIR: I'll be honest, I have no idea what I'm doing most of the time.

REIN: Which puts you squarely in the more than decent category.

AMIR: [Chuckles]

REIN: That's consistent.

AMIR: I'm persistent. I'll roll my head on the keyboard until something works. And I think that's how I make up for not knowing what I'm doing most of the time.

JOHN: What is your superpower and how did you acquire it?

AMIR: I think my super duper superpower is I am very sensitive to pain. So like an example, when you think about copy and paste on your keyboard, like command C, command V, I got to the point where it's like, "Well, isn't it better than instead of moving my left thumb, wouldn't it be better to do the right thumb on the right command?" Because you do command tab and you're like lifting your entire, where you've got your thumb on your left command and the tab keys with your pinky. So your entire hand is off [inaudible], ridiculous. But if I use my right command and tab, then it's totally better. So almost to a detriment, I'm really sensitive to that pain. It puts me in a position where if I'm in a team, I make the pain go away and the productivity benefits that everyone else gets, is worth the effort that I put in there.

JESSICA: Yey, developer productivity. My favorite topic.

AMIR: Developer productivity...

JESSICA: I wanted to ask whether you feel literal pain, like do you have strain injury in your hands or is this a 'I observed that I am doing this in a sub-optimal way'.

AMIR: Yes. Generally speaking, I observed that I'm doing this in a suboptimal way, but I do have wrist pain, which is why I'm obsessed with keyboards. This entire podcast will totally be about keyboards.

JESSICA: [Laughs]

REIN: Can we put a 5-minute time box on the keyboard talk?

[Laughter]

AMIR: Yeah, I do have wrist pain and I'm obsessed about keyboards. But yeah, generally this is sub-optimal kind of thing, but I just take it to the nth degree and it's become a superpower. I've turned it into a superpower.

JESSICA: What do you do when people say, "How much time does that save you?"

AMIR: I say it saves me enough time over a 40-year period because I plan to do this for a very long time. And I also try to explain to them that the cognitive overhead for [inaudible] has to be part of it. It's just a few seconds [inaudible] and I'm like, "Well, it's a few seconds to move the file over and then 15 minutes to go back to what I was originally doing in my head."

ARTY: Exactly. It's about brains, not clocks.

AMIR: Right, exactly.

REIN: The other thing is if you ruin your career because of RSI, then how much does it matter if you save time?

AMIR: Yes, that's it. Yeah, so back to keyboards. I've got a necklace. I built it myself and it's got Kailh bronze switches and it's super clicky.

ARTY: Oh yeah, it is clicky. So that's your favorite?

AMIR: That's my favorite.

ARTY: Do you like the clicky?

AMIR: Yeah, I found that it actually helps with typing accuracy. I went with like a super light smooth switch and my typing accuracy fell.

ARTY: Oh, because it was too easy?

AMIR: I don't know what it is. I think it's like the subconscious thing, when your finger has to click and the audible feedback, there's a component there, but I actually dropped by 3%.

JESSICA: [Laughs] I love that you have a number for that. That's great.

AMIR: Yes. Like I said, I obsess about this thing. Yeah. It dropped by 3% and I was like, "This is beyond the standard deviation that I'm seeing." [Inaudible], this is great. I'm back up.

REIN: Amir, obviously if you have firmware or you can use a Karabiner to set up a configuration where it disallows you from using the wrong shift, for instance. So, if you use left shift in A, it won't do anything.

AMIR: Oh my friend, you should see my Karabiner and Hammerspoons configures.

REIN: I'm thinking maybe it could trigger an electric shock too. That might be good.

AMIR: Just to talk about the superpower, actually I have an Eye Tracker and I use it to click. So I'll look at an area and then I'll press like the layer on my key to [inaudible].

REIN: Oh, my God.

AMIR: The accuracy isn't great though. So the accuracy, you have like about a 200-pixel accuracy issue. So you can use it to click windows and stuff, which is good. You just can't use it to do like find selection. But sometimes it's like I want to click in this text area or I want to swap back to a previous screen. So I just literally look at it and then press a button.

ARTY: Without moving your hands.

AMIR: Without moving my hands. This is the insane issue I'm talking about. I spent $2,000 on the SDK for the Eye Tracker.

JESSICA: [Laughs] That's awesome.

AMIR: Just like ridiculous thing. Why would you do something like this?

JESSICA: But we need people who obsess about that to find the important thing they pass on others. So what have you passed on, you mentioned earlier some of the stuff you share with your team and everyone's productivity is helped.

AMIR: Some of the things that I share, like an example, so this is actually a story from some of my mercenary stuff. Other than like .NET development, and for those that either are or aren't familiar with .NET development or C# development, there's a heavy emphasis on [inaudible] and using the IDE and stepping through code and using that type of fidelity with regards to troubleshooting as opposed to testing or standard or [inaudible] statements. And the really interesting artifact that I found was that if I go around and [inaudible] enough people, the break points are always in the same place because no one communicates with regards to how they troubleshoot. I go around and say, "Okay, his breakpoint is pretty much in the same place as this other guy's breakpoint," which is pretty much in the same place as this other guy's breakpoint. So then I look at the code base and try to find a means to provide some other form of feedback that doesn't require [inaudible]. So that could be [inaudible] statements, that could be like a file that's outputted as an artifact or when you set your log level to a higher level. It could be part of the CI tool suite.

ARTY: An event.

AMIR: It could be an event, yeah. Some of those things that just kind of like ancillarily or automatically happened for them just by being sensitive to, you're setting a breakpoint by pressing a button or using your mouse. Oh gosh, you're using a mouse.

JESSICA: [Laughs]

AMIR: This is already horrible that you're using your mouse. Like some of those things where people are like, "Why would you [inaudible]?"

REIN: The thing about figuring out sort of what is possible -- okay, I've got an analogy. Bear with me for a sec. So say you're playing Civ 6 and you've got a settler and you're like, "Okay, this is a good spot, but there's fog of war there. If I just spend another turn and I moved over there, maybe would be an even better spot."

JESSICA: On a fog of war, that's the part where you can't see the map in front of you.

REIN: Yeah.

JESSICA: So you find a good spot, but there might be [crosstalk].

REIN: Some unexplored territory that's nearby. Or let's say I'm starting to use git and I'm coming from subversion and I'm committing at the end of the day, like a sort of normal thing that you might do. And then I'm like, "Is once a day really optimal? How would I know that?" And so then I set up a thing that would commit to git every time I exited insert mode.

AMIR: I see nothing wrong with anything you said. No, I'm just kidding. [Chuckles]

REIN: [Chuckles] And so I was committing like every 10 seconds, and this was too frequently.

JESSICA: [Laughs] You have to go to the opposite extreme before you can hope to find the right balance.

REIN: If I had never explored that territory, I would never have realized that how much closer to every few seconds I can go versus every day and be productive and find something that works for me. I might've settled on like twice a day, which would have been not nearly enough.

AMIR: Yeah, and I think the keypoint right there is the perspective. Another [inaudible] I use is, I'm not sure if you know Plato's Allegory of the Cave. Are you all familiar with that? For those that aren't, it's essentially this group of people that understand life within this cave and that's all they know. One of them gets their shackles removed. They step outside of the cave and see this whole nother world. But when they come back into the cave and try to explain this other world to everyone else, they're considered crazy and no one listens to them. I think having that perspective is important. It makes you better.

ARTY: Yeah. And that's what makes data useful.

AMIR: Yep.

ARTY: You have perspective and the data gives you clarity or focus.

AMIR: Yeah. And the important question I try to ask myself is relative to what? When someone says, "Oh, this web framework is awesome." Then I go, "Relative to what?" Relative to the previous version of that same framework? Of course it's awesome because that was version 2.0 and now you're on 3.0. But relative to what? And with regards to deciding on do we take the next step [inaudible]? I think that comes with experience. It becomes intrinsic in how you think and you get a feel for it. Is it worth the effort to move another step to find that extra area where I'm at?

JESSICA: But you get that by exploring too far?

AMIR: Yes.

JESSICA: You talked about studying what developers are doing and finding the common points where they're feeling pain without noticing it. Arty has done a ton of work on that.

AMIR: Arty, I'm very intrigued. She's built you up. This should [inaudible].

ARTY: I had a whole chain of thoughts when you started to talk about all the details around keyboards and these subtle things with respect to interfaces. So just to give you problem statement to think about, I fairly recently got a magic leap that I've been having a lot of fun playing with and thinking through what kinds of things we could build if you break all your constraints in terms of how we interface with the machine.

JESSICA: Wait, what is a magic leap?

ARTY: It is an augmented reality device that basically builds a polygon map of the room that you're in. And then you can overlay a 3D world of all sound and a 3d world of visualizations, like you're in a game that sit on top of the polygon maps of your room. And then, you've got a focus controller with an eye tracker. So for example, I can look at something in my room and then I can bring that application into focus. Like I could walk around, for example, look at a thing and snap. And that would be how I activated an application. Like for example, I could have a 3D little address book that's virtual sitting on my desk and I can look at my address book, snap my fingers, and it would open an augmented reality address book that you could then go and interact with in space. And having controls like that, you've got fine grain gesture controls. So we can do motions, we can do sounds, sensing, we can track where eyes are looking, we can track our relative position in this polygon room. And then if I start to think, what if this room is my new IDE? What if this is my next gen IDE and all of the ideas and concepts I'm building with my team, we interact in this room together perhaps. Or maybe I have my own room and you have your own version of the room and we can interact with our networks of thoughts we have active potentially like I can invite you into my plot space. And if we start thinking about if we break all those constraints, what the ergonomics would look like around how would we organize our ideas and why are things together and think together and how would breaking those constraints change things. I'm curious what kind of ideas you have.

AMIR: So, just as an aside with regards to the eye tracker and this idea and just to give you another example of kind of breaking the mold and reevaluating efficiencies and rethinking how we do things. Another thing that I use this eye tracker for is guided record can of course detect my eyes so it knows when I'm sitting at the computer versus not. And so what I did was I had a daemon process and what it does is every second, it pulls to see if it sees my eyes. And if it does, it takes a screenshot of my screen, grayscales it, does an OCR read of the screen itself, gets all processes that are available, exports all that information and uploads [inaudible], my private [inaudible] server. And it does this every second forever and ever and ever for the entire year. So you think about, "What was that one website that I went to and it had dinosaurs on it and I never thought I would ever need to bring down this website and now I'm in this situation where I didn't bookmark it and I can't remember it." Well now, I have a graphable searchable history of everything that I was looking at at that point in time across the history of what I'm looking at.

ARTY: Wow. Talk about an external memory.

AMIR: Yeah, I mean, it's amazing. We have all this power in this technology and just even taking something as simple as a daemon process and S3, forget this augmented reality steps. What we have access to right now, we're not even leveraging it to its full potential. And we've got the superpower, we've got the ability to do this versus someone that doesn't have the ability to talk to a computer, I guess. But yeah, these ideas are worth looking at as an ancillary thing because I do contract work and it ended up helping me out in contract work too because it's almost like a dash cam. It was like, "Oh we don't believe that you worked 15 hours on this." I'm like, Actually, I did. And I have proofs that I did work 15 hours on XYZ. You are getting billed that specific time." So yeah, part of it is I love the idea of all these extended capabilities we have and all these cool devices. It's just unfortunate that we're not even leveraging even simple stuff to [inaudible].

JESSICA: With the computers and the devices that we have now, we are only scratching the surface with the combinations. Like here you've combined an eye tracker, a screenshot, OCR, S3, search functionality and other stuff to build this external photographic memory.

AMIR: Exactly, pretty much.

JESSICA: Yeah. I mean, we're only starting to explore this stuff and you have to, somebody has to obsess over it in order to explore that particular direction.

AMIR: Yeah. I can even think about, I can say like what is the highest propensity of time for me to start browsing Reddit? Is there a pattern?

JESSICA: [Laughs] Is there a particular class that I just hate looking at?

AMIR: Yeah. And I might find out like, "You know what, Amir, you're useless after 3:00 PM. So just take a nap. Just stop for the day." And then, you can measure all this interesting aspects of your own psyche. And then again optimals.

ARTY: So I've been studying what I've been calling idea flow or this flow of ideas between the developer and the software as they're working. And if you think about your thoughts as a process where you're making this continuous stream of decisions over time and you're looking at things and seeing things and making a decision and then you're looking at things and seeing things and making a decision. And we have this context that builds up over time. And so I started thinking about this flow over time, like a musical process and then looking for musical signal changes and creating events based on, "Oh, there's a musical signal change here." What is this event and what if we give this thing a name? And so I started breaking down the process of idea flow as a -- my background is in statistical process control, so everything is a control system in my brain. And so, I started thinking about breaking down a stream of intentions where you've got like a steering wheel that you're working your way toward a little mini goal and you're breaking down a bigger intention into smaller intentions, and each one you're kind of steering the way to the goal. And then you run into these disruptions - what I started calling the WTF events where the mental model in your head and what is going on in the world is incongruence and how your predictions are off and you're surprised by something. And then from that moment that you're in that surprise state, until you resolve that discord, that dissonance, you can't move forward. You can't have flow again until you resolve that. And so I started measuring these things as like TTR metrics and then you could associate these with the particular area code you're in, what your thought processes were during that time. So imagine you've got the snapshot of all the things you're focusing on over time. And then overlaying over the top of that, you've got the breakdown of your big intention into smaller intentions as kind of markers in time. And then during that moment you're troubleshooting a problem, all the things that you look at during that time are going to be highly relevant to that particular problem you're troubleshooting. And so you get a much higher correlation of relatedness during those troubleshooting events than you do any other time. And so I've been working on putting together a way to give us monitoring and feedback loops for all of those sorts of things, such that you can fingerprint all of these incidents that you have in time. So then the next time you run into a WTF event, you have an error on your screen, right? How can we use the conditions of the current situation as a search against your database of past experiences and start building connections of links between those things so that we can take all of our tacit knowledge from software development and figure out ways to make it usable for all of our future problems we run into and figure out how to make it shareable for other people that run into similar problems. There's a whole set of connectedness related issues that there's like a gold mine of potential, I will say.

AMIR: Yeah, and I agree. I think another caveat to that, I guess specifically as developers is that a part of it can be beneficial if it's generic, but you have to tune it to yourself. I almost feel like it has to be specifically tuned and specialized for you as a person. And over time, it's just going to get better and better for who you are and gets rid of all the nuance. I think that's the most important thing is that I want to get rid of as much noise as possible so I can keep present in the things that I want to be present in.

JESSICA: Oh yeah, be present. On Arrested DevOps the other day, Nicole Forsgren was talking about how they defined productivity in a state of DevOps report and it was about being able to do complex tasks and focus on them. And it is that. There's like this developer productivity is about developers actually being able to use our brains for the really hard stuff.

AMIR: Yes.

REIN: One of the things I think that's really interesting here is that you are effectively working to create an environment that enables you working in this environment to solve problems. So you're doing all this work to build up an environment around you that enables you. And in a sense, it's not very much like the traditional sort of Shannon-Weaver communication model where you tell a computer to do a thing and then the computer does a thing and it gives you some information and then you respond to the information, and then you tell the computer to do a thing and this keeps going. It's more that you're sort of working together. You, as a part of this system, are working towards goals. And you specify the goals because you are human, but it's a mutually dependent sort of dynamically coupled system.

AMIR: Yeah. And just to add to that, I do it on an assessment from the perspective of I'm one person and I love building video games and I'll occasionally have people that I collaborate with here and there, small collaborations. But I'm not the type of person that will have a team of 30 people. So if it gets to a point where I can't scale, I have to keep a pin on my upkeeps and make sure that they don't hinder me from doing all the things that I want to do. So that's one of my big motivations is that I can't clone myself and I don't want to do a big team, so how do I fix this problem that I have? And it's about saying, "Well, I can increase my own productivity to the nth degree." And it starts out really slow and it's difficult. But with every new knick-knack, every new skill, every new automation, every new trick you learn, it compounds over time. So like for example, you had that thing where it's like you're trying to get the auto commit, git commit stuff to work well, and every time you save a file versus once a day, you haven't derived some kind of filewatch out of that. And that's an artifact that you can use moving forward. That's not something that you have to figure out a game of how to reliably watch a file and make it do something. And so later in the future you get to leverage all the "wasted time" you've had in the past.

JESSICA: Ooh yeah, yeah, yeah. I think of it like you gain that kind of skill of file watching, for instance, and you grow a couple inches and you can reach things that are on a higher shelf.

AMIR: Yes.

JESSICA: And suddenly you start using those champagne glasses, whereas before you would just pour the champagne into teacups because that's what you could reach.

AMIR: Yup. And then it's like, "Well, I'll filewatch this thing and then I'll filewatch that thing." And then you're like, "Man, it's a little painful to spin up this filewatching." Then you streamline that and then make that automatic and it gets to the point where you get fast, you get very fast.

REIN: Key insight of this area is that you're not improving your performance per se. Like if you've removed yourself from this system, you wouldn't have the same performance. You're improving the performance of a system of which you are a part.

AMIR: Right.

ARTY: It seems like automating leverage, like you're looking for opportunities to get more leveraged by automating some little bit that gives you kind of more power almost.

AMIR: Yeah, and the interesting part is there is a deferred gratification because it is really, really hard to get started at some of this stuff just because for the eye tracking [inaudible], I mean I had to deal with C drivers, straight C for the eye tracker, I had to learn S3. I had to learn about daemon processes, OCR, compression. It took time to get to that point and it's a lot of effort.

JESSICA: The obsession helps a lot.

AMIR: Yeah, the obsession helps. [Laughs] Can we call it a superpower? No, I'm just kidding.

JESSICA: [Laughs] I mean, it looks like that to people outside. But as long as it's not affecting your life and taking you away from your other responsibilities and as long as you still remember to shower at least once a week, then it's not an unhealthy obsession.

AMIR: Right. [Crosstalk} So I mean, that's the great part of it, I guess.

JESSICA: You said 'had to learn' and yeah, you were driven by this particular purpose, this goal that you set to learn this thing, but that learning becomes a part of you and makes you more powerful in a diversity of ways because all of these pieces can be combined with a thousand others to explore more possibility space.

JOHN: Yeah. Something I try and emphasize when I'm talking about, especially in debugging context but also like in building a new project context where you had to build up all these little pieces in order to finally get them to solve the problem you are trying to solve. But the little pieces you learned on their own are valuable and can be recombined. I'm working on a talk right now that tries to put the emphasis on those little bits of learning so that you can, especially when you're debugging and like a lot of the things you ended up learning aren't things that solve your problem because they're there before you found the one thing that did solve your problem. But those bits of learning are still valuable and treating them as such makes it feel much less demoralizing to spend X hours banging your head against the problem when you realize you actually were learning new things the whole time.

ARTY: The other thing I'm seeing that's kind of interesting is you stitching a whole bunch of things together as a way to create something new because technologies aren't, I mean they've been out there for a long time, but you have this idea of what you wanted to track in terms of your process and then you thought, "Okay, I want to make a snapshot of the thought." What was the thought in this moment? How do I capture all the information possible about what was going on in this particular moment. It makes me wonder too, if you started adding some various kind of automated indexing in that, like they have those brain controllers where you can basically fingerprint the electrical signals coming off your neocortex at that moment in time kind of like do a simulated unfold of your neocortex and fingerprint, your thought in your brain. And I wonder if you could use that as a search such that then you could think that same thought later. "What was that dinosaur page?" And if that can pull up the index to the dinosaur...

AMIR: You are dangerous for me.

ARTY: [Laughs]

AMIR: I'm over here like looking at foot pedals and potentially ways to incorporate this and you're like, "Oh, just jack right into your brain." I'm totally doing this.

ARTY: [Laughs] [Crosstalk] STK for the EKG.

AVDI: So for the record, I have foot pedals. As a matter of fact, I brought my Kinesis, speaking of keyboards and optimizations, I brought my Kinesis and my foot pedals. I took a checked bag so that I could take my Kinesis and my foot pedals with me.

AMIR: There's nothing wrong with it. I am not shy. Yeah, obviously. You know what I mean?

AVDI: Obviously.

JESSICA: It was that, or I spend $500 buying another set. It'll happen.

AVDI: [Laughs] Eventually.

JOHN: Did you say Avdiously?

JESSICA: Avdiously.

AVDI: Oh yeah, that's right. It's one of your neologisms, isn't it?

[Laughter]

AVDI: Anyhow, so with that said though, there's a flip side to all this which is the side that I tend to take in these discussions, somewhat ironically, considering my foot pedals, but it's that I've observed -- and I've observed this primarily in myself -- I've observed that developers are extraordinarily good at optimizing processes. And a lot of what we do is optimizing processes. And a lot of what we do for a living is optimizing other people's processes. But in the process, we often become very, very good at optimizing for local maxima and completely missing other maxima. My favorite easy tax as example of this, I think is I was an Emacs head for a long, long time. Spent, I don't know, well over a decade learning to use Emacs really effectively and I've used it for writing a lot of my books and stuff. And at some point in there, I also finally taught myself to touch type and I was touch typing my Kinesis.

JESSICA: [Laughs] I like that you had 10 years of optimizing Emacs before you learn to touch type.

AVDI: Yeah, isn't that great? Priorities. [laughs]

AMIR: Again, there's nothing wrong with what you've said so far.

AVDI: And like increasing my speed of putting words out. And then one day -- well it's not really a day, but it sounds better this way. One day, I started encountering a lot of RSI issues and I tried many different things to ameliorate them. But one of the things that I started doing is I started using some actually decent text to speech software, like commercial text to speech software, not for coding. I haven't figured out how to make that work yet. But for pros writing. And what I discovered is I could have optimized for my keyboard text output all for weeks and months and years, but I will never be able to communicate thoughts as fast with a keyboard as I can speaking. And if text to speech can actually keep up with that, it's a really efficient way of doing it. But it would have been really easy to just keep optimizing for that local maxima of, "Okay, I have a metric which is words per minute."

ARTY: And typing accuracy.

AVDI: Yeah. And typing accuracy.

ARTY: We can measure those.

AVDI: So yeah, accurate words per minute. And so just keep increasing that, keep increasing that with new devices, new pieces of software and stuff like that, new training. And I could've completely missed the fact that there is this whole other mode which just sort of bypasses all of it. Yeah, so local maxima is a thing that's really easy to fall into, I think.

REIN: So there's something I think that unifies both what you just said and what you were talking about how you were doing eye tracking thing, which is that approaches are conditioned by pragmatics. In other words, the fact that eye tracking exists and it makes an approach possible for you that wouldn't have been possible. If eye tracking didn't exist, you wouldn't even have been able to think the thought, "Hey, could I use eye tracking to solve this?" Likewise, if high quality text to speech software didn't exist, Avdi, you wouldn't have been even able to think the thought, "Hey, could I just talk my books into the computer?"

JESSICA: But then, Amir found that eye tracking was a possibility but it was completely impractical. But he made it work anyway and that gives him the opportunity. He might find out that this is perfect. I mean, especially for people that, then you get into accessibility. People who have an even harder time moving their hands than Amir does. And then he has the opportunity to make it into a product that makes it practical.

REIN: Pragmatics are also determined by approaches. What we want to do determines what we try to do. It's a very cool feedback system.

AVDI: Amir, did you have something that that feeds into game development from the local maxima thing?

AMIR: Yeah, and I completely agree with your local maximum. And it's something that is really with me having all this productivity to stay as a small team or solo work with some of my games, it's also a detriment because now I'm in a [inaudible]. And there's always that concern of am I in a local maximum and have I missed something just because I'm working with myself and optimizing my own stuff as opposed to maybe saying what others do. And it's a struggle. I think a part of just being curious about different things helps with that. So it's this new, like the, what was that? It's like a console, it's like yellow and it's got this like weird crank, like the most ridiculous thing. Why would you ever want to work on those? But just my curiosity is like, "I'm totally getting this. I'm going to do something with it." So I think that helps compensate for the local maximum. And with regards to that, when I see others work, I try to think of is this the best way or is this the most optimum way to work? And with regards to game development, I feel that we are in a horribly horrible local maximum when it comes to game development specifically because if you think about we have, I guess, 50 years of precedence that says this is how you shall make a game. And you've got this concept of sprites, entities, nodes, physics bodies, these are all just nomenclature that's out there. No one is taking the time to then step back and say, "Wait, hold on. We were dealing with hardware that was from 50 years ago. We were dealing with compilers and tool chains that are 50 years old." And some of these concepts maybe don't hold water and maybe we're in this local maximum of this is how you shall build a video game. And no one took the opportunity to come out and look down from [inaudible] somewhere else. I think the best analogy I can think of was with Rails back in the day and look at all this stuff I'm not doing. But you have Enterprise JavaBeans, you've got Spring, you've got all these web frameworks that 'this is how you do web', this is how you're supposed to build things. And then Rails comes and says, "Maybe not. Maybe we can do it this way." And maybe it's better. Maybe it's faster and yes, it's going to have [inaudible] to it but that was definitely something I found with regards to mobile development and game development. We're in a horrible local maximum [inaudible]. And that's where I guess with the new initiatives and the new products and kind of what I've done over the past five years with the games that I've built, I've explored this other approach to doing game development that I think may interrupt the market or cause our people, which is what I'm hoping for at least.

ARTY: Interrupt, nice.

JOHN: It reminds me very much of Bret Victor, had a talk a while ago called The Future of Programming. He set up his presentation very much in a, like 1975 context where he's wearing a pocket projector and he's using a transparency projector for this whole talk. And he set himself in the time of 1975 saying. "We've got all these things we do to develop code. We have text files and compilers and hard drives. And surely by the time 1990 rolls around, we will have come up with much better ideas for how we can organize all of our development tools." And of course everything he points out, which was a great idea in 1975, is something we're still stuck with.

AMIR: It's insane. We still keep doing it. Another frustration I have is that no one questions it. You get into this situation where it's like, why do you do it this way? So, a specific example with games is -- this is concept of a game loop. This is the thing that runs as fast as possible. Some of them are request animation frames and you have all these gamers out there. And the right way, the way you're supposed to do it is this game loop or this on update event has to have a parameter passed to it called Delta Time. And this Delta Time is a float value that gives you the time between your last render frame and your current render frame. And so when it comes to game development and building out a game, building out physics, building out rendering, how your character moves, you're supposed to multiply everything by this Delta Time. And it's just this massive cognitive overhead. So, [inaudible] of a jump power, you can't just say, move the character by this much jump power. No, you have to move the character by this much jump power multiplied by the delta time. And you ask, "Why are you doing this? Why are you doing this insanity over and over again?" And it's like, "Well, this is just how we do it." And that's such a weird answer. It's not enough for me. "This is how we do it." Why? Why is it how you do it? I feel the frustration and it's unfortunate. So we're here in 2019, we're still using text files and compilers. Why? Well, this is how we've always done it.

ARTY: I think it takes a certain kind of mind to be willing to step back from all your foundational assumptions, everything you know as the way it's always been done, to look at the world through all the lenses that are available, to look through it at and go, "Okay, what are we actually trying to do here?"

JESSICA: To step out of the cave?

ARTY: Yeah. To step out of the cage.

JESSICA: Because it's brave to do that. Because as soon as you -- I know you experienced this -- as soon as you go back in and start talking to everyone else, they think you're nuts.

AMIR: Yeah. People think I was complete nuts for creating video game using a dynamic interpreter language. They're like, "There's no way this is going to work" And it does. And the thing is it works because one, we've gotten a lot smarter with how we do [inaudible]. The compiler tool chains are much more advanced with [inaudible] and LLVM and how they do all their optimizations. There's so many things that are just better. They're just better. And it's good enough or it's a possibility now. [Inaudible] functional programming, I think, you see this huge researches of functional programming because we actually have numbering models and computer power to support that kind of immutability. And now that we have that, there's so many way cooler things that we can do with that power that we may not have been able to do before. And you should see people's expressions on their face. I asked one of my colleagues, "I want you to [inaudible] and I want you to render as many sprites on the screen as you can." The sprite moves in a diagonal up into the right and then wraps around. What is the limit? They hit about 2,800 sprites. And this is [inaudible] compiled language. This is how you're supposed to do game development. You're supposed to do [inaudible] type language, you're supposed to compile, you're supposed to create sprite [inaudible] and all these complex classes and they're supposed to do it. And then I did the same thing with dragon [inaudible] and I was at 1800 sprites without any kind of optimization in a interpreted language. And then when I went ahead and did the optimizations, we're at 4,500 sprites while Unity's pushing 2,600 and can't retain the 60 frames per second. So they have to put a Delta time and then do all the multiplications [inaudible]. They asked me, "How are you going to do this?" Well, unity is using an arcane, a version of [inaudible] and the arcane version of [inaudible]. It's GC is 10 decades old. It's compiler tool chain has to go from C# sharp to an intermediate language that Microsoft created, MSIL. That MSIL gets converted into C++, C++ gets sent through [inaudible], which is converted into an intermediate representation, which then is converted to [inaudible]. And so all those things combined, you get a copy of a copy of a copy of the copy, and you're left with just an optimize code. And I've been doing the same thing except I'm going from interpreter to straight C via C extensions and C [inaudible] right down to [inaudible]. And it was because I'm taking advantage of what is available today, if that's possible.

JESSICA: Yeah. As Avdi pointed out to me a minute ago, this is an example of you're building on a world that didn't exist when they built Unity.

AMIR: Correct.

JESSICA: And so Unity is living in the past in that sense.

AMIR: I understand that can create breaking changes.

JESSICA: Exactly. Breaking changes because everyone who uses your stuff holds it back.

AMIR: Yeah. And I'm sure I'll be there at certain points too.

JESSICA: That's a win.

AMIR: Yeah. It's a win. And it pushes the next step. People are still just like, "I don't understand how you do this kind of thing."

REIN: So Arty, you know how you were talking about questioning fundamental assumptions and then we were saying, well sometimes it's not received very well when you do that. I think if you think about Kant, what he did was he did that too much.

JESSICA: Well, somebody has to push it to too much so we can find the balance.

REIN: Exactly. So Kant program of doubt was, I'm going to question what I can know to be true. He went all the way back to thoughts are happening, therefore something must exist that is thinking them. So I think the thing is if it's not working, do more of it.

AMIR: One thing to add to that, and I think it goes back to this idea that this is how we've always done it. I think that I've tried to capture, I think it's because of Ruby that I have this perception that I didn't have before, I'll call it Continuity of Design, TM, I'll TM that. The idea and the general criticisms that I've had of domain driven design in the past is that there's no continuity with regards to how do I start with an if statement, an [inaudible] statement and move it to a more complex end structure or architecture. And not only that, but there has to be a spectrum saying an [inaudible] statement is totally fine. Then moving to this other more complex structure is totally fine. And moving to this other more complex structure is totally fine. When someone sees a piece of code and they say, "Oh, this is an aggregate route," and that's totally fine. Your experience have shown you the final distillation of this construct and what it can become, but what are other valid points on the spectrum? Why do I have to go all the way to an aggregate route in its [inaudible] form for it to be valid. And by exercising these continuities, these points of continuity on the spectrum, you remember where you came from. So, with regards to game development, the idea of like, "Oh, this has to be an entity component system," or, "This has to be in this kind of architecture." How do you evolve to that? How do I start with just a sprite on the screen and what forces me down that progression and when should I do it? Do I have to do it upfront? Can't I do it later? I think with Ruby, it's such a beautiful aspect of the language because you can start with just one line that's a variable name. And then you're like, "Well, these variable name needs to be a function." And because of the optional parentheses, the call side doesn't have to change. You can just turn it into a function. And then when that function needs to be used in two places, you put it into a module and then you do an include. And then when that module needs to hold some kind of implicit state, you move to a class. But at no point are you forced to say thou shall create a class. You can start with a variable. Then they can function then make it a module. That continuity of design is intrinsic in the Ruby language. And I think I grasped onto that specifically with the game development because that's just kind of have to work that way. Start with something simple, get something working and then through experience, know the spectrum, know that this will eventually become a prefab or some kind of class or component, but I am not going to go there yet. I'm going to wait till the last responsible moment to go there because people waste so much time taking it to that final statements of I've done this 50 times. And then the general response again is one, we've always done it this way, and two, it's going to save me time in the future. Maybe it will.

JESSICA: But is it going to save you brain in the future? No, it's not. Because that more complicated structure is actually harder to read and understand.

AMIR: Yes. And it's a detriment to projects because what happens is that I go onto a project and the project starts off, it's a brand new Greenfield project and every developer says, "I want to do this right." And I'm like, "I don't want to do it right. I want to categorize all these different patterns because when there's a production fire, guess what's going to happen? We are not going to do it right." And we're going to skip the test or we're going to skip whatever, like XML documentation. We're going to skip those things because we're on a deadline. So I'd rather discover valid points on that spectrum so that when I have to make a decision of doing it "right versus fast", I can make that decision objectively and not jeopardize the health of the code. And so I think that continuity of design in the spectrum is so important. And then when someone asks you, why do you do this way? This is why, this is how we start, this is how we ended. And we've seen this pattern enough times to know that it's best to just go ahead and do the same thing for this category of problems.

AVDI: The thing that you described in Ruby is definitely one of the things that attracted me to it as well over the years. That ability to sort of start from just like a single line script and gradually move to more of an architected system. And I've seen a few other things over the years that have that property, but it's kind of rare.

AMIR: It is.

JESSICA: Gradual typing.

AVDI: Gradual typing is a good example of that where you can just start adorning your code with types without having to go through this whole like phase shift of shifting to a different language or something like that. There's actually a term for it. Christopher Alexander, the guy that invented the idea of design patterns in the architecture world, which is where we got them from in software. He has a term called gradual stiffening, which is where that idea of being able to sort of gradually add ceremony to a design rather than have to go through these sudden phase shifts where it goes from a little bit of complexity to we have to get to the next level of organization, we have to go through this whole thing.

AMIR: Yeah. And we try to skip and compensate for it by always taking it to the final step. We could just say, "This is not sustainable. We can't do this."

JESSICA: But if you think you know the right way to do it, you're definitely wrong. Because development is an exploration of the possibility space.

AMIR: Well, I was saying with game, even more so because the novelty is what makes a game a game. So it's funny that if I can actually derive an inheritance hierarchy from a game, I get worried because it's like this game is going to be boring because I have a reuse. [laughs] I have a reuse in this game, so it's going to be boring. Holy crap. I got to worry about that.

JESSICA: You have what?

AVDI: Have what?

AMIR: Reuse.

AVDI: Oh.

AMIR: Reusing my code.

JESSICA: [Laughs] Oh God, that's beautiful.

AMIR: Because the definition of a game is novelty. So if I find that all these components end up deriving from this one like boss class, I'm like, "Holy crap, I'm in a lot of trouble," because I don't have enough cyclomatic complexity in this game. [Laughs]

JESSICA: Yeah, because that's life. And what excites us about life is the novelty.

AMIR: This idea of gradual typing works the same way and the stiffening is, I don't know what I'm building. When a [inaudible] type language asks me, "What is this character you're building?" "I'm building a game. I don't know what my main player character is even going to be." So how can you demand properties of this character upfront when I myself am still exploring these ideas. Yeah, Ruby game development is just beautiful and then the gradual typing, it's that local maximum that people are in that keeps them from saying these "obvious benefits" for using a dynamic language.

REIN: Can I just highlight that you said increased cyclomatic complexity to paraphrasing here, increased variety.

AMIR: Yeah.

REIN: And that's not an accident because complexity and variety are two sides of the same coin.

AMIR: Yeah.

AVDI: The novelty, yeah.

AMIR: The novelty is what's so interesting about it, yeah. It's a weird thing to say. It's like, "This code looks too good. It's too structured."

AVDI: I think this is closely related to the quality of richness, which is something that we very often don't optimize for, to our detriment. Richness, that's another of those things that I think of, Rein, as being like these are two sides, richness and complexity. You don't get richness without complexity, but richness is good.

JESSICA: Yeah. And richness is like the quality that a hundred year old neighborhood has compared to the brand new subdivision. And a hundred years ago, my neighborhood -- well, okay, 80 years ago, my neighborhood was a brand new subdivision and all the houses, if you get inside them, you can almost see that they used to have the same floor plan, but now they look nothing alike.

AMIR: Yeah. And it's great because...

AVDI: Christopher Alexander would approve of that.

ARTY: Yeah. It's beautiful.

AMIR: Yeah. And that kind of evolutionary aspect, it's a quality of a legacy. I really dislike when people say legacy code is bad. It's like this legacy code is why you're employed right now and there's a lot of truth in all this richness that you are not taking into consideration.

JESSICA: Amir, I'm curious. So we just said that this richness is a quality of legacy and it is. So if you look at like the unity game engine, that people are using and held back by because it's built on old assumptions and yet it's built with the legacy of it solved a lot of problems. Some of those are reasons or historical reasons. Some of them are still valid, some of those problems don't exist anymore. And the house next door doesn't have air conditioning yet because it's got radiant heat and installing air conditioning is hard. So how do you balance that appreciation of richness with like [inaudible] to build on the power of the modern world?

AMIR: I think the first step is just understanding. An example, it's got delta time. And I understand why delta time is there from a legacy standpoint. It was there because [inaudible] vary. It was there because we want to push [inaudible] to the limits. We want to go as fast as possible. As hardware gets better, your game just gets smoother and smoother, which is fantastic. It's a good premise. And so I have an understanding of why delta time is there. Then I also have an understanding of why we jump in delta time now. And a part of that is for 2D games, 60 frames per second is trivial to do. If you can hit 60 FPS on a 2D game, you are writing a very rich code. So then the other thing is with regards to this day and age, specifically for mobile, the [inaudible] system actually pins you to either 60 frames per second or 30. There is no in between. So when you think about delta time, it's either going to be 0.17 for your frames or double that, and that's all you have. So the developer's going through all this effort to do this multiplication and in my head I'm going, the whole reason [inaudible]. And the platforms are going to literally only have two steps, 60 and 30. What are you doing? Why are you killing yourself with this? Then it's like, well yeah, it's for the better video cards and whatnot. And then I told them and I responded like, "Okay, I understand for 3D games when you want to push the limits and do that. But the 2D games, 60 frames per second is 60 frames per second." There's no compelling reasoning rendering at 120 frames per second.

Another example in unity is that they have a concept of a vector class for 2D games. So when you say the location of the sprite is equal to this vector three. I'm going, "Vector three? What? We're dealing with a 2D game, it's X and Y. Why do you have a Z?" And the reason is because unity started off as a 3D engine. So they added to the after the fact and then they reused some of those previous concepts and [inaudible]. But at least I understand why that [inaudible] is there. And so I think the respect for the legacy is not to immediately say this sucks. It's to say, okay, this is there for a reason. I have no idea why. But it's there for a reason. This if block with nothing inside of it, with a [inaudible is there for a reason. I have no idea why, but I need to understand that before making a claim to its viability in the present.

JOHN: Reminds me of 1989 when I got my first PC. It had a hardware switch on the back that would switch from 4.77 megahertz to 8 megahertz. And for a long time I wondered why you would ever want to slow down your CPU. And I learned that it was because certain games had been written with a fixed clock speed and if you run them at 8 megahertz, everything would double and you couldn't play them.

AMIR: Oh God, we're right back to that now. [Laughs]

REIN: I had an entire box of games, like 800 games, that were all that way. And I was running them on a 486 and I basically couldn't run them.

[Laughter]

AVDI: Wing Commander on my own 486 was either -- I think it was like Wing Commander 1, but it was too fast or too slow depending on which position the turbo button was in.

AMIR: Yeah. And we're right back to it. Great. Now every iPhone and Android game out there is pinned to 60 hertz. Thanks. We're going to recreate these things 30 years later and like, "We can't play any of this stuff." [laughs]

AVDI: Because hertz doesn't make any sense anymore.

REIN: The variety that's in Unity is a response to the variety of things people want to do with Unity.

ARTY: And have ever wanted.

AMIR: And have ever wanted.

REIN: Yes.

AMIR: I think that goes back to that whole idea of continuity design and something that we, I think, miss is the discoverability of these continuities. So you think about the spectrum and then the next obsessive step is, "Okay, how do I position a framework? How do I position a code base such that someone writes in [inaudible] statement then the compiler or the language and the framework says, "Hey you know what? You're getting to the point where you probably want to take a step to the next point in that spectrum. One thing with the game engine that people says, Amir, you don't have any documentation. And the API docs are a little sparse." But it's because I think API docs are a sub optimization. I need to think of ways to let them start with the hello world and discover the next pieces without having to go to Stack Overflow or docs. It's like the engine tells you, "It looks like you're doing this," hopefully not a clicky type of thing, but just this idea of can I create a AST of the current code of their current file and make some assumptions or try to do some kind of heuristics that helps me communicate to them that, "Hey, you're doing this. It's probably better to use this new class because this does exactly what you want to do." And I think that's something that's horribly missing in Unity and why you get all of the things that everyone ever wanted and there's like a checkbox for that, [inaudible] say, "Oh, I want to do this. There's a check box for that." But no one remembers where any of the stuff is. It sucks.

ARTY: Yeah. This is where languages like Elm and Elixir are demonstrating that it's all about the error messages that you give people, the help and guidance messages. I finally was sitting back here thinking about Rein's question earlier about being a weirdo or being on the edge, being an outlier, thinking differently than everyone else. And the thing that I was thinking about is socially, there's this pushback against being a different sort of weirdo. And people that are more extreme create space for others to be within that boundary. So it's like you push the outer limit on what extremeness is socially acceptable by being out there and different. And then other people are like, "Oh, I can be a little more extreme." And so, people that push boundaries tend to create a gravity that pulls that direction. And when these outliers become centers of communities, their values in the communities they build around them tend to echo whatever philosophy they believe and demonstrate as just a person being in the world. And so you see these pockets of communities center around certain values. And so I started to think about the way that we create movements for these new ways of thinking. Who are the people that are like totems for new ways of thinking out there or values that we want to adopt and sit around in our culture?

AMIR: I think a part of that [inaudible], how we phrase some of the approaches that we take. Do any of you play Smash Brothers?

REIN: Yes.

AMIR: We have a couple. Avdi, you are very proud and raising your hand. Can you give me a little bit of background and maybe you can help me with this explanation.

AVDI: I don't know. I just like Smash Brothers.

AMIR: Who's your main? Do you play tourney style or...

AVDI: What's that?

AMIR: Okay, never mind. I get it.

AVDI: I like being in a room with a bunch of people who are playing Smash Brothers. That's what I like. I like Marth a lot. I like Samus a lot.

JESSICA: I only play Wii Fit Trainer.

AMIR: Wii Fit Trainer. That's a good game.

AVDI: The character.

AMIR: Oh, the character.

JESSICA: No, the Wii Fit Trainer is one of the people you can fight with in Smash Brothers. So, Smash Brothers is like everybody who has no business being in a contest with each other fighting.

AMIR: Yes. It's so awesome. In the wider -- just the general game, specifically with Smash Brothers, there's this concept of a meta. What is the current meta? And the idea there -- and that word is very key, it's meta. What is the meta? And this started back in Super Smash Brothers Melee which came out I think 2001. There's a three hour documentary on YouTube about the history of Smash Brothers. You really have to like Smash Brothers to get through the documentary. But it's really good.

[Laughter]

AVDI: I cut my teeth Melee, yeah.

AMIR: And so the beauty of Melee was that over the years, they had many, many competitions. And the current meta or the meta for Melee was that for you to win a tournament, you have to be good with Fox, Marth, Sheik. And that's basically it. Like you had to be one of those three people to have any kind of fighting chance against in the top tier competitive [inaudible]. And that was the current meta. That's what it was. And happened was that someone came in, they actually have the term of the five gods and then the plus one came almost a decade later. And the plus one, he used Yoshi. And this is effectively...

ARTY: With the five gods, do we mean like players?

AMIR: They're players.

ARTY: Okay.

AMIR: Yeah. So they were crowned the five gods over that decade and then someone came in and he became a demigod and he used Yoshi.

JESSICA: Which threw everyone off because that's not who they were used to fighting.

AMIR: Yeah. And so it's off meta. And the thing was, was that he was so good. It was unreal that someone could be the character that could counter or that could contest all of the current aspects of meta. And the problem I think we have in the technical community is that we don't use meta and off meta. We use best practices and everything else that's not best practices. And it's like, no, that is totally the wrong way to think about it. There is a current meta and I'm not disputing that, but there are off meta solutions and usually the people that provide or try to present off meta solutions know the meta solutions incredibly well. The only way he was able to do Yoshi and play Yoshi the way he would always play it to counter the top three current meta [inaudible] was because he knew the meta so well and he was able to extrapolate and say this is the off meta answer to what the current meta is that will upset everybody.

JESSICA: So if you understand Unity really well and the problems that it solves, then you can find the problems that it doesn't solve well and use an interpreted dynamic language to make those claims.

AMIR: Exactly. And then the problem goes that the immediate response I get for presenting something like that would be, that's not best practices. But if I was in a fighting community, if I was playing Melee, they'd be like, "Oh, that's a nice off meta. What you're doing is off meta..."

JESSICA: Because they can't deny that you won. It's a fight.

AMIR: It's like what you're doing, Yoshi guy, what you're doing is off meta.

JESSICA: So you have to start a fight by asking them to make sprites move diagonally.

AMIR: Unfortunately. And it's just the presentation of it. It's this acceptance that what the general populace or the greater populace is doing right now, it's not a best practice. It's the current meta.

JESSICA: There is no absolute best. It's just what are people doing right now.

AMIR: Yeah. And the current meta is to build stuff with this technology stack.

JESSICA: And people like that because it's safe. They won't get fired for doing it.

AMIR: And that's totally fine. There are benefits to being on meta because there's precedents and it's established as meta.

JESSICA: An interoperability.

AMIR: And the challenge comes with presenting a dissenting opinion. When you say meta and off meta, it's different than saying best practices. And what is the opposite of best practices?

JESSICA: Other practices?

AMIR: Crappier? There's no good way to frame not best practices. And it also puts out there that the meta evolves. It's an evolving thing. And then off meta ideas will come and off meta challenges the current meta which forces the meta to change. It doesn't necessarily mean that the off meta is adopted, but it forces the change. And these off meta solutions and meta solutions need each other. And right now, I don't think we have the technological space.

ARTY: So to rephrase in a technical context, looking at best practices. If we understand the current best practices in software development well enough that we can also see what the side effects are from those particular optimizations what is not getting optimized, what's getting left out, then we can find the off meta solution that optimizes for these other sorts of things in the software world to give us new sorts of leverage and advantage that people maybe aren't thinking of.

AMIR: Yeah, and I think the other emphasis is as a community when you stop calling best practices.

JESSICA: Yeah, that's a phrasing that holds us back. And this then is the balance between the richness of legacy and the modernity of newer solutions. It's really understanding both the historical reasons that are embedded in the legacy and the new things that are available and new possibilities that you're exploring that people couldn't explore before.

REIN: And also understanding that the goals and needs of the practitioners, the people actually using this stuff.

AMIR: Oh, one final comment. If all the game engine stuff and all the cool things I was talking about actually sounds really cool, go to fiddle.DragonRuby.org and you can try my off meta solution to game dev in the browser. Go to [inaudible] with an editor side by side. There's a tic tac toe sample up and a pong sample up both under like 150 lines of code that are off meta. Completely off meta. But yeah, fiddle.DragonRuby.org. And from there, you will be taken to [inaudible].

ARTY: All right, so this is the point in the show where we go into reflections and we all wrap up any final comments we have. And Amir, you get to go last. Jess, you want to start?

JESSICA: Sure. I had a bunch of thoughts but I'll just stick to one. Amir mentioned the phrase a pin on my upkeeps and I thought that was really interesting as in that the more you limit overhead, if you're constantly reducing overhead, reducing the time it takes you to do the things you need to do, then you can continually do more things. Avdi, do you want to go next?

AVDI: Sure. So I'm just still rolling around meta and off meta in my head. I think that's a wonderful framing and I think it's going to be buzzing around in my brain for awhile.

JESSICA: We can say mainstream and new stream.

AVDI: Maybe.

REIN: Counter culture.

AMIR: I think we just need to play more Smash Bros.

JESSICA: [Laughs]

REIN: Also true.

JESSICA: So hard.

JOHN: One idea that stuck with me from earlier was the discussion about the smooth conceptual gradient between the simplistic implementation and the complex implementation. I can't remember the exact phrasing that we used, but that really struck with me. And what popped into my head during that discussion was premature abstraction is harmful just the same way as premature optimization because you're going into an abstract state that you don't know that you actually need long before you know what actually needs to be built. And I think that's a useful way of thinking about that. And also just the discussion of that continuity of design -- yes, thank you, Jessica -- is a youthful way for me to think about one of the ways that the Ruby language works and to advocate for using simpler solutions as the initial build and then waiting for an evolution to make them more complex. And so, I think that's going to be useful in the future.

REIN: Okay. I have a thing. Oh boy, is it a thing? So we've been talking a lot about continuity and the flip side of continuity is discreteness, of course. And humans have a very [inaudible] continuity and discreteness. We are very good at forming a continuous representation of something discreet and a discrete representation of something continuous. So continuity of design is based on some discreet thing we're doing, whether it's a program transformation or typing individual keys into the keyboard, something underlying that is discreet. But at the same time, something underlying that i.e. human cognition is continuous. And even the dichotomy between discreet and continuous is up for debate. We're very good generally speaking in managing these things, but we also have heuristics that fail us and we make category errors and things like that where we have a failure of mistaking something discreet for continuous. And I think it's really interesting for me to tease out how these two things interplay.

ARTY: One of the threads I see through all this is this process-oriented thinking. And if we look at everything as a process, if we look at everything as spectrum over time, then there's an immediate set of problems that emerge. And if I imagine the thoughts in my head of where I'm at and things I'm thinking of as like a graph where from this perspective, from this vantage point, I can see a variety of things in front of me, I might innovate and jump to any of those things I can see. And I can spend time investing and exploring and putting more things on that map, or I can jump to one of the things available on the map. And if we start thinking about our thoughts and exploring our thoughts as a graph of new places we can reach that has spectrum in the nature of the movements, this idea of discoverability is essentially dimension that causes other options to be seeing on the map. And so when I think about process-oriented thinking, the meta of process-oriented thinking is this landscape of discoverability as a beautiful thing.

AMIR: I guess for my reflection, I am going to just [inaudible]. But talking about my competitor in the 2D game engine space, I think during this conversation, I have to be really cognizant about being consistent with my philosophies [inaudible] legacy code even when it comes to a competitor. The marketing side of me says these other 2D game engines are "horrible". But at the same time, they have a legacy that I need to respect. And especially in those situations where I'm dealing with a competitor or something that I may have vested interest in with regards to seeing them do [inaudible] myself, I have to be extra sensitive to respecting that they did [inaudible].

ARTY: Thank you for joining us, Amir. This was a lot of fun.