Welcome to my first "My week from git diff", where I take a look at the changes to my Personal Knowledge base over the past week. Here's the diff:

In the past week, I was fascinated with developments going on in the AI space, spent some time building a prototype web app, and did a lot of work on a particularly intricate work project.

AI

In general, I follow the field of AI moderately closely. This week I was fascinated by the letter that was put out to pause development on AI. The key resource I'll share on this point is this live stream between Andrew Ng (AI Startup founder) and Yann Lecun (VP & Chief AI Scientist at Meta). I lean towards the opinion that while there are important dangers, risks and open issues with the products of advanced AI, a pause on research is not the way to address them. Andrew and Yann provide some thoughtful, non-hyped views on the topic.

Perhaps more interesting to me, is how the topic of AGI - Artificial General Intelligence has been brought up through these recent developments. Currently, I'm learning about David Deutsch, in particular, reading his book "The Beginning of Infinity." A large topic of the book is the nature of AGI. I found that David's explanation of AGI, while written 12 years ago, is monumentally helpful in understanding the fear-driven aspects of the letter and supports Lecun's explanation of how GPT-type models are fundamentally not the blueprint for AGI. On the other hand, David points out that all "jumps to universality" - an incremental improvement in a system that massively extends its reach - have happened by a small change to a system. What do you think: will we arrive at AGI by making incremental improvements to existing technologies? If so, how many incremental improvements are we away from AGI?

Side note: I highly recommend reading this book (or learning about the ideas in it) for anyone interested in understanding the nature of knowledge, creativity, scientific progress, and becoming better at reasoning.

Anyways, the ideas of "a blueprint of AGI", and universality within a system were significantly fascinating to me, resulting in some notes on AGI, theorizing what a blueprint of an AGI might be and thinking about the future of computing (that's the note titled "Universal Virtualization System").

Prototypes

The changes to the two notes on "Hackchat" are spawned from the time I spent prototyping an app idea. There are two interesting points I'll share here.

Firstly, I tried prototyping in Elm but ultimately switched over to React after a few hours. Prototyping with Elm was pleasant, as working in Elm always is, but after a few hours of work I wasn't impressed with my progress. So, I jumped over to a stackblitz (a browser-based coding environment), and in less than 15 minutes, replicated what I had constructed in Elm. I was a little surprised by this, given how Elm provides a much-reduced decision space compared to UI development with Javascript frameworks. In short, it comes down to the fact that Elm's abstractions are not optimized for speed. React, and probably any Javascript framework you have familiarity with provides abstractions that require less work to spit out a workable UI. Don't get me wrong, in any circumstance other than a "single developer trying to pump out a prototype as fast as possible", I'd pick Elm.

Second, I had my first twinkling of doubt against the "UI first" prototyping approach. Context: when prototyping an app idea, I generally tend to focus on developing the frontend, then use the resulting frontend to drive the requirements for the backend. I haven't found a case where this isn't a safe approach. The crux of that matter is this: while developing the frontend without a working backend, you spend effort setting up mock data, and simulating certain UI states. If you could come up with the requirements of the backend without physically developing the UI, you could theoretically spend time developing the final UI, instead of one riddled with mocks and dummy data. The approach I wish to explore next is using use case modeling and wireframes to build an understanding of the UX before writing frontend or backend code.

Leadership

There's a surprisingly small number of notes about work. Two reasons for this are that a lot of the work was probably captured in the daily Journal notes, and because this particular project requires a lot of coordination and discussions with different teams. I'm learning a lot about leading complex projects in siloed Enterprise environments, but one lesson stood out above the others this week: grit.

My motto of the week for this project was "We live to fight another day." This project has had numerous obstacles thrown its way and there have been multiple occasions to fully shut it down or claim failure. This would negatively impact the image of our team, and close off opportunities for our team to expand its services to other teams.

I realized early on, the only way I will get this project forward is with a strong acceptance of reality, detaching my emotions from the obstacles and challenges, and a rational, creative problem-solving mindset.

A strong acceptance of reality meant not getting caught up in ideals, predictions, or my or my team's perspective. I needed to be aware of what the other teams were thinking and proactively address challenges. This is only possible if one doesn't rely on their expectations too heavily.

Everyone has a plan until they get punched in the face...

I was getting punched in the face a lot on this project :).

Detaching emotionally from the situation ties into the previous and the next point. It is the underlying behavior that enables the other two behaviors. How does one do this? That's a topic for a separate post, but suffice it to say, everyone should work on accepting their emotions without reacting to them if they want to succeed in complex social environments like home, work or anywhere!

Lastly, having the flexibility to find compromises with the various teams that our team was working with was crucial to keep this project moving. Whenever some team we were depending on threw up their hands and said "no way", it was up to me to address their concerns and find a compromise or accommodation. At least for me, I've tended to see rationality and problem-solving as a calculated, analytical, and orderly objectification of a problem. Sometimes this is the case, but in situations where there are tight timelines, multiple teams, and misaligned or poorly aligned objectives, problem-solving is almost entirely about creativity. There isn't time to systematically break down the problem. Even if you did, you'd find a bunch of dead ends. Asking the right questions and making people feel safe, heard and respected opened all the doors to keep the project moving one step at a time.

That's a wrap

AI, frontend development, and complex projects... it was a fun week! Did anything in your past week resonate with this? What's one thing you can share from your past week that might help others?

Let's keep the discussion going.