September is a communication assistant for people living with neurodegenerative conditions like ALS (Amyotrophic Lateral Sclerosis, also known as Lou Gehrig's disease), MND (Motor Neuron Disease), or other speech & motor difficulties.

Background

I was diagnosed with ALS in 2019, and have gradually lost the ability to speak and type. I relied on a combination of dictation, one-handed typing, and a mouse. However, as my speech became more slurred and my arms weakened, I continued working, coding, and using my computer. I adapted to various combinations of one-handed typing, dictation, and on-screen keyboard. I currently use an on-screen keyboard and a head-mounted mouse (a device that tracks head movement to control a computer cursor).

Tools I've Used

GitHub Copilot: With the launch of GitHub Copilot in 2021 (an AI assistant that helps write code and text), I was able to continue coding and writing everything in VSCode (a popular text editor used by programmers). The smart text suggestions that learn from your writing were a game-changer. I was able to write e-mails, blog posts, long messages, work documents, and all within VSCode. I would copy-paste text to-and-from different platforms like Slack, Google Docs, GMail, etc. While cumbersome, it was an effective way to type faster. I hoped that the Apple Mac's on-screen keyboard would somehow provide a similar experience.

Voice Banking Challenges: As my speech slurred, I tried several voice banking apps. All of them required long recordings in quiet environments. It was hard to get a good recording with a 3-year-old in the house during lockdown.

ElevenLabs Voice Cloning: In 2023, ElevenLabs launched their voice cloning technology. This was the first easy way to clone my voice without jumping through hoops. But by then, my speech was already slurred. So I dug through my old hard drives and videos to find old recordings of me speaking. I used these recordings to create a long enough recording to clone my voice. It wasn't perfect, but it was better than everything else.

With the rapid evolution of AI technologies in coding, writing, and speech, I set out to build an application that combines all these different advancements to make communication easier.

Daily Communication Needs

All these smart AI tools changed the way I wrote code and worked remotely, but daily communication remained challenging.

The most common thing I do is talking to people around me. It could be for simple things like asking for water, or telling what I'd like to eat for lunch. Sometimes, it could be video calls with my family and friends. Or just telling my wife about how my day went.

Most often I would compose messages in notes or WhatsApp and have people read them while talking to me. Even with voice cloning services, I still need to type out full sentences every time. These tools don't offer auto-complete or suggestions based on previous conversations. Nor could I use my cloned voice with FaceTime, Zoom, or other video calling apps.

While using head-mouse or eye-tracking devices, clicks are precious. Especially when the vocabulary and sentences used every day are the same, I should not have to type out full phrases and sentences every time.

Beyond daily conversations, I also needed to share longer thoughts and stories. Whether explaining technical concepts to my team, recounting childhood memories to my son, or documenting ideas that might help others facing similar challenges, I found myself writing longer pieces of text. These weren't just messages—they were narratives that I wanted to share with my voice, not just text on a screen.

The Product: September

These experiences inspired me to build September—a communication tool that combines the AI technologies I've been using to make daily communication easier and more natural.

Smart Text Editor

I wanted September to learn from how I actually talk, not just provide generic suggestions. The smart text editor uses my message history to provide instant auto-complete suggestions, just like GitHub Copilot did for my coding. It also uses AI (Gemini, Claude, etc.) to provide contextually relevant sentences, phrases, and words. The more I use it, the better it gets at understanding my writing style and providing more accurate suggestions.

I also wanted to be able to share my thoughts and stories with proper context. In every conversation, I can provide additional context in the form of notes, documents, images, videos, or links. September indexes all this information to help me "speak my mind" in conversations, whether I'm explaining technical concepts to my team or sharing childhood memories with my son.

Text-to-Speech

September integrates with multiple text-to-speech providers, giving me a choice of voices that suit my language, style, and personality.

Voice Cloning

The ElevenLabs voice cloning technology was a breakthrough for me. September makes it easy to record my own voice or use samples from existing audio or video files. I can also search and choose from a wide range of community and professional voices. This gives me the flexibility to use my own voice when I have good recordings, or find alternatives that work well for me.

Transcription

When others are talking to me, September needs to understand what they're saying quickly. September uses AI to transcribe audio in real-time and provides contextually relevant suggestions based on the conversation. This helps me respond more naturally and keep up with the flow of conversation.

Multiple Keyboard Layouts

Since I use a head-mounted mouse and need to minimize clicks, September provides multiple on-screen keyboard layouts—QWERTY, Circular, Emojis, and more. I can choose the layout that works best for my current input method, whether that's mouse, or eye-tracking devices.

Accessible Design

September is designed to work for people like me who have speech and motor difficulties. It works on any modern web browser across desktop and mobile devices, and it's compatible with various input methods. No complex setup or downloads are required—I can just open it in my browser and start communicating.]]> september als https://raviatluri.in/articles/handling-go-errors https://raviatluri.in/articles/handling-go-errors Tue, 27 May 2025 00:00:00 GMT If you've written Go, you know that error handling is a core part of the language. Go's approach is pretty simple: errors are just values, and you're expected to check and handle them explicitly.

The simplest way to create and use errors in Go is with errors.New:

var ErrUserNotFound = errors.New("user not found")
func GetUser(id int) (User, error) {
    if id == 0 {
        return User{}, ErrUserNotFound
    }
    // ...
}

Checking for specific errors is straightforward with errors.Is:

if errors.Is(err, ErrUserNotFound) {
    // handle user not found
}

This works well for most applications. But, sometimes you'll want to add & propagate more context with errors, while still preserving the original error value.

Go 1.13 introduced error wrapping with %w in fmt.Errorf. This lets you add context while preserving the original error:

func GetUser(id int) (User, error) {
    if id == 0 {
        return User{}, fmt.Errorf("user with id %d not found: %w", id, ErrUserNotFound)
    }
    // ...
}

You can still use errors.Is to check for the original error, but you lose access to the extra metadata (like the user ID) as the error propagates.

To carry metadata with your errors, you can define a custom error type:

type UserNotFoundError struct {
    ID int
}
func (e UserNotFoundError) Error() string {
    return fmt.Sprintf("user with id %d not found", e.ID)
}
func GetUser(id int) (User, error) {
    if id == 0 {
        return User{}, &UserNotFoundError{ID: id}
    }
    // ...
}

This lets you attach structured data to your errors, but it comes with a cost: you'll end up creating lots of custom error types, which can get verbose and hard to maintain—especially if you want to add structured logging, metrics, or handle errors in middleware and HTTP handlers.

What if you could attach arbitrary key-value pairs to errors, and access them anywhere the error is handled?

xtools/errors (docs) makes this possible by allowing you to attach arbitrary key-value pairs to errors:

package errors_test
import (
	"fmt"
	"github.com/gojekfarm/xtools/errors"
)
func ExampleWrap() {
	// Create a generic error
	err := errors.New("record not found")
	// Wrap the error with key-value pairs
	wrapped := errors.Wrap(
		err,
		"table", "users",
		"id", "123",
	)
	// Add more tags as the error propagates
	wrapped = errors.Wrap(
		wrapped,
		"experiment_id", "456",
	)
	// errors.Is will check for not found error
	fmt.Println(errors.Is(wrapped, err))
	// Use errors.As to read attached tags.
	var errTags errors.ErrorTags
	errors.As(wrapped, &errTags)
	// Use the tags to construct detailed error messages,
	// log additional context, or return structured errors.
	fmt.Println(errTags.All())
}

With this approach, you can:

• Attach context as the error propagates (e.g., table, user ID, experiment ID)
• Check for specific error types with errors.Is
• Extract all attached metadata for logging, metrics, or constructing API responses

Your consumer probably looks something like this:

consumer, err := kafka.NewConsumer(&kafka.ConfigMap{/.../})
err = consumer.SubscribeTopics([]string{/.../}, nil)
// some way to cancel and stop the consumer
run := true
for run {
    msg, err := consumer.ReadMessage(time.Second)
    if !err.(kafka.Error).IsTimeout() {
        // handle error from consumer/broker
    }
    // process message
    // manually commit the offset, if needed
}
consumer.Close()

There's a lot that goes into the processing loop:

• read messages
• handle Kafka and application errors
• retry transient errors
• metrics, logging, tracing, etc.
• secondary dead letter queues
• and, of course, wiring all this together

A surprising amount of code isn't really about your application logic. If you're building something that consumes more than one kind of message, this quickly gets verbose. Most of the code is just scaffolding.

What if we could make using Kafka, in Go, feel more like writing a simple HTTP service?

HTTP-like Kafka

xkafka (GitHub) is a Go library that provides HTTP-like abstractions for Kafka. It tries to make working with Kafka feel a bit more like writing a simple HTTP service, and a lot less boilerplate and plumbing.

Here are the core abstractions:

• Message: Like an HTTP request. It has the topic, partition, offset, key, value, headers, and so on. It also allows callbacks to track message processing.
• Handler: Like an HTTP handler. It's where your business logic lives.
• Middleware: Just like HTTP middleware, but for Kafka. You can add logging, metrics, retries, etc., without cluttering your core logic.

Publishing Messages

First, let's get simple things out of the way. Here's what publishing a message looks like with xkafka:

producer, err := xkafka.NewProducer(
    "producer-id",
    xkafka.Brokers{"localhost:9092"},
    xkafka.ConfigMap{
        "socket.keepalive.enable": true,
    },
)
producer.Use(/ add middlewares /)
msg := &xkafka.Message{
    Topic: "test",
    Key:   []byte("key"),
    Value: []byte("value"),
}
err = producer.Publish(ctx, msg)

That's it. You can also publish asynchronously if you want higher throughput or want to handle delivery events asynchronously:

producer, err := xkafka.NewProducer(
    // ...
    // configure a callback to handle delivery events
    xkafka.DeliveryCallback(func(msg xkafka.Message) {
        // ...
    }),
)
// ...create a message
// or, configure a callback on the message itself
msg.AddCallback(func(msg xkafka.Message) {
    // ...
})
// start the producer. this will start a background goroutine
// that will handle message delivery events.
go producer.Run(ctx)
// publish a message. this will return immediately.
err = producer.AsyncPublish(ctx, msg)

Consuming Messages

Now let's talk about the other side of Kafka: consuming messages. In my experience, this is where most of the complexity (and headaches) with Kafka show up. There are so many ways to configure and process messages in a consumer. The tradeoffs between throughput, durability, and delivery guarantees can get confusing and complicated.

xkafka distills the most common patterns into a few simple abstractions and sensible defaults, while still giving you the flexibility to tune things for your needs.

handler := xkafka.HandlerFunc(func(ctx context.Context, msg xkafka.Message) error {
    // ...
    return nil
})
consumer, err := xkafka.NewConsumer(
    "consumer-id", // consumer group id
    handler,
    xkafka.Brokers{"localhost:9092"},
    xkafka.Topics{"test"},
    xkafka.ConfigMap{/.../},
)
consumer.Use(/ add middlewares /)
err = consumer.Run(ctx)

Streaming vs. Batch

There are two main ways to consume messages:

• Streaming (with xkafka.Consumer): You process messages one at a time, as soon as they arrive. This is great for low-throughput systems, or when you want to keep memory usage low and have strong processing guarantees.
• Batch (with xkafka.BatchConsumer): You process messages in batches, either by size or by time window. This is useful for high-throughput systems, or when you want to buffer spikes and avoid hammering downstream systems or databases with every single message.

Both approaches keep messages in order. With batches, you can control the size or frequency of those batches.

consumer, err := xkafka.NewBatchConsumer(
    // ...
    xkafka.BatchSize(100), // batch size
    xkafka.BatchTimeout(15time.Second), // time window
)

Sequential or Async

After reading a message or batch, xkafka.Concurrency(N) determines how messages or batches are processed:

• Sequential: Default. One message or batch at a time. The next one isn't read until you're done with the current one.
• Asynchronous: N > 1. Multiple messages or batches are processed in parallel.

Offsets

One thing that always tripped me up with Kafka consumers is offset management. By default, Kafka moves the offset forward as soon as it delivers a message, not when you finish processing it. That means if your downstream is temporarily down, or your app crashes mid-processing, you might lose messages.

To solve this, I have seen developers add a separate database or queue to guarantee message processing. This adds another system to maintain and an additional point of failure. This is unnecessary.

xkafka simply sets enable.auto.offset.store=false and only stores the offset after the handler finishes processing the message or batch. So if something goes wrong, you'll just re-process the last message, not lose it. For batches, it tracks the highest offset, per topic and partition, in the batch.

This means you don't need a separate database or queue just to keep track of what you've processed. Kafka handles it for you.

Note: If you are tracking the Kafka lag, remember that increasing lag is not a bad thing. Instead of optimizing for zero lag by offloading messages to another queue, you should focus on improving throughput of your downstream systems.

#### At-Most-Once Guarantee

By default, xkafka relies on Kafka's enable.auto.commit=true and auto.commit.interval.ms to commit offsets, periodically in the background.

By enabling xkafka.ManualCommit(true) in sequential mode, you can achieve at-most-once processing guarantees for each message or batch. xkafka ensures that the offset is committed before reading the next message.

#### At-Least-Once Guarantee

If you combine xkafka.ManualCommit(true) with xkafka.Concurrency(N > 1), you can process messages or batches in parallel, while xkafka will ensure offsets are committed synchronously in order. This way, you get at-least-once processing guarantees.

Error Handling

One of the tricky parts of Kafka is handling broker errors, application errors, transient errors, and retries. xkafka allows you to handle errors in a layered way:

Handler Level

The simplest way is to handle application errors in your handler implementation itself.

handler := func(ctx context.Context, msg xkafka.Message) error {
    err := processMessage(ctx, msg)
    if err != nil {
        // log and/or trigger alert
        // optionally, move message to a dead letter topic or queue
        msg.AckSkip()
        return nil
    }
    msg.AckSuccess()
    return nil
}

Middleware Level

Middleware is a great way to reuse application-specific error handling logic across handlers and consumers.

handler := xkafka.HandlerFunc(func(ctx context.Context, msg xkafka.Message) error {
    // ...
    if err != nil {
        // propagate error to middlewares
        msg.AckFail(err)
        return err
    }
    // ack the message
    msg.AckSuccess()
    return nil
})

You can use a combination of retry and custom error handling middlewares to implement different retry strategies.

consumer.Use(
    RetryMiddleware(/.../),
    xkafka.MiddlewareFunc(func(next xkafka.Handler) xkafka.Handler {
        return xkafka.HandlerFunc(func(ctx context.Context, m *xkafka.Message) error {
            err := next.Handle(ctx, m)
            if errors.Is(err, app.SomeError) {
                // handle application error
            }
            // differentiate between transient, retryable errors
            // and permanent failures
            return err
        })
    }),
)

Global Level

xkafka.ErrorHandler is a mandatory option when creating a producer or consumer. Kafka broker and library errors are only visible to the xkafka.ErrorHandler.

consumer, err := xkafka.NewConsumer(
    // ...
    xkafka.ErrorHandler(func(err error) error {
        // returning a non-nil error will stop the consumer
        return err
    }),
)

This layered approach forces you to think about error boundaries and how you want to handle errors in your application.

A colleague once asked me, _"What was some of the good mentoring guideline that might have been shared with you in past to help you become a Sr PE?"_

The traditional view presents career progression as a binary choice: you either stay on the Individual Contributor (IC) track or switch to the management track. But in my experience, this is an oversimplified model that doesn't help you learn and grow.

Let me illustrate this with an example:

Imagine you're a CXO launching a critical, game-changing initiative. You have three candidates to choose from:

• A software architect skilled at building systems and applications
• A manager with a track record of delivering results and managing effective teams
• Someone who regularly contributes to code and architecture while successfully managing complex projects

Who would you pick to lead?

Rethinking Career Growth

While most companies define career ladders as mutually exclusive paths - either management or IC. I've developed a different mental model over my years working across various teams and roles. This model views career growth as a combination of three dimensions:

• Spectrum of Skills
• Problems to be Solved
• Sphere of Influence

True growth means expanding in all three dimensions, though not necessarily linearly or at the same time.

Spectrum of Skills

Your career typically begins as a software engineer, focusing on mastering programming languages, frameworks, and tools. You start by picking up tasks, writing code, and fixing bugs.

As you progress, you begin tackling architecture problems. While you're still coding, you're also writing architecture documents, designing systems, and evaluating trade-offs. This is when you start engaging in discussions, debates, and consensus-building. You begin collaborating with product teams, designers, and business stakeholders while building your reputation.

But here's the key: while technical skills dominate early career stages, you're simultaneously developing people skills and process understanding. The real growth comes from realizing that skills are skills - they're not confined to categorical boxes. Reaching senior levels isn't about becoming either a better coder or a better manager - it's about learning to learn whatever skills you need to get things done effectively.

Problems to be Solved

Early in your career, you work on assigned tasks - coding, reviewing, deploying, and marking them complete. As you advance, you handle more complex tasks and eventually lead initiatives and projects. However, the real growth begins when you start identifying problems yourself.

Problems exist everywhere - in codebases, architecture, product experience, and processes. The key is developing the ability to:

1. Identify issues and patterns that others might miss 2. Build compelling narratives around why these problems matter 3. Research and develop effective solutions 4. Execute and iterate on those solutions

This cycle of identifying problems and solving them becomes your engine for learning and career growth. The problems will change, evolve, but this fundamental approach remains constant.

Sphere of Influence

Drawing from Stephen Covey's concept of "circle of influence," think of your influence as a sphere that expands in multiple directions. This influence isn't tied to titles or positions - it's about creating visibility for your work and ideas.

Your narratives should always connect your work to its importance for team effectiveness, system architecture, product, user experience, and business outcomes. To be truly effective, your influence needs to extend in multiple directions—across technology, product, processes, and people. You should be able to communicate and collaborate effectively with peers, managers, and cross-functional teams.

A key part of career growth is learning how to scale your impact through others. There is only so much you can do on your own. As you progress to roles like Tech Lead, Principal Engineer, or Engineering Manager, your ability to mentor, unblock, and elevate others becomes essential. Helping your teammates succeed and grow helps you grow your sphere of influence.

Easier Said Than Done

On paper, this model might seem straightforward. But, in practice, your time & energy are finite. You'll constantly juggle multiple projects, initiatives, and responsibilities. You can't simultaneously focus on learning new skills, solving complex problems, and building influence.

Think of this model as a compass rather than a turn-by-turn navigation guide. It's perfectly fine - and often necessary - to focus on one dimension at a time. The key is maintaining awareness of all three dimensions while making conscious choices about where to direct your energy.

Roles & Titles

Who doesn't like important-sounding titles?

While titles and roles are important markers of career progression, they shouldn't be your primary focus. They define accountability and scope of work, but they don't limit what you can learn or how you can grow.

For example, a tech lead is accountable for service uptime, but that doesn't prevent them from learning new technologies or architectural patterns. You can follow the traditional title-based career progression, or you can chart your own path by continuously learning, solving meaningful problems, and building your reputation.

Remember: Focus on expanding your skills, tackling increasingly complex problems, and growing your sphere of influence. The roles, titles, and compensation will naturally follow.]]> https://raviatluri.in/articles/introducing-xdb https://raviatluri.in/articles/introducing-xdb Thu, 03 Apr 2025 00:00:00 GMT XDB is a new kind of database library based on tuples.

