DEV Community: Sumit Mishra

The Pros and Cons of Working in a Team

Sumit Mishra — Mon, 05 Oct 2026 12:21:34 +0000

Working in a team can be one of the fastest ways to learn, build projects, and gain experience. But let's be honest: teamwork isn't always as productive or enjoyable as people make it sound.

A good team can multiply your output. A bad team can multiply your headaches.

I've noticed that being part of a team comes with a clear trade-off: you get more opportunities and shared workload, but you also have to deal with communication, coordination, and differences in effort.

The Pros of Being in a Team

1. More Hackathon Opportunities

One of the biggest advantages of having a team is being able to participate in more hackathons.

Hackathons often require different skills—someone might handle frontend development, another person works on the backend, someone else manages AI or research, and another person focuses on the presentation.

Instead of one person trying to do everything, the workload can be divided among the team.

This makes it possible to participate in bigger and more ambitious challenges.

2. You Save Time

Working alone means you have to handle everything yourself.

Research, coding, debugging, testing, documentation, deployment, presentations—you name it.

In a team, these responsibilities can be divided. While one person works on the backend, another can work on the frontend and someone else can handle research or documentation.

If the coordination is good, you can accomplish much more in the same amount of time.

3. You Learn From Other People

This is probably one of the most valuable benefits.

Everyone has a different way of solving problems. A teammate might introduce you to a technology, programming technique, workflow, or shortcut that you wouldn't have discovered on your own.

You don't just learn technical skills either.

You also learn how to communicate ideas, give feedback, handle disagreements, review code, and work toward a common goal.

Sometimes, watching how another person approaches a problem can teach you more than reading ten tutorials.

4. You Gain Real Experience

Building something with other people gives you experience that goes beyond writing code.

You learn about:

Git and collaboration
Task management
Code reviews
Deadlines
Project planning
Communication
Responsibility
Handling disagreements
Working with different personalities

These are skills that become increasingly important as projects get bigger.

5. More Opportunities to Earn

A capable team can take on projects that would be difficult for one person to handle.

Freelancing, competitions, hackathons, open-source projects, startups, and client work can all benefit from having people with different skill sets.

Instead of asking, "Can I do this myself?", a team can ask, "Can we do this together?"

That difference can open up more opportunities.

The Cons of Being in a Team

Of course, teamwork isn't magic.

Sometimes the team itself becomes the bottleneck.

1. Communication Overload

This is probably one of the biggest problems.

When several people are working together, communication can quickly become excessive.

You might have messages on Slack, Discord, WhatsApp, GitHub, email, meetings, and random calls.

Instead of actually working, you can end up spending a huge amount of time talking about the work.

Communication is necessary, but too much communication becomes another form of work.

2. Async Communication Can Be Frustrating

Remote teams make this even more complicated.

Imagine you're waiting for someone to answer an important question.

They're offline.

You wait.

They come online later.

You reply.

Now you're waiting again.

A decision that could have taken five minutes in person can sometimes take an entire day when communication happens asynchronously.

This is especially painful when one person's work depends on another person's response.

3. You Can Feel Undervalued

Another difficult part of teamwork is feeling like your contribution isn't being recognized.

You might spend hours solving a difficult technical problem while someone else gets more attention because their work is more visible.

Sometimes this isn't intentional.

People simply don't see all the work happening behind the scenes.

But that doesn't make the feeling any less frustrating.

4. Unequal Effort

This is the classic team problem.

Everyone starts with the same enthusiasm.

Then the project gets harder.

One person keeps working.

Another disappears.

Someone contributes occasionally.

And suddenly, two people are carrying the entire project.

Nothing destroys team motivation faster than feeling that you're putting in significantly more effort than everyone else.

5. Coordination Takes Time

Dividing work sounds easy until you actually have to do it.

You need to decide:

Who does what?
What needs to be done first?
How will the components connect?
Who reviews the code?
What happens if someone misses a deadline?
How do you resolve disagreements?

All of this takes time.

A solo developer can make a decision in thirty seconds.

A team might need a discussion first.

6. Different Working Styles

Not everyone works the same way.

One person might want everything planned before writing code.

Another might prefer experimenting first.

One person may work at night.

Another may work in the morning.

One person might care deeply about clean architecture.

Another might say, "It works. Ship it."

These differences can create friction if the team doesn't establish expectations early.

So, Is Working in a Team Better?

Not necessarily.

It depends on the team.

A good team can make you significantly more productive. You get more perspectives, divide the workload, learn from others, and potentially access opportunities that would be difficult to pursue alone.

A bad team can make you less productive than working alone.

You'll spend your time waiting for people, attending unnecessary meetings, resolving conflicts, repeating information, and wondering why nobody finished their part.

The real goal isn't simply to work in a team.

It's to build a team where:

Responsibilities are clear.
Everyone contributes.
Communication is intentional.
People respect each other's time.
Decisions don't take forever.
Contributions are recognized.
Everyone knows what they are responsible for.

The Bottom Line

Being part of a team is a trade-off.

You sacrifice some control and simplicity in exchange for more capacity, knowledge, opportunities, and shared responsibility.

When the team works well, 1 + 1 can feel like 3.

When the team doesn't work well, 1 + 1 can somehow feel like 0.5.

So before joining a team, don't just ask:

"Are these people good at coding?"

Also ask:

"Can we communicate well, trust each other, divide responsibility fairly, and actually get things done?"

Because technical skill can build a project.

Good teamwork is what keeps the project moving.

Kept — a resume link I made for Rahul

Sumit Mishra — Mon, 05 Oct 2026 06:06:20 +0000

This is a submission for the Hacktoberfest Weekend Challenge: Build for a Friend

What I Built

I made Kept for my friend Rahul. He ships on GitHub. His resume does not. The PDF he last sent still describes a project he has already rewritten, and the private work he is proudest of never makes the page, because he will not paste that code into a chatbot.

Kept is one link for him. He connects GitHub, chooses the projects, and writes a short brief for the role this version is for. A design role and an engineering role can each keep their own link and their own brief, which matters when he is applying to more than one kind of job. The studio offers two choices: only public projects, or public and private. Anyone with the address opens a PDF. When his repositories change, Kept writes the PDF again. The link stays the same, so he does not email a new file every time the work moves on.

The counts come from his GitHub account: stars, forks, releases, and the latest commits in a 90-day window. A sentence about a project is kept only when it names the project and mentions something that actually appears in the files. If the model wanders, that sentence is dropped and the resume keeps the counts.

Demo

Try it: https://kept-virid-two.vercel.app

The page a recipient sees: https://kept-virid-two.vercel.app/sample

Try as guest is the path I gave Rahul first: the studio on bundled sample projects, with no account. A guest session starts on public and private projects. When he connects GitHub from that session, the sample account is replaced by his. The browser remembers which guest login is tied to his GitHub login (kept.binding in local storage) and reloads the project list, links, and studio form for that account. Leaving guest mode forgets the pair.

Code

Sumit884-byte / kept

Kept

Kept turns the work you publish on GitHub into a resume PDF with a stable link. When that work changes, the PDF is written again. The link stays the same.

The pages speak in plain language. This file is the technical map.

What happens when GitHub changes

The person connects GitHub with OAuth. The grant is always read:user, user:email, and repo. The repo scope is what the GitHub API requires in order to read private repositories and to install a hook. The studio then chooses a visibility for that link: public projects only, or public and private. A link set to public does not list private repositories, even though the token can see them.
In the studio they pick repositories and write a brief for that version of the resume. Each link stores its own brief and role, so one person can keep a design version…

View on GitHub

https://github.com/Sumit884-byte/kept

How I Built It

Two open-weight Gemma models, used for different jobs.

Private projects stay on the computer. When a private README is too thin to explain the project (no real sentence, fewer than twelve words, or a placeholder), the server stores the file paths and does not download the files. The browser asks GitHub for those files with the person's own token, holds them in memory, and runs onnx-community/gemma-3-270m-it-ONNX (the q4f16 build) through Transformers.js. It uses WebGPU when the machine has it, and WASM when it does not. The prompt asks for one resume sentence that starts with the project name and mentions only actions or tools written in those files. A second check throws the sentence away unless the project name is in it and at least one word from the files is in it. Only that sentence is posted back. The files are not stored, and they are not sent to the larger model. Rahul's guest session uses the bundled sample files and the same in-browser path, so he can see the shape of the resume before he connects anything. After he connects GitHub, the account is no longer a sample account, and later reads and the PDF use the repositories from his login.

Public projects are read through GitHub's API. Kept pulls repository metadata, the README, languages, releases from the last 90 days, and up to 30 commits in that window. It does not call GitHub's stats endpoints, so added and removed lines stay at zero and the PDF says "The latest N updates." A thin public README is read on the server from up to two manifests and five source files. That source is used to write a conclusion from routes, a command name, and a recent commit message, then discarded.

A role does not rewrite the resume. The project list the studio shows has a name, description, language, and star count. With a role filled in, the page pre-selects up to eight projects from that list. After the repositories are read, and only when LLM_BASE_URL is set, the role string goes to an OpenAI-compatible endpoint with store: false. On Render that endpoint is Gemma 3 4B Instruct: gemma-3-4b-it-Q4_K_M.gguf, served by llama.cpp on a private service (2 CPUs, 8 GB). The model returns JSON, skills and stacks. It is not given project names, descriptions, conclusions, or source. Kept then matches those phrases locally against each public project's name, description, saved conclusion, highlights, and language, and keeps up to eight. Private projects stay out of that request and remain on the resume if they were selected. If the model is missing or returns nothing, the same match runs from the words in the role. The brief on each link still applies on every rebuild: first person, "never mention," and "leave out."

The PDF is drawn from that saved resume with @react-pdf/renderer and a classic template in src/resumeTemplateClassic.js. History lives in Tiger Data (TimescaleDB). Three tables — project signals, the conclusion used on the resume, and why a link was rewritten — become hypertables on time when Timescale is present. A star change is attached only when an earlier row is at least an hour older. Weekly buckets use time_bucket('7 days', time).

The PDF at /r/<slug>.pdf renders the latest saved resume. On Render, npm start polls on a timer (default 10 minutes). On the Vercel demo there is no background timer; opening a real link schedules a check when the last one is older than the poll interval. /sample there is the built-in example at /r/keptsample and does not use the database. Guest, the project list, and sign-in status are small functions and do not boot the full server. With private-project access and a public https URL, Kept also installs a push and release hook and checks X-Hub-Signature-256.

Why Does Open Innovation Matter?

The private repositories are the ones Rahul will not copy onto a server he does not control, and they are often the ones his resume should mention. A closed chat API would take that source as the price of a paragraph. Gemma 3 270M is small enough to run in his browser, so the reading happens on his computer. I can refuse a sentence that does not match the files, because the weights, the prompt, and the filter are all in the project. His files never become a training example.

