After three months of work, I decided to completely rebuild Elystral from scratch. Here's why that was actually the right decision, and what I learned about premature optimization.

The Original Vision

Elystral started as a tool to help developers visualize their code architecture. I wanted to create something that could automatically generate beautiful, interactive diagrams from codebases. The goal was to help teams understand complex systems at a glance.

I had a clear vision: drag-and-drop interface, real-time updates, and smart suggestions based on best practices. I was excited to build something that could potentially help thousands of developers.

What Went Wrong

Three months in, I had built a complex system with:

• A custom graph visualization engine
• A sophisticated parsing system for multiple languages
• A real-time collaboration backend
• A complex state management system

But I had fallen into a classic trap: I built for scale before validating the core idea. I was solving interesting technical problems rather than focusing on delivering value quickly.

The Decision to Rebuild

After showing my progress to a few developer friends, I realized something important: they were impressed by the technical aspects but confused about how they would actually use it in their workflow.

That's when I decided to scrap everything and start over with a much simpler approach:

The new version had:

• A single command to generate a visualization
• Limited but useful language support (just JavaScript to start)
• Static exports instead of real-time updates
• Simple, opinionated styling with minimal configuration

What I Learned

1. Start with a "walking skeleton"

Build the simplest possible version that delivers the core value. For Elystral, that meant focusing on generating useful visualizations quickly, not building the perfect architecture.

2. Technical decisions should follow user needs

I chose technologies based on what I thought would scale best, not what would help me validate the idea fastest. This led to unnecessary complexity.

"Make it work, make it right, make it fast" — in that order. I was trying to do all three simultaneously.

3. Beware the "just one more feature" trap

I kept adding "essential" features before launching. This is a form of perfectionism and fear of feedback, not good product development.

The Rebuild Results

Two weeks after starting over, I had a working prototype that actually delivered value. It wasn't perfect, but it did one thing well: it generated useful visualizations of JavaScript codebases with minimal effort.

I shared it with the same friends, and this time the response was completely different. They immediately saw how it could fit into their workflow and had suggestions for improvements based on actual usage, not theoretical features.

Moving Forward

Now I'm iterating based on real feedback, adding features only when they solve actual problems users have encountered. The project is moving faster than before, despite having "thrown away" three months of work.

Sometimes the fastest way forward is to take a step back.

Being young while building in public comes with unique challenges and advantages. Here's what I've learned about managing expectations, handling feedback, and leveraging my perspective.

The Age Question

When I first started sharing my work online, I debated whether to mention my age at all. Would it help me stand out, or would it cause people to take me less seriously?

After experimenting with both approaches, I've found that transparency works best for me. Yes, some people will dismiss you because of your age. But many more will be impressed and supportive precisely because you're young and already building meaningful things.

Your age is neither an excuse nor a superpower. It's simply context that helps people understand your journey.

Lesson 1: Manage the "Wow Factor" Carefully

When you're young and building things, people's first reaction is often "Wow, that's impressive for your age!" This is both a blessing and a curse.

I've learned to appreciate the encouragement while setting my own standards. I don't want to be "good for a teenage developer" — I want to create work that stands on its own merits.

This means:

• Seeking feedback from people who won't go easy on me because of my age
• Comparing my work to industry standards, not to what other teenagers are doing
• Being honest about where my work falls short, even when others are impressed just because I'm young

Lesson 2: Use Your Perspective as an Advantage

Being young gives you a different perspective on problems. This isn't just about being "digital native" — it's about seeing possibilities that others might miss because they're too accustomed to how things have always been done.

For example, when I started working on LucidAI, I approached explainable AI from the perspective of someone who grew up with technology but still finds AI systems confusing. This led me to focus on visual explanations that make sense to non-experts, rather than the technical approaches that dominate academic papers.

Lesson 3: Build a Support System

Building in public can be emotionally challenging at any age, but especially when you're young and still developing confidence in your abilities.

