TOC
The Context
My mind wavers a lot. My thoughts and actions never stays at one place. It keeps jumping like a monkey. accumulating up these small drifts every day takes me far far away from my goals which I plan for that year. here is an analogy:
assume the blue line is what I plan my year (jan to dec). and red lines are possible deviations everyday towards that goal (life happens there can be tons of deviation,ups and downs). this is the ideal graph which we wanted. but for me I end up with the graph below
the dotted line is the final graph I end up with at the end of the year. it is still a improvement,still in positive direction but thats not what I actually wanted I wanted the blue non dotted graph. one important reason I identified is alignment issue. if I would have retrospected once in a week/ month to see if I am on the right track, I would have shifted my focus and who knows might have followed the ideal trajectory that I wanted. if you are reading this then definitely you are a self starter and a curious mind to learn new things. Tech is a funny field where we need to learn forever and nobody knows what to learn,where to learn. every one of us run in a circle cribbing about resources,guides,mentorship etc etc. if I learn something today its definitely because someone has shared that resource on the internet. all my learning are from the internet and my biggest joy is to share them so that you guys can find some more cool people and keep branching like a cyclic graph. I am very sure that some months are extremely busy,some months are extremely productive just like the red dots. eventually I want to be closer to the blue line. Writing about what I learnt is a way for me to be accountable as well and I am hopeful that smarter and more experienced folks will keep pulling me in the right direction, create a healthy conversations as well as introduce me to their favourite resources on similar topics
Dec 2025
I spent major time in this month working on my static site generator hanamark. I am lowkey proud of what it has turned into. my main goal was to build a static site generator for my blog https://www.thisisvoid.in/ to ease up my writings. It got picked up by few folks so I wanted to rewrite some parts to suit everyone (features are still the same: only what I wanted for my own blog) and make it easy for them to onboard if they want to build their own website. now its in beta and few folks have deployed their website with this engine. ping me if you want to be part of the beta and try it out. will release a proper version very soon. This project was super fun. I have been writing python for past few months and I have never felt this miserable in my entire life. such a pathetic language to write. I am hell bent on not to write python with my hand or look into the syntax more than a hour. so I am doing all my python related works purely via LLMs. I wanted a AI detox and this was a perfect usecase for me. I didn’t know writing every single line of code by myself in golang will give me so much of happiness. I use golang for webdev as well and finally I got to use go for an actual usecase which it is built for, ie to build cli apps. extracting binaries for each operating system for this engine was not very difficult, all credits to golang. since people use this tool in their system I did run security checks,lints, hardened things as much as possible. I also dived deep into executables. learnt a lot about CGO (It lets Go code call C code and C code call Go code within the same program),linkers,glue code,cross compiling binary and how to test it. solved some unique testing challenges for this engine which I will cover separately in a separate blog. also this is the first time I am doing a proper executable release. so my first idea was to write shell scripts to build the executables for different platforms, release it on github or whatever source control,do the routine release things like changelogs,release notes etc etc. this would have taken forever for me to implement and test. luckily I got to know about this tool called goreleaser (https://goreleaser.com/). Tools like these makes me fall in love with opensource. wrote a yaml file,added source control’s token ran a bunch of command through my makefile and boom all the executables are released properly. lesson learnt: before fiddling with bash script it is very important to go check if there are tools available on the internet I am not writing rocket science. There has to be tools for every problem I am trying to solve out there.
https://simonwillison.net/2022/Nov/26/productivity/. Documentation driven development is more common but learnt about issue driven development. It’s a way of working where you treat it like every project is going to be maintained by someone else. so on later half of building hanamark I kept adding every single thing as part of issue, how to solve as part of the issue which kept me super focused on what I want for my v1 release. A major challenge in building developer tools is the documentation. documentation cant drift away from the development. I also learnt about how test cases and guardrails can be written for documentations as part of committing the code. Just like how you write test and validate tests for the code you write, I learnt that you can also write documentation and test if the documentation is present before committing the code. This is still work in progress for hanamark but opened up my mind and solved a lot of headaches.
https://www.anthropic.com/engineering/building-effective-agents I saw many people sharing this blog around on building effective agents. went through the blog to understand what was the fuss about. all funny gibberish terms (like workflows,agents blah blah) but if we look at it with basic first principles it was nothing but yet another basic software engineering problems which we face everyday where here we have to deal with a non deterministic remote API. wearing a software engineer’s hat and observing the changes in ai is helping me a lot. I don’t have to remember all of these buzz words and all I focus on is to uncover the underlying engineering (that has been here for years) behind it.
I am very very impressed with how claude is building claude code. They are truly the company which sticks to the term “velocity is everything” I really like this article by sid who is engineer 2 at claude code. https://sidb.io/posts/velocity-is-everything
after reading the “velocity is everything” article I was very curious what exactly happens inside claude code team. luckily found this article https://newsletter.pragmaticengineer.com/p/how-claude-code-is-built its mind boggling how quickly they make and break things. more importantly this gave me a clear picture on where typescript stands now. I am not from the react ecosystem and I write golang so I was never interested in learning typescript which in itself it written in golang( I know I am stupid and egoistic). but reading this article made one thing clear:
popular languages will keep getting popular and llms understanding a language is a very important factor that needs to be considered for choosing a tech stack if velocity is your goal.
papers:
I went a bunch of paper and here are few interesting ones:
https://arxiv.org/pdf/2511.09030 this is an example of how not to trust a paper blindly. papers needs to be analyzed critically. this paper talks about solving tower of hanoi problem using a bunch of subagents aka micro solving a problem and stitching together. which might sound true for a markovian tasks but they didn’t talk about how to solve in non-markovian task which needs memory for more than the last state.
https://arxiv.org/pdf/2510.14232 this is a very interesting paper. I was always curious on how do these llms win tough programming contests like IOI when it struggles to write a bunch of loops for me. this paper uses gpt oss version and with help of brute compute and a bunch of smart technique to filter and find the right answer for those questions to win gold in IOI. yet another day we have more and enough proof that things will improve as long as we slap compute on it. the answer filtration part in this paper is a interesting idea
https://arxiv.org/pdf/2511.03506 there are way too many memory benchmarks like longMemEvals but still memory is a huge black box. its is very difficult to point out where things starts to hallucinate and this paper tries to bring in a new memory bench called HaluMem to evaluate and isolate hallucination
books I read this month:
- toilet seat by latha
- Interpreter of Maladies by Jhumpa Lahiri
- animal farm by george orwell
Jan 2026
coincidentally the theme for month has been memory. did a lot of things in pieces but somehow all of it led me to memory. I decided to focus properly on rust again. The last time I wrote proper rust was in late 2024. I had to pick up rust within couple of days and implement a feature to which rust is the perfect use case. its so stupid that within 2 days I glanced through the language like how we mug up on day before engineering exam and vomit it in the exam. I was thinking the logic in c++ way and I would implement just the rust syntax which performed extremely poor. I rewrote the same in go and it was way faster than my rust implementation. lesson learnt: poorly written rust will be slower than well optimized code from another language. The thing about rust is rust works in a memory first approach so my whole thinking needs to change into rust way of writing code. so I started to understand the why behind language design choices this month.
Unlike go rust ecosystem is very welcoming. If someone asks me to recommend resources to learn go I would point them to tour of go and effective go. I also very well know that these two resources are not exhaustive and they miss lot of intricacies of go language which we need to discover like a treasure hunt. But rust ecosystem is very different. they handhold you to atleast try to explain their language feature because they do know understanding rust needs a slight shift in thinking. I found out their official official rust book and used it as a supplementary material to finish the rustling challenge. rustling challenge is a terminal based debugging challenge where you keep debugging on each topic with slow increasing difficulty and you learn the concepts from the rust book and fix the errors in the rustling challenge to keep unlocking newer challenges. This was cool. I did it for a hr or two everyday for first half of the jan. helped me a lot of get an overview.
over the past year I have been reading fiction every day. 5-10 page minimum, 30 pages maximum in a day and over a period of 2-3 weeks I would have completed the book. this gave me a new confidence that I can pick up any pillow and slowly get through it over few months. so simultaneously I started to read Computer Systems A Programmer’s Perspective. This is a fantastic book written by professors from Carnegie Mellon and it is also part of cmu’s coursework. infact it is one of the most famous courses in cmu. this book is about 1200 pages so I though I could read 10 pages a day and finish it by 3 months. I was able to finish 3 chapters in this book: Tour of Computer Systems(which gives an overview about different parts that comes under computer system),Representing and Manipulating Information (this is nothing but the EEE course every engineering student has to take in the first year which talks about boolean representation,complements,floating points, boolean algebra), Machine-Level Program Representation (heap,stack allocation,control,procedures etc). This book explains all of these concepts via c program. to be honest this book is getting very challenging to understand but with claude’s help as well as some lecture videos from cmu’s youtube channel where these two professors teach the same book I am barely getting through it.
Now back to rust. Once I completed the rustling challenge Just like go where the official materials to get started didn’t talk anything about web development but go is indeed a great language for web development and I use extensively to build web app. So I was very sure that we could do the same with rust. on searching I was able to find the famous zero to production in rust book. This book is extremely good. I am currently in chapter 4 (around 100ish page) and I am enjoying it. This is not a very beginner friendly book for rust as well as for building web applications in general. They don’t go in depth about the rust basics or the whys of web development basics like why observability,why middleware,why database,why application security etc. For me I want to learn rust toolings and practices for web development and this book is project based I am able to follow along. hopefully I finish this book in feb (no promises:))
This month didn’t go as per my plan. I want everything to happen mechanical thats a problem because life happens and it is impossible to follow a rigid path. I feel that I didn’t maximize the weekends this month and slacked off a lot. I need to fix my schedule and grind harder. this pace and intensity is really bad. I reread there is no speed limit again today and I somehow need to get back my momentum and focus.
This quote summarises my weekdays.There is almost 0 learning curve with AI, or rather, I have to learn about the existing system so that I can frame the questions in the right way to the AI to get the answers I need. Which still means I have to be a better developer with good CS skills to use the AI effectively. In the beginning of the article I mentioned about how the theme of this month was memory for me? because I spend second half of the month reading and implementing a lot about llms and agent memory (I know these are just stupid fluff terms). memory shoudn’t be a black box. it should be straightforward. everyone is trying to solve the same problem but there is no unified way to do things. I like the memory space. I am gonna drop something very rudimentary and simple it will annoy most of the AI bros soon!
I have a pile of backlog blogs to read but here are few blogs out of few 100s i read this month which I felt interesting:
https://rselbach.com/your-sub-is-now-my-weekend-project/ this is a very interesting take on how saas which solves singular small problem is dead. you can now prompt and build tools which you want. I feel building a product which works and which is purely written for you is easier than building a polished software that anyone can use.
https://josephmate.github.io/2026-01-20-ghost-in-the-wifi/ this blog rekindled my curiosity about not taking tech for granted and go as deep as possible to find the root cause which is enjoyable and you will learn a lot from it.
https://susam.net/writing-first-tooling-second.html this also reiterate the fact that building a product which works and which is purely written for you is easier than building a polished software that anyone can use. this is my first hand experience building hanamark. I built the first version of hanamark over a week and it was heavily customized for my use-case. it took 5 weeks for me to build a version which everyone can use:)
I wrote a blog this month which talks about AI and side projects https://www.thisisvoid.in/blogs/2026_01/ai_pessimism. I was frustrated and this blog was my tipping point. Now I am learning a new language and AI is not part of the code writing workflow.
https://openai.com/index/scaling-postgresql/ this is a lovely read. I was surprised how many people didn’t believe in this blog and they don’t see the power of postgres. This is a very very common architecture of single write many read replicas. I was also surprised how experienced engineers were commenting on it is impossible to have 1 write source of truth. bro they are not stupid to just have single point of failure, they do have hot standby. learnt about noisy neighbour problem. lovely read.
I don’t know how long its been here but I very very recently got to know about jsonL. https://jsonltools.com/what-is-jsonl this can solve lot of my problems. glad somehow I got to know about this. I will definitely use jsonL
despite there are many AI related articles, I perceive it as just yet another software engineering problem and llm as a black box API. so most of my reads atleast in jan was around architecting software around AI and ofcourse I contributed to clawdbot→moltbot→openclaw:) happy that I got in and exited clawdbot before they blew up.
Books I read this month:
I am still learning how to read tamil
yaanai doctor by jeyamohan https://amzn.in/d/6SeBMoS
The Poliquin Principles https://amzn.in/d/cJQZf7u
the shark and the dolphins https://amzn.in/d/ic3Mu1e
thanks for reading it. if you have any feedback please reach out to me. see you guys in next one.
Feb 2026
Feb hasn’t been very great for me. I had to take extremely complex life decision so it took a lot of toll on my mental health. I had lot of free time this month but I was too confused,was afraid of the consequences of that life decision so I didnt focus much on coding. just like jan I spend learning rust on whatever remaining ounce of motivation I had. gathered myself towards the later part of feb and started attempting to write a dev log.
I am struggling with productivity for a few months now and feb is the tipping point for me. With recreational programming, I never took steps to rectify productivity issues because I felt recreational programming has to be recreational and not forced. But it got so bad that I am starting to feel that if I have a rough structure/process then I can learn a lot more without fatigue or guilt. I have heard about Pomodoro style productivity for a while now and it never appealed to me because of the breaks in between coding sessions. I always had this pseudo productivity notion that long coding hours = better productivity so 25 min sessions won’t work for me and breaking in between sessions would affect my flow. So I never gave Pomodoro a try until today. I actually felt better today after trying it out. I used pomfocus’s with its default configuration. 25 min coding session, 5 min break and after every 4th cycle we can take a 15 min break. One small modification which I did is instead of hard stopping at 25 min, if I am in a good flow state I would keep coding but the timer is still 5 min for a cycle, 15 min after the 4th cycle. This gives me the best of both worlds.
rust is the first language I am learning post llm era and It has never been easier to learn a new language. paring up with claude code, it is easier for me to learn the best practices and help me fix my logic gaps. I have heard about speed reading a lot in multiple booktuber’s youtube channels. the basic idea is everybody has a natural reading speed per minute, that is the number of words you can comfortably read per minute. by comfortable I mean the natural pace in which you understand and absorb all the content you read. this can be trained and improved eventually with consistent practice. speed readers help you with that. when I look out for speed readers either they are expensive or they don’t support ebook speed reading. so I took it up as a challenge to build a small and cute tauri app which solves this problem for me. I want to load my favourite ebooks and the software should speed read for me so that I can eventually improve my speed. I am building it in rust for backend to put my rust learnings into action and vibecoding frontend in typescript.
damn bro I am mind blown how good claude code builds frontend. if there is no claude code I would have built a very simple frontend and fully focused more on my backend. now I still focus on writing the rust code but the frontend looks very polished. I am able to extract whatever frontend feature I want and mostly claude code is able to one shot it. If an frontend expert look at the generated code, I am very sure he would call it mid but its gold for me because if not claude code my frontend would have been plain html,css,js. so something better than nothing. I am securing things from backend so that its okay to do whatever crap in frontend and I don’t need to worry about anything other than ui working. Hope I finish it and I again get back to my reading spree.
March wont be the same. march I am gonna glue my hands on my keyboard,heads down and will keep building.
Interesting reads:
- https://sunilpai.dev/posts/on-guitars-and-javascript/ : sunil is one of my favourite person on the internet and this blog on guitars and javascript is a wholesome read on how language evolve.
- https://www.ck-7vn.dev/blog/Home : I am fortunate that I have a home,comfortable environment and still not coding and building upto my expectation. this blog was very motivating. this is about a prisoner who gets access to laptop in jail and his coding journey in jail. very motivating.
- https://hamy.xyz/blog/2026-01_high-level-rust: writing rust is very different from writing performant rust. there is a clear difference between both. at this point I can write rust but nowhere close to writing peak performant rust. this blog digs into this.
Books I read this month:
- zero to production in rust - https://www.zero2prod.com/
- if you see me dont say hi - https://amzn.in/d/0alL59bK
March 2026
Just like what I said in Feb, I went hands on keyboard rather than just going through materials. I started this month with building a rsvp ebook speed reader called vagaread. The ability to read and grasp more words per minute is a superpower and RSVP is one of the techniques to improve it. So I wanted to build a simple ebook reader for me to use using tauri and TypeScript. This served a dual purpose testing out my Rust skills in action using Tauri, as well as learning to properly vibecode frontend with TypeScript. Made a lot of mistakes while vibecoding the frontend, since I didn’t properly ground myself in frontend; when I tried to vibe-fix a bug it reintroduced newer bugs. This made me realize the importance of UI testing/automation tools like Playwright. Integrated Playwright and now it’s stable but still slowly fixing the rough edges whenever I notice them while using it. quick demo
I had some free time so I went ahead and looked into tools like openclaw. The idea is cool but the implementation is a bit sloppy. What if you build something so generic that you can integrate it with whatever you want at your own will? To me, a claw can be the same as a Claude coworker, an all-out CLI, or we should be able to model it into any kind of agent system that we want. This is a notoriously tough ask as there are so many factors to generalize to make this work. Plus every part of an agent stack (memory, gateways, agent loop, interface, channels, etc.) needs to be modularized so that it can be swapped with alternatives. This kind of harness is very important to improve individual components in an agent stack. Suppose we are able to evaluate that an agent does xyz upon swapping the gateway or memory or whatever component we can evaluate as +-xyz, this will be very important to validate improvements. The main reason why I built it is to keep testing newer techniques that come up every day which I can use to form an unbiased judgement. It takes way too much time to build this because a lot of pieces need to be written here but so far I am satisfied. I am writing this in a go+sqlite stack. My biggest takeaway here is don’t get disheartened by the fear mongering around agent building. They have their own challenges I had some trouble with sandboxing, wasm compiling, keeping the binary extremely small, not using podman or docker, thinking about session and memory management, agent observability, etc. but I am just treating it as yet another software engineering problem.
a desktop app similar to claude coworker but I didn’t write a single line of code to modify the core engine. just an electron wrapper and everything works!
Then I took a side quest in the middle of March. I am slowly starting to believe in “you truly learn only if you can write it out”. Every time I design something related to large quantities of data streams, I use Kafka whenever it’s needed. Things don’t magically get solved when we use Kafka. There are various intricacies starting from the configuration of brokers, clusters, partitioning, topics and a whole lot more configurations, as well as I use various data patterns which have existed for years but I somehow arrive at them purely via first-principles thinking. At times these terms get thrown at me. To address all of these I decided to code multiple miniature versions of patterns and whatever I know related to Kafka, find out the actual industry way of doing things and fill in the missing technical gaps. Since it’s a side quest I didn’t focus much on it in March but will take it up in April. I am going through this phenomenal book called kafka the definitive guide
Since none of the existing workflow orchestrator state machines like Netflix’s Conductor, Airflow, etc. have all the features I needed, I finally built a workflow orchestrator state machine which can independently execute task flows. Just like AWS you can write a workflow definition JSON (not complex ugly BPM suites) or configure your state machine tasks via UI. Temporal is the only existing solution which is very close to what I want but I want something much simpler than Temporal. I’m enjoying building it. Quickly built it in Python to learn about Python’s asyncio ecosystem but I will eventually move to my comfort language Go to implement tickers and schedulers.
The last couple of days I started exploring iximiuz labs. Loving it so far. There are way too many fundamental computer science concepts to learn and glad a lab like iximiuz exists.
Is it just me or does AI productivity feel like pseudo productivity despite metrics-wise we are able to achieve more with the help of AI? This is a mindset shift I am working on. At the same time I am understanding the boundaries I have set for myself regarding AI usage which you can read from this article that I wrote this month.
Slowly realizing the importance of note-taking. I use Obsidian for over two years now. A lot of times I’ve asked LLMs to expand my thoughts whenever I get stuck with grammar or blockers whenever I struggle to explain. LLMs would give me beautiful fill-ins which at that time made more sense than my broken thoughts so at times I would copy-paste those LLM explanations into notes. This month I got to revisit them they don’t make a lot of sense, but the notes which have broken language, are non-coherent but fully written by me make more sense. So I am taking proactive measures to stop this from happening and I am slowly trying to adopt this hybrid approach. I will write a blog about this after trying it out extensively.
I am taking an insanely huge risk (as usual) which I was joking to my mom about by referring to it as swing gambling! This risk makes me feel more anxious than usual. Usually when I feel anxious I shut things down, stop everything I do and get into survival mode but as an adult and avid risk taker I will be facing a lot more situations like these in the future and for a change I am trying to not stop the usual tasks that happen. My main goal for April is to put in the hard hours. As simple as that. I don’t remember the last time I’ve consistently clocked decent hours. I want that to change. I want to create a decent system around me so that I can clock in consistent hours of productivity.
Interesting reads:
- the log this 2013 article by LinkedIn is the fundamental article on looking at data as a stream and fundamentally as logs. This is a longer read (takes around 2-3 hrs) but understanding these fundamental principles is very important to grasp the internals of message queues and message brokers.
- speed at the cost of quality. This paper by Carnegie goes deeper into tech debt and how AI code generation productivity plateaus or goes back to the exact place where things used to be and identifies the real bottleneck in SDLC.
- detailed spec is nothing but code. This article takes real examples and goes deeper into why markdown spec-driven development is not a revolutionary idea and how things can misfire due to the non-determinism of LLMs.
- cold email works!
Books I read this month:
Going through a reading slump because usually I read before sleep and nowadays I doze off even before opening a book
- kafka: the definitive guide I am currently at chapter 6
From March, my biggest takeaway is I think I like this idea of a time-bound curiosity sprint over doing multiple things at the same time. I will start with a problem statement that I am facing, identify the tech and knowledge gaps that I need to fill, explore whatever I want to explore, flesh out code and write about whatever I learned for clarity, see if it sticks; if not then go ahead with the next problem. The time frame you give to a problem statement is debatable and depends from one person to another but this also helps me to think from first principles else I won’t be able to retain and interlink whatever I learn.