The same choice is why the role step is a 4B GGUF on a service I run, through llama.cpp. The request asks for skills and stacks, with storage off, and the project list is chosen afterward on our side. I can swap the GGUF. I can leave LLM_BASE_URL unset and the resume still builds from the brief and the GitHub counts. The writer is not allowed to add a metric that was not in the evidence.

Open weights are what make that rule enforceable. A retention promise on someone else's API is a policy. Running the model here is a property of the system.

Prize Categories

Best Use of Gemma — Gemma 3 270M in the browser for private projects, and Gemma 3 4B Instruct for turning a role into skills and stacks.
Best Use of Render — the 4B model runs as a private llama.cpp service (render.yaml). The app calls it with the role only.
Best Use of Tiger Data — GitHub signals, resume conclusions, and link rewrites are Timescale hypertables, so a star change shows up only after two readings at least an hour apart.

Hackathons: Learn More Than You Win

Sumit Mishra — Tue, 29 Sep 2026 08:44:22 +0000

Hackathons have become a cornerstone of the developer community, attracting thousands of participants worldwide. While many enter these competitions with trophies, cash prizes, and job offers in mind, the true value of hackathons lies far beyond the rewards. Here's why we should approach hackathons as learning opportunities rather than just prize-chasing endeavors.

The Learning Mindset

When you participate in a hackathon with learning as your primary goal, everything changes. You become more open to experimentation, more willing to take risks, and more resilient in the face of failure. This mindset shift transforms the entire experience from a high-pressure competition into an intensive learning workshop.

Skills That Transcend the Competition

Hackathons force you to work with new technologies, frameworks, and tools under tight deadlines. This pressure-cooker environment accelerates learning in ways that traditional study cannot. You'll learn:

Rapid prototyping: How to build functional prototypes quickly
Team collaboration: Working effectively with diverse skill sets
Problem-solving under pressure: Making critical decisions with limited information
Time management: Prioritizing features and managing scope
Communication: Explaining technical concepts to non-technical team members

The Network Effect

The connections you make during hackathons often prove more valuable than any prize. You'll meet developers from different backgrounds, learn their approaches to problem-solving, and potentially find future collaborators or employers. These relationships are built on shared experiences and mutual respect, not transactional interactions.

Embracing Failure as Feedback

One of the most valuable lessons hackathons teach is that failure is not fatal. When your code breaks at 3 AM or your API integration fails, you learn to troubleshoot, adapt, and persevere. These experiences build resilience that serves you throughout your career. Every bug you fix and every setback you overcome makes you a better developer.

Building a Portfolio That Matters

Projects built during hackathons demonstrate more than technical skills—they show initiative, creativity, and the ability to deliver under constraints. Even unfinished projects can be valuable additions to your portfolio, especially when you document the learning journey and challenges faced.

The Long-Term Perspective

Rewards are temporary; skills are permanent. A trophy gathers dust, but the knowledge you gain compounds over time. The frameworks you master, the patterns you learn, and the networks you build continue to provide value long after the hackathon ends.

Conclusion

Next time you register for a hackathon, reframe your expectations. Don't ask "What can I win?" Ask "What can I learn?" The rewards will follow naturally, but the learning will stay with you forever. Whether you're a beginner looking to build confidence or an experienced developer wanting to stretch your skills, approaching hackathons as learning opportunities will make you a better developer and a more fulfilled participant.

Remember: the real prize is becoming the developer you want to be.

Does Every Country Need Their Own AI?

Sumit Mishra — Tue, 29 Sep 2026 06:04:45 +0000

Artificial intelligence is rapidly transforming industries, economies, and societies worldwide. As AI capabilities advance, many nations are investing heavily in developing their own AI technologies. But does every country truly need to build their own AI systems, or is global collaboration a more practical approach?

The Case for National AI Development

Sovereignty and Security

Countries argue that having domestic AI capabilities is crucial for national security and technological sovereignty. Relying on foreign AI systems could create vulnerabilities, especially for critical infrastructure, defense, and sensitive data processing.

Economic Competitiveness

AI has become a key driver of economic growth. Countries with advanced AI capabilities can create high-value jobs, attract investment, and maintain competitive advantages in global markets.

Cultural Relevance

AI systems trained on local data and cultural contexts may better serve a country's specific needs, preferences, and values. This is particularly important for applications in education, healthcare, and public services.

The Challenges of Building National AI

Resource Constraints

Developing cutting-edge AI requires enormous resources: computational power, talented researchers, and sustained funding. Many countries simply cannot afford the billions of dollars needed to compete with tech giants or major economies.

Talent Shortages

There's a global shortage of AI experts. Countries without strong technical education systems or attractive research environments struggle to develop and retain AI talent.

Duplication of Effort

When every country builds similar AI systems independently, it leads to duplication of effort and wasted resources. The same problems get solved multiple times instead of being addressed collaboratively.

A Middle Path: Strategic Autonomy

Rather than building everything from scratch, countries could pursue a hybrid approach:

Core Competencies: Focus AI development on areas critical to national interests
Strategic Partnerships: Collaborate with other nations on shared challenges
Open Source Participation: Contribute to and leverage global open-source AI initiatives
Adaptation Over Creation: Customize existing AI models for local needs rather than building from scratch

The Role of Global Collaboration

Many of humanity's greatest challenges—climate change, pandemics, poverty—require global solutions. AI developed collaboratively across borders could:

Pool resources and expertise
Ensure more diverse training data
Create standards and best practices
Reduce redundant research efforts

Conclusion

Not every country needs to build AI from the ground up. Instead, nations should assess their unique circumstances and pursue strategies that balance autonomy with collaboration. Smaller countries might benefit more from partnerships and adaptation, while larger economies with strong research ecosystems may justify broader AI development programs.

The goal shouldn't be AI sovereignty for its own sake, but rather ensuring that all countries can benefit from AI's transformative potential while maintaining control over critical applications. The future of AI should be both globally connected and locally relevant.

What's your perspective? Should AI development be a global commons or a national priority? Share your thoughts in the comments below.

dub_movie: Building an AI-Powered Movie Dubbing Pipeline with Python

Sumit Mishra — Sun, 27 Sep 2026 03:23:49 +0000

You can explore the source code and experiment with the pipeline here:

GitHub — Sumit884-byte/dub_movie
What if you could take a Japanese movie or anime, translate its dialogue into Hindi, generate new speech automatically, preserve the background audio, and produce a finished dubbed video—all from a Python pipeline?

That is the idea behind dub_movie, an automated movie-dubbing project built around Python, Whisper, Edge TTS, translation backends, audio analysis, and FFmpeg.

The project is particularly designed for anime-style content with named characters and subtitle files, while also providing tools for processing longer videos in resumable stages.

What is dub_movie?

dub_movie takes a source video and subtitles and turns them into a dubbed version in another language.

The basic workflow looks like this:

Japanese Movie / Anime
        │
        ▼
   Subtitle / Audio
        │
        ▼
 Speech Detection
    (Whisper)
        │
        ▼
 Speaker Identification
        │
        ▼
 Voice / Pitch Analysis
        │
        ▼
   Translation
        │
        ▼
    Edge TTS
        │
        ▼
 Background Audio
   + Dubbed Speech
        │
        ▼
   Final MP4 Video

The repository describes its primary use case as Japanese source video plus SRT subtitles, producing translated speech with Edge TTS while matching character pitch and mixing the generated dialogue over a vocal-reduced background.

Why movie dubbing is harder than translation

At first glance, dubbing sounds simple:

Speech → Translation → Text-to-Speech

But real video dubbing has several additional problems.

The translated sentence needs to appear at the correct timestamp. The generated speech needs to fit inside the original dialogue duration. Different characters should sound different. Background music and sound effects should remain audible.

This means a useful dubbing system needs to solve several problems simultaneously:

Speech detection
Subtitle alignment
Speaker identification
Translation
Voice generation
Pitch analysis
Audio separation
Timeline synchronization
Video rendering

The dub_movie project approaches these as separate pipeline stages instead of treating dubbing as one giant operation.

The technology stack

The project is primarily Python-based and requires Python 3.10+ and FFmpeg. GPU acceleration is optional; Whisper can run on CPU, while local NLLB translation can benefit from CUDA.

Technology	Role
Python	Main application and orchestration
Faster-Whisper	Speech recognition and timing
Edge TTS	Text-to-speech generation
MoviePy	Video/audio processing
Librosa	Pitch/F0 analysis
NumPy	Numerical audio processing
FFmpeg	Media extraction and rendering
Deep Translator	Google translation backend
Transformers + NLLB	Optional local translation
Demucs	Optional higher-quality vocal separation
vLLM	Optional speaker identification

The core installation includes edge-tts, moviepy, numpy, librosa, httpx, deep-translator, and faster-whisper.

1. Whisper handles speech timing

One of the important components is Faster-Whisper.

Instead of simply translating the subtitles, the project can analyze the actual speech in the video and use Whisper to determine when dialogue occurs.

The recommended dub_movie_whisper.py pipeline combines Whisper speech detection with SRT alignment, making it possible to adjust subtitle timing around the actual spoken dialogue.

For example:

python dub_movie_whisper.py \
  --input movie.mp4 \
  --srt movie.srt \
  --output movie_dubbed_1min.mp4 \
  --duration 60 \
  --language hi

Here, hi represents Hindi.

The system also supports different Whisper model sizes such as:

tiny
base
small
medium

This creates a practical trade-off between processing speed and recognition quality.

2. Character-aware translation

A normal translation system might translate every sentence independently.

That can be a problem in anime or movies.

Characters have different personalities, relationships, speech patterns, and tones. A sentence that sounds natural for one character might sound completely wrong for another.

The repository therefore includes character_context.py, which is responsible for cast profiles, tone detection, contextual translation, and TTS voice mapping.

This is an important idea:

Movie dubbing is not just language translation. It is contextual translation.

For example, a character profile can help distinguish between:

"Come here."

spoken by:

a child
a villain
a teacher
a comic character
an elderly character

The literal translation may be similar, but the delivery should not be.

3. Speaker identification

The project can optionally use an OpenAI-compatible vLLM endpoint to identify which character is speaking each subtitle line.

The relevant configuration includes:

VLLM_BASE_URL
VLLM_MODEL
VLLM_API_KEY
VLLM_SPEAKER_BATCH
VLLM_TIMEOUT

The speaker-identification module is implemented in speaker_id_vllm.py.

This becomes especially useful when a subtitle file contains dialogue from multiple characters but doesn't reliably identify the speaker.

4. Pitch matching

One of the more interesting parts of the project is its voice analysis stage.

The system uses Librosa to estimate the fundamental frequency, or F0, of speech segments.

That information can then influence the Edge TTS rate and pitch settings.

