Product Development and Coding Speed

Coding is a key part of product development. However, it is only a small part. Significantly more time needs to be spend on activities such talking to potential users, figuring out what to build, testing, and getting user feedback. Also, organizations create many products that do not involve writing software. It’s important to realize that software is a tool that is suitable for solving certain problems.

As an example, for Create Third Places, I have been spending a significant time learning about urban planning concepts that are related to third places, and this does not require creating software. Even for dmvboardgames.com, which is a software project, I am not spending a significant amount of time coding. More of my time is spent on talking to users and thinking about ways to improve the user interface.

I think previous experience also affects how much a tool should be used. My previous software experience is helping to make coding useful for Create Third Places. On the other hand, Create Third Places could function without me creating software if I had a different set of skills.

Due to the fact that coding speed is only a small part of an organization, one should be careful about focusing too much on coding speed. After a certain point, efforts to improve coding speed can have a negative impact because less time is spent addressing the bottlenecks.

Time spent to address bottlenecks besides coding will be more important. Also, addressing bottlenecks will involve set of skills, and practicing a skill will make you better at it. In the long run, this will mean less time is necessary to address bottlenecks.

Over the past decade, I’ve also noticed that software development requires a mindset that is very different from other work. I find that I can have a balanced software mindset if I minimize unnecessary coding. However, if I focus too much on coding while trying to improve speed, I start to have difficultly with other work. I think one reason is the fact that I see software as rooted in real world use, and unnecessary coding disconnects me from the real world.

For further information, I recommend the Deep Life Podcast by Cal Newport. Cal is a computer scientist who talks about the impact of technology and ways to manage information overload.

Create Third Places and Slower Paced Information Processing

Currently, I see information overload as a challenge for society, and I want https://createthirdplaces.org/ to help address the challenge.

Create Third Places does not have an official presence on any social media website right now. While I could theoretically reach more people with social media, I don’t see that as beneficial. I would be competing with large organizations with vast amounts of resources to spend on social media that will probably make Create Third Places hard to notice.

Social media websites already present people with a large amount of information that causes overload. As a result, details about Create Third Places could be missed or understood incorrectly.  I would also be adding to the amount of information overload people are dealing with.  In addition, I would have less time to spend on other work because of the effort necessary to make Create Third Places visible on social media.

By sharing information about Create Third Places without social media, I am encouraging slower paced information gathering that prevents an overload. It is easier to share information Create Third Places in person where the environment is less distracting.

Why we should reduce the amount of generated information

The amount of information we are generating is rapidly increasing and information can be shared with more people through social media. However, the amount of information we generate is outpacing our ability to process it, which is causing challenges. This decline is demonstrated by a study showing that attention span when using computer declined from 3 minutes in 2004 to 40 seconds in 2023.

For the purposes of this article, I am classifying information as something that people are paying attention to and thinking about. For example, computer code that someone types is information. However, if the code is compiled into machine readable code, I don’t consider it information since a person will not be looking at. Automatically generated text is not information if nobody is going to pay attention to it. By the same logic, a busy city sidewalk may not cause information overload if you aren’t paying close attention to details about your surrounding that aren’t relevant to walking.

Challenges with information overload

Human brains have a limited capacity to process information. The extra information tends to become a net negative. More information means you are receiving information more rapidly. This means more context switching from trying to process information to trying to receive information. The information may also accumulate in your brain, causing an ongoing cost.

Context switching also has a time cost. Also, if you are context switching when trying to process information, unprocessed information will sit in your brain. Even if the time cost of context switching was hypothetically zero, information overload has a significant cost.

To simulate the effects of context switching, I set up a simulation representing 1 hour of time where it took 60 seconds to process a unit of information. I then configured 60 units of information to come at random intervals. Across 10,000 runs with 2 seconds of context switching to handle interrupting information, an average of 52.6 units of information were fully processed. If the number of units of information was doubled to 120, an average of 54.5 units of information was processed due to less downtime.

If the time needed to handle interrupting information increases, then the ability to process information will be significantly lower. At a certain point, the ability to process information will be close to 0.

Here are the results from running the simulation with different interruption lengths.

