Emergent behavior arises when the activity of a system becomes frequent enough that human measurement can perceive a new entity and nature of action. It does not introduce anything new in reality but rather introduces something new to our perceptive faculties; it’s a discovery. Specific behaviors we’ve seen in the domain of LLMs include:

• In-context Learning: Models can learn tasks during inference with no additional training.

• Zero-shot/Few-shot Capabilities: Performing tasks without specific training or with minimal examples due to generalized patterns of action.

• Multimodal Understanding: Applicability across multiple data types (e.g., text and images).

• Complex Reasoning: Solving problems involving multi-step logic and explanations.

• Self-correction: Revising outputs based on feedback or errors in prior responses.

Today, as many people take in the emergent behavior of LLMs, some have adopted a new perspective of them as pattern identifiers and pattern generators that can iteratively transform indefinitely. This has led some to draw similarities with other systems that continuously transform patterns into other patterns indefinitely: operating systems.

Comparisons to Operating Systems

Let’s first discuss our existing concept of an operating system and why this comparison feels justified. What is an operating system in a general sense? It is a system that has access to linear memory. It can read pieces of that memory and perform actions that further read or write back to it. These memory locations are connected to hardware that is actively running and also writes to these places in linear memory. The contents of this memory might represent the pixels on your screen, the position of your mouse, or data to send to your Wi-Fi card. An operating system interacts with these memory locations indefinitely, so quickly that it creates an experience that seems interactive to our human senses.

Today, we experience a similar effect in ChatGPT. The text we enter into ChatGPT is a kind of linear memory. ChatGPT reads this memory pattern and writes to it when it generates results. This memory’s encoded data is visible to us through our monitor as text characters on our screen. We indefinitely keep entering data, expanding upon the results of the text and generating new patterns. What arises from this is the feeling of something interactive.

What differs between these two interactions? Firstly, the speed of transformations. Operating system transformations are mathematically similar to AI, but they are far more simplistic transformations that typically read or modify a single location of memory ( adding, multiplying, moving numbers). Thus, an operating system can perform transformations to small bits of memory very quickly. LLMs, on the other hand, use matrix multiplication to modify vast sequences of linear memory and perform operations on all the elements simultaneously. This can be especially fast so long as your elements all require the same operation.

There is also a significant difference in the types of patterns that can be worked with. LLMs today work with very particular kinds of patterns. This data might be text, images, etc., encoded in a particular manner. LLMs are specialized to this data due to their creation through massive amounts of training steps on consistently structured data. Operating systems, on the other hand, tend to transform a wide variety of structures. Code could transform specific structures for hardware (like the protocol for communicating with USB drives) or very specific structures that only a human knows are meaningful.

Transformations Forever

Despite these differences, LLM matrix math and human-written code are fundamentally just transformations that can run indefinitely.

Consider a simple system with memory representing mouse velocity and other linear memory representing pixels on a screen. If we wanted to implement an experience where your mouse cursor displayed appropriately as you moved the mouse, we could easily write code that transforms mouse movement velocity in memory and translates it into pixels in the screen’s memory. We could also do this with LLMs. If we had a trained LLM take in mouse movement and the current screen’s pixels, it could generate a new sequence of encoded data in memory of what the next new screen’s pixels should look like.

These two implementations of transformations to generate human output are not the same mathematically, but they could, to the degree humans are able to measure visually, produce similar experiences of interactivity. The LLM could act as a form of compressing the understanding of how mouse and screen data transform into new screen data over time.

This simple program can be expanded into a system of multiple concurrent subsystems. An operating system kernel is a type of program responsible for multiple programs (modules) that are transforming linear memory. Similarly, we could imagine a set of many LLMs that are simultaneously transforming pieces of memory concurrently under some guiding program.

I term this concept of orchestrating LLM pattern transformers a Cognitive Operating System, as it functions similarly to the more general concept of an operating system but uses cognitive compression techniques akin to our own brain. Much like our brain sees interactive experiences and replays simulations of how new interactive situations would occur, LLMs can capture interactive experiences during training. Just like the human mind, which does not store every pixel of our retina but rather a compressed model of what we’ve seen, so too does the LLM.

BIOS for Brains

The maturation of Cognitive Operating Systems would probably require several innovations in the software industry. The first is an orchestrator that manages the memory regions that would be read and written to by LLMs. These LLMs would need some sort of mechanism for operating concurrently, likely a scheduler of sorts, that could iteratively transform all the various kinds of patterns that might be involved in a system and handle conflicts. The first implentations of these will likely be toy demos such as the cursor example above or video games, which require only a very limited set of linear memories useful for gamers.

As time goes on, though, this set of memories might grow to include all the kinds of hardware that traditional operating systems typically interact with: storage mechanisms, the internet, etc. You’d need more complex systems to manage the execution of all these LLMs together. It’s likely that an LLM will form specifically for the task of orchestrating other LLMs to create a particular experience for a human. LLMs could communicate their dependencies to one another to load into memory what’s required, much like how Linux loads into memory modules appropriate to the user’s actual hardware and configurations.

If the scheduler is itself an LLM, this begs the question of who starts the scheduler? What’s the equivalent of BIOS that even gets an LLM scheduler going? Typically such things would be code baked into the hardware itself. What might develop is hardware that not only allows the bootstrapping and running of LLMs directly but also the ability to reconfigure its physical structure.

In much the same way that software programs can download new versions of themselves from the internet, LLMs might be able to generate patterns that download new versions of their weights, or possibly even download new firmware into their host hardware that runs the LLMs. But this firmware might be more than code one day; it might actually be the physical configuration of dynamic hardware like FPGAs that physically changes its logic gates. LLMs might be able to one day redesign the hardware they run on by interpreting improvements they want to make into the pattern of their own hardware configuration language.

Likely for some time, though, this will be something humans excel at and will manage standards for. Traditional programming in a world of Cognitive Operating Systems might be relegated to something akin to VHDL for LLMs, shifting focus to the hardware itself rather than the interactive experience.

Who Will Build the Future?

Who will be developing on this new Cognitive Operating System if traditional coding is relegated to hardware? I believe a new type of developer will emerge—a type of neuroarchitect, specifically skilled at creating cognitive compression of experiences into LLM modules that run on Cognitive Operating Systems.

These individuals might initially resemble traditional machine learning developers, gathering data sets and creating matrix weights, but I suspect our industry will evolve to develop new methods of training. We might utilize neural interfaces that directly translate human experiences into the encoded data used in the transformations of LLMs. If someone is putting together a multi-modal LLM for tic-tac-toe, they might physically operate the game, focus their vision on it, and record those interactive patterns into an LLM that can recreate it in pixel form. These patterns might not even need to be actively generated; rather, we might be gathering these patterns all the time throughout our lives and filtering them later to form a novel module. Possibly even just imagining patterns might be enough.