The goal isn't necessarily to clone someone's exact voice. Instead, the system tries to make generated speech better match the characteristics of the original speaker.

The pipeline describes this as:

Original dialogue
       ↓
   F0 analysis
       ↓
Character voice profile
       ↓
Edge TTS rate/pitch
       ↓
Generated dialogue

This is a clever middle ground between basic text-to-speech and full voice cloning.

5. Preserving background music

Simply removing the original audio and replacing it with generated speech would destroy the movie's atmosphere.

Background music, ambience, and sound effects are a huge part of the viewing experience.

The project therefore creates a vocal-reduced background bed.

Its pipeline can use channel routing and optionally Demucs for higher-quality vocal separation.

The result is approximately:

Original Video
      │
      ├── Dialogue ──X
      │
      └── Background ─────┐
                          │
Generated Hindi Speech ──┤
                          ▼
                    Final Audio

The final audio is then combined with the original video.

6. Multiple translation backends

Another useful feature is that translation isn't hardcoded to a single provider.

The project supports several translation modes, including:

auto
parallel
minimax
cloud
google

The auto mode can use multiple backends in parallel, while Google translation is available through deep-translator.

There is also an offline NLLB option using Transformers:

facebook/nllb-200-distilled-600M

The device can be configured for CPU or CUDA.

That makes the architecture more flexible:

             Translation
                  │
       ┌──────────┼──────────┐
       ▼          ▼          ▼
     Google    Cloud/LLM    NLLB

Developers can choose between convenience, speed, cost, and local processing.

7. Long-running jobs can resume

Movie dubbing is computationally expensive.

If you're processing a two-hour movie and the process crashes near the end, restarting everything from zero would be painful.

dub_movie addresses this with state files and intermediate caches.

The pipeline records stages such as:

start
↓
whisper_audio_ready
↓
whisper_done
↓
aligned
↓
speakers_vllm
↓
voice_analyzed
↓
translating
↓
translated
↓
background_ready
↓
synthesizing
↓
synthesized
↓
rendering
↓
done

The project stores files such as:

*.state.json
translated_segments_*.json
*.voice.json
*.speakers.json
temp_chunks_*/
*.background.wav

These artifacts allow completed work to be reused during subsequent runs.

For a long movie, this is not a cosmetic feature. It's the difference between a usable pipeline and a frustrating one.

Different ways to run the project

The repository provides several entry points depending on the task.

Quick experiment

For a one-minute test:

python dub_movie_whisper.py \
  --input movie.mp4 \
  --srt movie.srt \
  --output movie_dubbed_1min.mp4 \
  --duration 60 \
  --language hi

Subtitle-timing workflow

If the SRT timestamps are already correct:

python dub_movie_whisper.py \
  --srt-timing-only \
  --duration 60 \
  --language hi

Standard SRT pipeline

python dub_movie.py \
  --input movie.mp4 \
  --srt movie.srt \
  --output movie_dubbed.mp4 \
  --language hi \
  --duration 300

The repository also includes preset scripts for 1-minute, 5-minute, 10-minute, clip, and full-movie processing.

Use cases

This type of technology has applications beyond simply watching anime in another language.

1. Anime localization

Japanese anime can be converted into languages such as Hindi, English, Spanish, and others.

2. YouTube localization

Creators can produce versions of videos for different language audiences without recording every language manually.

3. Educational content

Courses and tutorials can potentially be converted into regional languages.

4. Film experimentation

Independent filmmakers can experiment with alternate-language versions of their work.

5. Accessibility

Automatically generated speech can help make video content accessible to audiences who don't understand the original language.

6. AI research

The project is also a useful playground for experimenting with:

ASR
machine translation
TTS
speaker identification
audio separation
speech timing
multimodal pipelines

The interesting engineering idea

The biggest takeaway from dub_movie isn't any individual AI model.

It's the pipeline architecture.

Instead of asking one model to "dub this movie," the project breaks the problem into specialized stages:

                VIDEO
                  │
                  ▼
             Audio Prep
                  │
        ┌─────────┴─────────┐
        ▼                   ▼
     Whisper             SRT
        │                   │
        └─────────┬─────────┘
                  ▼
             Alignment
                  │
                  ▼
           Speaker Mapping
                  │
                  ▼
            Voice Analysis
                  │
                  ▼
             Translation
                  │
                  ▼
               TTS
                  │
                  ▼
          Audio Composition
                  │
                  ▼
             FFmpeg
                  │
                  ▼
             FINAL VIDEO

Each stage can be improved independently.

Want better transcription? Change the ASR model.

Want better translation? Change the translation backend.

Want better voice quality? Replace the TTS engine.

Want better vocal separation? Use Demucs.

That modularity is what makes this kind of project interesting from an engineering perspective.

What could be improved?

The current architecture also reveals several areas for future development.

Better voice cloning

The project currently focuses on pitch/rate matching with Edge TTS rather than full speaker voice cloning.

A future version could integrate modern voice-cloning models to produce more character-specific voices.

Better lip synchronization

The current pipeline focuses primarily on audio timing. A more advanced system could modify facial animation or lip movements to match translated speech.

More robust translation

Context-aware translation is already part of the architecture, but dialogue-heavy content could benefit from larger contextual windows covering entire scenes.

Better automatic speaker detection

Speaker identification could potentially combine audio diarization with subtitle context and LLM reasoning.

GPU optimization

Long movies involve thousands of speech segments. More aggressive batching, GPU inference, and caching could significantly reduce processing time.

Who should use this project?

dub_movie is particularly interesting for developers who want to learn how several AI technologies can be connected into a single real-world media pipeline.

It isn't just a chatbot project.

It combines:

Speech Recognition + Translation + LLMs + Text-to-Speech + Signal Processing + Audio Separation + Video Processing.

That's what makes it a useful engineering project.

Final thoughts

AI dubbing is moving from a theoretical idea toward an increasingly practical media-processing workflow.

The dub_movie project demonstrates one way to build that workflow using open development tools and interchangeable components.

Its most interesting feature isn't simply generating Hindi speech. The real engineering challenge is coordinating timing, translation, characters, pitch, background audio, caching, and final video rendering into one repeatable pipeline.

For developers interested in AI-powered media applications, this project provides a practical example of how multiple specialized technologies can be assembled into a complete application.

Note: The repository is intended for processing video that you have the rights to use. Copyright and voice/likeness rights can apply to both source movies and generated dubbing.

When Judge Bias Matters More Than Eligibility: The Hidden Problem With Modern Hackathons

Sumit Mishra — Fri, 25 Sep 2026 07:55:06 +0000

Hackathons are supposed to reward creativity, technical ability, problem-solving, and execution.

At least, that is what the eligibility criteria and judging rubrics usually tell us.

But there is an uncomfortable reality in many hackathons: getting eligible to compete can be far easier than building something that judges actually like.

A team may satisfy every eligibility requirement, build a technically impressive project, submit everything on time, and still lose because the final decision depends heavily on how a small group of judges interprets the project.

This creates an interesting question:

If judges' subjective preferences can influence the outcome more than the formal eligibility requirements, what exactly are hackathons measuring?

Eligibility Is Objective. Judging Often Isn't.

Eligibility criteria are generally straightforward.

You might need to:

Be within a particular age group.
Register before a deadline.
Have a specific team size.
Use a particular technology.
Submit your project through a specified platform.
Follow intellectual-property or participation rules.

These conditions are usually binary.

You either qualify or you don't.

Judging is different.

A rubric might say:

Criterion	Possible interpretation
Innovation	Is the idea genuinely novel?
Impact	How many people could benefit?
Technical implementation	How technically sophisticated is it?
User experience	Is it easy to use?
Presentation	How clearly was the idea communicated?
Feasibility	Could it realistically become a product?

The problem isn't that these criteria are subjective.

Some degree of subjective evaluation is unavoidable.

The problem appears when the interpretation of these criteria becomes more influential than the criteria themselves.

Two judges can look at exactly the same project and reach completely different conclusions.

One judge might see a technically sophisticated solution.

Another might see unnecessary complexity.

One might see an ambitious idea.

Another might see an unrealistic product.

One might value a working prototype.

Another might care more about market potential.

Neither necessarily has to be acting unfairly.

They may simply be applying different mental models.

The "Judge Fit" Problem

This creates something I would call judge fit.

Judge fit is the extent to which a project naturally matches the preferences, professional background, expectations, and mental model of the judges evaluating it.

Imagine two teams.

Team A builds an extremely sophisticated developer tool.

Team B builds a visually impressive consumer application.

If the judging panel consists largely of people from enterprise software backgrounds, Team A may receive more appreciation for its technical architecture.

If the panel consists largely of product and design professionals, Team B may receive more attention for usability and presentation.

The rules haven't changed.

The projects haven't changed.

The evaluators have changed.

And therefore, potentially, the outcome changes.

That is where concerns about bias become important.

Bias Doesn't Always Mean Malicious Intent

The word "bias" often creates the impression that someone deliberately wants to disadvantage a participant.

That isn't necessarily what happens.

Human judgment naturally contains cognitive biases.

A judge may unconsciously prefer:

Technologies they already understand.
Problems they personally care about.
Products resembling companies they have worked with.
Familiar business models.
Certain presentation styles.
Teams that communicate in a way the judge finds persuasive.
Projects that demonstrate concepts the judge already considers valuable.

There can also be anchoring.

If the first project a judge sees establishes a particular standard, later projects may be subconsciously compared against it.

There can be halo effects.

A polished presentation can make the underlying project appear stronger.

There can be authority effects.

A confident speaker may appear more technically competent than someone who is equally capable but less experienced at pitching.

None of these necessarily involve bad intentions.

They are simply consequences of human decision-making.

The Presentation Paradox

Hackathons frequently advertise themselves as technical competitions.

Yet presentation can become disproportionately important.

Consider two projects.

Project A

Excellent backend architecture.
Difficult technical problem.
Strong algorithmic implementation.
Functional prototype.
Average presentation.

Project B

Simpler technical implementation.
Beautiful interface.
Excellent demo.
Strong storytelling.
Highly polished pitch.

If judges heavily reward the second project's presentation quality, the competition has effectively become partly a pitch competition.

That isn't automatically wrong.

Communication is a legitimate engineering skill.

But participants should know that this is what they're being evaluated on.

The distinction matters because a participant optimizing for the written judging criteria may make very different decisions from someone optimizing for perceived judge preferences.

The Hidden Rubric

This is perhaps the biggest problem.

A hackathon may publish:

Innovation — 25%
Technical Implementation — 25%
Impact — 25%
Presentation — 25%

But participants rarely know exactly how judges translate those categories into scores.

What does "innovation" mean?

Is a new technical architecture more innovative than applying an existing technology to an underserved problem?

Does impact mean:

Number of potential users?
Revenue?
Social benefit?
Environmental benefit?
Technical significance?