Interrupt timeInformation processed with 60 incoming unitsInformation processed with 120 incoming units
2 seconds52.654.5
4 seconds51.346.9
8 seconds48.243.1
10 seconds46.539.3
1 minute50.6
2 minutes0.90.2
23 minutes0.60.1


These figures are likely underestimates due to the cognitive load of trying to keep information in your head until later, forgetting something, and some interruptions requiring switching priorities.

For example, let’s say you received 10% more information in an hour than you could process. More than 10% of the information you receive will be unprocessed. In the real world, the 10% of extra information will be spread out over the hour instead of being concentrated at one time period. In a scenario where you prioritize completing processing of a piece of information before moving on, some of your mental capacity will be devoted to prioritizing the 10% of information that you cannot currently process.

Challenges with information overload suggest that we should be careful about tools that allow us to generate output more quickly. This reduces the cost of generating output, which is an incentive that can cause people to generate more output. If people are looking at that output, that means adding to the information overload problem.

However, this doesn’t mean completely getting rid of tools that help you generate more informational output. Used with intention, they can be helpful. For example, when creating pages for this website, I did not log into the server and manually upload a file with HTML website markup. Instead, I used the WordPress content management system(CMS) I set up to type the page content and click the “save” button. The automatically generated HTML code is not extra information since I do not need to look at it.

The WordPress CMS on this website includes a large volume of code. However, it is not adding to the amount of information I need to process. The configuration I set up over a decade ago still works today, and I have never had a reason to look at the CMS server code.

Solutions

While technology can contribute to this issue, I think it is important to avoid the trap of focusing too much on problems with specific technologies. Technologies with positive real-world impact are contributing factors with the Internet being one example. With the Internet, it is important to remember how useful it has been to connect with people and find essential information. I’m finding it useful to also think more about.

The Internet can also be a useful tool for reducing information overload. For example, using an online tool for research can mean spending less time looking at irrelevant information from manually going through sites.

I have been spending more time on lower information activities when a higher information activity doesn’t provide much of a benefit. For example, yesterday I was doing research on population statistics in Arlington County, Virginia during the 1960s and 1970s. I decided to take the extra time to go to a library to look up the information. If I tried to look for the information on the Internet, I probably would have stumbled upon a lot of information that would have difficult to fully process.

At the library, I found information by reading old printed reports from Arlington County. The extra information was relevant to me, since the research was for an article about how neighborhoods in Arlington developed differently. I also took notes with a pen and paper instead of using my laptop. This made it harder to get distracted by the Internet since I would have to take the additional steps of unlocking my phone and opening a web browser.

AI powered trains and other domain specific automations are great

https://www.wmata.com/news/metro-to-launch-automatic-train-operation-on-the-blue-orange-and-silver-lines-on-june-15.html

Recently, the DC Metro has enabled Automatic Train Operation, and it has been great as a rider. Train rides seem to be significantly smoother and quicker. From an engineering perspective, I think this is a great form of AI in the form of domain specific automation. Trains are running based on clearly defined parameters and success criteria.

When riding the bus yesterday, I was also impressed with the new domain specific automation shown in the picture below. It took the GPS position of the bus and showed the upcoming stops.

This week, I have also been appreciating the automated weather forecast models telling about the upcoming heat wave.

Also, I leveraged a domain specific automation to make this blog post. I did not write this post in HTML and manually upload it to a server. Instead, I logged into the WordPress CMS and typed content using a visual builder tool. Once I clicked the save button, the changes went live.

Thoughts on usability improvements for dmvboardgames.com

I was considering adding a corkboard texture to event information on dmvboardgames.com to look more like a physical bulletin board for usability purposes. At first, I saw it as a good way to emphasize the site’s focus on in-person events. The next day, I thought about the idea some more and decided that it wasn’t a good idea.