New forms of collaboration could arise among people as they pool together their resources, much like the current open-source community. Imagine players of a game pooling together their digitally encoded memories of the game mechanics and lore to create an experience generator LLM module to distribute to the world for others to play. Perceptual collaboration could take place on a platforms where people can inspect, remix, and share their experiences.

History Rhymes

I’ll conclude this article by saying confidently that I have no idea what the future will bring in total. That said, there’s an apt quote: “History doesn’t repeat itself, but it does rhyme.” It is undeniable that the abstraction of LLMs as pattern transformers of linear memory shares aspects with traditional software operating systems. As hardware and AI algorithms drive LLMs faster and faster, how far will the consequences of that similarity bring LLMs down a similar path to traditional operating systems? We’ll just have to wait and see. At the very least, I'm certain many similar utilizations will be attempted. Whatever happens, please MIT license your brainwaves—it’s going to be a wild ride.

Welcome to my series on research and development. I am wanting to write down some details of my experience as an AI Software Architect, because I believe what I’m observing is a shift in our industry that might become more common. This trend is a shift to research and development being a primary aspect of technology organizations. The immense power of generative AI and companies evaluating its usage in applications in industries over the last years is what I suspect is the primary cause. It’s a technology that requires a non-trivial amount of discovery to confidently utilize. As someone who has historically been in 100% product development, my perspective might be useful for other product developers making the transition into these discovery roles that are effectively research and development.

The Goal

Software research at a company is not without context: your company exists to make profit and likely has a strategy on this if they are already investing in research. You must get something profitable onto the product road map as quickly as possible.  Prototypes are effectively worthless unless they sell to customers or bring feedback to improve the next prototype.  You must be someone who cares about money to increase the likelihood that you are allocating your time on viable prototypes and not mad science.

Resource allocation at companies is not random, they will be assigned where profit is proven/obvious. If you do not align people on financial value, they will never position research ideas before other product roadmap items in any significant way to make traction. And when you fail to do so, you will likely not have the help of product team members (designers, project managers, testers, etc.), relegating your work half-designed code hiding behind a feature flag never to see the light of day.  

To get something on the product roadmap at your company, you must find out the existing mechanisms for how things arrive there. Your company may have a very specific sequence of steps, but the unity among all those decision mechanisms is that someone with authority at your company will have to clearly understand the financial impact of your prototype. This is a very challenging and difficult process because it involves research into a market from various specialized perspectives that you don’t have time to assess as an engineer.

What you’ll be doing

As a software engineer, you may be used to spending a majority of your time building, but in the role of R&D a new critical need arises: educating other people on technology.  People cannot evaluate the financial impact of your prototype if they do not understand it.  If they cannot envision it in a form their customers would use, they will not be able to tell anyone of authority its value and how to prioritize it.  Even with a process of education, it will likely require a tangible pilot with a customer to evaluate. Product managers can theorize on your arguments all they like, but hearing a key customer express their judgment is worth its weight in gold. 

It’s critical in research and development that you recognize your variety of connections across a company will make or break you.  You not only ultimately need the buy-in from various perspectives to define financial impact, but you will likely need their help in the identification of non-viable prototypes.  Because research cannot be funded forever, you are forced to economize your actions, and saying “no” to things as quickly as possible is crucial. The likelihood of your first prototype being high enough in value to compete with existing product priorities is very low.  You need a system that allows you to experiment with multiple prototypes and get feedback from experienced judges with various customer/business experience (product, sales, marketing, customer success). 

Additionally, you will need conversation with people who understand your business for your own inspiration of identifying technology opportunities. As a programmer, you have awareness of countless technologies, but others in your company may not be able to tell if the capabilities are science fiction or a real opportunity.  They don’t know if integrating those advancements would take years or weeks.  You will sometimes have to be a judge of technology that only you understand, and having a mental model how your business makes money will help you in this to identify the related and unrelated pieces more efficiently. 

A concrete example of this is something like vector databases.  To many people they have no idea what this is, and to some it’s just a buzzword they know popular. They have no idea how it fits into a technological system and what it improves. In generative AI in particular - being full of new tools/libraries - you will have to judge technologies like this on your own, and must do what you can to be prepared to see the value of these opportunities from a financial lens.

Common mistakes

Promoting prototypes and educating people are a core part of the job, and it can take a variety of skills to master the art. This could be articles of their own, but for now, I’ll offer some common mistakes i’ve made I think are worth mentioning: 

• It’s important that you not be  productizing. Your goal in a prototype is to do just enough to convey the technological opportunity to the critical people of the company who can define financial impact: no more or less.  If you do less, people can’t see the opportunity, if you do more, you prevent yourself from the exploration of other prototypes.  That isn’t to say that your prototypes should be esoteric pieces of code. Keeping them in line with existing architectures can make the productization easier when it does happen, and complexity of completing the final implementation will certainly factor in weighing it against other product initiatives. You must be careful not to go overboard though.

• Avoid exaggeration. People will form mental models about your work when it’s presented, and those mental models will only flourish so much as they point to reality.  If I go around telling people that generative AI is a “thinking machine”, they will be disappointed when they go to use it in reality and realize it lacks the reasoning of many adults.  If I describe AI as a “pattern identifier”, people will find in reality that it indeed identifies patterns, and a conversation can more appropriately occur on what patterns it can confidently identify or produce. You can mitigate exaggeration where possible with testing if it’s appropriate, and in the realm of AI, it is certainly vital.

• Avoid being in a state where you cannot demo your work for too long.  Again, remembering that feedback to say “no” quicker is crucially important, and people seeing what you’ve built can convey a lot of information.  You must live in the sun with your actions. Showing your work and your ideas often will help build trust and keep people in the loop so your mental models are fresh in their mind.

Finally, let’s imagine you build a prototype that has matched with product’s priorities in your company, you’ve done the complex task of educating your leadership to identify the financial impact, and placed it onto your product roadmap when weighed against alternatives — you still have one more thing to do.  Document the impact your prototype actually has after it’s been fully productized. You must remember all facets of the company are measured in investor value, R&D is not exempt and has a challenge of being something easily forgotten because it’s a pre-production phase. The prototypes you create have to justify the costs of successful research, productization, and failed research. That can be a very large number, so take it seriously.

Ad Astra

With this strategy, I hope you have a clearer picture of the goal, how to work with your broader leadership team, and the essential role of educating your prototypes and measuring the impact they have. It’s an exciting challenge in this world, and we live in an era where the rewards can be immense for new discoveries of pattern matching applied to productivity.