And what does "technical implementation" actually measure?

Lines of code?

System architecture?

Difficulty?

Reliability?

Use of advanced technology?

A project can therefore satisfy the written rubric while still failing to match the unwritten mental rubric used by individual judges.

That creates uncertainty for participants.

Why This Matters More Than Eligibility

Eligibility determines whether you can enter.

Judging determines whether you win.

That distinction sounds obvious, but it has major consequences.

A participant might spend days carefully checking whether their project satisfies every eligibility requirement.

But once the project enters the judging phase, many additional variables can suddenly matter:

How memorable was the demo?

Did the judge understand the problem immediately?

Did the technology impress them?

Did they personally believe the idea mattered?

Did the team appear credible?

Did the project fit the judge's expectations?

These factors may not appear anywhere near the eligibility section.

Yet they can influence the final result substantially.

The Problem With "Best Project"

Another issue is the phrase "best project."

There is rarely one objectively best hackathon project.

There are projects that are:

More technically complex.
More commercially viable.
More innovative.
Easier to use.
More scalable.
More socially useful.
Better presented.
More complete.

These dimensions can conflict.

A technically groundbreaking project may have poor usability.

A commercially viable project may use relatively ordinary technology.

A socially valuable project may have limited scalability.

A beautiful prototype may have weak engineering underneath.

So the judging system has to decide which trade-offs matter.

That decision is inherently normative.

How Hackathons Can Reduce Judge Bias

The solution isn't to eliminate human judges.

Human expertise is valuable.

Instead, hackathons can make judging more structured.

1. Use detailed scoring definitions

Instead of simply saying:

Innovation — 20 points

Define what different scores mean.

For example:

0–5: Mostly existing implementation with limited differentiation
6–10: Meaningful adaptation or combination of existing approaches
11–15: Significant novel approach
16–20: Demonstrates substantial originality with clear differentiation

The exact scale can vary, but judges should have a common framework.

2. Require independent scoring

Judges should score projects independently before discussing them collectively.

Otherwise, the first confident opinion in the room can influence everyone else.

3. Use multiple judges

A single judge's preferences can have enormous influence.

Multiple independent evaluations can reduce the impact of one person's subjective preferences.

4. Separate categories

A hackathon could award separate recognition for:

Best technical implementation
Best UX
Most innovative concept
Best social impact
Best commercial potential

This acknowledges that excellence can exist in different forms.

5. Publish the rubric before the competition

Participants should know what will actually be measured.

The more predictable the evaluation process, the less participants need to guess what judges personally want.

6. Provide score breakdowns

Even a basic post-event scorecard can help.

For example:

Category	Score
Innovation	17/20
Technical implementation	18/20
Impact	14/20
UX	16/20
Presentation	15/20
Total	80/100

This doesn't eliminate disagreement.

But it makes the process more transparent.

Participants Also Adapt

There is another uncomfortable side to this issue.

Participants are rational.

If they discover that judges consistently reward polished demos, they will optimize for polished demos.

If judges reward AI usage, teams will add AI.

If judges reward social-impact narratives, teams will frame their projects around social impact.

If judges reward technical complexity, teams will make their architectures more complicated.

Eventually, participants aren't necessarily building the best solution to the problem.

They're building the solution they believe the judging system will reward.

That is a natural response to incentives.

And when the official rubric and perceived judge preferences differ, participants may optimize for the latter.

The Real Question

The debate shouldn't be:

"Are judges biased?"

Human beings inevitably bring perspectives and preferences into evaluation.

A more useful question is:

How much influence should individual preferences have over an outcome that is presented as a structured competition?

A good hackathon doesn't need perfectly objective judging.

That's probably impossible.

It needs transparent judging.

Participants should understand:

What is being evaluated.
How it is being scored.
Who is evaluating it.
How disagreements are handled.
How subjective criteria are interpreted.
How the final decision is produced.

Because there is an important difference between subjective judgment and unpredictable judgment.

Subjective judgment can be legitimate.

Unpredictable judgment is much harder for participants to prepare for.

Hackathons Are Incentive Systems

Ultimately, a hackathon is more than an event.

It is an incentive system.

Whatever judges consistently reward, participants will eventually learn to produce.

If the system rewards engineering depth, participants will invest in engineering.

If it rewards presentation, participants will invest in presentation.

If it rewards novelty, participants will chase novelty.

If it rewards whatever happens to impress a particular judging panel, participants will learn to optimize for judges.

And that may be the biggest lesson.

The published rules tell participants what the organizers say they value. The judging process tells participants what the competition actually rewards.

The closer those two things are, the more trustworthy the competition becomes.

Eligibility tells you whether you are allowed into the room.

Judging determines what happens once you're inside it.

And when the second is significantly less transparent than the first, participants have every reason to ask whether they are competing against the published criteria—or against the preferences of the people holding the scorecards.

That is a conversation hackathon organizers should take seriously.

Why You Should Go Anti-Trend Without Going Anti-Social Media

Sumit Mishra — Thu, 24 Sep 2026 11:06:55 +0000

I use social media.

You probably do too.

And that's exactly why I think we should talk about the copy effect.

This isn't an argument against LinkedIn, Instagram, YouTube, X, TikTok, or social media itself. These platforms are useful. They help us discover ideas, learn from people, find opportunities, build communities, and share what we're working on.

But there is a side effect that is becoming increasingly obvious:

The more ideas we see, the easier it becomes to reproduce them.

And sometimes, we don't even realize we're doing it.

We Don't Just Follow Trends. We Start Repeating Them

You see an interesting idea online.

Someone else builds on it.

Then another person creates a similar version.

Soon, the same underlying concept appears everywhere.

The names are different.

The branding is different.

The wording is different.

But the actual idea hasn't changed much.

Nobody necessarily thinks they're copying.

That's what makes the copy effect interesting.

When we consume enormous amounts of content, other people's ideas inevitably become part of our own thinking.

That's normal.

The problem starts when influence becomes replication.

Inspiration Is Not the Same as Copying

There is nothing wrong with learning from existing work.

In fact, almost everything we build is influenced by something that existed before it.

The important question is:

What did you add?

If you see someone's idea and it leads you to a completely different solution, that's inspiration.

If you study an existing product and build an alternative with a different architecture, philosophy, user experience, or target audience, that's not simply copying.

A great example is open-source alternatives.

Someone builds a popular piece of software.

Another developer thinks:

“I like what this solves, but I want a different approach.”

They build an open-source alternative.

Perhaps it has a different architecture.

Perhaps it is self-hosted.

Perhaps the license is different.

Perhaps it prioritizes privacy.

Perhaps it targets a different type of user.

Perhaps it removes features and focuses on simplicity.

Perhaps it solves the same problem using a completely different technical approach.

That's valuable.

You're not necessarily copying the creator.

You're competing with or extending an existing category of solutions.

And that's an important distinction.

You Can Build the Same Category Without Building the Same Thing

This distinction is especially important in technology.

You don't have to invent an entirely new category to be original.

We don't need one email client.

We don't need one database.

We don't need one programming language.

We don't need one operating system.

We don't need one note-taking application.

Multiple projects can solve the same fundamental problem.

What matters is how they solve it and what they contribute.

An open-source alternative can exist precisely because someone disagrees with the assumptions of the existing solution.

Maybe the original prioritizes convenience.

The alternative prioritizes control.

Maybe one is cloud-first.

The other is self-hosted.

Maybe one is designed for enterprises.

The other is designed for individuals.

Maybe one optimizes for features.

The other optimizes for simplicity.

Same problem.

Different thinking.

That's healthy competition.

The Problem Is Exact Concept Copying

The line becomes much clearer when you remove the branding.

Ask:

If I removed the logo and changed the name, would the underlying concept still look almost identical?

If the answer is yes, changing the surface probably isn't enough.

You might have changed the colors, interface, wording, or company name while keeping essentially the same idea.

That's where the copy effect becomes problematic.

It's easy to make something look different.

It's much harder to make it think differently.

Social Media Makes This Harder

Social media accelerates this process because successful ideas are publicly visible.

A post gets attention.

People can immediately see what worked.

A product becomes popular.

Thousands of people can study it.

A creator discovers a successful format.

Everyone can reproduce the format.

This creates a feedback loop:

Success → visibility → imitation → more visibility → more imitation.

Again, that isn't necessarily bad.

Ideas spreading is one of the best things about the internet.

The problem is when the easiest thing to spread becomes the exact same idea.

Don't Become Anti-Social Media. Become Anti-Autopilot.

I don't want to stop using social media.

I want to use it better.

There's an enormous difference.

Social media can be a source of:

inspiration
knowledge
opportunities
feedback
collaboration
competition
discovery

But it shouldn't become a machine that tells us what to think.

Use it to discover.

Then step away and think.

See what everyone is building.

Then ask what everyone is missing.

Read someone's idea.

Then challenge it.

Study a successful product.

Then ask what you would change.

That's where the interesting stuff starts.

Don't Copy the Answer. Explore the Problem.

This is probably the simplest rule I've found.

If someone solves a problem in an interesting way, don't immediately copy their solution.

Study the problem.

Ask why it exists.

Ask whether there are other users experiencing it.

Ask whether the assumptions behind the original solution are correct.

Ask whether there is a simpler approach.

Ask whether the same idea could work somewhere completely different.

The original solution becomes your starting point rather than your destination.

Being Anti-Trend Doesn't Mean Being Different for the Sake of It

If something is popular and genuinely useful, use it.

If an existing product solves your problem, use it.

If a popular technology makes your work better, learn it.

If someone has already built something great, learn from them.

You don't get originality points for unnecessarily reinventing everything.

The goal isn't:

“I must never do what anyone else is doing.”

The goal is:

“I understand what others are doing, and I can decide what I want to do with that knowledge.”

That's a much healthier definition of independence.

The Real Question

We live in a world where almost anything successful can be copied extremely quickly.

So maybe originality isn't about having an idea nobody has ever seen before.

Maybe it's about contributing something that couldn't have existed without your own thinking.

Take inspiration.

Build alternatives.

Fork projects.

Study competitors.

Learn from creators.

Use social media.

Follow trends.

But don't stop at imitation.

Because there's a difference between building another version of an existing idea and building an alternative that has a reason to exist.

And perhaps the simplest anti-trend mindset is this:

Don't ask, “How can I do what they're doing?”

Ask, “What do I think they got right, what did they miss, and what can I build differently?”

That's not going against the internet.

That's using it without letting it do all your thinking for you.

Why an Internal Compass Is More Important Than You Think in the Age of AI

Sumit Mishra — Wed, 23 Sep 2026 01:42:06 +0000

Technology has made it easier than ever to know what to do next.

AI can write your emails.

Search engines can answer your questions.

Recommendation algorithms can tell you what to watch.

