AI and LLMs: Useful, But More Code Isn’t Always the Solution The rise of AI and large language models (LLMs) has made writing code easier and more accessible than ever before. With a few prompts, developers can generate boilerplate, automate repetitive tasks, and even solve complex problems. This is a remarkable leap in productivity and creativity. However, it’s important to remember that code itself is not the solution—at least, not always.

What is Ollama? Ollama is a platform that makes it easy to run large language models (LLMs) like Llama, Gemma, Mistral, and many others on your local machine. It provides a simple interface for downloading, running, and interacting with these models directly from the terminal or via API, without relying on cloud services. This is especially useful for developers who want privacy, speed, and full control over their AI workflows.

Tooling Matters After 8 years as a software engineer, across startups and established companies, I’ve seen firsthand how much good tooling can impact productivity, onboarding, and code quality. Tooling is not just about convenience—it’s about enabling teams to move faster, reduce errors, and focus on solving real problems. Why Tooling is Critical Onboarding Speed: How quickly can a new engineer get a working environment and start contributing? The best teams make this nearly instant, with clear setup scripts, containerized environments, and automated checks.

What’s in your .gitignore? It’s become almost a convention to git ignore all the IDE specific files. Rationale being: it’s not really the part of the codebase people can have different preferences of what IDE to use these configuration files can be [[Bloated Git Objects]] Debunking These Although IDE configurations can indeed be bulky, we can cherry-pick the select few configurations—especially the ones pertaining to run and debug setups. Those are pretty light and don’t change frequently.

We must cultivate our garden. Volatire (Candide) This is the closing sentence in Volatire’s Satire Candide. Of course the metaphorical sense is, regardless of what’s happening in the world we should continue to work on ourselves and shouldn’t worry too much in things which are either inconsequential or are out of our controls. This doesn’t mean we become ignorant or indifferent towards those but rather put oneself and one’s concerns first.

Is Go Fast? Go is faster than interpreted languages like python in terms of sheer execution since it’s compiled to native executable format. Go is slower than other compiled languages like C,Rust in terms of execution. This is primarily because although compiled go runs with a ‘runtime’ which does some housekeeping (scheduling and multiplexing goroutines, managing/freeing memory (GC) etc). This overhead is much smaller than a virtual machine required for languages like java but is an overhead nonetheless.

Logs Logs (in a very degenerative sense) are a series of events/statements that act like the breadcrumb for the things that happened. Degenerative as I am referring mostly as application or software logs. (More pure meaning would be let’s say database logs which are used for replication process or a series of events for active state machine replication). I want to talk about the logs (application logs, system logs). For interested reader, I highly recommend I heart logs which talks about the power of logs in a distributed systems - how a series of immutable logs help us chronologically capture a series of events and computing/coming to consensus/committing transaction etc on top of it.

Go’s approach to Object Go is a fairly simplistic language and doesn’t come with inbuilt classes and other features that most object oriented programming languages have. It gives you building blocks in the form of structs and it’s upto programmer to design the abstraction around it. There is no inheritence - Go takes a very strong stance on composition over inheritence camp. (even other languages have practitioners who preach composition over inheritence but it’s not strictly enforced).

I encountered this quote while reading Martin Klepmann’s Designing Data-Intensive Application which got me thinking: A complex system that works is invariably found to have evolved from a simple system that works. The inverse proposition also appears to be true: A complex system designed from scratch > never works and cannot be made to work. John Gall, Systemantics (1975) This is a famous “law” in software engineering. (although the original context in which the author said this is in regards to general systems (mechanical systems like Titanic ship or human systems like an organization; come to think of it, even software systems are just an extension of such systems).

Time is not just an abstraction Of course time as we know in a day to day sense is an abstract thing. It’s a concept we defined to measure something. (like we defined length to measure how long something is or weight to define how heavy something is). But behind that abstraction is a physical reality. Events are a manifestation of that reality which really give us a sense of time.