The dream of three-dimensional cyberspace was imagined decades ago in a world that did not yet have the available technology to realize it. Meanwhile, a different kind of interactive world was forming in the World Wide Web, and web developers have been unlocking its potential  ever since. There’s an important lesson in history catching up with us, one fundamental to all interactive worlds (not just the web), with the possibility of redefining the trajectory of the metaverse’s technological future. In this article I talk about a new open source library I’ve created – HyperShape – that implemented 3D worlds in a fundamentally different way and what my discoveries were when making it.

On places like Hacker News, there is an ongoing conversation about web applications and alternatives to React. The root emotion of this conversation seems to be burnout, and its reality is wasted money and time. Web developers are starting to suspect that their craft has become unnecessarily complex. Anyone in this industry knows the feeling of endless web framework churn. Like a frog in a boiling pot, you wake up one day and suddenly hooks, virtual DOM, webpack, functional components powered by immutability all seem indispensable. Some are taking a step back and asking: do things really need to be like this?

Certainly, some applications require high performance, componentization, and cascades of state. Google Docs is a good example of a web app that pushes the limits of performance and properly requires advanced usage of JavaScript. But more often we deal with more basic problems: settings screens, basic navigation, etc. We don’t need to bring out the whole armada of JavaScript libraries to make these, and this is where I think the seed of doubt about our current industry lies: in a sense that what we are building is inappropriate for the problems we work on.

When we use multiple layers of abstraction (virtual DOM diffed UI, server side rendering, state, API clients, API handlers, ORMs, etc.) to make a simple email submission form, for instance, it not only takes time to create these abstractions (hoping for the day we’ll encounter a complicated frontend that fully utilizes them), it also ostracizes folks like backend developers who increasingly feel like they can’t understand the most basic frontend code. We’ve raised the bar of what it means to be a full-stack developer, to the point that some doubt such a role is even possible anymore. All this increases businesses costs, or if it’s your personal project, chips away at your precious time.

The New Old Way

Recently, technologies like HTMX have come into the scene, saying with a tempting whisper that there’s another way. They pick up on old ideas and reapply them, ideas they suggest are simpler. For those who aren’t familiar with the library, HTMX tries to pick up where the HTML spec was abandoned. To quote their website:

• Why should only <a> and <form> be able to make HTTP requests?

• Why should only click & submit events trigger them?

• Why should only GET & POST methods be available?

• Why should you only be able to replace the entire screen?

They believe these ideas could radically improve HTML as a language for making interactive web pages. HTMX makes a tradeoff by making the frontend radically thinner and tilting logic to the backend. It does this by using a JavaScript library that extends the functionality of HTML elements in ways they believe is a logical extension of the original HTML spec (and hopefully in the process let you avoid writing scripts almost entirely). The programmers behind HTMX believe the browser already has a great deal of tech inside of it that is not being fully utilized.

To give an example from their website:

<div hx-target="this" hx-swap="outerHTML">

    <div><label>First Name</label>: Francisco</div>

    <div><label>Last Name</label>: Danconia</div>

    <div><label>Email</label>: francisco@danconiacopper.com</div>

    <button hx-get="/contact/1/edit" class="btn btn-primary">

    Click To Edit

    </button>

</div>

Notice how the button indicates that a HTTP GET request will be called when it’s clicked, and a specific <div> element target will be replaced. What does this endpoint “/contact/1/edit” return? More HTML. This is a shift away from the common practice of JavaScript-driven UIs that use APIs returning JSON data, rather than usable hypertext including state.

<form hx-put="/contact/1" hx-target="this" hx-swap="outerHTML">

  <div>

    <label>First Name</label>

    <input type="text" name="firstName" value="Francisco">

  </div>

  <div class="form-group">

    <label>Last Name</label>

    <input type="text" name="lastName" value="Danconia">

  </div>

  <div class="form-group">

    <label>Email Address</label>

    <input type="email" name="email" value="francisco@danconiacopper.com">

  </div>

  <button class="btn">Submit</button>

  <button class="btn" hx-get="/contact/1">Cancel</button>

</form>

We see how little JavaScript is necessary to replace a small island of HTML in our website with an editable variant. The state is the HTML itself. This is a general theme of HTMX.

The authors of HTMX are huge proponents of the esoteric world of hypermedia systems. They wrote a book on this topic and addressed common questions like “Why didn’t this spec advance further? How could it have been made better?” and more importantly, where did all these ideas come from in the 1980s/1990s?

Primitive elements of an interactive World Wide Web

You might be wondering why looking to the past is of any value. Looking into the origins of Web 1.0 teaches the history of how it evolved, and the impact at each stage of evolution offers insight for today — in particular, the point where the World Wide Web became a place of interactive applications rather than just a read only network of research data. History can show us the absolutely essential requirements for the web — that which cannot be removed without destroying our concept of what’s possible to do.

The first essential element discovered came from the original web standard as a solution to a desperate documentation issue at CERN. Scientists and university academics had information piling up in siloed servers across CERN and there was a need for this information to be shared. This was in 1989, so computers had been around for some time — someone just had not put together all the elements into an idea of the internet (and a wiki was far from people’s imaginations at the time).

First the information had to be shareable even to read. This led to a language for describing the structure of this text, but most importantly the development of a first HTML element to unlock the power of the web.

“The WorldWideWeb (W3) is a wide-area hypermedia information retrieval initiative aiming to give universal access to a large universe of documents.”

The World Wide Web project (the internet’s first web page)

The link

The humble <a> tag or anchor link is a powerful idea. It is what allows us to move around from document to document. The World Wide Web was built to be unstructured. There was no intrinsic hierarchy to the information on the web (though Yahoo and others tried to impose one!). Links allow exploration without a fixed path — as many who get lost in Wikipedia are familiar with.

This innovation alone allowed a plethora of information to be explored and shared, and unlocked the read-only World Wide Web. 

The form

People’s imaginations were not satisfied with read-only browsers, and it didn’t take them long to think of ways that browsers could send information. This goal was realized in 1993 with the standardization of the <form> element, which became the first HTML element that could explicitly send data to servers. Standardized input controls in browsers unlocked the revolution of web applications. Imagine the World Wide Web transforming from a place where you could navigate pre-structured information about chemicals or celebrities, to a place where you could make search queries, order pizza, and send emails via web interfaces.

If the history of web forms interests you I recommend checking out The Evolution of Web Forms.

The foundations of an interactive world of information