I came to the conclusion that adding a corkboard texture was not a good use of time for the following reasons.

  • User feedback I received in the past does not give a clear indication that a corkboard texture would improve usability. On the other hand, a corkboard texture could negatively affect usability by adding additional content.
  • The main goal of the site is to show information about in person board game events in the DC area, and a bulletin board doesn’t clearly help. Other elements besides text have a clear purpose. The hex background is supposed to be a reference to hexes in board games, and I use colors that resemble hexes in the board game Catan. The figures at the top are meeples, which are commonly used in newer board games. The different colors are to promote inclusivity in board games.
  • Additional styling will have an ongoing cost in maintenance.
  • The boundaries between in person events and websites would be blurred. I want the site to exist as an entity distinct from the events themselves.



I then thought about my earlier views towards adding a corkboard texture as a way of trying to improve the usability of the site. Then I decided to think more about user feedback I had received to make some smaller UI improvements.

Alternatives to React for website development

Since leaving my last job in March 2025, I have avoided using React for website development. I am using vanilla JavaScript, CSS, and HTML with some third party libraries and a small framework I developed called places.js. These are the main website projects I am working on:

  • createthirdplaces.org/: The goals of this website is to promote accessible public spaces where people interact in person. It uses Kelp for styling. There is some use of places.js or highlight.js with it’s own styling for code examples. Most pages on the site run with no Javascript aside from code for blocking bot scraping.
  • dmvboardgames.com. This site is designed to support the mission of createthirdplaces.org by supporting public board game events in the DC area. It uses Kelp for styling and places.js for interactive parts of the website.
  • This website, which uses WordPress. I set up WordPress for this site more than 10 years ago, and I haven’t seen a strong reason to move towards another tool.

Source code for createthirdplaces.org and dmvboardgames.com can be seen here.

From looking through job postings and source code from open source projects, React is still widely used. Recent https://w3techs.com/technologies/overview/javascript_library from multiple sources confirms that it is one of the most popular JavaScript libraries. Despite this popularity, I think React is a flawed tool and that there are better choices out there.

Most sites are designed to render static content, and adding React is unnecessary complexity. For sites where interactivity is needed, I think React has problems that lead to an overly complex code base with UI performance issues.

1. Gaps in functionality around efficient cross-component state management, page routing, and API data fetching

Finding dependencies to address functionality gaps in React can be a time-consuming process. Due to the way React works, simply applying vanilla JavaScript patterns is probably not going to be a viable option. For example, I was once tasked with evaluating state management options for a React application, and the evaluation took two weeks.

First of all, there were a variety of state management tools available including MobX, Jotai, Redux Toolkit, and Zustand. Improved state management with more efficient uses of the useContext, useReducer, and useState hooks was also considered.

The project also had other dependencies used to address gaps in functionality, and it was using an old version of React. This version was not compatible with the latest version of some state management libraries. When I tried upgrading to the latest version of React, I ran into errors with some of the dependencies that required version upgrades and some code changes. Also,one of the dependencies was incompatible with the latest version of React, and adding a replacement was gong to take a while.

2. Quality of official documentation

As of June 2026, the official documentation recommends using React with a full-stack framework. Not every website requires custom server-side code, and adding it will likely lead to unnecessary complexity. While the documentation mentions that a full-stack framework can be configured to only support client-side rendering, the configuration is still added complexity.

There are better ways of implementing the functionality provided by a full stack framework. If the goal is to fetch data and render web pages on the server, I think PHP is a better choice due to the ease of getting started and quality of documentation. Otherwise, I think it’s better to run a separate server in the language of your choice. This ensures that complexity on the frontend and backend is isolated, which improves long-term maintainability of a codebase.

The documentation recommends one of three frameworks, Next.js, React Router, and Expo. I don’t think any of these frameworks are worth using.

Next.js is the top recommendation. It has features designed to rely on server-side logic, and they do not work with client side rendering.

The next recommendation, React Router suggests configuring a website as a single page application(SPA). I don’t think a website should be created as a SPA. Using a SPA can make the user experience slightly better due to faster loading speed after the initial page load. However, creating a high quality SPA will add a significant amount of complexity and time needed to maintain code. Complexity will come from the code necessary to implement SPA functionality in addition to the fact that complexity on one area of the website is less likely to be isolated.

It doesn’t appear that client side rendering is a limitation for Remix, which is the third recommendation. However, the documentation includes functionality that is unnecessary for a website.