Navigation apps can tell you where to go.

Productivity tools can tell you what to work on.

And now, AI assistants can increasingly help us make decisions.

We have more guidance than any generation before us.

Yet somehow, many people feel more lost.

That sounds like a technology problem.

It isn't.

It is often a direction problem.

We have built incredibly powerful systems for answering "How do I get there?"

But we haven't built equally strong systems for answering:

"Where should I go in the first place?"

That's where your internal compass becomes critical.

Technology Gives You Navigation. It Doesn't Give You Direction.

Think about GPS.

You tell it where you want to go, and it calculates a route.

But GPS doesn't decide your destination.

If you accidentally enter the wrong destination, it can give you a perfect route to the wrong place.

Modern technology works similarly.

AI can help you:

Build a business
Learn programming
Create content
Analyze data
Automate workflows
Write code
Research markets
Improve productivity

But AI doesn't automatically know which of those things actually matter to you.

That's your job.

Technology is becoming better at execution.

Humans still need to provide direction.

The New Bottleneck Isn't Information

For decades, access to information was a major advantage.

Today, information is cheap.

You can learn Python from thousands of tutorials.

You can ask AI to explain quantum computing.

You can find business ideas within seconds.

You can generate a website without knowing much HTML.

You can have an AI summarize a 300-page book.

The problem has shifted.

We are moving from:

"I don't know enough."

to:

"I don't know what deserves my attention."

That's a completely different problem.

When information becomes nearly unlimited, attention becomes the scarce resource.

And your internal compass determines where you spend it.

Algorithms Know Your Behavior. They Don't Necessarily Know Your Values.

This is one of the most important distinctions of the digital age.

Recommendation systems are extremely good at predicting what you're likely to click.

They can learn:

What you watch
What you search
What you buy
What you pause on
What you skip
What keeps you engaged

But predicting your behavior isn't the same as understanding your values.

An algorithm might know that you always click productivity videos.

It doesn't necessarily know that you're exhausted and actually need rest.

It might know that luxury cars hold your attention.

It doesn't know whether owning one is genuinely important to you.

It might recommend the career content everyone is consuming.

It doesn't know whether that career fits the life you want.

Engagement is not the same thing as meaning.

Your Internal Compass Is Your Human Decision Layer

Think of yourself as a technology stack.

At the bottom, you have infrastructure:

Body → Energy → Environment

Then capabilities:

Skills → Knowledge → Experience

Then tools:

Apps → AI → Automation → Software

But above all of them, you need a decision layer:

Values → Principles → Goals → Direction

Without that layer, having more powerful tools doesn't necessarily make your life better.

It can simply make you faster at doing things you shouldn't be doing.

That's a dangerous form of optimization.

Imagine this:

You automate a task that shouldn't exist.

You optimize a workflow that doesn't matter.

You scale a business you don't enjoy.

You become extremely productive at pursuing somebody else's definition of success.

Technology can help you execute all of this incredibly efficiently.

Your internal compass has to ask:

"Wait. Should I be doing this at all?"

AI Makes This Even More Important

AI changes the equation because it dramatically reduces the cost of execution.

Previously, having an idea wasn't enough.

You needed technical skills.

You needed designers.

You needed writers.

You needed analysts.

You needed developers.

You needed entire teams.

AI is gradually reducing some of those barriers.

That creates an interesting problem.

When execution becomes cheaper, choosing the right problem becomes more valuable.

If everyone can build faster, the question becomes:

What is actually worth building?

If everyone can create content faster:

What is actually worth saying?

If everyone can learn faster:

What is actually worth learning?

If everyone can automate their work:

What work is actually worth doing?

The advantage shifts from simply doing things to choosing things worth doing.

Your Compass Protects You From Shiny Object Syndrome

Technology creates an endless supply of shiny objects.

New programming language.

New AI model.

New framework.

New startup.

New productivity app.

New cryptocurrency.

New automation tool.

New social platform.

New business model.

New certification.

New trend.

You can spend your entire life learning tools without building anything meaningful.

That's where a compass becomes useful.

Instead of asking:

"Is this technology exciting?"

Ask:

"Does this move me toward something I actually care about?"

That question can save you enormous amounts of time.

The Developer Analogy

Think of your life like software.

Your values are the requirements.

Your goals are the architecture.

Your habits are the implementation.

Your tools are the dependencies.

Your decisions are the runtime behavior.

And your internal compass is the system that keeps everything aligned.

Without clear requirements, developers can build technically impressive software that solves the wrong problem.

The same thing happens in life.

You can have an impressive resume, a sophisticated tech stack, a huge audience, and an optimized calendar—and still be solving the wrong problem.

Don't Let AI Become Your Compass

AI can be an incredible thinking partner.

It can challenge assumptions.

It can generate possibilities.

It can explain complex concepts.

It can help you compare options.

It can expose blind spots.

But there is a line worth protecting.

Let AI expand your thinking. Don't outsource your values to it.

Ask AI:

"What are the trade-offs?"

"What am I missing?"

"Give me five possible approaches."

"Challenge my assumptions."

But ultimately, you need to answer:

"Which one aligns with the life I want?"

That's not a computational question.

It's a human one.

Build Your Own "Decision API"

If you work in tech, here's a useful mental model.

Imagine you had an internal API that every major decision had to call.

decision = evaluate(
    values,
    goals,
    constraints,
    long_term_effect,
    opportunity_cost
)

Before accepting a job:

Does it align?

Before learning another technology:

Does it serve my goals?

Before launching another project:

Does it solve a meaningful problem?

Before saying yes to another meeting:

Is this actually worth my attention?

Before following another trend:

Do I need this—or am I afraid of being left behind?

The quality of your life is heavily influenced by the quality of these decisions.

Your Compass Should Be Stable, Your Tools Shouldn't

Your technology stack should change.

Your tools should change.

Your programming languages can change.

Your career can evolve.

AI models will come and go.

Frameworks will become obsolete.

But some deeper principles can remain relatively stable.

For example:

I value learning.

I want autonomy.

I care about building useful things.

I want financial security.

I value relationships.

I don't want my entire life controlled by work.

These principles can survive multiple technology cycles.

That's powerful.

Because technology changes exponentially.

Your fundamental values don't have to.

The Future Belongs to People Who Can Combine Both

The goal isn't to reject technology.

Quite the opposite.

Use it aggressively.

Automate repetitive work.

Use AI as a thinking partner.

Learn powerful tools.

Build faster.

Experiment.

Create.

But maintain something technology cannot replace:

a sense of direction.

The most valuable person in an AI-powered world may not be the person who knows the most commands, tools, or frameworks.

It may be the person who can look at a sea of possibilities and say:

"This is what matters. This is what doesn't. And this is why."

Technology gives you leverage.

AI gives you acceleration.

Data gives you information.

Algorithms give you recommendations.

But your internal compass tells you where all that power should go.

And the more powerful technology becomes, the more important that compass becomes.

Because if you don't decide where you're going, something else eventually will.

Hardware: The Physical Summary of Software

Sumit Mishra — Tue, 22 Sep 2026 05:53:57 +0000

If you understand the hardware your software is going to run on, you can build software that is dramatically better.

A programmer can write software without knowing much about the machine underneath it. Modern programming languages, operating systems, frameworks, runtimes, and cloud platforms make this possible.

You can write Python without knowing how CPU registers work.

You can build a web application without knowing how RAM is physically organized.

You can train a machine-learning model without designing a GPU.

That abstraction is extremely useful.

But abstraction does not eliminate the hardware.

At the end of the day, every program becomes instructions that must be executed by physical machines.

And once you understand those machines, something interesting happens:

You stop writing software that merely works.

You start writing software that works with the hardware.

That difference can mean lower latency, lower memory usage, higher throughput, lower power consumption, and sometimes dramatically lower infrastructure costs.

Hardware Is the Physical Foundation of Software

Software is often treated as something independent from hardware.

It isn't.

Every application eventually depends on physical components such as:

CPU
RAM
CPU cache
storage
GPU or other accelerators
network interface
motherboard and buses
power system
thermal limits

A simplified view looks like this:

Your Code
    ↓
Compiler / Interpreter / Runtime
    ↓
Operating System
    ↓
Machine Instructions
    ↓
CPU / GPU / Accelerator
    ↓
Cache + RAM
    ↓
Storage + Network + I/O
    ↓
Physical Computation

The higher-level your abstraction, the easier it becomes to ignore what is happening underneath.

That's usually a good thing.

You don't want to manually manage every CPU instruction while building a web application.

But abstraction has a cost: it can hide the reason why software becomes slow, expensive, or inefficient.

Example 1: Same Algorithm, Different Hardware

Imagine you need to process 100 million numbers.

You write an algorithm that loops through them and performs calculations.

On a modern desktop CPU, the program might finish reasonably quickly.

Now imagine running the exact same program on a tiny embedded processor with:

one CPU core
very little RAM
low clock speed
limited cache

The code hasn't changed.

The algorithm hasn't changed.

But the machine has.

Same Software
     │
     ├── Powerful CPU → Fast
     │
     ├── Weak CPU     → Slow
     │
     └── Tiny Device  → Potentially impossible

This is why software performance cannot always be understood by looking only at source code.

The machine matters.

CPU: Understanding the Workhorse

The CPU executes general-purpose instructions.

Modern CPUs contain multiple cores, caches, branch prediction mechanisms, SIMD/vector units, and other features designed to execute instructions efficiently.

Consider a video-processing application.

You might have a task like:

Process Frame 1
Process Frame 2
Process Frame 3
Process Frame 4
...
Process Frame 1000

If the frames can be processed independently, multiple CPU cores may allow work to happen concurrently.

             CPU
       ┌──────┼──────┐
       ↓      ↓      ↓
     Core 1 Core 2 Core 3 ...
       ↓      ↓      ↓
    Frame 1 Frame 2 Frame 3

Instead of forcing one core to perform everything sequentially, your software can potentially use parallelism.

However, simply having more cores does not automatically make software faster.

If your program spends most of its time waiting for:

network responses
disk I/O
locks
memory
another process

then adding CPU cores may provide little benefit.

This leads to an important engineering question:

What is actually limiting the program?

CPU?

Memory?

Storage?

Network?

Synchronization?

Knowing the hardware helps you ask that question.

RAM: Your Program's Working Space

RAM is where actively used data and program state are kept.

Imagine an application processing a 20 GB dataset.

If your machine has only 8 GB of available RAM, loading the entire dataset into memory isn't practical.

A naive approach might look like:

Load entire dataset
        ↓
Put everything into RAM
        ↓
Process it

A hardware-aware approach could instead use:

Storage
   ↓
Read a chunk
   ↓
Process chunk
   ↓
Discard / store result
   ↓
Read next chunk

This is called streaming or chunked processing.

The software isn't fighting the machine's memory limitation.

