Adhesh Athrey

On the Art of Engineering

Adhesh Athrey — Mon, 11 May 2026 00:00:00 +0000

If you ever ask an engineer what engineering entails, you will usually get some noun. Compilers, circuits, engines, bridges. The fancy names and nouns differ, but the verbs repeat. Every engineering domain is a discipline of constrained modelling and creation, imagining something that does not exist, representing it as a human understandable model, and then persuading reality to accept that representation at an acceptable cost, all for the goal of making our lives easier or better. Maybe modernism too eh.

The art is not in the tools, but rather in the judgments the tools cannot make for you, and a man's imperfect vision of a perfect solution.

Constraints are the material

Science questions you on the fact. Engineering tells what is possible with sacrifices.

The budget may be mass, watts, milliseconds, dollars, memory footprint or the number of people who can understand the system at any point in time (big ask if it is 3 in the morning). A vision of a solution that disregards constraints is not ambitious, it is unfinished and crude. The first act of engineering is therefore not construction but questioning yourself on what is it that you need AND accounting. Yes accounting, what are we spending, and on what?

A bridge spends steel to buy span. A database spends memory to buy latency. A compiler spends compile time to buy runtime. Optimization is never free. It is the deliberate choice of which scarcity to tolerate. And the most annoying of it all, is the situation when the constraints are in a conflict, how does a good Engineer choose between multiple constraints that are equally important?

Models are the workbench

Every field reasons through models. Beam theory, type systems, queueing models, finite elements, statics. A model is a compression of reality that keeps the part you need and throws the rest away. Nothing but a proposition to reality, to bargain your needs.

The engineer's question is not "is this model true?" but "is this model true enough for the decision at hand?" A type system that ignores aliasing is fine until two references mutate the same object. A benchmark that ignores the cache is fine until the working set grows madly.

So the art here is knowing, which part of your model is important and load bearing, and which part is eye-candy.

Interfaces are where ignorance is hidden

No one holds a complex system in their head. We build them out of parts that other people designed, tested, and documented. Abstractions are the contracts that make this possible.

A good interface hides a decision and makes a fair promise. A bad interface hides a bug and whacks you in the face on a fine good day. The art is choosing the seams. Where to fold or cut the system so that each side can be understood, visualized, tested, and replaced without messing up the whole.

Every abstraction leaks. Well it is meant to?? Well, I don't know, but the art is not avoiding leaks, but to let what you want the other side to see and pass through the joints. It is putting them where failure is observable and cheap and importantly, stupid easy to understand.

Margins are how we live with uncertainty, the compromises we are okay with

Every field has some vocabulary or fancy nomenclature for the same idea. DO NOT DESIGN TO THE EDGE.

Civil engineers call it a safety factor. Mechanical engineers call it tolerance or something. SREs call em an error budget. Some or the other fancy term, they all mean the same.

Engineering is the art of modelling materials we do not wholly understand, into shapes we cannot precisely analyse so as to withstand forces we cannot properly assess, in such a way that the public has no reason to suspect the extent of our ignorance.

~ A. R. Dykes

Margins are not timidity or fear of failure. They are the price of uncertainty that you can't calculate, just paid in advance. And the art is knowing how much to buy.

Judgment is the personality part

Give two engineers the same constraints, the same everything, and they will still produce different things. Why?

The difference is judgment, knowing what is worth solving, when good enough is realllly good enough, when to break an abstraction, when to stop optimizing, and when a warning sign is worth a week of investigation (Or maybe AI tokens nowadays). Intuition is abstract, but good intuition remains falsifiable. The best engineers I have seen hold strong opinions loosely and test them cheaply or well try to ig.

Drawings, specifications, units, schemas, tests, commit messages, incident reviews. All these exists because the artifact must survive contact with other people AND to appease others.

Ambiguity is a defect. An unmaintainable system is an unfinished one (thanks to unplanned AI sloppery, this is the hardest). The system includes the people who operate it, who debug it at questionable times, and the people who inherit it after you leave. Engineering is not done when the thing works. It is done when the thing can keep working without you. Well technically it is never done, because you pawned it off on someone else, but you get it.

The common core

Strip away the fancy nomenclatures and the same stance remains. Treat constraints as the medium, models as instruments, interfaces as promises, feedback as the method, margins as the price of uncertainty, and judgment as the part that cannot be outsourced.

That is why engineering is an art. Not because the finished result is aesthetic or perfect, but because it requires choosing well when the rules do not choose for you but instead fight you back.

Journey

Adhesh Athrey — Tue, 31 Dec 2024 00:00:00 +0000

Let's start off by defining what this entails.

This page is meant to be a space for me to track my time as I grow.
This page is by no means a perfected piece of content, but rather an attempt to record my time.
Anything from what I am building, or what I am reading all the way to what I ate belongs here (I eat a lot :x ).