Rather than writing database-specific schemas, queries, and migrations, XDB allows developers to model their domain once and use it with one or more databases.

XDB separates the application domain model from the underlying database(s) by using a simple yet powerful data model based on tuples. This lets developers focus on modeling, ingesting, and querying data—without worrying about the underlying database infrastructure or operations.

Why?

Not all databases are created equal. Most applications at scale use multiple types of databases:

• PostgreSQL/MySQL as the main database
• Redis for caching
• Elasticsearch for search
• Clickhouse for analytics
• BigTable for versioning

Each database solves a specific problem and comes with its own tradeoffs.

An application's domain model is often a combination of data that resides in different databases. Typically, each database has its own abstraction layer for migrations and queries. Sometimes, new microservices are spun up to manage specific use cases like search, analytics, or caching.

At the end of the day, developers must stitch together domain data from multiple databases or microservices to serve user-facing APIs. Looking at an end-to-end flow, there are several layers of data fetching, mutation, and transformation. Every time a feature adds new fields or relationships, the entire stack goes through churn.

XDB aims to separate the application domain model from database implementation and operations. What if, instead of maintaining multiple database-specific implementations, developers could model their domain once and seamlessly work with multiple databases?

Inspiration

XDB draws inspiration from two key concepts: Data Services and N-Quads.

