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