I've found it essential to have:

• A small group of trusted mentors who can provide honest feedback
• Peers who understand the journey (other young builders)
• Clear boundaries about when and how I engage with public feedback

The most valuable connections have come from reaching out to people whose work I admire with specific, thoughtful questions. Many experienced professionals are surprisingly willing to help young builders if you demonstrate genuine curiosity and respect for their time.

The Balancing Act

Perhaps the biggest challenge is balancing building in public with other aspects of teenage life: school, friends, family, and just figuring out who you are.

I've had to learn that:

• Consistency matters more than frequency — posting once a week reliably is better than posting daily for a month and then disappearing
• It's okay to step back when other priorities need attention
• Not everything needs to be shared — some experiments and failures are better kept private until you've processed them

Final Thoughts

Building in public as a teenager has accelerated my learning in ways that wouldn't have been possible otherwise. The feedback, connections, and opportunities that have come from sharing my work have been invaluable.

If you're young and considering building in public, my advice is simple: start small, be authentic, focus on providing value rather than impressing people, and remember that your journey is unique.

The world needs more young builders who are willing to share their work and perspective. Just make sure you're building and sharing for the right reasons — because you genuinely want to create something useful and learn in public, not just to collect validation.

Most social platforms are designed to maximize engagement through addictive patterns. I've been thinking about whether it's possible to design a social experience that respects human attention while still being viable.

The Engagement Paradox

Social networks face a fundamental tension: their business models typically depend on maximizing user engagement, but truly serving users might mean helping them spend less time on the platform.

This creates what I call the Engagement Paradox:

The more a social platform optimizes for engagement metrics, the more it tends to diverge from users' actual wellbeing and goals.

We see this play out in various ways:

• Infinite scrolling that removes natural stopping points
• Notification systems designed to create FOMO (fear of missing out)
• Content recommendation algorithms that favor emotional triggers over substance
• Gamification elements that create artificial social pressure

What Would an Ethical Alternative Look Like?

I've been sketching ideas for what an ethical social platform might look like. Here are some principles I'm exploring:

1. Finite by Design

Instead of infinite content, what if a platform was designed to be finite? You open it, see a limited set of high-quality updates from people you care about, and then you're done until tomorrow.

2. Conscious Friction

Not all friction is bad. Strategic friction can help users make more intentional choices about how they spend their attention.

Examples might include:

• A "post cooling period" where you draft something but it doesn't send for 30 minutes, giving you time to reconsider
• Limits on how many posts you can make per day
• Prompts that ask "Is this worth sharing?" before posting

3. Relationship-Centered, Not Content-Centered

What if the core metric wasn't engagement but meaningful connection? This would shift the focus from producing and consuming content to nurturing relationships.

The Business Model Problem

The elephant in the room is the business model. If you're not maximizing engagement for advertising, how do you sustain the platform?

Some possibilities:

1. Subscription Model

Users pay directly for a service that respects their attention. This aligns incentives but limits accessibility.

2. Cooperative Ownership

What if users collectively owned the platform? This could create different incentives than either ad-supported or venture-backed models.

3. Bounded Advertising

Advertising that's limited in quantity and clearly separated from organic content. The pitch to advertisers would be about quality of attention, not quantity.

Experiments Worth Trying

I'm considering building some small prototypes to test these ideas:

Final Thoughts

I don't have all the answers, but I'm convinced that the current paradigm of attention-extractive social platforms isn't the only possibility. There's room for innovation that aligns platform success with genuine user wellbeing.

The challenge is finding the right balance between creating something people want to use and something that respects their humanity and agency.

What do you think? Is an ethical social network possible? Would you use a platform designed with these principles in mind?

After years of using VS Code, I've made the switch to Neovim. Here's my current development setup, including terminal configuration, plugins, and productivity tools that have changed my workflow.

Why I Switched to Neovim

I've been a VS Code user for years, and it served me well. It's an excellent editor with a rich ecosystem of extensions. So why switch?

