Artisanal Concatenations of Sentient Emanations

I spent some time this weekend assembling an inexpensive pergola that we purchased from Amazon.com. I will not link it here, it is functionally equivalent to a tattoo that says “NO RAGRETS.” As hard as it is to believe, I do not need to steal nickels from Jeff Bezos that badly. I wanted to compare and contrast this with a different purchase I made the week before. I purchased a fancy pillow (and yes, I will steal nickels from the fancy pillow).

The inexpensive pergola aims to provide photon shielding for my children when they enter the backyard. I have purchased enough backyard items to know that everything we leave under the California sun’s withering glare will be swiftly reduced to crumbling rubble. This is even before any planned obsolescence is taken into account. The opportunity cost of buying an expensive backyard item that gets destroyed in equal time is simply too much. You can buy two cheap things and get twice as much utility over time.

On the other hand, I purchased a very high-quality pillow. You will spend hours daily with your face mashed against a pillow. By the same logic, I also want to get high-quality mattresses and high-quality chairs. You will spend lots of time rubbing parts of your body on these items and something-something posture. I would love to take this moment to call out my fancy Secret Lab Co Chair. Unfortunately, none of Jeff Bezos’s nickels get stolen should you buy yourself one of these chairs.

When I said high-quality, you knew that I meant expensive. Some things are worth it at any cost. You cannot really put a price on the quality of your sleep or your posture.

What does this have to do with engineering leadership? Plenty. You will find that there are many things that fall into the same category of Pillows, Beds, and Chairs in the software world. You will spend many dollars on Slack, email, and GitHub licenses. When designing your organization and choosing the products you wish to buy, you must ask yourself, “Am I buying an inexpensive pergola, or am I buying a fancy pillow?”

That’s it. That is the whole post. This is small enough that I could make a TokTok on it and get huge on the socials. Just maybe?

A girl can dream…

See you next week.

I have been coaching and mentoring engineering leaders for at least a decade. There was a recent article in Forbes about formal mentoring, and now that I have mentioned it, I cannot find the specific article. If you feel like using some Google power, there is a whole pile of older ones. I cannot link it because I just hit some monthly five-article limit on Forbes articles. Unrelated to Forbes and its paywall, I learned about some interesting tools and frameworks to apply to mentees as a result of my own transcendental coaching experience.

I recently established a formal coaching relationship for an engineering leader. Finding a good coach is difficult and becomes more difficult because each person responds differently to different coaching techniques.

When I was interviewing one coach, he asked me what specific issue I needed him to help fix. I responded that we do not yet have a particular issue and we just wanted to give a developing leader a coach. The coach was super puzzled by this. He responded, “I usually do not get called in to fix something until after something is broken.”

I had an “aha” moment occur here.

Let’s go back in time for a moment first.

I developed an informal ten-week program for training new managers ten years ago. About five years later, I wrote down all the parts and created a formal boot camp. Everyone involved appreciated the training, and they were surprised how much of it was based on stuff I had to learn the hard way—from the school of hard knocks.

My “aha” moment was that most people generally do not invest in coaching or mentoring their engineering leaders until they find a gap that needs addressing. Rather than ensure they have a strong foundation for leading and managing based on some foresight and preparation, they would rather let people figure out some of the hard stuff and pay for a coach when the gaps are clear.

This strikes me as disturbing.

I respect that bean counters would rather pay for fractional coaching to solve a specific problem. However, I also think that is myopic and dangerous. Suppose your engineers are highly valuable knowledge workers. In that case, you should consider it a wise investment to prepare them to manage said high-value workers to ensure their happiness and productivity at work. Gambling the health and well-being of your engineering team is incredibly risky, and the cost of replacing key staff is significantly higher than the cost of getting coaching for your newly promoted leaders and managers.

One side effect of this is that there are many coaches out there with a toolkit for helping fix specific reactive issues and coaches with a more far-reaching and proactive curriculum of materials.

You can guess which bucket of coaches I have sorted myself into.