With just these two elements, an entire textual world of modifiable data experienced by “Web surfers” could be created. What this suggests, surprisingly, is that JavaScript, CSS and so on are non-essential to the basic functionality of the Web. Yes, there were further advancements that allowed more sophisticated website experiences, but the link and form were the foundations to create the most minimal web as we know it. These foundations were heavily used by the software architecture of the server-side web applications in the early 2000s, powering the internet for over a decade.

Virtual worlds and the Web

Interactive experiences are not only of the flat 2D variety, but also exist in 3D. Typically these experiences occur in video games that attempt to maximize the experience of the user, and not creators (especially users who want to create entirely unique personal content). After reading about HTMX and the history of Web 1.0, I became curious how these basic principles could be applied to 3D environments.

Certainly, all the technology is now here to create 3D worlds with JavaScript. Browsers in the 2020s are not the same as in the 1990s. We now have a bevy of technologies at our fingertips: Canvas, WebGL, WebAudio, WebGPU, WebSocket, WebRTC, WebXR. These technologies come with the expectation of a lot of JavaScript to use them. I wanted to explore the question of whether virtual worlds could be expressed without JavaScript, but with as much power as Web 1.0.

Before we continue, I want to clearly define some terms:

3D world - Any 3D environment, including the most basic static artwork-like experience that can be roamed around.

Virtual world - A 3D world in which multiple players can see and interact with each other and with the world. 

Metaverse - An interlinked collection of virtual worlds, including worlds created by different people.

Web 1.0-Era Virtual Worlds

Looking back in time, we can find artifacts of similar methods of describing 3D worlds that tried to anticipate the future during the Web 1.0 era. VRML was one such technology introduced in 1994, aimed at 3D visualization using a hypertext language similar to HTML. It was envisioned by David Raggett as a potential language for the World Wide Web for 3D. 

I will be the first to say I am not a VRML expert, but imagine a markup language that defines explorable worlds. These worlds were meant to be interactive and scriptable (not with JavaScript originally). At this time there were not highly capable browsers, so VRML relied on specialized viewer applications.

A scene like this might be built with code like:

DirectionalLight {

  direction 0 -1 0

}

# A yellow cone rotated about 57 degrees from vertical.

Transform {

  rotation 0 0 -1 1

  children [

    Shape {

      appearance Appearance {

        material Material {diffuseColor 1 1 0}

      }

      geometry Cone {

        bottomRadius 2

        height 8.1

      }

    }

  ]

}

When building my own virtual world technology inspired by the history of Web 1.0, I knew it had to have at minimum the concepts of a link and form. Unlike VRML, I can take advantage of many advancements that exist in the current web graphics visualization world.

• Libraries like ThreeJS for 3D visualizations (which have solved many important problems like 3D model import, common shaders, and abstraction of graphics hardware).

• The standardization of GLTF as a file format for 3D on the web, optimized for transmission speeds in browsers.

• The standardization and implementation of Physical Based Rendering (PBR) as a shader language for lighting models to make things beautiful.

• The imminent cross-browser standardization of WebGPU, using cutting edge multi-threaded graphics APIs like Vulkan and Metal.

• The extension of HTML elements with Web Components, allowing me to more easily make up an HTML-like markup language.

• Various implementations of WebXR for augmented reality and the complex types of 3D worlds I think we can expect in the future.

A new hypertext for virtual worlds

Let’s imagine a simple Web 1.0-era markup language. Let’s start first with creating the world.

<mv-space>

</mv-space>

Think of this as the creation of an axis you can attach 3D objects to. Which objects? GLTF 3D models of course.

<mv-space>

      <mv-model src="fox.gltf" position="0,1,0"></mv-model>

</mv-space>

Now remember, Web 1.0 didn’t have JavaScript. We need to create a world where interactivity is built into our hypertext language itself. Let’s implement the first powerful idea – the link!  Imagine that I and my friend want to create two sites that link to each other. We have a website at https://www.mr-fox.com/fox.html:

<mv-space>

  <mv-model src="fox.gltf" position="0,1,0"></mv-model>

  <mv-link href="https://www.mrs-rabbit.com/rabbit.html">

    <mv-model src="next_arrow.gltf" position="2,1,0"></mv-model>

  </mv-link>

</mv-space>

My friend might have her own website at the URL https://www.mrs-rabbit.com/rabbit.html:

<mv-space>

  <mv-model src="rabbit.gltf" position="0,1,0"></mv-model>

  <mv-link href="http://mr-fox.com/fox.html">

    <mv-model src="back_arrow.gltf" position="-2,1,0"></mv-model>

  </mv-link>

</mv-space>

We can now bounce back and forth between each other’s sites by clicking on the appropriate 3D element link. (Internet history-conscious or older readers might recognize this as an old school “web ring,” such as on Geocities and Angelfire).

The simple and powerful idea of the hyperlink alone could create a virtual world that’s read-only and explorable. Servers could dynamically generate whole worlds for the user to explore based on just this idea and the URLs they link to. They need not only be static models: for example, they could include dynamic changes driven by time of day or weather. It’s in the power of the server to generate the world people see.

We shouldn’t stop here though! To extend our virtual world technology to the full potential of an application platform, we need to add the idea of a form. Forms are what allow our browsers to send information to server endpoints and see rendered hypertext results. In an HTML form, we have a submit button — let’s create a parallel idea in our hypertext language.

<mv-space>

  <mv-model src="rabbit.gltf" position="0,1,0"></mv-model>

  <mv-link href="http://mr-fox.com/fox.html">

    <mv-model src="back_arrow.gltf" position="-2,1,0"></mv-model>

  </mv-link>

  <mv-form action="http://favoriteanimal.com/like/rabbit" method="POST">

    <mv-input type="submit">

      <mv-model src="thumbs_up.gltf" position="0,3,0"></mv-model>

    </mv-input>

  <mv-form>

</mv-space>

And here we have a “Like” button! (Alas, we are on the web and we do like to “Like” things.) But wait, couldn’t we have just had a server that watched for linked special pages for GET requests and also tracked the Like server-side? Yes — that brings us to an important aspect of forms: input controls. HTML comes standard with a number of controls (text, checkboxes, dropdown boxes, passwords, etc). Their purpose is to feed named values into the form’s action URL HTTP request when submitted.

<mv-space>

   <mv-model src="rabbit.gltf" position="0,1,0"></mv-model>

  <mv-link href="http://mr-fox.com/fox.html">

    <mv-model src="back_arrow.gltf" position="-2,1,0"></mv-model>

  </mv-link>

  <mv-form action="http://favoriteanimal.com/like/rabbit" method="POST">

    <mv-input type="text" position="0,4,0" name=”email”></mv-input>

    <mv-input type="submit">

      <mv-model src="thumbs_up.gltf" position="0,3,0"></mv-model>

    </mv-input>

  <mv-form>