Three main reasons:

1. The Modal Editing Paradigm

Once you get used to thinking in terms of text operations rather than just inserting characters, editing becomes much faster. I found myself installing Vim emulation plugins in VS Code, but they never quite captured the full experience.

2. Terminal Integration

I was already doing more and more work in the terminal (git, running tests, etc.). Having my editor live in the same environment created a more cohesive workflow.

3. Customizability and Performance

Neovim starts instantly and uses minimal resources. Plus, configuring it taught me a lot about how text editors actually work.

My Current Setup

Terminal: Alacritty + Tmux

Alacritty is a GPU-accelerated terminal that's blazing fast. I pair it with Tmux for session management and split panes.

Neovim Configuration

I've moved to using Lua for my Neovim config, which feels cleaner than VimScript. Here are some key plugins I'm using:

Font: JetBrains Mono

I've tried many programming fonts, but JetBrains Mono with ligatures has been my favorite for readability during long coding sessions.

Productivity Tools I'm Loving

1. Zoxide

A smarter cd command that remembers which directories you use most frequently. After a short learning period, it makes navigation much faster.

2. Lazygit

A terminal UI for git that makes complex operations visual while still keeping you in the terminal.

3. fzf

Fuzzy finder that integrates with everything. I use it for file navigation, command history, and even selecting Git branches.

My Workflow in Action

Here's how these tools come together in my typical workflow:

1. Start or attach to a tmux session
2. Use zoxide to jump to the project directory
3. Open Neovim
4. Use Telescope to find files or grep through the codebase
5. Split the terminal when needed for running tests or servers
6. Use Lazygit for version control operations

The whole setup is keyboard-driven, which means I rarely reach for the mouse. This has significantly reduced the strain on my wrists and increased my overall speed.

What I Miss from VS Code

To be fair, there are some things I miss:

• The debugging experience in VS Code is still superior
• Some specialized extensions don't have great Neovim equivalents yet
• Settings UI is more approachable than editing config files

For these reasons, I still keep VS Code installed and occasionally use it for specific tasks.

Is This Setup For You?

If you're curious about trying a similar setup, I'd recommend:

1. Start with just Vim keybindings in your current editor
2. Once comfortable, try Neovim with a minimal config
3. Add tools and customizations incrementally as you identify needs

The goal isn't to have the most complex setup, but rather one that feels natural and helps you focus on the code rather than the tools.

I've been working on a new approach to visualize how transformer models distribute attention across inputs. This experiment uses interactive heatmaps to reveal patterns in how models process language.

The Black Box Problem

Transformer models like BERT and GPT have revolutionized NLP, but they operate as black boxes. We feed them input and get output, but the internal decision-making process remains opaque.

This opacity creates several problems:

• It's difficult to debug unexpected outputs
• We can't easily identify biases in the model's reasoning
• Users have to blindly trust the model's decisions
• Researchers struggle to improve models without understanding how they work

Attention as a Window into the Model

Attention mechanisms are a key component of transformer models. They determine which parts of the input the model focuses on when generating each part of the output.

By visualizing these attention patterns, we can get insights into how the model processes information.

The Visualization Approach

I've been experimenting with a multi-layered visualization approach that shows:

1. Word-to-word attention patterns across all heads and layers
2. Aggregated attention flows through the network
3. Interactive elements that allow users to explore specific patterns

Here's a simplified version of the code that extracts attention weights:

Key Findings

1. Specialization of Attention Heads

Different attention heads specialize in different linguistic patterns. Some focus on syntactic relationships (like subject-verb agreement), while others track semantic connections.

2. Progressive Abstraction Across Layers

Early layers tend to focus on local patterns and syntax, while deeper layers capture more abstract semantic relationships.

3. Attention to Special Tokens

Models like BERT pay significant attention to special tokens like [CLS] and [SEP], using them as aggregation points for sentence-level information.

Interactive Demo