• If you are contemplating getting a formal coach, ask them some questions.
• Do you use any formal assessment tools on mentees?
• Do you assign “homework” for items that your mentee needs to work on?
• Do you have a comprehensive list of conversations for every particular mentee?
• How often do you provide report cards or feedback to your mentees?

If your prospective coach struggles with some of these questions or provides evasive answers, they might be a better reactive coach who can help drill down into prospective areas and help a struggling engineering leader with their day-to-day issues.

If they have good answers to these questions, they are more likely to be a good proactive coach.

I do not know if there is any correlation between the two styles. Are people who are good proactive coaches also good reactive coaches? Any answers here would be purely anecdotal.

I do both types. If I have the luxury of time, I like to get started with a proactive set of materials. However, there are times when I am brought in as a reactive coach and have to jump right into firefighting.

My secret hope in writing this is that people will talk more with their existing bosses and leaders about formal coaching. According to Forbes, there are some material benefits to this. I acknowledge that this is a very self-interested statement, and you might argue that this is a sales pitch.

I am not going to disagree.

See you all next week!

I attended an OC CTO Tech Talk this week. The speaker was impressive and told an awesome story about migrating from Redshift to Databricks on AWS. There was a really well-built slide in the middle about the importance of mapping your long-term technical roadmap projects to business objectives and metrics, and this one bullet point stood out to me: “Avoid chasing shiny new tech.” I scanned the audience on this slide and witnessed an ocean of furrowed brows and puzzled expressions. At the end of the talk, there was this hilarious schizophrenic Q&A where about half of the questions came from the audience around shiny new tech and tactical questions, and I had my hand up to ask a series of related questions around soft skills, coaching, and having a mentor.

I talked with the speaker at the end of the event and thanked her for an amazing presentation. We spent a few minutes discussing the challenges of growing people professionally. In particular, we both commented on how there is a decent amount of trauma from previous bosses for most people who join your team at a startup.

Sometimes, managing people feels a little like being a professional psychologist. I first encountered this phenomenon over twenty years ago at Digital Chocolate. I was in my first director-level role and struggled a little with some of the business strategy and product direction. After some of my 1:1 meetings with company leadership, one of my peers, a producer, would ask me how the head shrinking was going. Five years later, I reflected on that comment while managing a team. We hired a new developer, and I spent considerable time unpacking that team member’s issues to help them be more successful.

Let’s fast-forward to today, after many years of high-velocity team building. I have learned that most people’s performance is heavily impacted by their previous managers—sometimes positively and sometimes negatively.

If you have an employee who has had a toxic manager or a manager with a scarce mindset, you will need to spend considerable time helping them work through that trauma to make them successful. I know that my two worst managers have shaped some of my behaviors. Now that I am in a leadership role, I find myself staring in the mirror occasionally to see if I can see them staring back at me. Whatever my faults are as a leader and a manager, there is a subset of behaviors that I self-regulate heavily to make sure that I never manifest them.

I don’t want to make light of people with startup trauma, but making them successful long-term is a lot like rebuilding Humpty Dumpty after his wall incident. It takes a lot of effort to get people into a place where they can deliver great work and feel safe to take important professional risks.

What are some things you should look out for?

The frightened messenger. If people try to hide bad news or get others to deliver it on their behalf, they fear being held accountable for it. If something breaks, it is important to confidently tell leadership there is a problem, especially if it is serious. The sooner, the better.

Swimming in denial. Have you heard someone say, “We will be late on the deliverable, and we will move the deadline by one week” three weeks in a row? Understanding how far something is behind and what needs to be done to deliver something is important. “I need more time!” is not enough. “How much time do you really need?” is needed.

Superman syndrome. Volunteering to step in and stop the bank robbers is also another problem. This is a super serious problem if you save it and still do not manage to move the needle on a struggling project. It is also a problem if you do it too many times because if you are good at doing your team’s work and you do it enough times, they will develop learned helplessness. Sometimes, this is absolutely necessary, but it is less often than most people think.