Data services are intermediary services that sit between APIs and databases. They provide simple APIs for your domain data, while automating and abstracting away the underlying database management.

N-Quad is a well-known format used to represent attributes and relationships in graphs.

Here's an example of N-Quad format:

 
            https://raviatluri.in/articles/frontmatter-obsidian
            https://raviatluri.in/articles/frontmatter-obsidian
            Mon, 31 Mar 2025 00:00:00 GMT
            
            After using Obsidian for few months, I accidentally discovered that it supports frontmatter.
Typing --- in the first line of a file creates a "Properties" block. https://help.obsidian.md/properties is the full documentation.
]]>
            obsidian
            markdown
        
        
            
            https://raviatluri.in/articles/using-mockery-go-generate
            https://raviatluri.in/articles/using-mockery-go-generate
            Wed, 09 Aug 2023 00:00:00 GMT
            
            This is a simple example of how to use mockery with go generate. It is my preferred way of generating mocks, because the mocks configuration is co-located with the interface definition.
1. Install mockery
go install github.com/vektra/mockery/v2@2.23.4 # use latest version
2. Add a go:generate comment to your interface
//go:generate mockery -name=MyInterface -output=mocks -outpkg=mocks -case=underscore
type MyInterface interface {
    DoSomething()
}
3. Run go generate
go generate ./...
Mockery - https://vektra.github.io/mockery/latest/
]]>
            golang
        
        
            
            https://raviatluri.in/articles/using-xrun
            https://raviatluri.in/articles/using-xrun
            Mon, 03 Jul 2023 00:00:00 GMT
            
            Example of using xrun(https://github.com/gojekfarm/xrun) to manage multiple components in a Go service.
Components can implement the xrun.Component interface or can be wrapped with xrun.ComponentFunc to be used with xrun.
kafka consumer
consumer := newKafkaConsumer()
gRPC server
server := newGRPCServer()
metrics server
metrics := newMetricsServer()
err := xrun.All(
    xrun.NoTimeout,
    consumer,
    server,
    metrics,
)
Blog: https://ajatprabha.in/2023/05/24/intro-xrun-package-managing-component-lifecycle-go
]]>
            golang
        
        
            
            https://raviatluri.in/articles/my-mac-accessibility-setup
            https://raviatluri.in/articles/my-mac-accessibility-setup
            Fri, 02 Jun 2023 00:00:00 GMT
            
            I was diagnosed with ALS in 2019. Over time, I have gradually lost the ability to type. Initially, I relied on a combination of dictation, one-handed typing, and a mouse. However, as my speech became more slurred and my left hand weakened, I transitioned to using an on-screen keyboard, mouse, and one-handed typing.