I've built a simple web interface that allows you to input text and see the attention patterns in real-time. The visualization shows:

• Heatmaps of attention weights
• The ability to select specific layers and heads
• Highlighting of the strongest attention connections

The interface is built with React and D3.js, with a Flask backend that handles the model inference.

Applications and Future Work

This visualization approach has several potential applications:

1. Educational Tool

Helping students and practitioners understand how transformer models work.

2. Debugging Aid

Identifying why models make certain predictions by examining what they're attending to.

3. Research Platform

Enabling researchers to compare attention patterns across different models and tasks.

For future work, I'm exploring:

• Combining attention visualization with other interpretability techniques like integrated gradients
• Extending the approach to generative models like GPT
• Creating more intuitive visual metaphors for attention flows

Try It Yourself

I've deployed a demo version of the visualization tool at attention-viz.herokuapp.com. It currently supports BERT and RoBERTa models on classification tasks.

The code is available on GitHub, and I welcome contributions and feedback.

Most accessibility discussions focus on visual, motor, or hearing impairments. I've been researching how to design for cognitive accessibility, which affects a huge portion of users but gets less attention.

Understanding Cognitive Accessibility

Cognitive accessibility refers to making content and interactions understandable and usable for people with different cognitive abilities, including those with:

• Learning disabilities like dyslexia
• Attention deficit disorders
• Memory impairments
• Executive function challenges
• Autism spectrum conditions
• Age-related cognitive changes

What makes this area particularly important is that:

Cognitive accessibility benefits everyone. We all experience situational cognitive limitations when we're tired, stressed, distracted, or in unfamiliar environments.

Key Principles I'm Exploring

1. Reduce Cognitive Load

Cognitive load refers to the mental effort required to process information. By reducing unnecessary complexity, we can make interfaces more accessible to everyone.

2. Provide Multiple Ways to Understand Content

Different people process information differently. Some prefer text, others visual information, and others might benefit from audio.

Examples:

• Accompany text with relevant images
• Provide video transcripts
• Use diagrams to explain complex relationships

3. Design for Different Attention Patterns

Some users may have difficulty maintaining focus, while others might hyperfocus on details.

Design considerations:

• Minimize distractions during critical tasks
• Allow users to pause and resume complex processes
• Provide clear visual hierarchy to guide attention

4. Support Memory

Working memory limitations affect many users, especially under stress.

Helpful approaches:

• Don't rely on users remembering information from previous screens
• Provide contextual help that doesn't require navigating away
• Use recognition rather than recall (e.g., dropdown menus vs. text fields)

Experimental Redesign: A Form Experience

To apply these principles, I redesigned a typical multi-step form with cognitive accessibility in mind.

Before: Traditional Approach

After: Cognitively Accessible Approach

Key Improvements

1. Clear Progress Indicator: Visual representation of the process with icons and labels
2. Contextual Information: Helper text explains why information is needed
3. Explicit Labeling: Form fields have clear labels instead of just placeholders
4. Preview of Next Steps: Users know what to expect next
5. Save and Exit Option: Reduces pressure and allows users to take breaks

Testing and Results

I conducted informal testing with 12 users, including 4 with self-reported cognitive differences (ADHD, dyslexia, and anxiety). The results were promising:

• Completion rates improved from 75% to 92%
• Average completion time decreased by 18%
• Self-reported confidence increased across all user groups
• Users with cognitive differences reported significantly lower frustration levels

Most interestingly, the improvements benefited all users, not just those with cognitive differences.

Next Steps

I'm continuing to explore cognitive accessibility through several avenues:

1. Creating a design system with built-in cognitive accessibility patterns
2. Developing automated testing tools that can identify potential cognitive accessibility issues
3. Researching how different cognitive profiles interact with various design patterns

I believe cognitive accessibility represents one of the most significant untapped opportunities in inclusive design. By addressing these needs, we can create interfaces that work better for everyone, not just those with diagnosed conditions.