The documentation is also hard to follow in some pages. One example is the fact that the https://react.dev/reference/react lists sections for server APIs and static APIs. Both of the them are used to render React components to HTML and include text saying “Most of your components don’t need to import or use them”. Meanwhile, these sections are also a distraction from documentation on hooks and built-in components that are more relevant.

3. API complexity

The React API has become very large, and it’s hard to know when certain functionality should be used. Every React application I worked on has turned into an unmaintainable mess of spaghetti, regardless of how experienced the developers were. The complexity of the API without effective tools for structuring UI code made it difficult to avoid the spaghetti.

The most notable example of this I experienced is with state management hooks. useContext, useReducer, and useState can all be used to manage UI state. Using all 3 hooks in a codebase will make it harder to understand. One can also use a state management library that comes with its own hooks.

The API complexity also leads to slow websites due to the challenge of writing React code. For a good user experience, a user interface should show some sort of feedback within 0.1 seconds of a user clicking on a button. On a slow React website, it might take significantly longer than 0.1 seconds. In the case that the codebase has turned into spaghetti, finding the cause of slow responses can be next to impossible.

Once the cause of the slowness has been identified, fixing it can take a long. Sometimes, this means indefinite postponement because of other high priority work.

4. Extra complexity when page has a significant amount of static content.

In many cases, it makes sense to render a page with static HTML and small islands of interactivity. There is some additional overhead that is necessary to have the interactivity islands use React. Also, React does not have built-in support for sharing state between islands. An additional library or specialized logic is necessary.

More evidence about the problems with LLMs

I think the current iteration of LLMs is flawed and being propped up by billions of dollars in subsidies.

LLM company OpenAI is running out of money and is planning for an IPO. In the first quarter of 2026, they lost $1.22 for every dollar of revenue generated.

Meanwhile, the cost of GitHub Copilot LLM tokens is going up by 10x to 100x.

Businesses are also funding LLM data centers with collateralised debt obligations like the ones that caused a major financial crisis in 2008. The commercial real estate market in the US is already approaching a state of crisis, and the pop of the LLM bubble will make the crisis worse.

Many of these data centers are being viewed as commercial real estate loans, and are contributing to a rise in real estate debt. Meanwhile, commercial real estate prices are on a steady decline. The decline will likely accelerate once the LLM data centers are recognized as worthless.

Sources

International Monetary Fund, Commercial Real Estate Prices for United States [COMREPUSQ159N], retrieved from FRED, Federal Reserve Bank of St. Louis; https://fred.stlouisfed.org/series/COMREPUSQ159N, May 26, 2026.


Board of Governors of the Federal Reserve System (US), Real Estate Loans, All Commercial Banks [REALLN], retrieved from FRED, Federal Reserve Bank of St. Louis; https://fred.stlouisfed.org/series/REALLN, May 26, 2026.

Deciding to not work on idea I have

I have an idea for training task-specific models using multi-stage training. The first stage would be training the model simple data. During subsequent steps, the model would be retrained with increasingly complicated data. However, I am deciding not to work on it for two main reasons.

 First of all, while the idea seems to make sense in my head, it may not be realistic to actually implement. Practical realities are likely to make multi-stage training not make sense. Researchers have tried to implement a multi-stage training process in the past and ran into difficulties. If resolving them is possible, the solution is probably going to be complex and require a more detailed understanding of AI model training.

Also, I think software should be designed from a user first perspective where a developer talks with people and uses the feedback to create a helpful product. Trying to focus on a specific solution would move me away from a user first perspective, even when the solution has uses. User needs for a solution will also fluctuate over time. It’s important to pivot away from working on a technology if it is no longer relevant to what a user is looking for. Also, if a new technology I develop turns out to be useful, other people will try to copy the technology or develop their own version.

When it comes to developing AI technology, I believe in being fully transparent about how it works. If it is based on some proprietary algorithm, people won’t be able to understand it and give feedback. It would also be far more disconnected from users. Also, models can be very complex, and trying to make one that is straightforward enough for people to understand without a background in AI is hard.