TLDR of 2024.

I have no written records for much of 2024, but as I write this on the last day of 2024, I have come to a conclusion, 2024 was riddled with everything.

Ups and downs, just like any other human on this rock, I too had them, from the crazy LFGs when a piece of code I wrote worked at 12 in the night, to disappointment of opening the results tab on PESU app at 12 in the night and more.

But regardless I have learnt a lot, thanks to the most important 主義 that I learnt back in 2023.

The places or the oppurtunities I have had feels surreal looking back at it, so surreal that it's as though it was all by fluke, the dice rolled the right number every time.

I guess this is what Imposter Syndrome is. The feeling of believeing you dont belong to where you stand, is filled to the brim. But no reason to give up, be in a state of bewilderment or be hung up on it. Even if it is true, not a lot of people get a chance to stand where I am, so the only right path is to prove otherwise.

Well before we run to 2025, thanks to myself (Yes, ofcourse me too), my family and friends, because none of this would've been true without them.

But what is 主義 you ask?

Hmm well the simple translation of it from Japanese to English is Principle, and my principle is

If I dont challenge myself no one will.

Yes well if I dont challenge myself or even bet on myself no one is going to, there's no choice but to get up and grind, to race the me from yesterday.

At the bottomline, I am more than glad if i can win over the yesterday's me today in any way possible.

Funny enough this was my New Year's Resolution going into 2024. As we approach the end of 2024, I want to start 2025 with a new addition to my 主義.

What is it going to be?

Retrace and Repair.

Record everything that goes wrong, work upon it and fix it.

Leave nothing under the gone wrong column.

Mistakes are proofs that I can optimise more, not a reason for getting hung up on something.

With that lets start 2025!!

Why is it empty??

Duhh, not even 24 hours has passed by -_-

Adhesh Athrey

Adhesh Athrey — Sun, 29 Dec 2024 00:00:00 +0000

Adhesh Athrey

Hello world! I'm Adhesh Athrey, a final-year undergraduate computer science student at PESU. I like building anything that looks cool, so that's more or less how I pick what to work on.

I interned at LinkedIn as a summer intern in the Core Infra org. I was previously a research intern at PES Innovation Lab, and I'm currently a member of the lab since 2025.

Lately I've been exploring FPGAs. I'm also working on sculite, a fork of SQLite that uses the GPU to accelerate queries.

Writing

There is a high chance that some work here is incomplete.
Infact this site is quite incomplete.

Why? Well i would never put anything out if I wanted perfection or completion, sounded like a reason for procrastination, so here we are, we move the right direction step by step.

This site serves as a testament to my journey of progress, showcasing my interests and various projects and honestly anything.

Projects

Adhesh Athrey — Sat, 04 May 2024 00:00:00 +0000

Projects

All of my projects are on Github

Anna

A lightning-fast static site generator written in Go.

This project is maintained by Adhesh Athrey, Nathan Paul, Anirudh Sudhir, and Aditya Hegde

Link to the blog

Hive

A Bitcask clone in GoLang

I will be writing a dedicated blog on this soon

Eventloop

A Full Stack event management platform project.

FOSS project maintained by Adhesh Athrey, Anirudh Sudhir, and Aditya Hegde over at HSP

Building anna

Adhesh Athrey — Thu, 04 Apr 2024 00:00:00 +0000

This post is WIP(work-in-progress) and has been authored by Adhesh, Aditya, Nathan and Anirudh.

There are several amazing static site generators(SSG) out there, like Hugo and 11ty. Building your own SSG is an amazing learning experience. It also motivates one to maintain and improve their personal site.

Building personal blogs from the ground up can be a tedious process. Some of us have had our hands deep in vanilla HTML and CSS, which isn't fun to maintain. We all want to get to the point and share our thoughts on the web. But, there is a small hurdle that stops us from doing so.

Maintaining your personal site is like working with your own Neovim configuration. Every issue fixed would lead to an entirely unrelated bug. There is a lot of time spent fixing things rather than getting productive work done.

A static site generator is an immensely useful application

Lighthouse scores of the anna-docs page

It can simplify the whole process: allowing you to spend time and energy on quality content. Keep reading to find out how we designed anna.

Introduction

ACM-PESU ECC conducts the ACM Industrial Experience Program (AIEP), an annual program that spans six weeks.

It involves students working as a team to develop an industrial-level project. AIEP intends to give students hands-on experience with real-world projects. It is an excellent opportunity to interact with like-minded individuals.

Our AIEP team consisted of Adhesh, Aditya, Nathan, and Anirudh.

Our mentors (cool senior names!) gave us some great ideas for our team of four freshers. We were puzzled whether to build a distributed Postgres clone or a load balancer.

Deep discussions over a week got us to the topic of making blog sites and how tiring it is to work with, which only gets worse as you write more and more content for your internethome.