The hedge-hog. If you think about considering the possibility of contemplating a decision after consulting with stakeholders to align synergies, you might be a hedge-hog. A trivial example of this behavior is asking someone, “What is the ETA for your current task?” They reply, “I am working on it right now!” Sometimes, people do not love committing to dates because they have been punished. It is important to make decisions and commitments.

The hungry hoarder. When I took too much food at the family dinner table, my parents would look at me and ask, “Are your eyes bigger than your stomach?” Taking on too much work and not necessarily reconciling that work against your existing commitments before accepting it suggests that someone may be a people pleaser. If they over-commit and under-deliver, they may have had a toxic manager in the past who rewarded people who would work long hours and try to push through as the hero who saves the day. This is an unhealthy behavior. I recall offering some strategic tasks to a team member as an optional activity. I was interviewing three candidates and suggested they could shadow one or more candidates to see how I do my initial screens. I know they had some tasks that were due soon, and in my mind’s eye, I believed they would decline to do all three if they were worried about missing deadlines. They cheerfully accepted all three optional interview screens, and a week later, they missed delivering on their core work. It was an unfortunate situation.

When I encounter some of these behaviors in team members, I often spend time with them unpacking the source of the behavior. If we can figure out where it started, we can create a plan to fix it.

After giving someone an opportunity to stretch and grow, like the previous hungry hoarder example, you will have a pretty clear “teachable moment” to discuss with your team member what went wrong and help go through the decision-making that led to the unfortunate result.

A previous boss often constructed hard tasks for his direct reports to observe how they got stuff done. He would assign them a challenging project with insufficient information or resources to witness their “default tendencies.” He would do this under a controlled environment to be prepared for their default tendencies when there is an actual work crisis.

It is an effective way to understand what your people are capable of, although it is a bit “old skool” as a way to learn how your team operates.

You cannot learn this early on as a leader or manager. This is one of those things you develop over time through hard practice. You will also develop the skill of fixing team members through breaking deliverables, teams, or entire companies.

Situations like these are why I choose to mentor and coach people. I have had some people who have started a new role, and from the way they describe their new boss, you can tell that there are rocks in the waters ahead. I do feel a certain amount of relief when I can help someone steer through those waters clearly. I also feel empathy during the times when we are not able to clear the rocks together, and the ship gets wrecked. Talking through what went wrong and how to do better next time is a part of professional improvement and personal healing.

I suppose this is where I make the sales pitch. I like to mentor people and help them professionally. Let’s talk if you feel like you have team members in these situations or bosses who exhibit some of these traits and want a partner to give you perspective and help steer you through some of your challenges.

Have an excellent week!

The most challenging UIUX work is in video games. I almost want to stop there and say, “That’s it, that is the whole post.” It is not like I get paid by the word, nor do you click on any of the books or random items I link here with the hope of stealing nickels from the Bezos. Okay, a few of you clicked—enough for me to get paid once in the many years of writing. Thank you for that.

When I was designing my own mobile games, I had a small office located above a Starbucks. I played a game of my own there because a decade or so ago, there was a pretty easy way to get a third of your coffee from Starbucks for free. I remember explaining this to a friend of mine. His wife used to work at Starbucks, and the brand loyalty was so deeply etched into her soul that she got angry at my cheeky stunt and punched me in the arm. If I do not post the sneaky trick everyone in your town is talking about, I fear the internet will punch me.

Enough about Starbucks hacking.

In addition to intermittent free Starbucks coffee, I also went there to test whether my games were good. I would go to the staff or occasional regular that I recognized and thrust a test phone into their hands. “Here is my game!” I would proclaim loudly, “tell me what you think!”

You can guess what happened next: Nothing at all. People would invariably freeze up for two reasons. The first is that they did not know what to do. The second is that they were afraid of doing the wrong thing.

This was my introduction to user testing. I quickly learned I should add animations to my mobile games to help drive decision-making and button pressing. This was the first of many places where I added subtle pieces of animation to help unfreeze people in possession of one of my mobile games. I should have learned this lesson years before while playing Bejeweled. If you stared at their match three board long enough without finding three in a row, it would give you a subtle hint that there was a possible match. I confess to being so focused on getting that dopamine fix from counting to three that I may have missed the learning moment.