</mv-space>

Using these, we can add a user’s email to their intention of a “Like” using this text entry input to fully utilize the vision of forms.

So there we have it, the two foundational primitives that powered Web 1.0 — now driving a virtual world. I call this hypertext language technology HyperShape, and it’s an implemented library you can play with right now.

This library is primarily created to show the most essential primitives of hypertext language applied to a 3D world. I’m not expecting anyone to go and create a high-quality game using this technology in its current form, but I think this library could be used for thinking about how a virtual world might be created from radically different first principles. Similar principles in the foundations of libraries like HTMX solve similar problems: particularly, the burnout on JavaScript. I wanted an interactive 3D technology usable by backend people that was as familiar as web forms are today.

Did I just invent a new industry role of backend 3D graphics programmer? I’m not sure I want to put that on my resume just yet, but it’s an interesting consideration: why shouldn’t server side developers be participating more in massively interactive worlds, with simpler tools to implement visualization and interactions. After all, they often have many adjacent skill sets that might be applied to other aspects of virtual worlds: identity systems, data storage, and collaborative networking. Why not integrate those with a good hypertext language, rather than requiring them to become overly specialized frontend JavaScript 3D developers?

Thoughts on a Web 1.0 metaverse and beyond

I imagine a potential future where many backend 3D developers are creating interconnected worlds with each other. I want to emphasize that even with the principles of a link and form I believe a huge variety of metaverses could be made, but … I think to make great-feeling metaverses, some additional technological considerations are needed that take into account people’s aesthetic needs.

Augmented reality

Augmented reality presents a new frontier, and we can see the implementation playing out right now. I think it’s important to be forward thinking from the beginning with HyperShape; I call the axis of my 3D objects <mv-space> in anticipation of worlds with multiple spaces. There are already implementations on Oculus Quest’s browsers for

• anchor points (fixed points in 3D space you want the device to remember)

• specific types of plane representative of real world environments (walls, tables, etc.)

HyperSpace will be built with the consideration of there being multiple spaces that could be attached to. In your house there might be many spaces managed by various people. You might have a chess board attached to your coffee table run by your friend’s server and your own calendar hanging on your wall run by your own infrastructure.

Form limitations

HTML forms have various inputs which provide values to form data, but one feature they lack is the ability to pass HTML headers along with their input data. Given the nature of virtual worlds, I thought it was crucial to be able to pass along contextual information about the avatar by default in order for the server to make informed decisions on what world to render next. In particular, the camera position and look-at position are passed as hidden elements to all form submissions.

Every form POST comes with form data items like these:

metaverse-camera-position 0,1.75,3
metaverse-camera-lookat 0,0,0

... other form data

I believe this is essential to enabling metaverse exploration in a way that is easy for servers.

There might be additional technologies required for form submission. I am exploring the potential of:

• Using WebSockets or other networking technologies for real time submission of data.

• The ability to declaratively auto-submit after a certain amount of time, or submit on an interval or by some other event (like movement of a camera).

• How to handle authentication information passed along to forms in a scalable way (perhaps more complex than hidden input fields). Particularly, I'd like a way that doesn’t involve cookies, to account for various legalities.

Forms are the sole point of data submission in this hypertext language. HTMX exposed the limitations of forms in our web applications, and I believe there are things I can learn from HTMX that are specific to the concerns of metaverses.

View transition technologies

HTML recently gained the capabilities of the View Transitions API in Chrome. In short, this is a technology that lets you swap out pieces of HTML more gracefully without a lot of effort. HTMX has also been an innovator in figuring out ways to manipulate a DOM without the full page reloads that forms and links produce, and recently announced support for View Transitions.

I am keeping my eye on innovations in both these technologies to help think of ways to make the interaction with metaverse environments more graceful and visually appealing. HyperSpace currently can swap out hypertext, but it could do more such as graceful fadeouts/fadeins, smooth movement with animation curves, etc.

This is valuable because design considerations  are often one of the main reasons why people turn to JavaScript. I want to limit the use of JavaScript in metaverses to only the most complex experiences.

Server-side patterns

When people face common server-side challenges, they tend to develop common architectures and best practices. As what happened with Web 2.0, I expect backend patterns to develop around rendering hypertext for virtual worlds. Already I’m foreseeing potential new architectures for several particular concerns:

• Making server-side content be more informed by physics and scripted behavior

• Allowing servers to collaborate in a unified presentation of digital land

• A protocol for inventory collections and spawning

The solutions for this might include web servers hybridized with headless game engines, standardized protocols for one server discovering and sharing hypertext representations of terrain with another, and standards around inventory associated with web identities. This is beyond the scope of this article, but I'm eager to experiment.

Sound

Sound adds an entirely new dimension to virtual worlds, and I haven’t even begun to scratch the surface of how to represent it. Some considerations for sound:

• 3D positioned sound

• Interaction sound effects

• Realtime sound streams (such as voice)

Conclusion

Reflecting on the difficulties of interactive application development with JavaScript, exploring the history of Web 1.0 principles and creating HyperShape has been a joy. I was happy to see that the retro virtual world tech of my recent imagination is not only possible with existing web technologies — but also powerful. This is an exciting frontier to me, and I hope it will bring us closer to metaverse technology where:

• Technology to create 3D worlds is more accessible to technologists than ever, particularly that backend developers and young web developers aren’t excluded from experience design implementation.

• People are excited about using web technologies, and not feeling locked into JavaScript.

• Individuals and businesses are given a sense of simplicity and lower investment during creation (ultimately resulting in money and time saved).

I don’t entirely know where this will go on two fronts:

• I don’t know if HTMX will be validated in practice as solving a crucial problem of investment of time in frontend development, but there’s a ton of activity in the dev community that will teach us in the next year.

• I don’t know what the fabric technology of the metaverse will be built on, but i’m optimistic for the web because it’s not a walled garden.

What I am sure of is that the cognitive load of HyperShape is low. So low that I put a tutorial on how to learn it in 4 brief steps below this article. Whether or not this library becomes a useful foundation, I hope this article helps in emphasizing a principle related to 3D interactive environments that should be considered in development of future metaverse technologies.

Learn HyperShape in 4 examples

3D model positioned in space that links to another page

<mv-space>
  <mv-link href="https://en.wikipedia.org/wiki/Fox">
    <mv-model
      src="https://richardanaya.github.io/hypershape/dist/Fox.gltf"
      position="0,.1,0"
      scale=".005"
      rotation="0,45,0"
    ></mv-model>
  </mv-link>
</mv-space>

Play with the demo.

An ocean and HDRI environment light with a camera looking at the horizon