It is designing around it.

Cache: The Hidden Performance Layer

One of the most important hardware concepts for performance is cache.

CPU cache is much smaller than RAM but significantly faster.

A simplified hierarchy looks like:

CPU Registers
     ↓
L1 Cache
     ↓
L2 Cache
     ↓
L3 Cache
     ↓
RAM
     ↓
SSD
     ↓
Network / Remote Storage

As you move downward:

capacity generally increases
latency generally increases

This creates an important principle:

Where your data is can matter almost as much as what your program does with it.

Suppose you repeatedly access the same piece of data.

Keeping that data close to the CPU can be much more efficient than repeatedly fetching distant data.

This is one reason techniques such as:

caching
data locality
batching
sequential access
compact data structures

can improve performance.

Example 2: Database and RAM

Imagine you're building an online store.

You have:

10 million products

Your users frequently request:

Product ID
Price
Availability

If every request requires expensive disk or network access, your application may become slower under heavy traffic.

Instead, frequently accessed information can be cached.

User Request
     ↓
Application
     ↓
Cache
   ↙   ↘
Hit     Miss
 ↓       ↓
Return   Database
         ↓
       Cache

Now the hardware becomes part of your architectural thinking.

You start asking:

How much RAM is available?
How much data should be cached?
Is the cache local or remote?
How fast is the storage?
How many CPU cores are available?
How much network bandwidth exists?

Those questions influence the software architecture.

Storage: SSD vs HDD vs Network Storage

Storage is another major consideration.

Suppose your application needs to read millions of small files.

A traditional hard disk and a modern NVMe SSD have very different performance characteristics.

Now imagine the files aren't even local.

They are stored on a remote server.

Your access path becomes:

Application
     ↓
Network
     ↓
Remote Server
     ↓
Storage
     ↓
Data
     ↓
Network
     ↓
Application

Now network latency becomes part of the performance equation.

A software engineer who understands this might:

batch requests
cache data locally
reduce unnecessary reads
use sequential access where appropriate
compress data
move frequently accessed data closer to the application

The fastest request is often the request you never had to make.

GPU: A Different Kind of Computer

A GPU is not simply a "faster CPU."

It is designed around massive parallel computation.

Consider an image containing millions of pixels.

Suppose you need to apply the same mathematical operation to every pixel.

Conceptually:

Pixel 1 → Operation
Pixel 2 → Operation
Pixel 3 → Operation
Pixel 4 → Operation
...
Pixel 1,000,000 → Operation

This kind of workload can be highly parallel.

A GPU can process many operations simultaneously.

That's why GPUs are heavily used for workloads such as:

machine learning
graphics rendering
image processing
scientific simulation
matrix operations
certain video-processing workloads

But moving work to a GPU isn't automatically beneficial.

If the workload is tiny or requires constant communication between CPU and GPU, the overhead may eliminate the advantage.

So the real question isn't:

"Can I use the GPU?"

It's:

"Does this workload match the GPU's strengths?"

Example 3: AI Application

Imagine you're building an AI application that processes images.

Your pipeline might look like:

Camera
   ↓
CPU
   ↓
Preprocessing
   ↓
GPU
   ↓
Neural Network
   ↓
CPU
   ↓
Application

If the neural network performs billions of mathematical operations, GPU acceleration may make sense.

But suppose your application spends most of its time waiting for network requests:

Request
   ↓
Wait 300 ms
   ↓
Receive Data
   ↓
Small Computation

Buying a more powerful GPU wouldn't solve the main problem.

The bottleneck is the network.

This is why good optimization starts with measurement, not guessing.

Network: The Computer Isn't Always Next to You

Modern software increasingly depends on networks.

Your application may communicate with:

databases
APIs
cloud services
object storage
authentication services
other microservices
users around the world

Consider a web application that makes five sequential API calls:

Request
  ↓
API 1 → 100 ms
  ↓
API 2 → 100 ms
  ↓
API 3 → 100 ms
  ↓
API 4 → 100 ms
  ↓
API 5 → 100 ms

Even before considering computation, you've introduced significant waiting time.

A hardware- and systems-aware engineer might ask:

Can these requests happen concurrently?

Or:

Can I combine them into one request?

Or:

Can I cache the result?

Or:

Can some of this data be stored closer to the user?

The network becomes part of software design.

Power and Thermals Matter Too

Not every computer has unlimited electricity and cooling.

A desktop server in a data center has very different constraints from a smartphone.

A smartphone has:

limited battery
limited cooling
limited RAM
mobile CPU/GPU
thermal throttling

Imagine an application continuously performing expensive computation.

Initially:

High Performance
      ↓
Heat increases
      ↓
Temperature limit
      ↓
Thermal throttling
      ↓
Lower Performance

The software may need to adapt.

For example, a mobile application might:

reduce background computation
lower refresh rates when appropriate
avoid unnecessary polling
batch work
use hardware acceleration
perform expensive work only when necessary

The fastest possible computation isn't always the best computation.

Sometimes the most efficient computation is the one that consumes the least energy while meeting the requirement.

Embedded Systems: When Hardware Limitations Become Extreme

Consider a tiny microcontroller inside a sensor.

It might have:

very little RAM
limited flash storage
a low-power CPU
strict energy constraints

You can't casually deploy a massive application stack there.

Instead, software might need to be:

Small
 ↓
Predictable
 ↓
Memory-efficient
 ↓
Power-efficient
 ↓
Reliable

For example, a temperature sensor might only need to:

Read temperature
      ↓
Process value
      ↓
Transmit result
      ↓
Sleep

Keeping the processor asleep most of the time can significantly reduce energy consumption.

The software architecture is shaped directly by the hardware.

Hardware and Software Are a Feedback Loop

The relationship isn't one-directional.

Hardware enables software.

But software also creates demand for new hardware.

Hardware
   ↓
Enables Software
   ↓
Creates New Workloads
   ↓
Workloads Demand Better Hardware
   ↓
Better Hardware
   ↓
Enables More Advanced Software
   ↺

Consider artificial intelligence.

Large neural networks created enormous computational requirements.

GPUs and specialized accelerators made many of these workloads practical.

Those hardware improvements enabled larger models and more sophisticated applications.

Those applications then created demand for even more capable hardware.

The cycle continues.

The Most Important Concept: Bottlenecks

One of the biggest lessons from hardware-aware programming is understanding bottlenecks.

A bottleneck is the part of a system that limits overall performance.

Your application might look like this:

CPU      ██████████
RAM      ███
Storage  ██
Network  ██████████

If the network is the limiting factor, optimizing a tiny CPU calculation may barely change the user experience.

This is why blindly optimizing code can be a waste of time.

First determine:

Where is the time going?
        ↓
What resource is saturated?
        ↓
What is causing the bottleneck?
        ↓
Optimize that part
        ↓
Measure again

Measure → identify bottleneck → optimize → measure again.

That's much more reliable than guessing.

Hardware Changes the Meaning of "Fast"

"Fast" isn't a universal property of software.

A program might be:

CPU-efficient but memory-hungry
memory-efficient but storage-heavy
GPU-efficient but network-heavy
low-latency but expensive
high-throughput but power-hungry

You have to define what you're optimizing for.

For example:

System	Important Constraint
Gaming PC	GPU/CPU performance, latency
Smartphone	Battery, thermals, memory
Database server	RAM, storage I/O, CPU
AI server	GPU/accelerator, memory bandwidth
IoT sensor	Power, RAM, CPU
Cloud application	CPU, RAM, network, cost
High-frequency system	Latency and predictability

The "best" software design depends on the machine and the workload.

Hardware-Aware Thinking

Before building a system, ask:

CPU

How many cores are available?
Is the workload parallelizable?
Is computation CPU-bound?

Memory

How much RAM is available?
How large can the working set become?
Can data be streamed instead of loaded entirely?

Cache

Does the application repeatedly access the same data?
Can data locality be improved?
Are data structures causing unnecessary memory access?

Storage

Is storage SSD, HDD, or remote?
Is the workload sequential or random?
Can data be cached?

GPU / Accelerators

Is the workload highly parallel?
Is GPU acceleration available?
Does transferring data to the accelerator introduce significant overhead?

Network

How much latency exists?
How much bandwidth is available?
Can requests be reduced or batched?

Power and Thermals

Is the device battery-powered?
Can sustained computation cause throttling?
Can the workload be scheduled more efficiently?

Hardware Is Not an Afterthought

A common mistake is:

Build Software
      ↓
Deploy
      ↓
Discover Hardware Problems
      ↓
Rewrite Architecture

A better approach is:

Understand Requirements
        ↓
Understand Hardware
        ↓
Understand Workload
        ↓
Design Architecture
        ↓
Build Software
        ↓
Measure
        ↓
Optimize

You don't need to know every transistor inside the CPU.

You don't need to become an electrical engineer.

But you should understand enough about the machine to answer an important question:

What does this software actually need from the hardware?

The Real Lesson

You don't need to become a hardware engineer to become a good software engineer.

But understanding the machine underneath your code gives you another level of control.

When you understand hardware, concepts such as:

algorithms
concurrency
caching
memory management
parallelism
storage
networking
GPU acceleration
power efficiency

stop being isolated programming concepts.

They become parts of one larger system.

Software tells the computer what to do. Hardware determines the physical resources available to make that computation happen.

So before building software, sometimes the most important question isn't:

"What code should I write?"

It's:

"What machine am I writing this for?"

Because when you know the hardware, you don't just make software that runs.

You design software that belongs on that hardware.

Questions to Think About

Before moving on, try answering these without looking anything up:

Why can the exact same program run quickly on one machine and slowly on another?
If a program is waiting mostly on network responses, would buying a faster CPU necessarily solve the problem? Why?
Why does having more CPU cores not automatically make every program faster?
Why might loading an entire 20 GB dataset into RAM be a bad design on an 8 GB machine?
Why are GPUs particularly useful for some AI and image-processing workloads?
Why can excessive computation be a problem on a smartphone even when the computation finishes successfully?
What is a bottleneck, and why should you identify it before optimizing?
If you were building software for a Raspberry Pi, a gaming PC, a smartphone, and a cloud server, would you design all four systems the same way? Why or why not?
Which matters more for a particular application: CPU speed, RAM, storage speed, GPU power, or network speed? What information would you need to decide?
If you had to design one piece of software specifically for a machine, what hardware information would you want to know before writing the first line of code?

The Most Underutilized Part of Tech Is the Media Layer

Sumit Mishra — Mon, 21 Sep 2026 04:39:08 +0000

Technology has a strange communication problem.

We have never had more powerful tools, more ambitious startups, more capable computers, or more sophisticated software. Yet when most people encounter new technology, they are often given one of two things:

Corporate jargon or science fiction.

Neither is particularly useful.