This is an essential thing for game developers to learn. Okay, there two things game developers should learn. First, you should always try to put your game into “n00b” players’ hands to see whether your game explains itself without you, the developer, talking. Your players might not survive by their wits alone. Second, player testing is incredibly valuable. The more people who play your game who satisfy the requirement of being “not you,” the better off your final product will be.

That’s it. That is the whole post.

See you all soon!

I have often said, “Good teams build products. Great teams build tools.” This has become a part of me over decades of shipping software, both good and bad. The best software I have ever shipped has included many tools for operators and intermediate users.

Over those two decades, I have also encountered a few moments of regret. One of the most frequent regrets occurred when I wished I had access to libraries and tools I had developed elsewhere. If I built a nice kernel-level memory management library in C, why shouldn’t I be able to use that elsewhere if the two companies are not competitors?

I had to throw in that last question because I am sure every armchair software developer was halfway out of their chair to demand “whaddabout competitor?!” Checkmate, dear reader. I am way ahead of you.

Setting aside the competitor issue for the moment, I just imagine needing to call a plumber or an interior decorator, and while I require their specialized knowledge and services, I do not run out and buy them an entirely new set of tools to do my job.

I am reducing this absurdity on purpose. I have not felt this particular type of regret in a while because part of what I have done over the past several years is build some software as a consultant, where I changed the underlying assumption about what I have built from a work-for-hire basis to that of a licensing model.

Part of the reason I did this was to give a steep discount to some customers who were not well-financed. Finding cheap product market fit is attractive, and I priced these projects accordingly. The result was that I built a gigantic pile of libraries for several companies, which I now own.

I have gone through these repositories a few times over the years. Some of the time I cackle and imagine I have a gigantic trove of riches. We all know this is fiction. My dragon hoard of software is not a pile of golden coins and gemstones. It is essentially a collection of half-eaten sandwiches and discarded pieces of lumber.

However, I intermittently have a library for timestamp management, database access, authentication, or similar core technology that enables me to build something swiftly.

I think there is a case to be made for software developers to build and maintain their own tools over the years. I can appreciate the IT department manager developing sweats and anxiety at an army of developers showing up with their personal laptops, fully configured to work, with access to their own code libraries. After all, a good chunk of software projects these days start with a pile of npm install instructions or similar that fetches open-source libraries from a billion places.

I exaggerate slightly and with good reason. In the era of the LLM, I can envision developers who have trained up their own AI to solve specialized problems for them. Does this not enable them to do their jobs more effectively?

I feel like I have to stop here. The world is not ready for this flavor of crazy. The IT department of Giant Mega Software Concern can stand down and move the minute hand of their doomsday clock back from midnight.

I wanted to make sure this was written down somewhere, so when this becomes normal in five, six, or even ten years, I can send links to the young peoples and leap up from my chair, pointing and screaming furiously, “See? SEE?”

I do believe a day will come when it will be normal for people to BYOT (Bring Your Own Tools) to work.

See you all next week!

Hello, everyone. I am glad to say that the majority of my move is behind, as we are down to a single-digit number of boxes left to unpack. There might be a future blog post about John’s unhealthy fixation with cardboard boxes or the wonderful feeling of removing a good percentage of your household items through yard sales, donations, and dump runs. As a matter of principle, I may want to do this every five to ten years. 

Many people ask me what I think about AI, and more specifically, AGI (Artificial General Intelligence). I have two replies. The first is that I wrote a story about how that will end. You can read it on this very blog. The second thing is that I do not think LLMs will get us there.

I think a second generation (Third generation? Fourth generation?) of AI systems will soon be coming and will have a better symbolic understanding of the data. The investment frenzy for those systems and the startup companies that create them has not yet begun.

The symbolic understanding of the data is important. The only reason current LLM systems can answer the question, “What do a fire engine and a book have in common?” is because someone typed it into the internet already. We need an AI system that spontaneously, without prompting, creates jokes with that level of cleverness. The spontaneous creation of new ideas, and eventually new science and mathematics, is the part that will tip it over into AGI territory.