Nowadays, I solely rely on an on-screen keyboard and mouse, and I have been using this setup for over a year. Surprisingly, I have been able to continue coding, sending emails, and writing articles with this setup, enabling me to maintain most of my previous activities despite my condition.
This is my work coding calendar in September 2022:
And the same calendar for May 2023:
I am sharing my accessibility setup in the hope that it can assist others in similar situations.
Keyboard
The on-screen keyboard I currently use is a custom layout created using the macOS Accessibility Keyboard. I began with the default ANSI keyboard and gradually added shortcuts, passwords, emails, phone numbers, and other frequently used items.
The on-screen keyboard is available in Settings > Accessibility > Keyboard > Accessibility Keyboard.
The keyboard can be customized using the Panel Editor.
You can find more information about the macOS Accessibility Keyboard on Apple's website.
Typing
For typing, I rely on the native typing suggestions provided by macOS. Although the typing suggestions are mostly limited to a few sentences in most apps, they offer greater functionality in the Notes app.
When using Chrome, I heavily rely on Compose AI for composing emails and using Slack.
In VSCode, I utilize GitHub Copilot for coding and writing articles.
More recently, I have started using ChatGPT for writing. I begin by outlining the article's key points and main highlights, and then I use ChatGPT to generate the content. Finally, I review and edit the generated content to refine the tone or add additional details.
Next Steps
I plan to try Glassouse, a head mouse, as my ability to use a traditional mouse will eventually be affected.
I recently discovered Karbiner-Elements, a powerful keyboard customizer. I found the following articles particularly useful:
Karabiner God Mode
Karabiner Wiki
Similar Resources
Josh Comeau's article on Hands-free Coding introduced me to the idea that I can continue coding, writing, and creating even with my limitations.
For comprehensive information on accessibility features across all Apple products, I highly recommend exploring Apple Accessibility.
]]>
            accessibility
            
        
        
            
            https://raviatluri.in/articles/the-als-story
            https://raviatluri.in/articles/the-als-story
            Thu, 23 Dec 2021 00:00:00 GMT
            
            _This is a ChatGPT generated summary of my Twitter thread. The original thread can be found here: https://twitter.com/sonnes/status/1474042833535262725_