We hear about "AI-powered transformation," "autonomous systems," "spatial computing," "quantum breakthroughs," and "the future of work."

Or we see a cinematic video of humanoid robots walking through futuristic cities while dramatic music plays in the background.

What we rarely get is the simple explanation:

What is this actually doing, how does it work, and why should an ordinary person care?

That missing layer may be one of the most underutilized opportunities in technology.

Technology Has a Media Problem

The technology industry is exceptionally good at building things.

It is considerably worse at explaining them to people who aren't already inside the industry.

There is a massive gap between technical documentation and mainstream entertainment.

On one end:

Research papers
GitHub repositories
API documentation
Technical conferences
Benchmark charts
Architecture diagrams
Developer tutorials

On the other:

Science-fiction movies
Futuristic advertisements
Sensational headlines
"This changes everything" videos
Robot demonstrations
AI apocalypse debates

The average person lives somewhere in the middle.

They don't need a 40-page research paper.

They also don't need a robot dramatically staring into a camera while someone predicts the end of humanity.

They need someone to explain what is happening.

We Keep Turning Technology Into Magic

One of the biggest consequences of poor technology media is that technology starts looking like magic.

Ask someone how a recommendation algorithm works.

The answer might be:

"The algorithm knows what I like."

How?

"AI."

What does the AI actually do?

"It learns."

How does it learn?

That's where the explanation often ends.

The same thing happens with large language models.

A person types a question.

A machine responds instantly.

It feels intelligent.

But without explanation, the experience becomes almost supernatural.

The interesting story isn't that a machine "magically understands language."

The interesting story is that enormous amounts of computing power, training data, mathematical techniques, optimization, specialized hardware, and engineering have been combined to create a system capable of generating remarkably useful predictions.

That explanation is less cinematic.

It is also far more interesting.

The Science-Fiction Trap

Science fiction is useful.

It gives people a vocabulary for imagining possibilities. It asks questions about society, identity, automation, surveillance, artificial intelligence and the future.

The problem starts when science fiction becomes the default visual language for explaining real technology.

A new AI model launches.

The media shows a humanoid robot.

A new chip is announced.

The media shows a futuristic city.

A company builds an automation system.

The thumbnail has glowing blue circuitry.

A new computing architecture appears.

Someone talks about "the next technological revolution."

Eventually, everything begins to look like the same future.

The actual technology disappears underneath the aesthetic.

The Most Interesting Technology Is Often Boring

The irony is that some of the most important technological changes don't look futuristic at all.

A database optimization.

A better compression algorithm.

A new networking protocol.

A cheaper sensor.

A more efficient battery-management system.

A better compiler.

A warehouse automation system.

A tiny improvement to semiconductor manufacturing.

An open-source library used by thousands of developers.

None of these necessarily produce a spectacular demo.

But they can quietly change what is economically possible.

Technology doesn't always arrive as a robot walking into a room.

Sometimes it arrives as a 30% reduction in cost.

Sometimes it is a process that used to take eight hours and now takes twenty minutes.

Sometimes it is software that allows one person to do the work of several people.

Sometimes it is infrastructure nobody notices.

That is the technology story most people aren't being shown.

We Need Technology Journalism for Normal People

There should be an entire media category dedicated to explaining technology without assuming the audience is technical.

Not dumbed-down technology.

Translated technology.

There is an important difference.

Dumbing something down removes complexity.

Translation preserves the important complexity while making it understandable.

A good technology communicator should be able to take:

"A transformer-based multimodal model performs autoregressive inference over tokenized representations."

and eventually get an ordinary reader to understand:

"The system breaks information into pieces, processes relationships between those pieces using a neural-network architecture, and predicts what should come next."

The second explanation isn't perfect.

But now there is something to build on.

The reader can ask better questions.

That's the point.

Show the Machinery

Technology media should spend more time showing what happens behind the interface.

Instead of showing someone talking to an AI chatbot, show what happens between the question and the answer.

Instead of showing a robot walking, show the sensors.

Show the cameras.

Show the motors.

Show the control system.

Show the software.

Show where the failures happen.

Instead of saying that cloud computing powers an application, explain what "the cloud" actually means.

It is computers.

Lots of computers.

Organized into infrastructure.

Connected by networks.

Managed by software.

Stored in buildings.

That explanation isn't less impressive.

It is arguably more impressive.

Technology Needs Its Own "How It Works" Culture

We have entire television formats dedicated to explaining nature, history and science.

Technology deserves the same treatment.

Imagine a mainstream technology channel where an episode doesn't ask:

"Will AI replace humanity?"

Instead, it asks:

"What actually happens when you send a message to an AI model?"

Or:

"How does Google Maps figure out where you are?"

"How does Netflix deliver a movie to your phone?"

"Why do GPUs matter for AI?"

"What actually happens inside a data center?"

"How does a semiconductor factory make something smaller than a grain of sand?"

"Why does your phone know which direction you're facing?"

These questions sound ordinary.

The answers are extraordinary.

The Opportunity Is Bigger Than News

Technology media shouldn't just report what companies announce.

It should explain the machinery behind modern life.

That means covering:

Infrastructure
Chips
Energy
Networks
Software
Robotics
Manufacturing
AI
Cybersecurity
Databases
Logistics
Sensors
Telecommunications
Open-source software
Automation
Scientific computing

And connecting all of it to ordinary life.

Not:

"Company X launches revolutionary AI platform."

But:

"Here is the problem this technology solves, here is how it works, here is what it replaces, here is what it cannot do, and here is what changes if it becomes cheap enough."

That is a much better story.

The Goal Isn't to Kill the Wonder

Explaining technology doesn't make it less exciting.

It can make it more exciting.

Knowing how an airplane flies doesn't make flight boring.

Knowing how a computer works doesn't make computing less impressive.

Knowing how a camera sensor turns photons into an image doesn't ruin photography.

Understanding the mechanism creates a different kind of wonder.

Instead of:

"That's magic."

You get:

"Holy shit. Humans figured out how to build that."

That's a much healthier relationship with technology.

The Next Great Tech Media Company Might Not Make Technology

It might explain it.

There is enormous value sitting between engineers and the general public.

The opportunity is to build media that treats technical subjects with the same seriousness that great science documentaries treat physics or biology.

No unnecessary hype.

No artificial futurism.

No endless apocalypse narratives.

No assumption that everyone already understands the terminology.

Just good storytelling, good visuals, accurate explanations and genuine curiosity.

The technology industry has spent decades building increasingly complicated machines.

Perhaps the next underdeveloped layer isn't another machine.

Perhaps it is the interface between technology and human understanding.

Because if technology is going to reshape everyday life, people shouldn't have to experience that change as magic.

They should understand what is happening.

And perhaps the biggest opportunity in tech isn't building the future.

It's finally explaining the present.

Experimenting With Tech: Build Something Just Because You’re Curious

Sumit Mishra — Sun, 20 Sep 2026 01:30:56 +0000

I remember when I was in Class 12, I wanted to build two things that probably made very little sense as “projects.”

One was a faster AI suggestion tool for the desktop — something that could understand what I was typing and suggest what I might want to write next.

The other was a PDF n-gram counter — a tool that could take a PDF, analyze the text, and tell me which words or sequences of words appeared most frequently.

I didn't have a startup idea.

I wasn't solving a business problem.

I didn't have a detailed roadmap.

I just had two questions:

“Can I actually make this?”

And that was enough.

Looking back, I think that's where experimentation really starts.

Most people think building with technology starts with a big idea.

You need a startup idea.
You need a business problem.
You need a detailed roadmap.
You need to know exactly what the final product will look like.

I think that mindset is backwards.

Some of the most interesting things you can build start with a much simpler thought:

“I wonder if I can make this.”

That is experimentation.

Build First, Figure Out the Point Later

Imagine waking up and wondering:

“What if I had a bot that watched a few websites I care about and told me only the interesting changes?”

You don't need to turn that into a SaaS product.

Build it.

Maybe the bot checks websites, RSS feeds, GitHub repositories, research papers, product launches, or even a few obscure forums. It collects what changed, sends the information through an LLM, and produces a small daily summary.

A few hours later, you have something that didn't exist that morning.

Maybe it is useful.

Maybe it is completely pointless.

Both outcomes are valuable.

The interesting part is that you learned something.

Curiosity Is a Better Starting Point Than Requirements

Another day, you might wonder:

Can I make a bot that talks to my own documents?
Can I build an AI that explains everything happening in a particular field?
Can I automatically detect interesting GitHub projects?
Can I analyze my browser history and discover what I spend time researching?
Can I turn thousands of saved articles into a searchable knowledge base?
Can I build a personal dashboard that tells me what changed since yesterday?
Can I make an agent that investigates a question and gives me sources?
Can I predict something purely as an experiment?
Can I scrape a public dataset and discover something nobody asked me to discover?

None of these need to become products.

They're technical playgrounds.

And playgrounds are where you learn surprisingly quickly.

Build Your Own Information Radar

One experiment I find particularly interesting is creating a personal AI information system.

Instead of asking:

“What happened in the news today?”

you define:

“What changed in the things I care about?”

For example, suppose you're interested in AI infrastructure.

Your system could monitor:

GitHub
   ↓
Research papers
   ↓
Company blogs
   ↓
Product changelogs
   ↓
Developer discussions
   ↓
Technical forums
   ↓
News
   ↓
     AI summarizer
          ↓
Interesting changes
          ↓
Personal daily briefing

The output doesn't have to be another generic news summary.

It could say:

3 things worth investigating today

A new open-source inference framework appeared.

A major model provider changed its API pricing.

A GitHub project you've been watching suddenly gained 2,000 stars.

Now the AI isn't replacing your curiosity.

It is amplifying it.

The Best Experiments Are Slightly Ridiculous

Try building things that sound unnecessary.

A bot that argues with your ideas.

A program that finds the most interesting commits in your favorite repositories.

An AI that reads your bookmarks and groups them into topics.

A script that checks whether websites you follow have changed.

A personal "what did I miss?" machine.

A bot that watches a dataset and messages you when something unusual happens.

A system that takes a random question every morning and researches it automatically.

A tiny AI that summarizes your own notes every evening.

A dashboard showing what technologies you've been researching over the last six months.

These aren't necessarily businesses.

They're questions turned into software.

Why This Is Different From Following Tutorials

Tutorials usually give you the destination.

Experimentation gives you the problem.

That changes everything.

Instead of:

"Today I'm going to learn FastAPI."

you might think:

"I want a bot that receives a URL, analyzes it, stores the result, and lets me query my collection."

Suddenly you have a reason to learn:

FastAPI
databases
APIs
authentication
background jobs
embeddings
web scraping
LLMs
deployment

The technology becomes a tool for answering your question.

That's much closer to how real engineering works.

Keep Experiments Tiny

The biggest mistake is turning an experiment into a six-month project.