Until then, everything we read from current AI systems is just a highly plausible set of words calculated from a subset of gobbledygook that humans have saved onto the Internet. Paragraphs of text read like they were written in a hurry by a tenth grader who has an essay due in nine hours, not even considering the high level of hallucinations that sometimes find their way into the output.

The AGI system that will eventually exist will combine multiple generations of AI systems and add a top-level layer of autonomy, asking, “Is this what I really think, or at least, what I really want to say?”

When two different instances of the AGI software answer Spock’s Mom’s question (go ahead and Google it if you are an unlearned heathen) in a way that makes justice systems of the world contemplate making it illegal to hit the off switch, AGI will have arrived.

See you next week.

Last week, I did not have my machine assembled, and now that it is physically set up, this week, I am not mentally set up due to all of the box ferrying: up the stairs, down the stairs, open the box, empty the box, repeat.

I promise I will resume sending you all Amazon links and industry rants next week.

I have talked to aspiring engineers about professional skills they will need that not taught in school. Some of them are technically taught in school, although they are taught poorly. Version control systems are a great example of this.

While getting the basics for fetching code, creating branches, and committing code is nice, that is not the education you need with version control software. I will use Git for our example today, although it could just as easily have been one of many different flavors of version control. Perforce comes to mind as a version control system that video game developers use because it manages large repos of game assets nicely.

The things you need to learn about version control are more related to merging code and how to deal with a repo that four or more people are actively working on, sometimes even editing the same file. This is not what you get to do in school unless you are working on some kind of capstone project. A week-long project with two or three developers does not get to the level of excruciating pain and suffering that results from four or more people actively working in tandem on a codebase. You seldom get projects with enough people, and you are not working on a project for long enough for the pain to really be felt.

It raises the question: “What is the reasonable expectation for source control proficiency for a new employee without any experience?”

The answer is: “Git proficiency is not a reasonable expectation.”

There is a moment of cognitive dissonance when a new employee asks for help with a git merge. “Hey,” You might be tempted to say, “Didn’t you submit your code sample from a git repo?” While that is a perfectly reasonable knee-jerk reaction, it is not really a good one. Merging code into a large project on a team is not the same as “one person writes a small piece of code and uploads it in a controlled environment with no one else touching it.” It is not in the same ballpark and probably not even in the same league.

You are left with two options.

The first is to buy one of them there goofy mugs with all of the Git commands written on it and to have them hunker down and “git gud.” Maybe this works here and there. I do not know if it scales well. If you want to try that, you have the Amazon Affiliate Link to buy it. I will thank you for them tasty Bezos nickels if you buy one.

The second option is to have them look at using nicely written GUI tools to do their Git management.

I am a fan of the second option. I have used Sourcetree to great effect with new engineers, technical artists, and other team members to solve Git issues. Sourcetree is reasonably good and it is free. It is also a Gateway product to Bitbucket and Atlassian products. Consider yourself warned.

Other people use Smartgit, a fine alternative. It just costs the monies.

Visual tools like this are a reasonably good and fast way to teach new hires to triage repo issues effectively.

In the long term, is this a skill you will need to be a successful senior software engineer or architect? Possibly. Some people get quite good at using visual tools to manage the repos for their whole organization. Some people need to go to the command line, possibly out of personal choice.

The point I want to make is that this is not an urgent skill to learn right out of the gate. If you do need it, maybe, in several years, you will have time to learn it. There are enough important things to learn as a freshly employed software engineer that this one is worth punting down the field a little.

Thank you for coming to my TED talk!

At least one finance person has made the jokes about GAAP and how it does not mean what a game developer thinks it means. GAAP in this conversation means Games As A Platform. Consider yourself disambiguated.

We are all watching the conflagration in the mobile app stores and eating our popcorn. The view from down here is magnificent and… big enough to see from space. What is selling today? Recent studies show many six-year-old franchises and [checks notes] Monopoly-plus-coin-master.