<mv-space>
  <mv-camera position="0,1.75,3" lookat="0,1.75,0"></mv-camera>
  <mv-light
    type="hdri"
    src="https://richardanaya.github.io/hypershape/dist/assets/kloofendal_43d_clear_puresky_4k.hdr"
    backkground="true"
  ></mv-light>
  <mv-water></mv-water>
</mv-space>

Play with the demo.

A login screen in a HUD

<mv-hud>
  <mv-form action="/login">
    <mv-input type="text" position="0,.2,0" name="email"></mv-input>
    <mv-label position=".1,.2,0" text="Email"></mv-label>
    <mv-input type="password" position="0,0,0" name="password"></mv-input>
    <mv-label position=".1,0,0" text="Password"></mv-label>
    <mv-input type="submit" position="0,-.2,0"></mv-input>
    <mv-label position=".1,-.2,0" text="Login"></mv-label>
  </mv-form>
</mv-hud>

Play with the demo.

Replace content with interactive buttons

<mv-space id="my_object">
  <mv-model
    src="https://richardanaya.github.io/hypershape/dist/Fox.gltf"
    position="0,.1,0"
    scale=".005"
    rotation="0,45,0"
  ></mv-model>
</mv-space>
<mv-hud>
  <mv-form action="/avocado" target="my_object">
    <mv-input type="submit" position="0,0,0"></mv-input>
    <mv-label position=".1,0,0" text="Avocado"></mv-label>
  </mv-form>
  <mv-form action="/fox" target="my_object">
    <mv-input type="submit" position="0,-.2,0"></mv-input>
    <mv-label position=".1,.-2,0" text="Fox"></mv-label>
  </mv-form>
</mv-hud>

Play with the demo.

Subscribe now

Individuals within software development organizations display a great diversity of competency for different tasks. There are various aspects of these people that contribute toward their competency: experience, passion, and by far the most significant dimension - familiarity with organizational tasks. Familiarity with tasks is shown pronouncedly in a class of developers known as subject matter experts (SME). In this article, I will discuss what is essential to SMEs, how they are formed, and how managers can enable their creation through process design.

But first, why should we care to be aware of how SMEs are formed? The primary reason is the positive impact on many kinds of business strategies. Whether increasing the amount of work done, reducing costs, reducing risks, or innovation, they accelerate the pursuit of improvement. By mastering the art of creating SMEs you are making the most out of your resources. More SMEs will: 

• Increase the velocity of code implementation

• Reduce meeting time for knowledge gathering 

• Prevent burnout by distributing challenging tasks amongst more minds

• Increase the likelihood of seeing critical problems in advance

These individuals often have exceptional effectiveness with a particular part of a codebase. Their distinctive ability arises because an organization's problems are often unique. While many of an organization's problems have similarity to others in an industry, even a programmer with deep knowledge in general development may not have knowledge applicable to the choices that have been made within the organization’s codebase (architecture choices, performance choices, tech debt that accumulated to reach deadlines, etc.)

SMEs are formed through intentional effort. The harsh reality is that time alone is not sufficient. Some people exist within companies who have been working for years and not developed into one; even between two people with similar skills, passion, experience, and time at the same company, one might develop into a SME but the other might not. What’s happening here, what makes the difference between people, and why is time not enough? We will discover that crucial to understanding what makes a SME is understanding the psycho-epistemology of software developers. Ayn Rand defined psycho-epistemology as "the study of man's cognitive processes from the aspect of the interaction between the conscious mind and the automatic functions of the subconscious." What this means is, we’re going to be looking how the mind works and why it’s related to SME formation.

How to make a SME

Subject matter experts (SMEs) are formed by a very specific psychological process. Man’s consciousness has a certain nature of forming knowledge, and when action is applied ( no matter how long ) that does not adhere to that nature, it will not develop into a knowledge base with the equivalent sophistication of these effective individuals. Managers know if you want something done fast, go to a SME, and if you have the luxury of time perhaps a task can go to a non-SME to learn a new area. But what do we mean by these phrases “go fast” and “learn a new area”? A software developer is able to see the entire source code, all information is available to them. What differentiates a SME is the ability to quickly connect a task to non-explicit information laced inside the code base and to the decisions of the organization itself. How they do this, and what makes their work seem fast, is through the efficient recall of relevant information to a task and its subtasks via the subconscious.

Why the subconscious? Humans are limited in the amount of information they can maintain in their consciousness at any given time. When working on code, software developers do not have every line of code spinning actively in their brain. Certainly while many find it easy to recall details from one’s daily activity, but SMEs are recalling information from a wider structure of knowledge. Subconsciousness, is the place of that long term memory, primed for automatic recall for when the consciousness beckons for suggestions.

They are neither people with wildly intelligent brains who can parse through code quickly, nor people with unusually large working memory capacity. The subconscious is the determining factor, but how does it get there in the first place, and why does it seem like all people do not become a SME through sheer exposure to information in the office? Forming long term knowledge in the subconscious has requirements of its own and does not happen automatically. Man is a volitional creature; firstly, they must want to focus and form knowledge. Much like a student will never learn in class if they do not choose to focus on what a teacher says. Second, they cannot form knowledge for what they don’t have exposure to. Regardless of one's desire to develop into a SME, without a breadth of experience ( given opportunities, time with mentors to see different problems, etc. ) and given time to digest knowledge, it will not happen.

Rational conceptualization in particular is the essential process of what allows knowledge to form in the subconscious mind in a useful form. When we go through life, we are exposed to an innumerable number of objects. We simply cannot remember every individual object we see, and our mind has the ability to abstract these individual objects we see into concepts that we can economically retain. For instance, I do not remember every individual banana I have seen in my life, but I have a concept of a banana by which I can use and recall in a situation where fruit/yellow things/sweet things are mentioned.

The difficulty of forming conceptual knowledge in the workplace lies in the absence of explicit terms that anchor our experiences for recall. “Banana” and “fruit” are words I and everyone else have grown up with, and as soon as they are mentioned a flood of information comes to my mind for use when it does. As programmers however, we encounter many code patterns, data management techniques, and algorithms that simply do not have names. If you are lucky, a wise software engineer might have formed a jargon of an industry problem, but in the scope of your organization's unique tasks, if we are not forming concepts and labeling them mentally, we will have a mind full of individual snippets of experiences totally unconnected and thus unrecallable because they are not related to anything.