Don't.

Give yourself constraints.

One evening.

One weekend.

One API.

One dataset.

One weird question.

Build the smallest version that can answer:

“Does this idea actually work?”

If it works, extend it.

If it doesn't, throw it away.

Then start another experiment.

That ability to throw things away is important.

You don't need every experiment to become a portfolio project.

Some experiments exist purely to teach you something.

Your Personal Tech Laboratory

You can even maintain a simple list:

Experiment	Question	Result
Desktop AI suggestions	Can I make typing suggestions faster?	Learned from the attempt
PDF n-gram counter	Can I extract useful patterns from documents?	Learned from the attempt
GitHub bot	Can I detect interesting projects automatically?	Works
Paper summarizer	Can AI identify papers worth reading?	Partially
Personal search	Can I search all my notes semantically?	Works
Web monitor	Can I detect meaningful website changes?	Surprisingly useful
AI researcher	Can an agent investigate a topic autonomously?	Needs improvement

After a year, you might have built 50 strange little systems.

Most will be abandoned.

A few will be useful.

One or two might become something much bigger.

But even the failed experiments leave you with something valuable:

technical intuition.

Don't Only Consume Technology. Play With It.

There is an enormous amount of technology to consume today.

News.

Launches.

Benchmarks.

Tutorials.

Tweets.

Videos.

Podcasts.

Reddit threads.

Documentation.

It's easy to spend an entire day learning about what other people built.

Experimentation changes the relationship.

Instead of asking:

“What is everyone building?”

start asking:

“What can I build in the next two hours?”

That question is more interesting.

You don't need permission.

You don't need a startup.

You don't even need a particularly good idea.

Find something that makes you curious.

Build the smallest possible version.

Break it.

Fix it.

Learn something.

Then find another question.

That is experimentation.

And in a world where technology is becoming easier to build with, the ability to turn random curiosity into working software might become one of the most useful technical skills you can develop.

How to Switch Programming Languages Without Starting From Zero

Sumit Mishra — Sat, 19 Sep 2026 03:44:05 +0000

Learning your first programming language can feel difficult.

Learning your second one is usually much easier.

Why?

Because when you switch languages, you are not really learning programming again. You are learning how another language expresses programming concepts you already understand.

If you already know variables, loops, functions, conditions, data structures, debugging, and basic software design, you have already done much of the hard work.

The trick is to stop treating every new programming language as a completely new subject.

1. Learn Programming Concepts, Not Just Syntax

A common mistake is memorizing syntax.

For example, you might learn:

if age >= 18:
    print("Adult")

Then, after switching to JavaScript:

if (age >= 18) {
    console.log("Adult");
}

The syntax changed.

The idea did not.

Both examples contain:

A condition
A comparison
A block of code
An output operation

When switching languages, ask:

"How does this language implement the concept I already know?"

Instead of:

"How do I learn this entire language?"

That small change in thinking makes language switching much faster.

2. Build a Concept Mapping Table

When moving from one language to another, create a simple translation map.

For example, if you know Python and want to learn JavaScript:

Concept	Python	JavaScript
Variable	`x = 10`	`let x = 10`
Function	`def add():`	`function add() {}`
Condition	`if x > 5:`	`if (x > 5) {}`
List	`[1, 2, 3]`	`[1, 2, 3]`
Dictionary/Object	`{"name": "Raj"}`	`{name: "Raj"}`
Loop	`for x in items:`	`for (const x of items)`
Null value	`None`	`null`
Boolean	`True`	`true`

You don't need to memorize the entire language.

Focus on the differences.

This turns language learning into comparison instead of memorization.

3. Learn the "Big Five" First

When switching languages, learn these five areas before anything else:

1. Variables and Types

Understand:

How variables are declared
Mutable vs immutable values
Static vs dynamic typing
Primitive types
Type conversion

2. Control Flow

Learn:

if
else
for
while
switch or equivalents

3. Functions

Understand:

Function declaration
Parameters
Return values
Anonymous functions
Closures

4. Data Structures

Learn the language's equivalents of:

Arrays/lists
Sets
Maps/dictionaries
Tuples or records
Stacks and queues

5. Error Handling

Understand:

Exceptions
Error values
try/catch
Error propagation
Debugging tools

Once these are familiar, the language starts feeling much less foreign.

4. Understand What Is Actually Different

Not every language is simply "another syntax."

Some differences are fundamental.

For example:

Python

x = 10

Java

int x = 10;

Java requires you to explicitly declare the type in this example.

That difference is not merely syntax.

It reflects a different type system.

Similarly, moving between languages may introduce concepts such as:

Garbage collection
Manual memory management
Ownership and borrowing
Prototypes
Interfaces
Generics
Traits
Pattern matching
Concurrency models

These are the areas where you should slow down.

Don't blindly translate syntax when the underlying programming model has changed.

5. Build the Same Project in the New Language

This is probably the fastest way to make a language switch practical.

Don't spend three weeks watching tutorials.

Build something.

For example, suppose you already built a task manager in Python.

Build the same application in JavaScript.

The project might contain:

User input
CRUD operations
Lists
Functions
File/database operations
Error handling

Because you already understand the application, your brain can focus on the new language.

You are learning:

new language + familiar problem

instead of:

new language + completely unfamiliar problem

That dramatically reduces cognitive load.

6. Don't Translate Everything Literally

This is one of the biggest traps when switching languages.

Suppose you know Python and start learning JavaScript.

You might try to write JavaScript as if it were Python.

That can work initially, but it prevents you from learning the strengths and conventions of JavaScript.

The same applies when moving between:

Java → Kotlin
C++ → Rust
JavaScript → TypeScript
C# → Java
Python → Go

Learn the idiomatic way of doing things.

For example, don't ask only:

"How do I write Python's feature X in JavaScript?"

Also ask:

"How do JavaScript developers normally solve this problem?"

That is the difference between knowing syntax and actually knowing a language.

7. Learn the Ecosystem, Not Just the Language

A programming language is only one part of the development environment.

You also need to understand its ecosystem.

For example:

Python

Common areas include:

Web development
Data science
Machine learning
Automation
Scripting

JavaScript / TypeScript

Common areas include:

Web applications
Backend development
Mobile applications
Desktop applications
Serverless applications

Rust

Common areas include:

Systems programming
Performance-sensitive applications
Networking
CLI tools
WebAssembly

The language itself may be easy to learn.

The ecosystem can take considerably longer.

8. Use Documentation Instead of Memorizing Everything

Experienced developers don't remember every function.

They know:

What they want to accomplish.
What feature they need.
Where to find the documentation.
How to verify that their implementation is correct.

When learning a new language, keep the official documentation open.

Search for things like:

JavaScript official array documentation
Go official error handling documentation
Rust official ownership documentation
Java official collections documentation

Documentation is not a sign that you don't know the language.

It is part of professional programming.

9. Use the 20/80 Rule

You don't need 100% of a language to start building useful software.

Learn the approximately 20% that you'll use repeatedly.

For many languages, that includes:

Variables
Functions
Conditions
Loops
Collections
Modules/packages
Error handling
File/network operations
Testing
Debugging
Package management

Then learn advanced features when your project actually requires them.

Don't spend two weeks learning an advanced metaprogramming feature before writing your first useful application.

10. Learn Differences in Mental Models

This is where experienced programmers become much faster language switchers.

Consider memory management.

In Python, memory management is largely handled automatically.

In Rust, ownership and borrowing are central concepts.

If you try to approach Rust as "Python with different syntax," you're going to struggle.

Instead, understand the model:

Python

"The runtime manages most memory concerns for me."

Rust

"The ownership system gives compile-time guarantees about memory and references."

Once you understand the underlying model, the syntax becomes much easier.

11. A Simple 7-Day Language Switching Plan

You can use this process whenever you switch languages.

Day 1 — Syntax

Learn:

Variables
Types
Conditions
Loops
Functions

Don't build anything complicated.

Day 2 — Data Structures

Learn:

Arrays/lists
Maps/dictionaries
Sets
Strings

Implement a few small exercises.

Day 3 — Functions and Modules

Learn:

Imports
Packages
Functions
Scope
Closures
Dependency management

Day 4 — Error Handling

Learn:

Exceptions/errors
Debugging
Logging
Common runtime errors

Day 5 — Build Something

Create a small application.

Examples:

CLI calculator
Todo application
URL shortener
Expense tracker
File organizer

Day 6 — Learn the Ecosystem

Explore the framework, package manager, testing tools, formatter, debugger, and commonly used libraries.

Day 7 — Rebuild Something You Already Know

This is the important part.

Take an old project and rebuild it using the new language.

You'll quickly discover what you actually don't understand.

12. Choose Languages Based on Your Goal

Don't randomly collect programming languages.

Choose a language because it gives you access to something you want to build.

Goal	Languages worth exploring
Web frontend	JavaScript / TypeScript
Backend	Python / Java / Go / JavaScript / TypeScript / C#
Data science	Python / R
Mobile	Kotlin / Swift / Dart
Systems	C / C++ / Rust
Game development	C# / C++
Automation	Python / JavaScript
High-performance services	Go / Rust / C++

The exact choice depends on the ecosystem, project requirements, existing team, performance requirements, and job market.

13. The Hardest Part Isn't Syntax

The hardest part of switching languages is usually discovering what the new language considers normal.

For example:

A Python developer might initially write JavaScript that works but doesn't follow common JavaScript conventions.

A Java developer might write Rust code that compiles but doesn't take advantage of ownership and borrowing effectively.

A C++ developer might initially approach Go with unnecessarily complicated abstractions.

The goal isn't simply:

"Make my old code work in this language."

The goal is:

"Understand how developers using this language naturally solve problems."

14. The Fastest Way to Become Polyglot

You don't need to master ten languages.

Instead, learn languages from different programming paradigms.

For example:

Python → JavaScript → Go → Rust

Each can expose you to different approaches to programming.

You start noticing patterns:

What concepts exist in almost every language?
Which features are language-specific?
How do different type systems work?
How do different languages handle concurrency?
How do different runtimes manage memory?
How do ecosystems solve dependency management?

At that point, switching languages becomes much easier.

You stop thinking:

"I have to learn another programming language."

You start thinking:

"I already know programming. I just need to learn this language's rules, ecosystem, and philosophy."

And that is the real skill.

Final Takeaway

The secret to switching programming languages quickly is not learning faster.

It's learning less.

Don't relearn programming from scratch.

Instead:

Identify what you already know.
Map those concepts to the new language.
Learn the major differences.
Build a familiar project.
Learn the language's idioms.
Explore its ecosystem.
Use documentation instead of memorizing everything.
Learn advanced features when your projects demand them.

Once you understand programming fundamentals deeply, your second language is no longer a completely new mountain.

It's mostly a new set of tools for solving problems you already know how to solve.