đ Work 2.0 - the interruptible programmer
This is a good read from Steves String. I discovered this blog from a youtube channel called Internet of Bugs. The post completely changes the way we think about productivity and work, especially when your are at the other end of your 30s.
The post discusses about how it’s not feasible to work for long hours without any interruption. It’s not just about the physical health, but also about the mental health.
And this post discusses about two things: Allowing interruptions, and move the context out of your head as soon as possible (AKA Taking notes before you lose focus).
I love this idea, especially how copilots and all the AI coding tools makes it a second nature to offload all the context to the coding tool, and then revisit it later whenever you want.
I suggest you to read the original post, it’s more than a decade old, but it will still be relevant in 2030s.
Jest, ESM, and the Meta Tech Conundrum: A Cautionary Tale
Code Assistants: Blurring Category Lines
The RAG Challenge: A GitHub Copilot Experiment
đ Software Is Bananas
Kent Beck has shared some good insights in his substack. If I have to start with something, this is probably it. This post takes a short and stingy look around real “aglileness” of software development. Short but quick deployments and closer feedback loops instead of long and drawn out processes. Because at the end of the day, there is one bug lingering only in production enviorment which is waiting to be revealed.
Software is bananas. Buy a banana and youâd better eat it. Youâre not going to be happy with the experience in a month.
Interesting to see me using the ârotting foodâ metaphor in another context. I think Iâm trying to sensitize people to the cost of delay. Somehow some folks just donât feel it.
đ Choose Boring Technology
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…
Streamlining Invoice Management with a Serverless Approach
đ What Goes Around Comes Around... And Around...
This is an interesting paper I read last month. The notes on this paper gave me an idea of having linkblogs…
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…)
đ AI Agentic Workflow Andrew Ng
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.
Updates in blog
đ How does AI impact my jobs
Itâs not their fault. They enrolled in a masterâs program to get a job in tech. Why? Letâs be candid: tech has promised job security and agreeable (sometimes borderline perverse) financial returns for a couple of decades. Many tech employers also spin a yarn about âsaving the worldâ and coast on the reputational allure of âif you work here, youâre a genius.â Sounds great, doesnât it? Except, now that students have invested five figures of money in their tech education1, had their skulls crammed full of âinvisible hand of the marketâ propaganda, and counted on having secured their ticket to the party, theyâre seeing layoffs. Theyâre seeing exposĂ©s. Theyâre seeing compensation adjustments at the most lucrative tech companies. And theyâre seeing a news cycle that oscillates wildly between blaming AI for these changes and extolling it as the solution.
you learn to write Dijkstraâs from a blank editor so you can get the job at Twitter, but once you accept the offer you never actually do that. What you need to do is understand, update, and (optimistically) un***k existing systems written by other people.
Are large language models gonna cause programmers to lose their jobs? Not anymore than StackOverflow did, in my view. However, it’s going to change themâŠsomewhat.