You might narrow your eyes and proclaim, “But whaddabout Balatro?” Or you could point at me and mumble, “Something something Palworld!” Yes, you are right. Four or five amazingly successful indie games exist out of at least ten thousand published annually.

I keep telling people every year, “Right now is both the best time and the worst time to be making video games.” Yes, that is right, I am very conflicted about this. Too bad I cannot channel that into a career making the Toktoks.

Let’s throw some more conflict on the fire. I am a gigantic fan of true player ownership of digital goods. I believe that web3 represents a possible means to this end. I am also a fan of distributing games on the open internet. That last point represents a conundrum because the best path to tackling the existing mobile dual monopoly is yet a third closed platform: The Epic Game Store. The enemy of my enemy is not my enemy. While he is still fighting the Apples and the Googles, Tim Sweeney is my favorite person in the games industry every year.

Let’s bring that back to GAAP. Roblox. Fortnite. Minecraft. Zepeto. These are a few of the names I have heard for GAAP. Roblox is presently the incumbent in this space, possessing full facilities for developers to sell virtual goods, mass adoption, and a thriving developer ecosystem. Fortnite is on its way there. You cannot directly sell your items yet, but we must believe this capability is coming. Minecraft is still unsure what it wants to be when it grows up. Zepeto is just this strange international platform that smart people keep yammering about. I am including Zepeto in this conversation out of respect for their pattern recognition skills.

So how do we know that GAAP will be so gosh-darned big?

The first thing to point out is that making games is expensive. Let’s pretend that game developers are construction workers for a moment. How much more expensive and time-consuming would it be to build a house if the construction workers were not allowed to reuse their hammers from job to job? Unreal Engine, Godot, and Unity are all engines that make it easier for people to make games; however, the production pipelines and intermediate tools made on top of them generally do not enjoy portability from game to game or company to company. This is one of the reasons that GAAP is attractive. There are already companies founded by Roblox players who have turned their passion into their livelihood. One of those games is so popular they had a toy included in Happy Meals from McDonald’s!

The creator programs for Fortnite are not far behind Roblox. They understand this is their future. It took years for Roblox to reach Seven Hundred Million Dollars in payouts to creators. In a year, Fortnite got halfway there. Fortnite is kind of cheating a little because it is paying creators out of the revenues generated by selling items and V-Bucks. I strongly believe that a real creator economy will be coming soon.

What makes this interesting is that you can make some comparisons to the dual monopolies in mobile app stores. For example, you can argue that Roblox is like Google and Fortnite is like Apple. There is some delicious irony in that last comparison.

Like in mobile app stores, a dual monopoly creates pressure to compete. Similar things are happening in ridesharing. Uber and Lyft essentially keep themselves honest with their customers. There are more disturbing comparisons to be made between ridesharing drivers and game developers, and we will choose to have that conversation later.

The last interesting point that makes me believe more firmly in the GAAP future is how hard it is to publish… anything. The Friction Is Too Damned High. This will eventually be a problem that comes to GAAP, but today is not that day. Going through all the submission processes for mobile and console games is hard. I cannot speak to the Steam submission process here because I have never done it. I see developers begging to have their game wishlisted on the socials all of the time, and it sounds like it has its very own rituals and observances.

If I started my career fresh today, I would make a game on Roblox or Epic’s UEFN. Heck, the desire to try making games for these platforms is even non-zero for me. I can feel the pull, and it is stronk.

I have declared that GAAP will be a “Next Big Thing” and might even be here in 2025. There are lots of people who believe that “something something AI” is going to be a “Next Big Thing” and are puzzled that I left it off my list. I feel like I should address this.

AI tools are coming to games, and I believe they will be here in the next few years. I also do not think they are a revolutionary change. LLM-based AI will be an evolutionary step that reduces studios’ costs. I do not think it is an automobile; I think it is a faster horse. I will let you all puzzle out what that means. If you need help, you can contact me on my socials.

On that perplexing note, I hope you all are here again next week!