Two years ago, my life took a dramatic turn. After seven successful years at PaGaLGuY, I made a bold decision to join GojekTech, drawn by the promise of Southeast Asia's hypergrowth phase. With my wife and one-year-old son, we packed our bags and moved to Jakarta, ready to embrace the new opportunities that awaited us.
Settling into a new city wasn't without its challenges. My wife's first mission was to find familiar grocery items, and our trips to Singapore became a ritual of stocking up on essentials from Mustafa. Amidst the settling-in process, our son began swimming lessons, my wife took up tennis, and I even achieved my PADI dive certification. However, my attempts at learning tennis were far from successful, and I blamed my clumsiness on overdoing deadlifts and snatches.
Little did I know that the following months would bring unexpected health concerns. It started with some discomfort, leading me to consult doctors, orthopedics, and neurologists. I underwent a series of tests, from ENMG to cervical MRI scans, in search of a diagnosis. The initial suspicions pointed toward spondylosis or even a motor neuron disease, most likely ALS. The spectrum of possibilities was overwhelming, and I couldn't help but hope it was just a pinched nerve.
The uncertainty lingered as we waited for conclusive results. An MRI scan left the radiologist puzzled, unable to provide a definitive diagnosis. We found ourselves back at square one, contemplating our next move. We decided to fly back to Hyderabad, seeking further medical evaluations and putting an end to the relentless search for answers.
November 2019 was marked by a week filled with more tests, including MRIs, PET-CT scans, and countless blood vials. Each moment was filled with apprehension and a sense of urgency. Yet, despite the numerous evaluations, there was still an air of uncertainty surrounding the diagnosis. The neurologist cautiously suggested that ALS was the most likely culprit. The state-of-the-art diagnostic test? Waiting. Waiting to see how the condition progresses. The doctor prepared us for the worst, explaining that I may have only a few years left, at best, and perhaps a little more if luck was on my side.
With these grim prospects, questions began to flood my mind. How much time do I have left? Are there any treatments available? Thoughts ranged from contemplating my legacy to planning the optimal investment strategy to put my young son through college. Amidst this turmoil, I found it difficult to shed tears, but everyone around me seemed to do so.
At some point, I reached a breaking point and said, "FUCK IT!" I made a conscious decision to move forward and live one month at a time, cherishing every precious moment that life had to offer.
The year 2020 brought its own set of challenges. In addition to the ALS scare, I received a diagnosis of Hirayama, which brought its own worries. The world was hit by the COVID-19 pandemic, imposing lockdowns and restrictions. Amidst the chaos, I underwent cervical fusion surgery, hoping to alleviate some of the discomfort. Fortunately, the diagnosis of Hirayama provided a glimmer of hope, as it was not a fatal condition.
But as 2021 rolled in, my speech deteriorated further. Simple tasks became increasingly difficult to perform. Halfway through the year, the neurologist confirmed what I had feared all along: ALS. The ground crumbled beneath me once again, but this time, I refused to let it consume me.
In 2019, I couldn't fathom making it to 35. And yet, here I am, still alive, still mobile, but facing the same diagnosis once more. Despite the challenges
]]>
            als