Let’s say every company gets about three innovation tokens. You can spend these however you want, but the supply is fixed for a long while. You might get a few more after you achieve a certain level of stability and maturity, but the general tendency is to overestimate the contents of your wallet. Clearly this model is approximate, but I think it helps.

You can replenish the tokens if you can to hire more people who brings new innovation tokens with them.

If you choose to write your website in NodeJS, you just spent one of your innovation tokens. If you choose to use MongoDB, you just spent one of your innovation tokens. If you choose to use service discovery tech that’s existed for a year or less, you just spent one of your innovation tokens. If you choose to write your own database, oh god, you’re in trouble.

Write own database should be worth 9 innovation tokens in this scenario.

Any of those choices might be sensible if you’re a javascript consultancy, or a database company. But you’re probably not. You’re probably working for a company that is at least ostensibly rethinking global commerce or reinventing payments on the web or pursuing some other suitably epic mission. In that context, devoting any of your limited attention to innovating ssh is an excellent way to fail. Or at best, delay success.

Above paragraph is the most important paragraph every company should have printed instead of those innovative inspiring posters.

The nice thing about boringness (so constrained) is that the capabilities of these things are well understood. But more importantly, their failure modes are well understood.

The problem with “best tool for the job” thinking is that it takes a myopic view (aka short term) of the words “best” and “job.” Your job is keeping the company in business, god damn it. And the “best” tool is the one that occupies the “least worst” position for as many of your problems as possible.

Be it elections or tech, chosing least worst is most essential thing we forget or refuse to do…

In the realm of contract work, invoicing often feels like a tedious chore that consumes valuable time and mental energy. As a seasoned professional who’s navigated these waters for years, I decided it was time to revolutionize my approach. The result? A serverless invoice management system that transformed a hours-long ordeal into a 5-minute task.…

This is an interesting paper I read last month. The notes on this paper gave me an idea of having linkblogs…

Original Paper link

Some quotes

Under 4: Parting comments

ORMs are a vital tool for rapid prototyping. But they often sacrifice the ability to push logic into the DBMS in exchange for interoperability with multiple DBMSs. Developers fall back to writing explicit database queries to override the poor auto-generated queries. This is why using a RDBMS that supports SQL is the better choice.

Echoing my post on ORMs. epmhasis mine

The portion below, under the sections of blockchain is where things get personal…

Shots Fired for blockchains Ofcourse emphasis mine

We are required to place trust in several entities in today’s society. When one sells a house, they trust the title company to manage the transaction. The only applications without real-world trust are dark web interactions (e.g., money laundering). Legitimate businesses are unwilling to pay the performance price (about five orders of magnitude) to use a blockchain DBMS. If organizations trust each other, they can run a shared distributed DBMS more efficiently without wasting time with blockchains. To the best of our knowledge, all the major cryptocurrency exchanges run their businesses off traditional RDBMSs and not blockchain systems.

Blockchain proponents make additional meaningless claims of achieving data resiliency through replication in a peer-to-peer environment. No sensible company would rely on random participants on the Internet as the backup solution for mission-critical databases.

Essentially, Blockchain is a solution looking for a problem. And more ofthen than not, there are always better solutions then what Blockchain offers.

On ability to have a better onboarding DX.

One of the salient selling points of many non-relational DBMSs is a better “out-of-box” experience than RDBMSs. Most SQL systems require one first to create a database and then define their tables before they can load data. This is why data scientists use Python notebooks to analyze data files quickly. Every DBMS should, therefore, make it easy to perform in situ processing of local and cloudstorage files. DuckDB’s rising popularity is partly due to its ability to do this well. (My Note: Didn’t think about this till now…)

Youtube Video, via JS Party podcast episode Building LLM agents in JS

Notes

Non Agentic workflow: Do it start to finish. Mostly zero shot prompts.

Agentic workflow: Revise, iterative, reflect, use tools if you need to….

Four design patterns.

1. Reflect: Produce one thing and ask another chat thread with different system prompt to evaluate it. E.g. Create a code, than ask a rubberduck debugger to read it line by line, or run the test suite and provide the result to LLM generated the code to evaluate it. Or write a post, and ask an editor LLM to reflect it, and ask writer LLM to update the post on feedback.

2. Tool Use: Use tools and function calls, there are lot of that, even we have developed one for SourceSailor.

3. Planning: Like give a task to LLM and then ask it to plan the solution step by step, and then ask LLM to execute the plan. Take the task description, create a plan, break a plan to subtasks, and then use aider to execute the plan.

4. Multiagent Collaboration: Create multiple LLMs for one single task, and create an orchestrator LLM to collaborate between them. Like one LLM (Powred by sonnet) for figuring out style, another LLM (Opus) for generating the writing, another LLM (Opus or Gemini or GPT) to do the reflection and a haiku or 4o powered LLM which orchestrates between them.

After more than a year, the blog is getting an update. This is a short summary of what is getting changed…