I continue to earn about fifteen cents a month as an Amazon Affiliate. Whoever bought that book from my top ten last week, thank you. This week, I wanted to talk a little about “The Next Big Thing.”

The Next Big Thing is a consumer phenomenon. Once upon a time, the iPhone was a “Next Big Thing”. At one point, the internet was a “Next Big Thing”. CD Rom drives, The Nintendo Switch, and even the Commodore 64 all had their moment in the sun as The Next Big Thing.

Figuring out what will be “The Next Big Thing” is hard. I gave a talk in Seattle called “Out of Touch: The Next Big Thing After The Next Big Thing.” My thesis was that in 2014, gesture technologies were up and coming, and there were so many interesting technical problems that needed to be solved that it would not be the Next Big Thing, but it could possibly be the Next Big Thing after that. It was a fun talk, and the audience rated it highly. I do not have my slides anymore or I would share them. All I have is this great picture of me wishing I was Tom Cruise.

Now that we are in 2024, I was clearly wrong about gesture technology’s speed to market. I remember declaring that there will be a point when gesture technology will be the predominant driver for man-machine interfaces. There will be a new form of sign language that machines will use to interpret gestures, and old people like me will use an old keyboard to talk to machines. The keyboard will not be connected to anything… Some product manager somewhere will take pity on us old people and have a “fax machine compatibility layer” that will watch the gestures of someone typing on the disconnected keyboard and understand what letters are supposed to appear.

There are lots of people who think that voice is a killer app for communicating with computers. They do not have kids, and some… probably do not have a robust dating life. I do not mean to be mean about it. They just forget that sound is a lousy shared transportation medium for data. It will be hard for a room full of kids to scream commands into some online game and have them all easily understood. At the same time, you can always add more cameras if you have maxed out the ability of a machine to count wriggling fingers and elbows. An interactive application with gestures is possible at a football stadium in the same way that a voice-driven application in the same venue is not.

So now that we know that I was mostly wrong about gesture technology a decade ago, what do I think about The Next Big Thing today?

I see three things.

GAAP (Games As A Platform)

I think that this is The Next Big Thing. Roblox and Fortnite have gotten to a billion dollars in creator payouts. This is almost real money! I am also learning that other platforms exist, like Zepeto. Also, while they are currently at a disadvantage in their current market position, Minecraft can still make itself felt here. If I had to bet dollars on this, I would bet on GAAP being a significant driver for consumer game spending. I think this will double by next year in size and be the big theme for next year’s GDC (Game Developer Conference).

Augmented Reality

Right on its heels, I can see the Apple Vision Pro and similar AR devices being very real by 2026. I have some self-interest in this position. I wagered a fancy steak dinner in SF that there will be 4 million AR devices in the marketplace by 2026. I do not know what the killer app for AR will look like yet, either. No one is throwing dead presidents at me to parachute in and get feral with the device in search of its Genre Defining Hit. I do think there is a clear prosumer and urban city dweller killer app outside of games. People looking to meet in real life will use AR tools to find replacement meeting places for work or play when someone is stuck in traffic or if the place they want to meet is just too busy. There is a clear advertising model here for coffee shops, bars, restaurants, and other businesses to offer incentives via discounts or BOGO (buy-one-get-one) for consumers to adjust their plans in real-time. AR can advertise the arbitrage opportunity inside the display, and the platform can also give everyone updates on where to go and when.

Distributed Ledgers

While this is the one I am most interested in, I think this one is the furthest out. I did not call it web3 or Crypto on purpose. Grifters and bad actors have done a considerable amount of damage to the growth of this space. We are in a prolonged period of indigestion on distributed ledgers accordingly. There are many uses for tokens and distributed ledgers, and we cannot get to this future fast enough for me. Some great use cases for distributed ledgers include resource access, public spending, fund-raising, member-based governance, and voting.

There you have it. 

– 2025 will be the year of GAAP.

– 2026 will be the year of AR.

– 2029 will be the year of distributed ledgers aka web3

I will do my very best to remember to check in at the end of each of these years to see how far off I am. I do have a history of being very early to most new technologies.

See you all next week!