In order for the subconscious to store knowledge that is useful and recallable, we must have time to be able to see the similarity of objects in a meaningful way and intentionally recognize the most important connections. Consider if in my experiences with bananas, I only spent enough time to recognize they had a peel. I might associate a banana with an apple and orange. Outside of other things with peels I might give it no further relevancy as a concept in my mind had I not paid attention to its color, shape, or taste. All these aspects have the potential to be important, connections of the concept of a banana to other groups of things is useful (yellow things, long curved things, and sweet things). However, it’s most important we pay attention to aspects meaningful to our work. For instance, if I were a baker, it’s probably more important I know the sweetness aspect of the concept of bananas. Similar as a software developer, there are concepts we are forming with many aspects, some associations more potent than others, i.e. more connected to our wider knowledge base of our code than others. For instance it might help me to create concepts of code structures that have security concerns, CPU utilization concerns, are confusing for other programmers to read, or need thought around design patterns.

Let’s review the above quickly, before turning to consideration of how we use this knowledge in organizational process:

• Observed SME performance by outsiders is the observation of the SME’s efficient subconscious recall of information relevant to their tasks.

• Information is not stored in long term subconscious unless multiple experiences in clear conditions can be compared rationally

• Knowledge does not form automatically and must be desired by an individual to be created.

• We need to put in effort to rationally connect aspects of concepts that meaningfully tie to our actions and other knowledge.

This article isn’t a masterclass in psychology, but I hope i’ve given you a reminder of some important broad strokes we can focus on for utility.

Metrics for management

To improve organizational process with our knowledge of psycho-epistemology, effects must be measured. Given what we know now, we see that to quantify this type of improvement, we need to identify units of actions that increase rational conceptualization of knowledge or application of concepts. Some actions we might quantify include:

• Documentation - by documenting, an individual is forced to write and label concepts they’ve seen into a coherent structure. It might be architectural patterns, performance techniques, testing standards, etc. All of these solidify understanding for the writer and can help accelerate future creation of SMEs in the same domain who read it.

• Long term specialization - aligning organizations deeply with strategic initiatives rather than short term goals has the side-effect of creating repeated exposures to problems in a similar domain. This prevents the mental thrashing that occurs when someone jumps from radically different tasks that don’t allow one to see common aspects within the time of memory.

• Knowledge sharing - coders focus cannot be everywhere at once, but creating forums for people to share patterns they’ve seen can accelerate conceptualization of people who see similar patterns.

In science fiction, we might imagine a world with neuro-implants that allow us to track if people are maximizing subconscious recall of concepts. We could use this tool during the implementation of tasks, and see who and what actions are correlative. In the meantime we need our own introspective form of tracking. Individuals know their subconscious best, so to quantify this we need a system to create data points based on their own statements. Consider a survey of questions like these:

• “Do you feel like you are working on tasks you’ve seen before and are applying wisdom gained from previous work?”

• “Do you feel you have time to mentally digest tasks you’re working on?”

• “Do you feel you’re able to share knowledge created while working on your tasks with other people? How often?”

• “Do you like thinking about the problems you are working on?”

If over a long term, some process change suddenly turned all these answers into “no”, you will want to be aware of the corresponding drop in performance due to the cognitive inefficiencies created. The nature of human cognition is constant; if operations hamper it, performance will be affected.

I think it’s fair to say that this kind of tracking of conceptualization is not common in our industry, but I believe with observation, a team can see velocity shifts of an environment conducive for SME formation, hopefully in the positive. This is a science of the cognitive conditions of our organizational environment that can help managers see new dimensions of the impact to process change and interruptions. While many organizations may not have the luxury of making everyone a SME, we can try our best within financial limits to create a process that does its best by being aware of deeper effects of process policy. I hope this article has equipped you with a new tool for enhancing the efficacy of programming teams and perhaps knowledge workers more broadly.

I want to share with you my method for making software time estimates by economizing one’s analysis of timed activities to a cognitively manageable level. Why is this worth your time? Working in software engineering makes you very aware of the value of knowing how to size your work. There are many approaches:

• Some people view it as a mystic art, discovered like some pythagorean mystery of secret ratios by which to fudge numbers.

• Some view it as elaborate statistics of t-shirt sizes, poker cards, or other units of velocity.

• Others just shoot from the hip

If you possess any amount of talent in this industry, you will be asked the question: "When can you get it done?"

The cause of this comes from businesses' need to make plans for a very long term. This might occur for instance when they start to get a glimpse of the market they serve or start a project that might take a year or more. Companies often will put strong visibility into a single quarter, and sometimes rough visibility 1-2 quarters ahead. These often begin as nebulous plans, built on a variety of goals each with specific risk. To take them from existing as pure whim, a long chain of questions is asked that eventually cause a developer to be asked “How long would this take?” This process happens because there are trade offs in strategy. Consider if some feature:

• takes 6 months

• has high risk and likely will not be done on time

• is aligned with the company's target market

• earns a million dollars

Versus some other feature that:

• takes 2 weeks

• low risk and will certainly be accomplished

• is not aligned with the target market

• earns five hundred thousand dollars

Leadership may interpret these features differently, particularly when they have accurate time estimations.

These tradeoffs must be informed because business branches must align across a long period of time. There is a funnel of customer attraction that starts with marketing first spreading the word to an industry, sales people bringing in those attracted as customers, and finally engineers having an actual functioning product for them when they arrive. If the funnel does not have something of value at the end of the long path, strategy will not succeed to acquire a market, customers may churn, and/or frustration within the organization will happen.

If your career started like mine, you probably once felt when estimating that you could not predict that far in advance (especially when measuring for a team as a whole). You might give a good estimate of how much code you could write in 5 minutes, but not over 5 months. The consequence of this for my career was my teams and I always felt like we were being too ambitious but couldn’t put our finger on why. Software engineering veterans inevitably come to the conclusion that “we don’t have as much time as we think'', but we must understand exactly what causes this for our conclusion to be useful in making change.

What makes a good estimation system effective is how deeply you have identified fundamental action in your business quarter. What do I mean by fundamental? I mean that in a given quarter, there is action that is essential to creating product features (i.e. if the action is missing, the outcome will certainly not happen), and there is action that is non-essential. You must have evidence of what this fundamental action is and how much of it you have. Rather than looking inward, you have to look outward toward objective action. Thus, this method begins with a deep analysis of how people spend their time.

Warning: the following numbers are estimates chosen solely for the purposes of explanation.

Human Time

At a high level, we can think of a programmer's time divided into at least four parts:

It is well known that humans do not work 100% of the time at the job. While true, it can be difficult to admit in a workplace. Businesses, however, do not benefit by ignoring this reality and hoping people will somehow “make up for it”. Before you even get to work, you must first be human. What does being a human mean in a work perspective?

• Humans need rest and will take vacation. They need this not only for their personal health, but also to be productively optimal. This use of vacation includes fixed holidays but may also be sporadic.