This and inspirations from Saaru and Sapling pushed us to tackle this problem with our own SSG.

    ___
   /   |  ____  ____  ____ _
  / /| | / __ \/ __ \/ __ `/
 / ___ |/ / / / / / / /_/ /
/_/  |_/_/ /_/_/ /_/\__,_/

A static site generator in Go

The small but big decision!

Anna is written in Go. We considered writing it in Rust, but it came with a steep learning curve. Go is a powerful language and has excellent concurrency support, which suited our requirements to build a performant application.

What's in a name?

Probably the first thing that the four of us came across when joining ACM and HSP was the famous Saaru repository, one of the projects that inspired our ssg. Saaru is a thin lentil soup, usually served with rice and is a Kannada word.

In Kannada, rice is referred to as 'anna' (ಅನ್ನ) pronounced /ɐnːɐ/

This was just a playful stunt that we engaged in. We planned on beating Saaru at site render times, optimizing at runtime.

Genesis

We began the project in a unique manner, with each of us creating our own prototype of the SSG. This was done to familiarize everyone with the Go toolchain.

The first version of the SSG did just three things. It rendered markdown (stored in files in a content folder in the project directory) to HTML. This HTML was injected into a layout.html file and served over a local web server. Later, we implemented a front matter YAML parser to retrieve page metadata

What made us develop this to a great extent?

Beginner-friendly: An easy setup wizard, ready to use layouts, and themes. We wanted the process of typing out a blog and putting it up on your site to be short and simple.
Speed: Render sites in a flash (hugo – written in Go, is remarkably fast)
Maintainable: This ssg would be used by us, hence it should be easy to fix bugs and add new features
Learning curve: None of us had really shipped a production-ready application. Since AIEP is all about making industry-ready projects, we chose to use Go: so we could spend more writing code and not worrying about our toolchain or escaping dependency hell.
Owning a piece of the internet: Aditya and Anirudh registered their own domain names. Now their anna sites live on hegde.live and sudhir.live.

Benchmarks! Can anna lift??

In simple terms, to beat Saaru's render time (P.S. we did beat the initial version!). Something you probably never notice while deploying, but it is what pushed us to spend hours on this.

Adhesh was pretty excited to pick up Go and implement profiling, shaving milliseconds off build times, when he implemented parallel rendering using goroutines.

We cook! 🍳

Here are some images that demonstrate build times, profiling et-al when having thousands of markdown files or in this case just copy-pasting a single markdown file en-mass!

Hyperfine benchmarks comparing the render times of anna, Saaru and 11ty

2 weeks into the project, we had a PR bringing parallel rendering and profiling to the table

Profiling

For those who love to get technical, anna has a profiling flag and a debug endpoint(available during live reload). This flag prints the profile data of the rendering process to stdout. The debug endpoint displays the data for site render in the live reload mode, which can be visualised by navigating to the specified pprof endpoint

Live Reload

anna can be run in a serve mode which serves the rendered site over localhost. It also includes live reload, which performs a re-render of the site for every change made to the markdown content. It also injects a script which auto-refreshes the browser on a site re-render.

Initial version

The initial version consisted of a multi-goroutine system.

A new goroutine would be spawned to walk the required content directories. If the current path being walked was a file, the path would be passed to another function along with its current modification time.
The previous mod time of the file would then be retrieved from a map holding the mod times of all the files:

If the given file was freshly created, its modification time would be added to the map.
If there was no change in the mod time, no changes would be made.
If there was a change between the current and previous mod times, a re-render of the site would be performed.

The site re-render function checks if a child process is running:

For the first render, when a process has not been created, a new process is created that runs anna ("go run main.go --serve")
For successive renders, the existing process is killed and a new process is spawned once again that runs the application.

This prototype was not very efficient as it created and killed processes for every change. It had multiple goroutines attempting to walk the directories at the same time, which also required multiple mutual exclusion locks to prevent data races. This was designed as a standalone component and integrating this proved to be challenging.

Improvements

The updated version of live reload utilised two goroutines.

The main goroutine used the initial file walker, with one important change: it sequentially traversed the directory without spawning new goroutines. For any modification to a file in the current traversal, a vanilla render of the entire site would be performed. The goroutine would then sleep for a specified duration (currently 1 second) before attempting the next directory traversal.

The secondary goroutine ran a local web server that served the rendered/ directory.

This eliminated all locks and avoided the creation and destruction of child processes.

Browser reload (WIP)

When anna performs a re-render of the site, the browser is automatically refreshed to reflect the latest changes. This involved utilising server-sent events(SSE). A script was injected into all pages that polled a particular port. On receiving an event sent by anna during the re-render, the script would reload the page.

(The following content is WIP)

A big rewrite (when we went for a TDD approach)

Starting off this project, we kept adding functionality without optimization. We did not have a proper structure; PRs would keep breaking features and overwriting functions written by team-mates.

We dived into the codebase to rebuild the application following a TDD-approach.

A new proposed rendering system

main.go

Firstly, we refactored main.go to only handle flags. The rest of the program logic was moved to other packages. A benchmark for main.go was also written to time the entire application.

pkg/ modules

Modules previously part of cmd/anna/utils.go and cmd/anna/main.go were to be split between pkg/parsers/, pkg/engine/ and pkg/helper

pkg
├─── helpers
│   ├─── helpers.go
│   └─── helper_test.go
├─── engine
│   ├─── anna_engine.go
│   ├─── anna_engine_test.go
│   ├─── engine.go
│   ├─── engine_test.go
│   ├─── user_engine.go
│   ├─── user_engine_test.go
│   └─── engine_integration_test.go
└─── parsers
    ├─── parser.go
    ├─── parser_test.go
    └─── parser_integration_test.go

Wrote unit and integration tests for the parser and engine package

Splitting the render pipeline

Currently, there are three kinds of files that have to be rendered. One set includes user-defined files such as index.md, docs.md and various posts. These are specific to a user.

The second set of files that are rendered include tags.html and posts.html, which are present on every site rendered by anna.

The third set of files included the tag-sub pages. For every tag, there would be a corresponding sub-page containing all of the posts with the same tag.

Split the rendering system to make parallelisation easier by switching to a three method system.

Render "user defined" pages which include all markdown files and posts (This method has been parallelised, Render tags and tag-sub pages separately, which could be parallelised in the future

Useful features

To search or not to search? 🤔

That is the question > Is our static site becoming dynamic and at what cost?

We were wondering if we’d need a search function on our site since Google and any other web-crawler index our site anyway. If we needed to implement it, we had a constraint: do not use an API. It had to be static and local to be user-friendly to work with. We implemented a JSON index generator that uses "Deep Data Merge" to index posts on our site.

This index is generated during the site render and functions without any lag or noticeable delay when searching across posts. We mean to re-write it using WASM if necessary.

Here's a gif demonstrating search

JS integration as plugins

We added a field to the frontmatter which lets you pick and add certain JS based snippets to your site. This way, you get to add highlight.js support, analytics scripts and donation page widgets; that you can source from the static/scripts folder and toggle as needed per-markdown page.

Wizard

An important ease-of-use feature was a GUI; a web-based wizard that let's a new user setup anna along with a couple of easter eggs along the way 🍚

The wizard lets a user pick a theme, enter your name, pick navbar elements, and validates fields using regex checks so you don’t need to worry about relative paths in baseURLs, canonical links, and sitemaps. After successfully completing the setup, the wizard launches a live preview of your site in a new tab.

Raw HTML

What if you'd want to add a contact form to your site? or embed YouTube videos or iframes of your choosing?

Anna let's us do that! Although, the point of a static site generator is to quickly get to writing and focusing on the content. You can still embed js elements and iframe as needed to showcase any interesting YouTube videos or to just rickroll people!

changelog: showcasing important additions, which are yet to be added to this blog

Deep Data Merge
Style feed.xml
Site bootstrapping

Next steps

Wizard theme repo
Performance: Explore memory-mapping, etc

Feedback? / Learnings

We have a lot of things in store and bugs to squash!

Feel free to ask any questions / send feature requests you'd like to see?

This blog post misses out of many not-so well documented features and learnings that we got during midnight calls and the patches we kept sending each other fixing trivial but interesting issues. Have a look at our GitHub, for more

Today, we use anna on our personal sites: hegde.live // sudhir.live // polarhive.net

01100001 01101110 01101110 01100001

Adhesh Athrey

On the Art of Engineering

Constraints are the material

Models are the workbench

Interfaces are where ignorance is hidden

Margins are how we live with uncertainty, the compromises we are okay with

Judgment is the personality part

Engineering is a social act

The common core

Journey

Let's start off by defining what this entails.

TLDR of 2024.

But what is 主義 you ask?

What is it going to be?

With that lets start 2025!!

Adhesh Athrey

Adhesh Athrey

Writing

Projects

Projects

Anna

Hive

Eventloop

Building anna

Introduction

The small but big decision!

What's in a name?

Genesis

What made us develop this to a great extent?

Benchmarks! Can anna lift??

We cook! 🍳

Profiling

Live Reload

Initial version

Improvements

Browser reload (WIP)

A big rewrite (when we went for a TDD approach)

A new proposed rendering system

main.go

pkg/ modules

Splitting the render pipeline

Useful features

Tags

To search or not to search? 🤔

JS integration as plugins

Wizard

Raw HTML

changelog: showcasing important additions, which are yet to be added to this blog

Next steps

Feedback? / Learnings