• Humans occasionally get sick or have major physical changes that require time off. This can happen at any time to anyone. We should not be assuming your team will be forever in a singular state of health.

• Humans have psychological inertia. Let’s face it, you aren’t at the top of your game all day and every day. Monday morning before you’ve had your coffee is not the same as Wednesday afternoon after you’ve been two days deep in thinking about problems.

• Humans do not transition effectively. We do not instantly start typing the second we end one meeting. These little buffer zones between activities eat away at our time.

• Humans have a social need for companionship and assurances of where they are. Perhaps they have coffee breaks with people, attend all hands, lunch and learns, company parties, or have 1 on 1s with their boss. Many of these meetings happen at regular intervals.

• Humans leave companies. We can’t assume people will be at your company forever in the grand vision of their career ( though by reading articles like this you are certainly encouraging it! ).

Needless to say, this human reality takes a huge chunk out of people’s time and must be acknowledged. Even among teams of entirely smart individuals these limitations exist. They derive from natural limits of the consciousness and body.

Product Time

After we subtract out human time, we need to further divide the time allocated most directly toward the company’s product goals. There’s a number of subcategories:

• Product roadmap features to acquire a market.

• Tech debt not on the product roadmap to make more maintainable code or reduce costs.

• Innovation and growth tasks to let teams be prepared for new challenges and making radical decisions more knowledgeably.

• Sporadic work to prevent churn of valued customers

Not all work for the product road map is equal. The fundamental action that creates product features is literal coding with hands on the keyboard. There’s a number of supportive actions that surround this fundamental action, each existing in various ratios relative to the time of the core action of programming. For example, if there is 2 days of programming, there’s might some amount action surrounding it:

• Product meetings that had to happen to make the days of programming informed.

• Coding practices your team has decided to do to maintain quality: automated testing, documentation, etc.

• Work that gets sent back from a tester to fix some hopefully minor bug.

• Meetings for a software development methodology (Agile, SCRUM, Kanban). These meetings synchronize information, raise blocking issues, and demonstrate what’s been made. One should pay close attention in particular to code freeze dates (if they exist) as they represent points in a cycle which no coding can occur.

Quarterly planning also requires time itself. This is not a trivial task as it requires the orchestration of the product to come up with potential features for developers to understand/break down/size/compare. During this time leads will naturally be directly involved more than others, but often they will have to ask questions directly to programmers due to their limited knowledge/familiarity of specific areas. Involving non-leads is also crucial to get a sense of commitment. If an engineering team is going to say “I commit to this quarter” with full honesty, they have to be asked to evaluate it to a degree with their own mind.

Risk

An additional dimension to time allocations in a quarter is the level of risk. At least two kinds of risk exist:

• Risk of the role performing the activity. Experience is unequal in any company and it should be taken account of that some individuals will need more time to get to solutions than others.

1. Consider a junior programmer or new employee for instance, and the reality that a sizable percentage of their time may be applied to researching an existing codebase

2. Even fully trained employees may not get the right architecturally aligned implementation written on the first time around.

3. Consider that bugs are more likely to happen in complex work with many aspects to get right vs simple one liner changes.

• Risk of product change

1. Not all work is equally well defined. Product and design hit limits just as programmers do. You might get into a quarter unprepared with product requirements and should treat that risk appropriately.

2. Discovery can happen at any minute. A customer might tell you some detail of how they use their product that completely changes how it gets implemented.

All these risks need to be accounted for if one has meaningful evidence. For instance, imagine a full time programmer who has been at the company has 40 days of work scheduled in a quarter. One might observe through experience when they operate in your codebase that 90% of effort is hands-on coding time that reaches the final code base, 10% might be rewriting. A different codebase may have different proportions! In another aspect, you may form an observation that 20% of all features tend to be complex development tasks with high risks of bugs, and 80% of tasks are simple with low risk of bugs. Again, you must integrate this observed risk and adjust the amount of expected bug time if you see it.

When it comes to risk, you should always assume the maximal risk. With quarterly planning, the importance is that leadership knows what to expect 100% of the time. If you do more work, that’s fine, and importantly should be appropriately recognized. Only by carefully reflecting reality and risks will your victories above and beyond be apparent.

Aggregating of Variation

Finally, one must take these numbers and aggregate them into the engineering organizational structure. This is highly dependent on your own company and possibly who you expect to join or leave. Work is typically done by teams oriented around a primary aspect of a product they are familiar with. Each of the individual roles of that team contribute a certain number of hours of raw coding time based on experience. If, say, I had:

• A lead with 6% of her quarter toward coding ( time being taken by mentoring and leadership communication )

• 2 standard devs with 10% their quarter toward coding ( have maximal potential of time )

• 1 junior dev with 7% of his time toward coding ( inhibited by unfamiliarity with a codebase or programming concepts )

These percentages can come up with a maximum real coding time number that can be brought to the quarterly planning. Perhaps you say, “We only have 10 coding weeks” total for a team we can apply toward some domain of features. This indicates if features will be completed fully or partially, and may suggest a re-org, hiring, etc. is needed. Ideally even a rough estimation of this is known in advance of the next quarter to start a hiring process early.

Importantly too you must recognize the contextuality of individuals. You’ll want to know if members of one team are taking 2-3 weeks off for December holidays or saving them for a spring trip to another country in a different quarter. Don’t be the engineering leader who sets his team up for failure for not accounting for holidays (and the mental recovery from these necessary detours from productivity)!

Conclusion

The goal of this method is to reduce the number of considerations when assessing how long features will take to be done. After you have subtracted out objectively based allocations of human time, meeting times, development supportive tasks, and risk, the question is much simpler to answer. 3 months of time may in actuality be only a few weeks of actual hands-on coding time on a keyboard. Programmers are far more capable in making commitments when they can clearly imagine a continuous time of optimal conditions for programming they can see from beginning to end.

This is a method for making an estimate appropriate to man’s consciousness and its limits, it is not an attempt to generate a one size fits all answer for every company under the sun. No person can write a divine pie chart for all companies and their permutations of experience, quarterly holidays, software development methodologies, roles, codebase complexity, product domains. Making estimates for NASA computer scientists is not the same as doing so for a startup focused on a social media app, so focus on the essential activities you can see contextually in your own company. I personally put all my formulas in an excel sheet and visualize a cycle of development time (2 week sprint) to validate where I see hours being applied. I hope you have fun assembling your mental model of your team in the tool of your choice. There's an aesthetic value in seeing a massive chart of all these numbers with your colleagues and saying: "This is who we are", and an even more important career value in being teams that can be trusted to meet expectations.

May your path be planned, and your successes be seen!