# Kishore M — Comprehensive Developer Profile & Full Article Catalog Kishore M (MKishoreDev) is a student developer from Tirunelveli, Tamil Nadu, India. He started programming in 2021 by building Telegram group management bots that scaled to over 10,000 groups. Since 2024 he has focused on backend architecture, API design, AI integration, and open-source tooling — while simultaneously preparing for Class 12 board exams. --- ## Identity - Full Name: Kishore M - Role: Student developer - Location: Tirunelveli, Tamil Nadu, IN (IST / UTC+5:30) - Portfolio Email: kishore@mkishore.is-a.dev - Contact Email: kishoredxd@gmail.com - Availability: Open to internships, freelance & OSS collaborations - Last Updated: Aug 6, 2026 - Copyright: © 2026 Kishore M --- ## Hero & Summary - Availability: Open to internships, freelance & OSS collaborations - Journey Summary: Started with Telegram bots in 2021, went deep on backend architecture in 2024, and now architecting scalable software and open-source tools — while balancing Class 12 boards. --- ## Tech Stack ### Core Technologies - Python (Primary language) - JavaScript (Frontend & scripting) - HTML (Web structure) - CSS (UI styling & layouts) ### Backend & APIs - FastAPI (Modern Python APIs) - Flask (Lightweight web framework) ### Databases - PostgreSQL (Advanced relational DB) - MongoDB (NoSQL document database) - MySQL (Relational database) - Neon (Serverless Postgres) ### Tools & Infrastructure - Git (Version control) - Linux (Dev environment) - Vercel (Deployment & hosting) - Visual Studio Code (Primary code editor) - PyPI (Package distribution) --- ## Work / Projects ### Live Projects (2026) #### PretendAI — Reverse Turing Test AI Game - Status: Live (2026) · Featured - Tagline: How AI are you ? - Description: A reverse Turing Test where humans act as AI assistants and AI acts as users. Built with Python, FastAPI, MongoDB, Groq, HTML, CSS, and JavaScript. - Tags: Python, FastAPI, HTML, CSS, JavaScript, MongoDB, Groq, Vercel - Live URL: https://pretendai.vercel.app - GitHub Repository: https://github.com/MKishoreDev/PretendAI #### En Peyar — AI Naming Platform for Startups - Status: Live (2026) · Featured - Tagline: Names with meaning. - Description: AI-powered naming platform that generates meaningful Tamil, English, and Tanglish names for startups, SaaS products, apps, brands, and projects. - Tags: Python, Flask, HTML, CSS, JavaScript, Groq, Vercel - Live URL: https://en-peyar.indevs.in - GitHub Repository: https://github.com/MKishoreDev/En-Peyar #### KaizenReply — AI Message Improvement Assistant - Status: Live (2026) · Featured - Tagline: Messages don't get rewritten. They evolve. - Description: AI-powered communication assistant that improves messages for different audiences, platforms, and situations. - Tags: Python, FastAPI, HTML, CSS, JavaScript, Groq, Vercel - Live URL: https://kaizenreply.vercel.app - GitHub Repository: https://github.com/MKishoreDev/KaizenReply #### KaguneBin — Encrypted Developer Pastebin - Status: Live (2026) · Featured - Tagline: Paste Fear. Share Power. - Description: Dark-themed developer pastebin with password protection, burn-after-read, and expiring pastes. FastAPI + PostgreSQL, inspired by Tokyo Ghoul. - Tags: Python, FastAPI, HTML, CSS, JavaScript, PostgreSQL, Neon, Vercel - Live URL: https://kagunebin.vercel.app - GitHub Repository: https://github.com/MKishoreDev/KaguneBin #### Redirox — Open Source URL Shortener - Status: Live (2026) · Featured - Tagline: Smart Links. Clean Routes. - Description: Modern open-source URL shortener — fast redirects, password-protected links, expiry windows, QR codes, and a published Python SDK. - Tags: Python, Flask, HTML, CSS, JavaScript, MongoDB, Vercel - Live URL: https://redirox.vercel.app - GitHub Repository: https://github.com/MKishoreDev/Redirox #### Vyn-Notes — AI-Powered Notes App - Status: Live (2026) - Tagline: Write. Think. Win. - Description: Lightweight AI-powered note app built with Streamlit + Groq. Fast capture, clean editing, AI-assisted refinement. - Tags: Python, Streamlit, Groq, MongoDB, Vercel - Live URL: https://vyn-notes.streamlit.app/ - GitHub Repository: https://github.com/MKishoreDev/Vyn-Notes #### KaguneBin Python SDK - Status: Live (2026) - Tagline: Python SDK for KaguneBin - Description: Official SDK to create, retrieve, and manage pastes from Python — with password, expiration, and burn-after-read support. - Tags: Python, Requests, SDK, PyPI - PyPI URL: https://pypi.org/project/kagunebin/ - GitHub Repository: https://github.com/MKishoreDev/kagunebin-pypi #### Redirox Python SDK - Status: Live (2026) - Tagline: Python SDK for Redirox - Description: Developer-friendly SDK with QR generation, password links, and Telegram-bot integration examples using Pyrogram. - Tags: Python, Requests, SDK, PyPI - PyPI URL: https://pypi.org/project/redirox/ - GitHub Repository: https://github.com/MKishoreDev/redirox-pypi ### Archived Projects (2021–2023) #### SerenaRobot — Telegram Group Management Bot - Status: Archived (2021) - Tagline: Where it all started. - Description: Advanced Telegram group management bot. At its peak it supported 10,000+ groups. - Tags: Python, PTB, Pyrogram, Telethon, PostgreSQL, MongoDB, Redis - GitHub Repository: https://github.com/MKishoreDev/SerenaRobot #### IdInvaded — Psycho-Pass Automation Bot - Status: Archived (2022) - Tagline: Psycho-Pass Sibyl System bot - Description: Telegram automation bot inspired by the Sibyl System from Psycho-Pass, featuring modular plugins, group administration, and community moderation. - Tags: Python, Pyrogram, MongoDB, aiohttp, TgCrypto - GitHub Repository: https://github.com/MKishoreDev/IdInvaded #### GilbertAnimeBot — Telegram Anime Manager - Status: Archived (2022) - Tagline: Modular TG management - Description: Modular Telegram anime and group management bot built with Pyrogram, Telethon, and SQLAlchemy. - Tags: Python, Pyrogram, Telethon, SQLAlchemy - GitHub Repository: https://github.com/MKishoreDev/GilbertAnimeBot #### Wager — Telegram Mini-Games Bot - Status: Archived (2022) - Tagline: Telegram wager & mini-games - Description: Fast-paced wager and mini-games bot built with Pyrogram — competitive group play, built with developer friends. - Tags: Python, Pyrogram, MongoDB, Games - GitHub Repository: https://github.com/MKishoreDev/Wager #### Nekos-Best-Bot — Anime GIF Bot - Status: Archived (2022) - Tagline: Anime GIF interaction bot - Description: Anime-themed Telegram bot for entertainment, GIF reactions, and community engagement using the Nekos.Best API. - Tags: Python, Pyrogram, Nekos API, Requests - GitHub Repository: https://github.com/MKishoreDev/Nekos-Best-Bot #### TruthOrDareBot — Group Game Bot - Status: Archived (2022) - Tagline: Group game bot - Description: Telegram group game bot with random truth questions, dare challenges, inline support, and group interaction system. - Tags: Python, Pyrogram, Games, Requests - GitHub Repository: https://github.com/MKishoreDev/TruthOrDareBot #### NoPmBot — Anti-Spam PM Protector - Status: Archived (2022) - Tagline: Anti-spam PM protector - Description: Spam prevention Telegram bot that protects private messages. Improved and maintained from SpEcHiDe's original project. - Tags: Python, Pyrogram, PostgreSQL, SQLAlchemy, TgCrypto - GitHub Repository: https://github.com/MKishoreDev/NoPmBot #### ArcaneSystem — Telegram Moderation Tool - Status: Archived (2022) - Tagline: TG moderation & enforcement - Description: Archived Telegram moderation & enforcement system featuring anti-spam protection, reporting workflows, and MongoDB-powered management. - Tags: Python, Pyrogram, MongoDB, Security - GitHub Repository: https://github.com/MKishoreDev/ArcaneSystem #### AutoPostTelegram — Media Auto-Poster SDK - Status: Archived (2023) - Tagline: Media auto-poster - Description: Python package for automatically posting memes, GIFs, and anime content to Telegram channels. - Tags: Python, Automation, Package - GitHub Repository: https://github.com/MKishoreDev/AutoPostTelegram --- ## Journey Timeline - **2021 — The Beginning**: Discovered Telegram bots during lockdown and developed my first automation script, igniting my passion for coding. - **2021–2023 — Serena**: Engineered Serena, a large-scale group management bot, acquiring practical programming skills through hands-on project development. - **2023–2024 — Deepening Knowledge**: Concentrated on Python fundamentals, core software engineering principles, and database management. - **2024 — Quality Shift**: Adopted a quality-over-quantity methodology, deeply exploring backend architecture, APIs, and system design patterns. - **2025 — Foundation Year**: Successfully completed 10th board examinations and committed to the Computer Science academic stream. - **2026–Now — Building in Public**: Architecting production-ready applications while continuously exploring scalable system design and modern frameworks. --- ## Currently Learning - **DSA & Architecture**: Learning linked lists, recursion, and problem-solving patterns after gaining confidence with arrays and lists. (Status: Building Foundations) - **Aptitude & Reasoning**: Practicing quantitative aptitude, logical reasoning, and puzzle-solving problems for upcoming competitive exams and assessment tests. (Status: Preparing) - **Open Source Ecosystem**: Learning contribution workflows, code review practices, and how large-scale projects are maintained. (Status: Getting Started) --- ## Full Blog Articles ============================================================ ### Post: before-ai-era URL: https://mkishore.is-a.dev/blog/before-ai-era --- title: "I'm Glad I Became a Developer Before the AI Era" date: "2026-07-22" updated: "2026-08-05" summary: "Rediscovering an old Telegram bot reminded me of a completely different era of programming—before ChatGPT, before AI coding assistants, and before software development changed forever." tags: ["technology", "journey"] draft: false cover: "/assets/images/blog/before-ai-era.png" --- > [!IMPORTANT] > This is **not** an anti-AI article. > > I use AI every single day. > ![Before Ai Era](/assets/images/blog/before-ai-era.png "before-ai-era") > This is a story about curiosity, open source, and why I'm grateful I learned programming before AI became everyone's first answer. --- *"Wait... I built this?"* That was the first thing that came to my mind. A few days ago, while cleaning up one of my old GitHub accounts, I found a repository named [Howdoi Bot](https://github.com/MKishoreDev/Howdoi-bot). The funny part? I genuinely couldn't remember creating it. I opened the repository expecting some unfinished experiment that I'd delete within a minute. Instead, I found something that instantly took me back four or five years. A small Telegram assistant written in Python using **Pyrogram**. Nothing extraordinary by today's standards. No large language models. No GPT. No Claude. No Gemini. No AI agent planning tasks. Just a simple Telegram bot that answered programming questions. As I kept reading the source code, memories slowly started coming back. I remembered exactly why I had built it. I remembered the excitement. I remembered spending hours trying to understand how another developer's bot could answer programming questions with a single command. And most importantly... I remembered what programming felt like before AI quietly became a part of almost every developer's workflow. --- ## A Tiny Repository That Meant So Much More The repository was built around an amazing open-source project called **HowDoI**. If you've never heard of it, it's a Python package created by the community that searches programming resources and returns quick answers to coding questions. Repository: [https://github.com/gleitz/howdoi](https://github.com/gleitz/howdoi) Today that probably sounds... Normal. Maybe even underwhelming. You might be thinking, > "So... it answered programming questions? ChatGPT does that in seconds." Exactly. That's the point. You're reading this in a world where asking an AI anything feels completely normal. But imagine going back to **2021**. No ChatGPT. No AI chatbots. No coding copilots inside every IDE. No "Generate Component" button. No AI explaining your stack trace. Back then, seeing a Telegram bot answer a programming question felt like seeing science fiction become real. I still remember the first time I used another developer's bot. The command was surprisingly simple. ```text /howdoi ``` That's it. You could type something like: ```text /howdoi write a simple Pyrogram bot ``` A few seconds later... The bot replied with code. Not perfect. Not conversational. But useful. Useful enough that I sat there staring at my phone wondering, > **"How is this even possible?"** That single question changed everything. --- ## Curiosity Is a Strange Thing I've realized something over the years. The best projects I've ever built didn't begin with an idea. They began with curiosity. Curiosity is weird. Sometimes it starts with seeing someone else's project. Sometimes it's an error message. Sometimes it's a random GitHub repository. Sometimes it's one tiny command that refuses to leave your mind. For me... It was `/howdoi`. Most people would've used it once, thought "that's cool," and moved on. I couldn't. I wanted to know what happened behind the scenes. How did it search? Where did the answers come from? Was it scraping websites? Was it calling an API? Could I build something similar? Questions kept leading to more questions. Eventually those questions led me to the **HowDoI** repository. I spent hours reading code that I barely understood. Looking back, I probably understood less than twenty percent of what I was reading. But that didn't matter. I wasn't reading because I already knew everything. I was reading because I wanted to. That's one thing I miss about those days. Not because AI didn't exist. But because curiosity always came before convenience. --- ## Before AI Became the First Tab We Open Today my workflow often looks like this. :::steps 1. **Think of an idea** 2. **Ask AI** 3. **Build** 4. **Refine** 5. **Ship** ::: It's incredibly efficient. Sometimes unbelievably efficient. Back then... The workflow looked very different. It usually started with Google. Then another Google search. Then Stack Overflow. Then Reddit. Then a GitHub issue. Then documentation. Then YouTube. Then another Google search because nothing made sense. Sometimes I'd spend an hour trying to fix a missing comma. Sometimes an entire evening disappeared because of one import error. Sometimes Google simply didn't understand what I was asking. Sometimes **I** didn't understand what I was asking. But every search taught me something. Every dead end taught me something. Every mistake forced me to understand one more tiny piece of programming. It wasn't efficient. It wasn't fast. But it quietly built foundations I still rely on today. --- ## The Internet Was Full of Invisible Teachers When people ask me who taught me programming... I honestly don't know how to answer. There wasn't one teacher. There were thousands. Most of them don't even know I exist. A Stack Overflow answer from 2013. A Reddit comment with three upvotes. A GitHub issue someone opened after midnight. A YouTube tutorial with 400 views. A random blog post written by someone who probably forgot it even existed. Those people unknowingly became my mentors. Every time they documented a bug... Every time they answered a beginner's question... Every time they shared code... Someone like me learned from it. Looking back, it's beautiful. Programming has always been a community effort. Long before AI started answering questions... Developers were already teaching millions of strangers without ever meeting them. I happened to be one of those strangers. And I'm incredibly grateful for it. --- ## The Telegram Bot Era My journey into programming didn't begin with web applications. It didn't begin with React. It didn't begin with Docker. It didn't even begin with building websites. It began with **Telegram bots**. Looking back, I genuinely think that era shaped me more than any tutorial or course ever could. Telegram bots weren't just little chat applications. For many of us, they were our first experience with APIs, asynchronous programming, databases, deployment, version control, debugging, authentication, automation, and open source—all packed into a project that felt exciting enough to keep us awake until three in the morning. There was always something new to build. A moderation bot. A music bot. A chatbot. A file uploader. A game. A utility command. Or simply something weird that made your friends say, > "Wait... you made this?" That feeling was addictive. --- ## Every New Feature Was an Adventure Back then, there wasn't an AI waiting to explain everything. When I wanted to add a feature, I usually had no idea where to begin. I'd search something like: > "Pyrogram inline keyboard" Open ten different tabs. Close eight because they weren't helpful. Read the documentation. Copy a small example. Break it. Fix it. Break it again. Finally understand why it worked. Then I'd forget it two weeks later and repeat the process all over again. It wasn't efficient. But every repetition made me a little better. Without realizing it, I wasn't memorizing code. I was learning patterns. --- ## The Community Was the Documentation I think one of the most beautiful things about that time was the community. Telegram developers were everywhere. People built plugins. Shared snippets. Answered questions. Explained weird errors. Maintained open-source libraries. Some were older developers. Some were college students. Some were kids like me. Most of us had never met. Yet somehow everyone kept helping each other. I still remember asking what now feels like embarrassingly simple questions. Nobody laughed. Someone always answered. Sometimes the answer was one sentence. Sometimes it was a GitHub link. Sometimes someone rewrote my entire function just so I'd understand it better. Years later... Those conversations still matter more to me than the code itself. --- ## We Didn't Have Fancy Hosting Today deployment feels almost effortless. Connect your GitHub repository. Push your code. Wait a minute. Your application is online. Back then... It wasn't like that. Especially if you were just a student. Cloud servers cost money. Most of us didn't have credit cards. So free hosting platforms became our playground. Heroku. Replit. Railway. PythonAnywhere. Render. GitHub Actions. If it could run Python for free... Someone had probably figured out how to host a Telegram bot on it. I remember using **Heroku** long before I understood how Git worked. Whenever I changed my code, I did something that sounds completely ridiculous today. I created a brand-new deployment. Every. Single. Time. I simply didn't know there was another way. One day another developer asked me, > "Why don't you just connect your GitHub repository?" I had no idea that was even possible. He showed me. It took him maybe five minutes. It probably saved me hundreds of hours over the following years. Looking back, it's funny. At the time, it completely changed the way I worked. --- ## GitHub Actions Wasn't Meant for This... ...but that didn't stop us. One trick that became surprisingly popular was running Telegram bots through **GitHub Actions**. The workflow would start the bot. It would keep running until GitHub's runtime limit was reached. Then it stopped. Whenever that happened... We simply started the workflow again. Was it the intended use of GitHub Actions? Absolutely not. Did GitHub probably expect teenagers to keep Telegram bots alive using CI workflows? Probably not. Did it work? Surprisingly well. It's one of those tiny memories that reminds me how creative developers become when resources are limited. When you don't have money... You compensate with curiosity. --- ## The Internet Felt Smaller Something else was different back then. The developer community felt... Smaller. Not because fewer people programmed. But because you'd keep seeing the same names. The same maintainers. The same Telegram usernames. The same GitHub profiles. You'd recognize people simply because you had seen them helping others before. Some of those developers disappeared over time. Some moved on to jobs. Some stopped programming entirely. Some deleted their accounts. I don't even remember all their names anymore. But I remember what they gave me. Knowledge. Without expecting anything in return. If any of those people somehow read this... Thank you. You probably don't remember answering a random beginner's question years ago. I do. --- ## There Was No "Perfect Prompt" One thing I rarely hear people talk about is how we asked questions before AI. You couldn't just say, > "Here's my code. Fix it." You had to explain the problem. Share the error. Describe what you already tried. Search using the right keywords. Sometimes the hardest part wasn't fixing the bug. It was figuring out **how to ask the question.** Ironically... Learning how to ask good questions became one of the most valuable programming skills I ever developed. And I still use that skill today—even when I'm asking AI. Because the better your question... The better your understanding usually becomes. --- ## Looking Back... I don't think that era was better. It was harder. Much harder. But I'm grateful I experienced it. Those years taught me patience. They taught me persistence. They taught me that reading documentation wasn't punishment. It was part of being a developer. Most importantly... They taught me that every great developer was once someone staring at an error message with absolutely no idea what to do next. The only difference between beginners and experienced developers wasn't intelligence. It was simply that one person kept asking questions a little longer than the other. --- ## Then AI Arrived I don't remember the exact day. I don't think anyone does. There wasn't a countdown. No announcement saying, > "Programming is about to change forever." It just... Happened. One day people were sharing Stack Overflow links. A few months later everyone was sharing ChatGPT screenshots. At first it felt like another cool tool. Then GitHub Copilot became better. Then image generation exploded. Then AI could generate voices. Then videos. Then entire applications. Then autonomous coding agents. Almost overnight, asking an AI became the default starting point for solving problems. And honestly... It still amazes me. Sometimes I ask AI to explain an unfamiliar technology. Sometimes I ask it to review code. Sometimes I use it to brainstorm architecture. Sometimes I simply ask, > "Am I thinking about this correctly?" What would've taken hours now takes minutes. That's incredible. --- ## The Best Productivity Tool I've Ever Used I won't pretend otherwise. AI has made me significantly more productive. I write code faster. I learn concepts faster. I prototype ideas faster. I write documentation faster. Sometimes I even discover libraries I would've never found through a normal Google search. If someone asks me, > "Should developers use AI?" My answer is always the same. Absolutely. Why wouldn't you? Ignoring one of the biggest technological shifts in software development would be like refusing to use Git because FTP uploads already work. Technology moves forward. Developers should move with it. The problem isn't AI. The problem is forgetting how to think once AI starts answering. --- ## The Day I Got Humbled Not long ago, I contributed to a fairly large open-source project. Like many developers today, I used AI to help me draft parts of my contribution. I reviewed it. Modified it. Submitted it. The maintainers weren't impressed. Some of my reasoning was wrong. Parts of my review showed that I hadn't fully understood what was happening internally. Someone corrected me. Publicly. For a moment... It hurt. I felt embarrassed. I wondered if they simply saw me as another "AI developer." Another kid copying responses without understanding them. Then I stopped feeling defensive. Because if I removed my ego from the situation... They were right. Not about who I was. But about the mistake I had made. I had trusted AI a little more than I should have. That experience changed how I use AI forever. --- ## AI Doesn't Remove Responsibility One lesson stayed with me after that contribution. AI generated the response. I submitted it. That means the responsibility was still mine. It's easy to blame AI. "The model hallucinated." "The AI misunderstood." "The prompt wasn't good." None of those excuses matter. If my name is attached to the code... It's my responsibility. Not the model's. That applies whether you're writing software, documentation, blog posts, or reviewing someone else's pull request. AI can help. AI can suggest. AI can even teach. But AI doesn't replace accountability. --- ## The Difference I Keep Seeing Over the past few years, I've noticed something interesting. Some developers become dramatically better after they start using AI. Others stop growing almost completely. The tool is exactly the same. So what's different? Curiosity. The first developer asks, > "Why did AI choose this solution?" The second developer asks, > "What's the next prompt?" The first developer opens the documentation. The second developer opens another chat. The first developer experiments. The second developer regenerates the response. Same tool. Completely different mindset. --- ## Sometimes I Worry I'm still young. Technically, I'm part of the AI generation. But I sometimes worry about new developers entering programming today. Not because they use AI. Because they might never experience programming without it. Imagine learning mathematics where every question is instantly solved. You might become very good at asking questions. But will you understand why the answer works? Maybe. Maybe not. That's entirely up to you. I meet developers who can generate beautiful landing pages in minutes. Yet some struggle to explain basic concepts like DNS, responsive layouts, HTTP requests, or Git. The application works. Until something unexpected happens. Then the AI conversation gets longer and longer... Because the missing piece isn't another prompt. It's understanding. --- ## If You Build With AI, Learn With AI Too This is probably the advice I'd give my younger self. Don't just ask AI to write code. Ask it why. Ask it what alternatives exist. Ask it why one approach is better than another. Ask it to explain concepts like you're five. Ask it to argue against its own answer. Challenge it. Treat AI less like an employee. Treat it more like a mentor that occasionally makes mistakes. Because it does make mistakes. And sometimes... Those mistakes become incredible learning opportunities. --- ## The World Didn't Lose Curiosity People often say AI is making developers lazy. I don't think that's entirely true. Curious people remain curious. AI simply changed where curiosity begins. Years ago my curiosity started with Google. Today it might start with ChatGPT. Tomorrow it might start somewhere else. The starting point isn't what matters. The journey afterward does. Do you stop after getting an answer? Or do you keep asking why? That's the question that separates someone who merely uses technology from someone who truly understands it. --- ## The Skills AI Can't Build For You If there's one thing I'm truly thankful for, it's this: I learned how to struggle. That might sound strange. Nobody likes struggling. Nobody enjoys spending four hours debugging something that turns out to be a missing comma. Nobody enjoys reading fifty Stack Overflow posts before finding the one answer that actually solves the problem. Nobody enjoys deploying the same application over and over because they don't know a better way. I didn't enjoy it either. But those struggles quietly taught me something AI never could. Patience. Persistence. Problem-solving. The confidence to keep going when absolutely nothing makes sense. Those skills stayed with me long after the bugs disappeared. --- ## "Would You Still Be a Developer?" Sometimes I ask myself a question. Not because I expect it to happen. But because I think it's a good way to measure how much I've actually learned. > **If AI disappeared tomorrow... would I still be a developer?** My answer is yes. Would I become slower? Without question. A feature I finish today in one afternoon might take me two weeks. I'd spend more time reading documentation. I'd watch far more YouTube tutorials. I'd search GitHub issues again. I'd read Stack Overflow answers from 2012. I'd probably ask more questions in developer communities. I'd make more mistakes. I'd get frustrated more often. But eventually... I'd still build it. Because AI accelerated my workflow. It didn't create my foundation. That difference matters. --- ## Foundation vs. Acceleration I like thinking of AI like this. Imagine someone gives two people the fastest race car in the world. One person already knows how to drive. The other has never touched a steering wheel. Both have the same car. Only one reaches the finish line. AI is the race car. Understanding is the driving skill. Without understanding, faster tools simply help you get lost more quickly. --- ## Knowledge You Can't Prompt Into Existence Some lessons simply cannot be generated. You only learn them by building. The first time your production server crashes. The first time you accidentally delete your database. The first time you spend hours debugging before realizing your environment variable has a typo. The first merge conflict. The first rejected pull request. The first feature users actually love. The first bug report. The first contributor correcting your code. The first time someone says, > "There's a better way to do this." Those experiences change how you think. No prompt can replace them. --- ## Programming Isn't About Memorizing Syntax One of the biggest misconceptions beginners have is thinking experienced developers remember everything. We don't. I still search documentation. I still forget syntax. I still copy examples. I still read API references. The difference isn't memory. It's recognition. After enough experience, patterns become familiar. You stop thinking, > "How do I write this?" Instead you start asking, > "Why is this designed this way?" That shift changes everything. AI can generate syntax. Only experience teaches intuition. --- ## Curiosity Is Still My Favorite Superpower Looking back, curiosity has probably been the single most important reason I've stayed in programming. Curiosity made me search for the HowDoI project. Curiosity made me read source code I barely understood. Curiosity made me ask questions that probably sounded silly. Curiosity made me click "View Source." Curiosity made me fork repositories just to see what would happen. Curiosity made me break projects. Curiosity made me fix them. That's how I learned. Not through talent. Not through intelligence. Through curiosity. People often ask AI, > "Give me a startup idea." It usually gives ten decent ideas. But they're rarely new. They're combinations of things that already exist. The ideas that excite me the most don't usually begin with prompts. They begin with observations. Something annoying. Something inconvenient. Something I wish existed. That's where interesting software comes from. AI can help build it. But curiosity usually discovers it first. --- ## To Every New Developer Reading This If you're just getting started today... You're lucky. Seriously. You have access to tools I could only dream of a few years ago. You can ask questions in natural language. You can generate examples instantly. You can translate documentation. You can debug faster. You can learn almost anything. Don't feel guilty about using AI. Use it. Learn it. Master it. But don't let it become the only way you learn. Open the documentation even when AI already answered. Read the GitHub issue. Watch the conference talk. Read the pull request discussion. Study why the code works. Don't stop at "it works." Ask why it works. That one extra question compounds over years. --- > [!TIP] > My advice is simple: > > * Use AI to save time. > * Use documentation to build confidence. > * Use open source to build understanding. > * Use curiosity to build your future. --- ## Fork It. Break It. Run It. When I first started programming, I wasn't building amazing products. I was breaking other people's code. Forking repositories. Changing random values. Deleting lines just to see what happened. Running projects that crashed immediately. Fixing them. Breaking them again. Reading code I didn't understand. That's how most of us learned. Not by watching someone else build. By building badly ourselves. Even today, when I discover an interesting open-source project, one of the first things I do is clone it. I want to see how someone else solved a problem. Not because I want to copy it. Because I want to understand how they think. That habit has taught me more than any single tutorial ever has. And I hope I never lose it. --- ## Looking Back at That Little Repository After spending some time reading through the code, I closed the repository and just smiled. Not because it was well written. It wasn't. Not because it followed best practices. It definitely didn't. Not because it used some revolutionary architecture. It was just another Telegram bot. But it represented something much bigger than code. It represented a younger version of me. A kid who didn't know much. A kid who didn't know how deployment worked. A kid who didn't know Git properly. A kid who didn't understand asynchronous programming. A kid who thought seeing a Telegram bot answer programming questions was the coolest thing ever. A kid who wasn't afraid to ask, > **"How does this work?"** That question changed my life. Not overnight. Not in one week. But over years. Every repository I explored. Every Stack Overflow thread I read. Every Reddit discussion. Every YouTube tutorial. Every failed deployment. Every broken production bot. Every maintainer who corrected me. Every developer who answered one of my beginner questions. Every GitHub issue. Every bug. Every mistake. Every success. Every one of those moments slowly shaped the developer I am today. --- ## The Developers Who Never Knew They Taught Me Programming is a strange profession. Some of the people who have influenced me the most have absolutely no idea who I am. Maybe you wrote a Stack Overflow answer in 2014. Maybe you explained a confusing Python error on Reddit. Maybe you uploaded a Pyrogram tutorial with only a few hundred views. Maybe you maintained an open-source library. Maybe you reviewed my pull request. Maybe you simply answered a beginner's question in a Telegram group. You probably forgot about it. I didn't. Knowledge spreads in ways we rarely notice. One answer can teach thousands of people. One repository can inspire hundreds of projects. One encouraging reply can convince someone not to quit programming. Open source has always been about more than code. It's about people helping people they'll probably never meet. And I think that's beautiful. --- ## AI Will Continue to Change If there's one thing I'm certain about, it's this. AI isn't slowing down. It's getting better. Much better. I remember when AI-generated images looked distorted and almost funny. Now they're photorealistic. I remember when AI could barely complete a sentence consistently. Now it writes applications. I remember when AI-generated voices sounded robotic. Now they're almost indistinguishable from real people. I remember when asking AI to write code meant getting twenty lines of broken Python. Now it can generate entire applications, review pull requests, explain architecture, and help debug production issues. And this is probably the worst AI we'll ever use. Five years from now, we'll probably look back at today's models the same way we look back at early image generators. Primitive. That's exciting. And honestly... I'm excited to watch that future unfold. --- ## But Don't Outsource Your Curiosity There's one thing I hope never changes. Curiosity. The internet taught me programming because I stayed curious. Open source taught me programming because I stayed curious. Developers taught me programming because I stayed curious. AI should make that curiosity stronger. Not replace it. Don't stop exploring repositories. Don't stop reading documentation. Don't stop asking questions. Don't stop wondering, > "Why?" That one word has probably taught me more than any programming language ever has. --- ## A Message to Future Me Maybe I'll read this article ten years from now. Maybe AI agents will be building complete companies. Maybe software development will look completely different. Maybe we'll laugh at how much time we spent writing code manually. Maybe this entire article will feel outdated. If that happens... I hope one thing stays true. I hope I never become someone who stops learning. I hope I never think, > "AI already knows everything." Because that's the fastest way to stop growing. I hope I still open random GitHub repositories just because they look interesting. I hope I still read source code for fun. I hope I still break things. I hope I still build things that nobody asked for. I hope I still stay awake at two in the morning because one tiny idea refused to leave my head. Most importantly... I hope I never lose the curiosity that started all of this. --- ## One Last Question Before you close this page, I want to leave you with one question. Not because there's a right answer. But because it's worth thinking about. > **If every AI model disappeared tomorrow... would you still call yourself a developer?** If your answer is **yes**... Keep going. You're using AI exactly the way it should be used. As a tool. If your answer is **no**... Don't be discouraged. Start learning the fundamentals today. Read the documentation. Understand networking. Learn Git. Break projects. Fork repositories. Deploy something yourself. Read source code. Ask questions. Fail. Fix it. Repeat. The goal isn't to stop using AI. The goal is to become someone who can build with it—or without it. Because tools evolve. Frameworks change. Programming languages rise and fall. Companies disappear. Even AI will eventually be replaced by something better. But genuine curiosity... That never becomes obsolete. --- > [!IMPORTANT] > AI might become the most powerful tool you'll ever use. > > But your greatest advantage will never be the prompts you write. > > It'll always be the questions you're curious enough to ask. --- When I found that little [Howdoi Bot](https://github.com/MKishoreDev/Howdoi-bot) repository, I expected to rediscover an old project. Instead, I rediscovered an old version of myself. A curious kid. One Google search after another. One Stack Overflow answer after another. One bug after another. One tiny victory after another. I'm grateful I experienced programming before AI became the default answer to everything. Not because those days were better. Not because today's developers have it easier. But because those years taught me something I'll carry for the rest of my career. **Technology will always change.** **Curiosity shouldn't.** --- *If you ever find one of your old repositories, don't rush to delete it.* *Open it.* *Read it.* *Smile at the mistakes.* *Thank the younger version of yourself for being brave enough to build it anyway.* *You might just rediscover why you fell in love with programming in the first place.* ============================================================ ### Post: how-i-built-this-portfolio URL: https://mkishore.is-a.dev/blog/how-i-built-this-portfolio --- title: "How I Built This Portfolio: Inspiration, Systems, and Behind the Code" date: "2026-08-06" updated: "2026-08-06" summary: "From discovering SpEcHiDe's terminal portfolio to asking Lovable for a UI concept, building my own Markdown compiler, writing a terminal CLI in Vanilla JS, implementing automated CI/CD workflows, and why my repository is currently private. This is the complete A-to-Z technical blueprint." tags: ["technology", "architecture", "webdev"] cover: "/assets/images/blog/blogs-banner.png" draft: false --- # How I Built This Portfolio: Inspiration, Systems, and Behind the Code > *Until now, every article on this blog has been about my journey—my old username, lost repositories, hackathons, and reflections on turning 17. It's time for something different: the origin story, full architecture, automated workflows, and a raw A-to-Z technical blueprint of every system running behind this portfolio.* --- If you look around developer portfolios today, almost all of them follow a familiar template: - Next.js or Vite starter kit. - TailwindCSS utility classes crammed into every HTML element. - Dozens of NPM packages for simple scroll animations. - A 15MB JavaScript bundle for a page that displays five project links. When I started building [mkishore.is-a.dev](https://mkishore.is-a.dev), I wanted something completely different. I wanted a site that felt like a high-performance terminal app wrapped in sleek glassmorphism—sub-50ms load times, zero framework overhead, total control over every line of code, and an automated build system that makes publishing effortless. Here is the complete story, architectural breakdown, workflow manual, and code tour of everything built into this portfolio. --- ## 1. The Spark: A Random Chat & SpEcHiDe If we rewind to when I first started my programming journey back in 2021, my world revolved around Telegram bots and developer communities. Back then, there was a well-known developer from Kerala named **SpEcHiDe** ([@SpEcHiDe](https://github.com/SpEcHiDe)). He had over 1,000 followers on GitHub and was famous for building Telegram bot frameworks and userbot modules. Like many young developers starting out back then, I looked up to his work. In fact, if you search through my archived repositories, you'll still find [`NoPmBot`](https://github.com/MKishoreDev/NoPmBot)—a bot repository derived from his original code. Fast forward to a few months ago. I was in a casual chat with fellow developers, reminiscing about the old Telegram bot days. During the conversation, someone casually mentioned that SpEcHiDe was active on LinkedIn. Curious, I searched for his profile and found a link to his personal portfolio: [shrimadhavuk.me](https://www.shrimadhavuk.me/). His site was a minimal, ultra-clean terminal UI. It was simple, fast, and iconic. Seeing it hit me immediately: > *"I've been making excuses to delay building my portfolio for months. It's time to build one. And it needs to be great."* --- ## 2. The First Draft: Lovable & The Original Rule After months of procrastination, that moment finally killed my excuses. I opened **Lovable** and requested an initial UI concept layout to brainstorm how a glassmorphic terminal interface could look. That gave me the visual spark I needed. When I sat down to write the first line of code, I set one strict rule for myself: > **The Original Rule:** > *The portfolio MUST have an interactive terminal UI. No blog, no guestbook, no discussions, no extra pages—just a single, clean portfolio page.* That was how it started. Obviously... I didn't stick to a single page. Step by step, the project expanded into what you're seeing today. ### Maximalism vs. Developer Character While researching ideas for this site, I explored dozens of incredible developer portfolios across GitHub showcase repositories (and eventually submitted my own portfolio to curated GitHub portfolio lists!). During that search, I saw every possible aesthetic imaginable. My absolute favorite design style to look at is **Maximalism**—heavy visual effects, rich interactive widgets, dense typography, and constant motion. But as much as I admire maximalist portfolios, I realized something important about myself: > *"Maximalism doesn't match my developer character. I am not a UI designer; I am a backend and automation engineer."* I love clean terminal interfaces, raw performance, low latency, and efficient code. So I chose a design that reflected who I actually am: **simple, clean, fast, and terminal-driven**. Even now, I still update the codebase almost daily. I tune CSS variables, optimize build scripts, fix minor layout bugs, and add small interactions. Do most visitors notice these tiny daily updates? Probably not. But I build them anyway—because I love the craft of building software with care. --- ## 3. The Full Project Structure Here is the complete directory layout of the portfolio: :::filetree - Portfolio/ - .github/ - workflows/ - blog-auto-build.yml — CI/CD GitHub Actions pipeline - CODE_OF_CONDUCT.md - PULL_REQUEST_TEMPLATE.md - .well-known/ - llms.txt — Standard-path AI discovery file - security.txt — Standard-path security contact - assets/ - css/ - style.css — Full design system (128KB source) - style.min.css — Minified production CSS (104KB) - giscus-dark.css — Custom Giscus dark theme - giscus-light.css — Custom Giscus light theme - js/ - data.js — Centralized portfolio state (profile, projects, skills) - app.js — Main page engine (54KB, 1300+ lines) - terminal.js — Interactive CLI terminal (61KB, 1700+ lines) - blog.js — Blog rendering engine (26KB, 714 lines) - contributions.js — GitHub contribution graph (17KB, 482 lines) - guestbook.js — Giscus theme sync engine - templates/ - blog-template.html — Post compilation template - blogs-index-template.html — Blog listing template - blog-index-template.html — Blog index redirect template - blog/ - *.html — Compiled static HTML blog posts - blogs/ - index.json — Blog posts JSON index - posts/ - *.md — Markdown source files for all blog posts - scripts/ - build.js — Full-stack build & compilation pipeline (1157 lines) - auto-update-dates.js — Git-based automatic date tracking - 404.html — Custom "Page Not Found" page - CNAME — Custom domain configuration (mkishore.is-a.dev) - feed.xml — RSS 2.0 feed for blog subscribers - guestbook.html — Guestbook powered by Giscus (GitHub Discussions) - humans.txt — humanstxt.org standard credits file - index.html — Main portfolio page (minified, 73KB) - llms-full.txt — Extended LLM profile with all project data - llms.txt — AI/LLM discovery spec (llmstxt.org) - manifest.webmanifest — PWA manifest (installable web app) - package.json — Project dependencies & npm scripts - projects.json — Machine-readable project index (17 projects) - robots.txt — Crawler directives + sitemap references - security.txt — Security contact metadata (RFC 9116) - sitemap.xml — Master sitemap index - sitemap-blog.xml — Blog post sitemap - sitemap-images.xml — Image sitemap for Google Images - sitemap-pages.xml — Page-level sitemap - vercel.json — Deployment config: clean URLs, security headers, caching ::: --- ## 4. Centralized Data Architecture (`assets/js/data.js`) To ensure both the web interface and the terminal CLI stay 100% in sync without duplicating data, I centralized the entire portfolio state inside `assets/js/data.js`. ```javascript const SITE_DATA = { profile: { name: "Kishore M", handle: "MKishoreDev", tagline: "Backend, API & Automation Engineer", location: "Tamil Nadu, India", bio: "Building high-performance APIs, automation tools, and minimal web applications." }, projects: [ { name: "Portfolio & Blog Engine", tags: ["Node.js", "Vanilla JS", "CSS3", "Markdown"], featured: true, github: "https://github.com/MKishoreDev/Portfolio", live: "https://mkishore.is-a.dev" } // ...17 projects total ], skills: { backend: ["Node.js", "Express", "Python", "REST APIs"], frontend: ["HTML5", "CSS3 (Vanilla)", "JavaScript (ES6+)", "Terminal UI"], tools: ["Git", "GitHub Actions", "VS Code", "Vercel"] } }; ``` Both `app.js` (which renders the web cards) and `terminal.js` (which handles CLI commands) consume this exact same data object. If I add a new project or skill in `data.js`, it instantly reflects across the UI and the terminal. --- ## 5. The Main Page Engine (`assets/js/app.js` — 1300+ Lines) The main `index.html` page is powered by `app.js`, which handles a surprising number of interactive features: ### Dynamic Age Calculation & Birthday System The site dynamically calculates my age from my DOB (`2009-08-05`) and injects it everywhere via `window.KISHORE_AGE`. But the real magic happens **on August 5th**: the page detects my birthday and triggers a full celebration mode—a birthday banner appears, a floating 🎂 emoji hat renders above my avatar, and an **HTML5 Canvas geometric confetti engine** (80 particles, circles and rectangles, fading out smoothly between 12–16 seconds) fires across the screen. Within 7 days before my birthday, a live countdown timer appears with digit boxes (`Days:Hours:Mins:Secs`) that auto-refreshes when it hits zero. ### Spotlight Cursor-Follow Effect A radial gradient spotlight follows your mouse cursor across the page, creating a dynamic lighting effect on cards and sections: ```javascript var el = document.getElementById('spotlight'); document.addEventListener('mousemove', function(e) { el.style.background = 'radial-gradient(circle at ' + e.clientX + 'px ' + e.clientY + 'px, ...)'; }); ``` ### Dynamic Blinking Terminal Favicon The browser tab favicon isn't static—it's a **dynamically generated canvas favicon** that blinks like a real terminal cursor. When the page is visible, a green blinking cursor animates in the favicon. When you switch tabs, it freezes to save resources: ```javascript var canvas = document.createElement('canvas'); canvas.width = 32; canvas.height = 32; var ctx = canvas.getContext('2d'); // Draw terminal prompt with blinking cursor setInterval(function() { cursorVisible = !cursorVisible; // Redraw favicon with/without cursor block dynamicFavicon.href = canvas.toDataURL('image/png'); }, 800); ``` ### Lazy-Loaded Project Screenshots Project preview images use `IntersectionObserver` for lazy loading. Images only load when the user scrolls them into view, keeping the initial page weight minimal: ```javascript function initProjectLazyLoad() { var lazyImages = document.querySelectorAll('.lazy-project-img'); var observer = new IntersectionObserver(function(entries) { entries.forEach(function(entry) { if (entry.isIntersecting) { var img = entry.target; img.src = img.dataset.src; // Load actual image observer.unobserve(img); } }); }); lazyImages.forEach(function(img) { observer.observe(img); }); } ``` ### Lazy-Loaded GitHub Contribution Graph The interactive GitHub contribution graph (`contributions.js`) is **only loaded when the user scrolls to that section**, keeping the initial page render instant: ```javascript var ghChart = document.querySelector('.lazy-ghchart'); var observer = new IntersectionObserver(function(entries) { if (entries[0].isIntersecting) { // Dynamically inject contributions.js script var script = document.createElement('script'); script.src = '/assets/js/contributions.min.js'; document.body.appendChild(script); observer.disconnect(); } }); observer.observe(ghChart); ``` ### Scroll-Triggered Section Reveal Animations Every section on the page uses `IntersectionObserver`-powered reveal animations. As you scroll, sections fade in with smooth CSS transitions: ```javascript var revealObserver = new IntersectionObserver(function(entries) { entries.forEach(function(e) { if (e.isIntersecting) { e.target.classList.add('visible'); revealObserver.unobserve(e.target); } }); }, { threshold: 0, rootMargin: '0px 0px -5% 0px' }); ``` ### Auto-Generated Table of Contents For blog posts, a floating Table of Contents sidebar is automatically generated from heading tags (`h2`, `h3`) with `IntersectionObserver`-based active heading tracking as the user scrolls. ### Dynamic Blog Section Rendering The blog section on the homepage dynamically renders the latest posts from `window.BLOG_POSTS`, with automatic section numbering that adjusts when sections are empty. ### Live Third-Party API Stats The stats section fetches real-time data from external APIs—but only when you scroll to it (lazy-loaded via `IntersectionObserver`): - **LeetCode Stats:** Total problems solved and global ranking via `alfa-leetcode-api.onrender.com`. - **MonkeyType Stats:** 60-second WPM speed and accuracy via `api.monkeytype.com`. ### Availability Calendar Grid An interactive weekly schedule matrix (Mon–Sun × Morning/Afternoon/Evening) renders busy, limited, or free status cells so visitors know when I'm available. ### Formspree Contact Form The contact form submits directly to Formspree via JSON `fetch` with interactive button states (Sending... → Sent! → Error fallback to `mailto:`). ### Konami Code Easter Egg Try pressing [[↑]] [[↑]] [[↓]] [[↓]] [[←]] [[→]] [[←]] [[→]] [[B]] [[A]] on the main page. It triggers **Matrix Mode**—rendering a full-screen Matrix digital rain animation and launching a `canvas-confetti` burst! ### Keyboard Shortcuts Modal Pressing [[?]] on any non-input element opens a shortcuts guide modal listing all available keyboard shortcuts. --- ## 6. The Interactive GitHub Contribution Graph (`assets/js/contributions.js`) This isn't just an image embed—it's a **fully interactive, custom-built GitHub contribution graph**: - Fetches real contribution data via CORS-friendly GitHub API. - Renders an interactive grid matching GitHub's exact layout (weekday labels, month columns). - **Hover tooltips** show contribution counts per day. - **Click modals** display detailed contribution info for any date. - **Year navigation** lets you browse contributions from 2021 onwards. - **Live streak counter** and highest contribution day stats. - **Hides future days** dynamically based on the current date. - Mobile-responsive with a dropdown year selector and stats grid. --- ## 7. The In-Browser Terminal Engine (`assets/js/terminal.js` — 1700+ Lines) Clicking the terminal icon (or pressing `~`) opens an interactive shell right in the browser. It isn't a fake animation—it's a real command-line event loop. ### All 41 Terminal Commands | Command | Description | | :--- | :--- | | `help` | Interactive ASCII command directory | | `whoami` | Profile specs (age, location, school, CS focus) | | `about` | Developer journey timeline (2021–2026) | | `skills [python\|js\|db]` | Technology breakdown with sub-argument filtering | | `projects [--all] [--lang=]` | Formatted project table with filters | | `project ` | Deep-dive into a specific project's stack and links | | `status` | Real-time availability and timezone | | `contact` | Social links (GitHub, LinkedIn, Telegram, Email) | | `social` | All social profile links | | `date` | Current IST time | | `uptime` | "up 4+ years, still compiling" | | `neofetch` | Custom Arch Linux ASCII logo + system info | | `echo ` | Echoes input text | | `github` | Live API fetch from `api.github.com` | | `leetcode` | Live API fetch for LeetCode stats | | `monkeytype` | Live API fetch for typing speed | | `weather` | Live weather for Tirunelveli from `wttr.in` | | `blog list` | ASCII table of all compiled blog posts | | `blog read ` | Fetches and renders full blog post inside terminal | | `guestbook` / `sign` | Redirects to guestbook page | | `history` | Displays command history | | `calc ` | Safe math expression evaluator | | `joke` | Random programming joke from API | | `advice` | Random advice from `api.adviceslip.com` | | `cat` | Random cat fact from `catfact.ninja` | | `space` | NASA Astronomy Picture of the Day | | `ip` | Your public IP address | | `qr ` | Generates QR code link | | `quote` / `fortune` | Random programming quote | | `theme` | Toggles site dark/light theme | | `who` | "kishore pts/0 (still compiling)" | | `cowsay ` | ASCII cow with speech bubble | | `sl` | Steam locomotive ASCII train animation | | `birthday` | Birthday status or days remaining countdown | | `ping [kishore]` | Simulates ICMP ping with random latency | | `curl [url]` | Simulates HTTP response with ASCII developer card | | `git log` | Formatted fake git commit history | | `secret` / `secrets` | Directory of secret commands | | `npm install kishore` | Animated progress bar package installation | | `sudo ` | ==See Easter Eggs section below== | | `matrix` | ==See Easter Eggs section below== | | `clear` | Clears terminal output buffer | ### Core Engine Features: - **Command History Stack:** [[Up Arrow]] and [[Down Arrow]] navigate through previous commands. - **Real-Time Ghost Text Autocomplete:** As you type, a greyed-out suggestion appears ahead of your cursor (like GitHub Copilot). Press [[Right Arrow]] or [[Tab]] to accept it. - **Typewriter Boot Sequence:** When the terminal opens, a time-based greeting ("Good morning", "Late night coding?") types out character-by-character at 12ms per char. - **Terminal Glitch Shake:** Error commands trigger a physical CSS shake animation on the terminal window. - **Mobile Keyboard Handling:** Uses `visualViewport` listener and scroll locking to prevent page jumps when the mobile virtual keyboard appears. --- ## 7b. Terminal Easter Eggs 🥚 > [!CAUTION] > **Spoiler Alert:** These are hidden features. Try them yourself before reading! ### `sudo rm -rf /` — Fake Kernel Panic Running any `sudo` command triggers **CRT monitor mode**. The terminal overlay goes full-screen, scanlines appear, and fake Linux kernel panic logs stream line-by-line. Then a **Red Sudo 404 / Unauthorized Access overlay** appears with a progress bar cycling through stages ("Locating IP address...", "Alerting Kishore..."), ending with a dramatic self-destruct sequence. Click anywhere to escape. ### `matrix` — Canvas Digital Rain Enters a full-screen HTML5 Canvas animation rendering **Matrix-style digital rain** with Japanese Katakana characters (`0x30A0`), random white glowing leader characters, and smooth fading trails. Click anywhere to exit. ### `npm install kishore` — Fake Package Install Simulates a real `npm install` with an animated ASCII progress bar (`[#### ] 40%`), package resolution logs, and dependency linking output. ### `cowsay ` — ASCII Cow Generates a classic ASCII cow with a speech bubble containing your custom message. ### `sl` — Steam Locomotive A full ASCII steam locomotive train animation runs across your terminal screen. --- ## 8. The Blog Engine (`assets/js/blog.js` — 714 Lines) The blog pages (`/blog/*` and `/blogs/*`) are powered by `blog.js`, which handles: 1. **Reading Progress Bar:** A horizontal progress bar at the top of every blog post that fills as you scroll through the article. 2. **Back-to-Top Button:** Appears when you scroll past the fold; smoothly scrolls back to the top. 3. **Image Lightbox:** Clicking any blog image opens a full-screen lightbox overlay with zoom capability. 4. **Copy Code Button:** Every fenced code block has a "Copy" button that copies the code to clipboard with visual feedback. 5. **Share Link Handler:** One-click sharing to Twitter, LinkedIn, and clipboard with encoded post metadata. 6. **Blog Listing Search & Filter:** The `/blogs` listing page supports real-time search filtering across post titles, summaries, and tags. 7. **Spotlight Cursor-Follow:** The same radial gradient mouse-follow effect from the main page. 8. **Interactive File Tree Explorer:** `:::filetree` containers have collapsible folder toggles that you can click to expand/collapse. 9. **Tab Switching Logic:** `:::tabs` containers have click-to-switch tab panels with state memory. 10. **Dynamic Blinking Favicon:** The terminal cursor favicon animates on blog pages too. 11. **Scroll Reveal Animations:** Blog content sections fade in with `IntersectionObserver`. 12. **Mobile Hamburger Menu:** Responsive navigation with animated open/close toggle. --- ## 9. The Guestbook & Giscus Integration Instead of building a custom comments backend, I integrated **Giscus** (GitHub Discussions as comments): ```javascript // Custom Giscus dark/light theme sync function sendGiscusTheme() { var iframe = document.querySelector('iframe.giscus-frame'); var isDark = document.documentElement.classList.contains('dark'); var themeUrl = isDark ? 'https://mkishore.is-a.dev/assets/css/giscus-dark.css' : 'https://mkishore.is-a.dev/assets/css/giscus-light.css'; iframe.contentWindow.postMessage( { giscus: { setConfig: { theme: themeUrl } } }, 'https://giscus.app' ); } ``` I wrote custom CSS theme files (`giscus-dark.css` and `giscus-light.css`) so the Giscus iframe perfectly matches the portfolio's glassmorphism aesthetic. A `MutationObserver` watches for dark/light mode toggles and instantly syncs the Giscus theme via `postMessage`. When I looked at SpEcHiDe's blog, I noticed he used **Telegram Auth** for post comments. While that works great for Telegram communities, I chose Giscus instead. Why? Because developers already carry GitHub credentials, comments remain archived in GitHub repositories, and it eliminates the need to maintain bot webhook polling servers just for blog comments. --- ## 10. The Custom Markdown Compiler (`scripts/build.js` — 1157 Lines) Instead of relying on Jekyll or Hugo, I built my own Node.js Markdown parser. ### Inline Formatting Rules ```javascript // Custom Glitch Text: [glitch:Text] str.replace(/\[glitch:(.+?)\]/g, '$1'); // Custom Neon Text: [neon:Text] str.replace(/\[neon:(.+?)\]/g, '$1'); // Keyboard Badges: [[Ctrl]] -> Ctrl str.replace(/\[\[([^\]]+)\]\]/g, '$1'); // Inline Mark Highlight: ==Highlight== str.replace(/==(.+?)==/g, '$1'); // Click-to-Reveal Spoiler: ||Spoiler|| str.replace(/\|\|(.+?)\|\|/g, '$1'); // Automatic GitHub Repo Badge Conversion // Detects raw github.com URLs and converts them into styled SVG repo badges ``` ### Custom Container Blocks (`:::`) :::tabs :::tab Tabs Container Tabbed panels with click-to-switch logic. ::: :::tab Filetree Explorer Interactive collapsible directory tree explorers. ::: :::tab Step Timelines Numbered step-by-step timelines. ::: :::tab Multi-Column Grid Responsive multi-column layout grids. ::: ::: ### GFM Alert Boxes > [!NOTE] > These callout boxes are parsed from `> [!NOTE]`, `> [!TIP]`, `> [!IMPORTANT]`, `> [!WARNING]`, and `> [!CAUTION]` markers. ### Schema.org JSON-LD Generator Every compiled blog post automatically embeds structured data: ```javascript function generateJSONLD(post) { return JSON.stringify({ "@context": "https://schema.org", "@type": "BlogPosting", "headline": post.title, "author": { "@type": "Person", "name": "Kishore M" }, "datePublished": post.date, "dateModified": post.updated || post.date, "description": post.summary }); } ``` ### Zero-Dependency Build-Time Multi-Language Syntax Highlighter Instead of bundling heavy client-side highlighters (which cause layout shift and extra browser JS execution overhead), `scripts/build.js` features a custom zero-dependency build-time code highlighter: - **Placeholder Tokenization System:** Uses non-word control character placeholders (`tok_N`) to extract strings, comments, object properties, constants, keywords, booleans, and numbers without regex collisions on HTML `class="..."` attributes. - **Order-Preserving Extractor:** Extracts multi-line strings and single-line strings *before* comment matching—preventing URLs inside strings (`https://schema.org`) from being misparsed as comments. - **JS Object Property & Constant Support:** Tokenizes JS object keys (`profile:`, `name:`) into `` and ALL_CAPS constants (`SITE_DATA`) into ``. - **Glassmorphic Terminal Code Cards:** Styled with translucent backdrop filters (`backdrop-filter: blur(12px)`), rounded corners, violet borders matching `--primary`, and curated HSL colors for all syntax tokens in external `style.css`. --- ## 11. The CSS Design System (`assets/css/style.css` — 128KB) The entire visual design runs on Vanilla CSS with no preprocessors: - **CSS Custom Properties:** 50+ design tokens (`--accent`, `--bg-glass`, `--text-primary`, etc.) for instant theme switching. - **Glassmorphism:** `backdrop-filter: blur(12px)` with semi-transparent backgrounds on cards, navigation, and terminal overlays. - **`@keyframes` Animations:** Glitch text effect, neon glow pulse, terminal cursor blink, skeleton loading shimmer, fade-in reveals, and spotlight gradient transitions. - **Responsive Breakpoints:** Mobile-first design with fluid typography using `clamp()` and container-aware layouts. - **Dark/Light Mode:** Full theming via CSS variables toggled by a single `.dark` class on ``. --- ## 12. GitHub Actions CI/CD Workflow Every push to `main` that touches blog content, assets, or build scripts triggers an automated **GitHub Actions CI/CD pipeline**: ```yaml name: 🚀 Blog Auto-Build CI/CD on: push: branches: [main] paths: ["blogs/**", "assets/**", "scripts/**", "index.html", "404.html"] workflow_dispatch: inputs: force_rebuild: description: "Force a full rebuild regardless of changes" ``` :::steps 1. **Checkout Repository:** Full git history (`fetch-depth: 0`) for accurate date tracking. 2. **Setup Node.js 22:** With npm cache for fast installs. 3. **Validate Blog Frontmatter:** Runs `scripts/validate-blogs.js` to catch missing titles, dates, or tags. 4. **Update Modification Dates:** Runs `scripts/auto-update-dates.js` — compares each post's body against its previous Git version. Only updates the `updated:` frontmatter field if the content actually changed. 5. **Build Production Assets:** `npm run build` triggers the full minification + compilation pipeline. 6. **Cache Busting:** Runs `scripts/cache-buster.js` to inject fresh version hashes. 7. **Sanity Check:** Verifies all required build artifacts exist (`index.html`, `feed.xml`, `sitemap.xml`, `projects.json`, `llms.txt`, `humans.txt`). 8. **Smart Commit & Push:** Only commits when there are actual content changes—prevents empty "rebuild" commits from cluttering history. Uses `github-actions[bot]` as the committer. ::: The workflow has **concurrency control** (`cancel-in-progress: true`) and **bot-loop prevention** (`if: github.actor != 'github-actions[bot]'`). --- ## 13. Vercel Deployment & Security Headers The site is deployed on **Vercel** with a custom `vercel.json` configuration: ```json { "cleanUrls": true, "headers": [ { "source": "/assets/(css|js)/(.*)\\.min\\.(css|js)", "headers": [{ "key": "Cache-Control", "value": "public, max-age=31536000, immutable" }] }, { "source": "/(.*)", "headers": [ { "key": "X-Content-Type-Options", "value": "nosniff" }, { "key": "X-Frame-Options", "value": "DENY" }, { "key": "Content-Security-Policy", "value": "default-src 'self' 'unsafe-inline' https: data:; object-src 'none';" }, { "key": "Permissions-Policy", "value": "geolocation=(), camera=(), microphone=(), payment=()" } ] } ] } ``` - **Clean URLs:** `/blog/my-post` instead of `/blog/my-post.html`. - **Immutable Caching:** Minified assets cached for 1 year with cache-busting version hashes. - **Security Headers:** CSP, X-Frame-Options DENY, nosniff, strict referrer policy, and locked-down Permissions-Policy. --- ## 14. Web Standards & Discovery Files Beyond the visible website, there's an entire layer of machine-readable discovery files: | File | Standard | Purpose | | :--- | :--- | :--- | | `robots.txt` | robotstxt.org | Crawler directives + 4 sitemap references | | `sitemap.xml` | Sitemap Protocol | Master sitemap index linking sub-sitemaps | | `sitemap-pages.xml` | Sitemap Protocol | Page-level URLs with `lastmod` dates | | `sitemap-blog.xml` | Sitemap Protocol | Blog post URLs with publication dates | | `sitemap-images.xml` | Sitemap Protocol | Image URLs for Google Images indexing | | `feed.xml` | RSS 2.0 | Blog subscription feed | | `humans.txt` | humanstxt.org | Human-readable credits: team, tools, standards | | `security.txt` | RFC 9116 | Security vulnerability reporting contact | | `llms.txt` | llmstxt.org | AI/LLM discovery with bio, projects, feeds | | `llms-full.txt` | llmstxt.org | Extended profile with all 17 projects | | `manifest.webmanifest` | W3C Web App Manifest | PWA installability (standalone display mode) | | `projects.json` | Custom JSON | Machine-readable project index (17 projects) | | `blogs/index.json` | Custom JSON | Machine-readable blog post index | --- ## 15. What Building This Portfolio Taught Me ### 1. Google Search Console & Meta Infrastructure Building this site taught me how Google Search Console crawls, indexes, and ranks URLs. I learned why structured metadata (OpenGraph tags, meta descriptions, canonical URLs, and Schema.org JSON-LD graphs) is the difference between a site that gets indexed in hours versus one that stays invisible. ### 2. Building a DB-Less Static Blog Architecture I learned how to construct a 100% database-less blog system. Markdown files, JSON indexes, and static HTML compilation = zero hosting costs, instant load times, and complete immunity to database downtime. ### 3. SEO Performance & Web Vitals By enforcing zero layout shifts (CLS), sub-50ms interaction to next paint (INP), and asset minification, the site scores a perfect 100/100 on Google Lighthouse. ### 4. Free Developer Subdomains & DNS Infrastructure I discovered the world of free developer subdomains (like `is-a.dev` → `mkishore.is-a.dev`). I learned how CNAME records, A records, DNS propagation, custom domain verification, and automated SSL/TLS certificates work under the hood. ### 5. Why XML & Plain Text Files Help AI Crawlers & Bots I learned why structured XML files (`sitemap.xml`, `feed.xml`) and plain text standards (`llms.txt`, `llms-full.txt`, `robots.txt`, `security.txt`, `humans.txt`) are essential for modern web discovery. Web traffic is no longer just humans in web browsers—AI agents, LLM scrapers, and automated bots actively index developer profiles. Providing clean XML feeds and standard `llms.txt` files allows AI search engines (like ChatGPT, Claude, and Perplexity) to index my projects, stack, and technical articles accurately without struggling through client-side JavaScript execution loops. --- ## 16. Things People Notice vs. Things People Don't :::grid columns=2 :::col ### Things People Notice ✨ - Glassmorphic backdrop filters and smooth dark theme - The interactive CLI terminal with real commands - Clean typography (Space Grotesk + Inter + JetBrains Mono) - Responsive card layouts with hover spotlight effects - Reading progress bar on blog posts - Image lightbox with full-screen zoom - Copy-to-clipboard buttons on code blocks ::: :::col ### Things People Don't Notice ⚙️ - Dynamic blinking terminal cursor as the browser favicon - Schema.org JSON-LD structured data on every page - Master sitemap index hierarchy (4 sub-sitemaps) - Per-page Git-tracked `Last Updated:` timestamps - `llms.txt` + `llms-full.txt` for AI/LLM discovery - `humans.txt` + `security.txt` web standards compliance - PWA manifest (site is installable as an app) - Content Security Policy and security headers - Lazy-loaded contribution graph via IntersectionObserver - Lazy-loaded project screenshots (images load on scroll) - Giscus iframe theme sync via postMessage + MutationObserver - Bot-loop prevention in CI/CD workflow - GitHub Actions concurrency control (cancel-in-progress) ::: ::: --- ## 17. How to Build Your Own Zero-Framework Portfolio (Blueprint) If you're a developer planning to build your own portfolio from scratch, here is the exact 5-step blueprint: :::steps 1. **Design System:** Create `index.html` and define CSS variables in `style.css` for colors, glassmorphic backdrop filters (`backdrop-filter: blur(12px)`), and responsive fonts (`Space Grotesk`, `Inter`, `JetBrains Mono` via Google Fonts). 2. **Centralize Data:** Create `data.js` containing your profile, project links, skills, and social handles in a single JavaScript object. Both your UI renderer and terminal CLI should read from this same source of truth. 3. **Build the CLI Terminal:** Write a JavaScript module (`terminal.js`) with an input listener for [[Enter]], [[Up Arrow]], [[Down Arrow]], and [[Tab]], mapping command strings to functions that output data from `data.js`. 4. **Create a Markdown Compiler:** Write a simple Node.js script using `fs` and regex to read Markdown files, wrap them in an HTML template, and output static HTML files. Add cache-busting version hashes (`?v=TIMESTAMP`) to asset references. 5. **Deploy & Add Free Domain:** Push to GitHub, deploy for free on Vercel or GitHub Pages. Register a free `is-a.dev` subdomain by opening a PR on the [is-a-dev/register](https://github.com/is-a-dev/register) repository. Add Giscus for comments, `robots.txt` for crawlers, and `sitemap.xml` for Google Search Console! ::: --- ## 18. Why Is My Portfolio Repository Private? People occasionally ask why my portfolio repository isn't open-source on GitHub. Here is the honest truth: 1. **Constant Instability:** I am constantly modifying styles, experimenting with build scripts, removing features, and pushing quick experimental commits. The codebase is often in flux and unstable. 2. **Personal Playground:** It's my personal scratchpad where I test ideas without worrying about maintaining a clean public repository structure. > [!TIP] > **Want the Source Code?** > > If you're interested in how this portfolio is built or want to use the architecture for your own site... **let me know!** > > Scroll down and leave a message on the [Guestbook](/guestbook) or send me a message on LinkedIn. If enough people are interested in the code, I'll gladly clean it up, make it modular and easy to edit, and open-source it for everyone! --- ## Final Thoughts Building your own portfolio from scratch—instead of relying on templates—teaches you how the web actually works under the hood. You learn regex parsing, DOM manipulation, CSS layout math, build performance, RSS spec formatting, SEO structured data, security headers, CI/CD automation, and DNS infrastructure. I still have a long backlog of improvement ideas I brainstormed while building this—like interactive API playgrounds, live terminal WebSocket relays, and custom RSS topic filters. I intentionally held back on implementing all of them at once to keep the initial build focused, fast, and stable instead of over-engineering. Good software isn't built all at once; it evolves over time. This portfolio is more than just a place to display my projects. It's a living playground where I test ideas, experiment with systems, and refine my engineering skills. Thank you for reading! --- **P.S.** The build script that generated this exact page took `1.2 seconds` to minify assets, parse Markdown, build sitemaps, update RSS feeds, and render static HTML. Zero frameworks required. ============================================================ ### Post: my-first-hackathon URL: https://mkishore.is-a.dev/blog/my-first-hackathon --- title: "My First Hackathon Certificate" date: "2026-07-20" updated: "2026-08-05" summary: "A participation certificate usually isn't something people celebrate. But this one reminds me of my first hackathon, my first real team project, and the experience that quietly changed how I think about learning, teamwork, and growth." tags: ["journey", "technology"] cover: "/assets/images/blog/my-first-hackathon-certificate.png" draft: false --- # My First Hackathon Certificate > *Sometimes, the first certificate you receive isn't proof of what you've achieved. It's a reminder of where everything began.* ![My First Hackathon Certificate](/assets/images/blog/my-first-hackathon-certificate.png "My First Hackathon Certificate") Today, I finally received the medal and certificate from my very first hackathon. Someone looked at it and casually said, > *"It's just a participation certificate."* I smiled. Because they weren't wrong. It **is** a participation certificate. It doesn't say *Winner.* It doesn't say *Runner-Up.* It doesn't even say we qualified for the next round. Yet somehow... it's one of the most meaningful certificates I've ever received. Not because of what it says. But because of everything it reminds me of. To understand why, we have to go back to where it all started. --- ## It started on an ordinary school day If someone had asked me that morning whether I'd be writing a blog post about that day years later, I probably would've laughed. It was just another Computer Science period during Class 11. The bell rang. Everyone was getting ready to leave the Computer Science lab. We were about to leave when our Computer Science teacher stopped us. She told us something unexpected. There was going to be a hackathon exclusively for Kendriya Vidyalaya students. There would be multiple rounds—regional, zonal, and perhaps even further for the teams that qualified. Our school could send two senior teams—one boys' team and one girls' team. I had heard the word **hackathon** before. But I had never participated in one. To me, it sounded exciting. Not because I imagined winning. Not because it meant missing classes. But because I finally had an opportunity to build something outside the classroom. I simply thought I was signing up for a competition. I didn't realize I was signing up for a lesson I'd remember years later. That single announcement would quietly become one of the biggest turning points in my journey. --- ## Building a team Like most school competitions, we had to form a team. Five members. No more. No less. My friend **Chris Jeyan** joined almost immediately. Both of us already had a little programming experience. Nothing extraordinary. We weren't experts. We were simply curious enough to spend our free time learning things beyond our syllabus. The remaining three members were also friends, but each of them had their own reason for joining. One chose Computer Science simply because our school didn't offer Commerce, and he preferred staying in a familiar environment instead of changing schools. Another joined because he assumed the coding work would mostly be handled by the rest of us. The last teammate had other priorities, so the hackathon wasn't his main focus. At that time, none of this seemed important. I thought we all had the same goal. Looking back... we really didn't. --- ## "Tech Shifter" Every team needed a name. Our mentor—who was also our Computer Science teacher—named ours: **Tech Shifter.** Even today, whenever I think about that name, I can't help but laugh. **Tech Shifter.** I'm still not entirely sure what exactly got shifted. Maybe our perspective. Maybe our confidence. Maybe just our classroom. Whatever it was... the name stayed with us throughout the competition. --- ## The bootcamps Before the regional round, AI VidyaSetu organized a series of bootcamps to prepare participants. For me, they were unlike anything I'd experienced before. Instead of memorizing textbook definitions for an exam, we were introduced to concepts that actually solved problems. Searching algorithms. Logical thinking. Computational problem solving. Programming challenges. At the time... it felt overwhelming. If I'm being completely honest, I don't think anyone in my team truly understood everything being taught. Including me. We listened, took notes, and tried our best to keep up, but many of the concepts felt completely new. I remember sitting there thinking, *"How do people even come up with solutions like this?"* Today, after spending more time learning Data Structures and Algorithms, many of those problems seem surprisingly straightforward. Funny how learning works. The questions didn't become easier. I simply became better equipped to understand them. Looking back now, I have one regret. I wish I had taken those bootcamps more seriously. Not because they would've guaranteed a better result. But because opportunities like that don't come around every day. Sometimes you only realize how valuable an opportunity was after it's already gone. --- ## Skipping classes... accidentally The bootcamps happened during school hours. This meant we occasionally had to leave regular classes to attend them. As a Class 11 student... I wasn't exactly complaining. Who wouldn't enjoy escaping a few lectures? But surprisingly, not every teacher saw it that way. We weren't skipping classes for fun. We were attending sessions that the school itself had nominated us for. Ironically, that was difficult for a few teachers to believe. I always found that a little funny. We weren't wandering around campus. We weren't wasting time. We were officially representing our school in a national-level student initiative. Still, from their perspective, it probably looked like another excuse to miss class. I don't blame them. But I remember thinking, *"We're actually trying to learn something here."* Ironically, those sessions taught me more about problem-solving than many of the classes I missed. --- ## Looking back At the time, I thought the hackathon was about building a project. I thought success meant qualifying for the next round. I thought technical knowledge alone would make the difference. I couldn't have been more wrong. The real lessons hadn't even begun yet. The regional round was still ahead. And so was the disappointment that would eventually change the way I thought about teamwork, responsibility, and learning itself. That, however... is a story for the next chapter. --- ## The day everything felt real Eventually, the day arrived. The regional round. The excitement that had been building over the previous weeks suddenly became real. No more bootcamps. No more "we'll learn it later." This was the day we had to apply whatever we had learned. Looking back, I don't remember waking up nervous. I remember waking up excited. It was my first hackathon. I was finally going to experience something I'd only heard developers talk about online. --- ## We weren't the same team I imagined Before the competition, I believed something that, in hindsight, was incredibly naive. I thought everyone on the team wanted the same thing. I assumed everyone wanted to learn. I assumed everyone would spend time preparing. I assumed everyone was just as curious as I was. They weren't. And that's perfectly okay. People join the same event for completely different reasons. Some genuinely wanted to learn. Some simply wanted the experience. Some enjoyed the opportunity to miss a few regular classes. Some probably joined because their friends were joining. None of those reasons are wrong. They're just... different. The problem wasn't that people had different motivations. The problem was that I expected everyone to think like I did. That expectation quietly became the biggest mistake I made throughout the entire hackathon. --- ## The questions Once the competition started... reality hit. The problems weren't impossible. They were simply unfamiliar. Many questions tested logical thinking. Some involved searching techniques. Some required programming concepts that weren't part of our everyday school lessons. A few even touched on Object-Oriented Programming. At that moment, everything felt difficult. I kept staring at certain questions, wondering, *"Where do I even begin?"* It's funny how perspective changes. Today, if someone handed me those same questions, I'd probably approach them very differently. Not because the questions became easier. Because I've spent the last year learning things I didn't know back then. That's one of my favorite things about learning. The mountain you once struggled to climb eventually becomes a hill you barely notice. --- ## Looking for someone to blame When the pressure started building... I made another mistake. I looked for someone to blame. My friend Chris was our team leader. Whenever something didn't go as planned, I quietly blamed him. Maybe we should've prepared differently. Maybe the team should've organized things better. Maybe someone should've taken more responsibility. Back then, it felt easy to point at the person leading the team. Today... I regret doing that. Looking back, I wasn't completely right, and I wasn't completely wrong either. Every team member, including me, could have contributed more. Leadership is one of those responsibilities that seems simple until you're the one carrying it. Making decisions for five different people isn't easy. Keeping everyone motivated isn't easy. Making sure everyone contributes equally isn't easy. Chris wasn't perfect. None of us were. Including me. Looking back now, I realize something important. Instead of asking, *"Why didn't my teammates do more?"* I should've asked, *"What more could I have done?"* That single question changed the way I think about teamwork. --- ## The result A few days later... the results were announced. We hadn't qualified for the zonal round. It was over. I remember feeling disappointed. Not because I expected a trophy. But because I genuinely believed we had a chance. For the next few days, I kept replaying everything in my head. What if we had prepared more? What if I had paid closer attention during the bootcamps? What if our team had communicated better? What if... Like most "what if" questions... none of them changed the outcome. --- ## A question I'll never forget Then something happened that stayed with me far longer than the result itself. Our Computer Science teacher looked at me and asked, > **"Kishore, what happened? You didn't qualify?"** That question caught me completely off guard. I wasn't the team leader. I wasn't the person responsible for every decision. Yet somehow... she expected more from me. At first, I didn't understand why. Later, I realized something. Maybe she wasn't asking because she expected me to win. Maybe she asked because she knew I cared. And if I'm being honest... I expected more from myself too. Not because we lost. But because I knew I could've contributed more. That question stayed with me long after the competition ended. It wasn't about qualifying. It became a reminder that responsibility isn't something you're officially given. Sometimes people simply trust you enough to expect more. And when they do... you either grow into that expectation... or learn from falling short of it. --- ## The biggest lesson wasn't technical For a long time, I believed that hackathons were mainly about coding. Winning. Building projects. Learning new technologies. Those things certainly matter. But they're not what stayed with me. What stayed with me was understanding people. Understanding that curiosity can't be forced. Ownership can't be assigned. Motivation can't be borrowed. A team isn't simply five people working on the same project. It's five people moving toward the same goal. When those goals are different... even talented people struggle to work together. That realization eventually became one of the most meaningful things I've ever shared on LinkedIn. The post wasn't really about the hackathon. It was about the people. The expectations. The lessons. Because when I looked back... I realized the hackathon hadn't taught me algorithms. It had quietly taught me something much harder. How to become a better teammate. And more importantly... how to become a better person. --- When the competition ended, I thought the story had ended too. I put the experience behind me. Moved on to new projects. Learned new technologies. Built new things. Life continued. I never imagined that almost a year later... a simple medal and a participation certificate would bring every one of those memories back. --- ## Almost a year later Life moved on. School became busier. Projects replaced old memories. The hackathon slowly became another chapter of my journey. Until today. Like most school days, I walked into the classroom a little late. One of my teammates looked at me and said, > **"Hey, we got our hackathon medals!"** For a moment, I was confused. *"Medals?"* I knew we'd eventually receive participation certificates. But I never expected there would be medals too. When I looked towards the front of the classroom, our Computer Science teacher had already placed the medals and certificates on the table. One by one, she called our names. When mine was called, I walked up, collected my certificate and medal, thanked her, and returned to my seat. It wasn't a grand moment. There were no cameras. No speeches. No celebration. Just another ordinary school day. But as I sat there holding that certificate, something felt different. I wasn't looking at a medal. I was looking at memories. Memories of my first hackathon. The bootcamps. The excitement. The disappointment of not qualifying. The lessons I didn't realize I was learning. For everyone else, it was probably just a participation certificate. For me... it was a reminder of where everything began. --- ## "It's just a participation certificate." While everyone was collecting their certificates, I overheard a few classmates talking. Some said, > *"It's just a participation certificate."* > *"Maybe I should've gone too, because they're giving it for no reason—just for wasting time and skipping classes."* Others joked that they could've joined too. Maybe they were right. Maybe anyone could have participated. But not everyone did. And that's what made me stop and think. A participation certificate isn't valuable because it says *Participation.* Its value comes from **what you participated in.** If you frame a participation certificate simply as *"I showed up,"* then yes, it doesn't sound very special. But if that participation becomes the beginning of something much bigger... then suddenly that small piece of paper means a lot more. --- ## More than paper When I looked at the certificate again, I realized it wasn't reminding me of the result. It reminded me of everything around the result. It reminded me of rushing to the computer lab after classes. The bootcamps. The confusing algorithm questions. The excitement of getting our participant medals. The conversations with teammates. The disappointment of not qualifying. My teacher asking, > **"Kishore, what happened?"** And the lessons I didn't realize I was learning at the time. Funny enough... I don't even remember every question from that hackathon anymore. But I remember exactly how it made me feel. That's probably how memories work. You rarely remember every detail. You remember how something changed you. --- ## The first chapter Sometimes we celebrate the wrong things. Winning is celebrated. Certificates are celebrated. Medals are celebrated. Those moments deserve recognition. But I think we forget to celebrate beginnings. Nobody celebrates their first line of code. Nobody frames the first project that never worked. Nobody proudly talks about the bug that took three days to solve. Yet those moments are where every story begins. This certificate isn't my biggest achievement. Not even close. But it represents the beginning of many achievements that came afterwards. Without this hackathon... there might never have been the confidence to build larger projects. There might never have been the curiosity that pushed me deeper into backend development. Maybe I wouldn't have started documenting my journey. Maybe this blog wouldn't even exist. Sometimes one ordinary experience quietly changes the direction of everything that follows. You don't notice it while it's happening. You only recognize it when you look back. --- ## Looking at the younger version of me Sometimes I think about the Class 11 version of myself. The one who walked into the hackathon believing technical skills alone would solve everything. The one who expected every teammate to care as much as he did. The one who blamed others before questioning himself. The one who thought not qualifying meant failure. If I could go back and tell him one thing, it would probably be this: > **"You'll learn far more from this experience than you realize."** Not immediately. Not next week. Maybe not even next month. But eventually. Because growth is strange. Sometimes the biggest lessons don't arrive when the event ends. They arrive months later... when you finally understand what the experience was trying to teach you. --- ## Why I wanted to write this A few months ago, I shared a LinkedIn post about the biggest lesson this hackathon taught me. It wasn't really about the competition. It was about teamwork. Ownership. Choosing the right circle. That post told the lesson. This blog tells the story behind it. Social media is great for sharing moments. But some moments deserve more than a timeline. Some deserve a place where they can stay. Years from now, I know I'll forget the number of likes that LinkedIn post received. But I hope I never forget why I wrote it. Or why this certificate mattered enough to deserve an entire blog. --- ## What this certificate really represents Today, if someone asked me what this certificate means... I wouldn't say, *"It's my participation certificate."* I'd say, *"It's my first hackathon."* It's the first time I worked on a problem bigger than a classroom assignment. The first time I experienced the excitement and pressure of building something as a team. The first time I realized that learning doesn't always happen inside a textbook. The first time I understood that failure and growth often arrive together. And perhaps most importantly... the first time I discovered that curiosity rewards those who keep showing up. Every developer has a beginning. Some remember their first "Hello, World." Some remember their first Git commit. Some remember their first open-source contribution. When I think about mine... I'll always remember this hackathon. --- ## Before I end this story Maybe this medal won't impress everyone. Maybe this certificate will always be "just a participation certificate" to some people. That's okay. Not every achievement has to be understood by everyone. Its value doesn't come from how others see it. It comes from what it represents to the person holding it. Years from now, someone might ask me, > **"Where did your journey as a developer really begin?"** I probably won't open GitHub. I won't show my portfolio. I won't start with my latest project. I'll probably smile... take out this certificate... and say, > **"It started here."** Not because this was my greatest achievement. But because every great journey deserves to remember its first step. --- **The certificate says "Participation."** **The memories say "Beginning."** ============================================================ ### Post: no-longer-a-16-year-old-developer URL: https://mkishore.is-a.dev/blog/no-longer-a-16-year-old-developer --- title: "No Longer a 16-Year-Old Developer" date: "2026-08-05" updated: "2026-08-05" summary: "Waking up expecting an ordinary day, quiet realizations in the classroom, and an unexpected flood of wishes from complete strangers on LinkedIn. A deep reflection on turning 17, outgrowing superficial celebrations, dropping the age badge, writing to my future self, and discovering the quiet power of building in public." tags: ["reflection", "journey"] cover: "/assets/images/blog/no-longer-a-16-year-old-developer.png" draft: false --- # No Longer a 16-Year-Old Developer > *Sometimes the people who know you least are the ones who pay the most attention to what you build. And sometimes, that is where real connection begins.* ![No Longer a 16-Year-Old Developer](/assets/images/blog/no-longer-a-16-year-old-developer.png "No Longer a 16-Year-Old Developer") --- If you've followed my blog for a while, you know I don't usually write about personal milestones. I write about technical mistakes, lost repositories, old usernames, and the strange feeling of learning to code before the AI boom. Today is different. Today, August 5th, I officially turned [glitch:17]. No party. No new clothes. No loud celebrations. No treats. Instead of going out or celebrating like most people expect a teenager to do, I came back to my desk, opened my code editor, and sat down to write this post. Not because I want to mark another birthday. But because waking up today made me realize just how much my mindset has shifted over the past twelve months. --- ## 06:00 AM — A Quiet Morning My alarm went off as usual. I opened my eyes, rubbed my face, and reached for my phone—the same morning routine I've had for years. I wasn't expecting anything special. To be honest, I approached the day treating it like any ordinary Wednesday. When I unlocked my screen, the first notification I saw was a message from a guy online. He wasn't a close friend. We had only exchanged a few brief messages in tech groups months ago. But he had manually saved my birthday on his calendar, and when the date arrived, he took a moment to write a genuine wish. That small, intentional gesture hit me surprisingly deep. Meanwhile, online friends who used to remember in previous years had completely forgotten. A few friends from school sent quick wishes. And at home in the morning? My parents didn't mention it before I left for school—not because they don't care, but because in our family tradition, we follow customs and celebrate the ||**Nakshatra / Star Birthday**|| instead. *(Later in the afternoon, when I returned home from school, my parents wished me warm birthday wishes, which felt really nice.)* Still, in the quiet hours of that morning before leaving home, if I'm being completely honest with myself... a small part of me had secretly hoped for a simple, quiet *"Happy Birthday"* when I woke up. I didn't get it then. And as I packed my bag for school, I realized that was okay. --- ## The Classroom and The Chocolate Realization When I got to school, one of my friends who had wished me earlier casually announced to the class that it was my birthday. Within seconds, people started coming over. *"Happy Birthday, man!"* And almost immediately followed by: *"Where's the treat? Did you bring chocolates today?"* I stood there by my desk, looking at the familiar faces in the classroom, and my mind quietly drifted back. On my 16th birthday, I was excited. I bought boxes of chocolates for the entire class. I spent my own money, distributed them to everyone, gave treats, and felt happy just sharing the moment. Over the past year, as classmate after classmate celebrated their birthdays, a few people brought treats too—but as time went on, most people simply stopped. It was never about the food or expecting chocolates in return. I used to go to treats, and I gave treats too. It was the sudden realization of the mindset behind it. Standing there in the middle of the morning noise, a sharp, quiet realization hit me: > *People often ask "Where's the treat?" out of habit and social routine, not because they genuinely care about the person or the milestone.* Why was I stressing myself out trying to live up to expectations from people who didn't actually care about the day itself? It wasn't anger. It wasn't resentment. It was simply **clarity**. I realized right then that I had outgrown the need for forced smiles, artificial excitement, and worrying about whether I handed out chocolates. If people only notice the date to ask for a treat, that attention was never real in the first place. So I stopped caring about it. --- ## The Unexpected Inbox By the time I got home from school, I was exhausted. I threw my backpack onto the chair, sat down at my desk, and opened LinkedIn on my laptop to check notifications. I genuinely expected nothing. After all, the people I talked to earlier in the day hadn't wished me. Former online acquaintances hadn't messaged. To my absolute shock... my notifications were buzzing. Dozens of birthday wishes had poured in on LinkedIn. But here is the part that surprised me most: It wasn't former close friends. It wasn't people I used to chat with every day. > [!NOTE] > **The Strange Nature of the Internet** > > The messages came almost exclusively from **random connections and complete strangers**. > > People I had never met in person. Developers who found my GitHub. Designers who stumbled upon my portfolio. Connections on LinkedIn who only knew me through the code I write, the projects I build, and the technical stories I post online. Complete strangers took time out of their busy days to type out thoughtful, encouraging messages. Sitting in the quiet of my room, looking at those notifications, I couldn't help but smile. It brought a profound realization about why I put my work on the internet in the first place. When you build things and share your journey publicly, you aren't just pushing code into a repository. You are dropping a signal into the dark. And occasionally, that signal reaches people who genuinely respect the effort—even if they don't know your real-life name, your face, or where you live. > [!IMPORTANT] > **Signal Over Noise** > > When you build in public, the people who connect with you aren't doing it out of social obligation or classroom proximity. They're connecting with your work, your mindset, and your growth. That is the purest form of networking. The internet remembered my birthday when I least expected it. And that meant more to me than any classroom chocolate ever could. --- ## The Bittersweet Shift: Dropping the Age Badge There is a subtle, bittersweet feeling that came over me today. For the past year, whenever I introduced myself in developer communities, open-source forums, or chat groups, I used a sentence that felt like a shield: > *"Hi, I'm a 16-year-old student developer."* That age tag felt like a comfortable badge. It gave me room to make mistakes. It made small achievements look bigger. It was a comfortable identity I carried everywhere. Today, I can't say that anymore. > [!CAUTION] > **The Trap of Age Badges** > > Relying on your age to make your work sound impressive is a trap. It lowers expectations and encourages people to grade your work on a curve. > > Dropping that shield at 17 is necessary. I don't want my projects to be called "good for a teenager." I want my code to hold up on its own engineering merits, regardless of birth year. Saying *"I'm 17"* feels different. It feels like childhood is quietly closing its doors behind me, and adulthood is standing on the other side of the threshold. The buffer zone is shrinking. Real responsibilities, board exams, college decisions, and career choices are no longer distant concepts—they're right here. Yet, looking back at 16, I'm incredibly grateful for what that single year forced me to become: :::steps 1. **Getting Back on Track** Overcoming burnout, letting go of old dead-end habits, and rebuilding my daily coding focus. 2. **Building a Custom Portfolio** Designing and compiling this entire site from scratch—no cookie-cutter templates, just custom HTML, CSS, and markdown compiler scripts. *(Note: The portfolio repository itself is private, but if you're ever curious about its architecture or how the compiler works, feel free to ask me!)* 3. **Documenting the Journey** Writing articles like *"The Username That Started Everything"* and *"Where Did Everything Go?"* to share my story openly. 4. **Building in Public** Setting up my LinkedIn profile, connecting with developers worldwide, and sharing project updates consistently. 5. **Shipping Real Code** Learning modern backend architecture, API design, and automation tools while balancing schoolwork. ::: One year ago, I was figuring out who I wanted to be. Today, I know what I'm capable of building. --- ## Mindset Over Milestones If you asked younger me what a birthday should look like, he would have described: * New clothes. * A party with friends. * A big cake. * Treats and gifts. Today, I had none of those things. And honestly? I didn't miss a single one of them. Maturity isn't measured by the number of candles on a cake or how many people show up to your party. Maturity is realizing that peace of mind is better than noise. It's understanding that a quiet evening spent writing code, thinking deeply, and crafting a blog post is far more fulfilling than chasing superficial validation. --- > [!TIP] > **A Note on Building in Public** > > If you're a young developer hesitant to post your work online... **just start**. > > Write about the bug you spent three hours fixing. Share the project even if it's incomplete. Create a LinkedIn profile even if you feel like you have nothing "impressive" to show yet. > > The internet is full of noise, but authentic effort acts like a magnet. The genuine connections you make by putting your real work out there will outlast almost any local school friendship built on convenience. --- ## Looking Forward: Seventeen, Still Learning A year from today, when August 5, 2027 arrives: * I'll have finished my Class 12 Board Exams and received my marks. * I'll likely be deciding which college to attend and preparing for the next chapter of my education. * The projects that are currently just rough sketches in my notebook will hopefully be live, deployed systems used by real people. * I'll have built dozens of new things, broken code, fixed bugs, learned new concepts, and grown even further. I don't know exactly what the future looks like. Nobody does. But I know one thing for certain: I will still be sitting at my desk. Still curious. Still learning. And still building. --- ## A Message to My Future Self If you're reading this years from now—maybe when you're 18, 20, or even older: I hope you haven't forgotten how this day felt. I hope you've stepped into places where you are genuinely valued for who you are and what you build—not just for what you can give or what treats you bring. I hope you're surrounded by people who are just as curious, passionate, and driven as you are. People who challenge you, inspire you, and value you no matter what stage of life you're in. I hope you haven't traded raw curiosity for ego or vanity metrics. I hope you're still building things simply because you love bringing ideas to life, not just because you want stars, titles, or external applause. Right now, sitting at this desk at 17, I have board exams ahead, college decisions to make, and a long road of engineering to master. Things feel challenging, messy, and exciting all at once. If future you has achieved big things... **stay humble**. Remember the kid who built his first bot under a Pokémon fan username, who deleted his accounts by mistake, who sat in an empty classroom on his 17th birthday realizing he didn't need chocolates to prove his worth, and who found genuine joy writing code in the quiet of his room. And if future you is going through a tough phase... **remember that you've restarted before**. You survived lost repositories, lost usernames, and lost direction, and you always found your way back to the keyboard. Never stop being curious. Never stop building. --- ## Closing Thoughts To the guy who saved my birthday on his calendar: thank you. To my friends at school who remembered: I appreciate you. And to the complete strangers on LinkedIn who took a moment to write a message to a teenage developer they've never met: you made a quiet day feel unforgettable. To my 16-year-old self: thank you for starting. Thank you for staying up late, for pushing through broken code, for building this portfolio, and for refusing to give up when things felt messy. Seventeen is here. Time to build even more. --- **P.S.** If you're reading this on the day it was published: no treats, no chocolates. Just code, writing, and another year of growth. Thanks for reading. ============================================================ ### Post: prompt URL: https://mkishore.is-a.dev/blog/prompt --- title: "AI Blogging Prompt & Spec" draft: true --- # 🤖 AI Blogging Prompt & Format Specification If you are an AI assistant writing or editing a blog post for this developer portfolio, follow the precise formatting rules below. The site uses a custom, zero-dependency Markdown-to-HTML compiler (`build.js`). Adhering strictly to these rules ensures that the blog post compiles perfectly and renders with all premium features. --- ## 📋 Standard YAML Frontmatter Every blog post file MUST start with a YAML frontmatter block between `---` markers. Do not add text before this block. ```yaml --- title: "Title of Your Post" # String: Clear, catchy title date: "YYYY-MM-DD" # String: Publication date (e.g., "2026-07-20") updated: "YYYY-MM-DD" # String: Optional. Last modified date summary: "1-2 sentence description" # String: Shown on cards & meta headers for SEO tags: ["technology", "guide"] # Array: 1-5 tags. MUST use ONLY these 4 categories: ["technology", "journey", "reflection", "guide"] draft: false # Boolean: true excludes post from homepage/sitemap/RSS cover: "/assets/images/thumbnail.png" # String: Thumbnail/social preview. Also accepts `image` --- ``` --- ## 🎨 Formats A to Z (Specification Guide) ### A — Alerts / Callouts (GFM style) Alerts are styled message boxes. Place them on lines starting with a blockquote marker `>` followed by `[!TYPE]`: * `> [!NOTE]` — Blue/Neutral information box. * `> [!TIP]` — Green recommendation/tip box. * `> [!IMPORTANT]` — Purple emphasis box. * `> [!WARNING]` — Amber warning box. * `> [!CAUTION]` — Red warning/alert box. *Example:* ```markdown > [!TIP] > Keep your code modular and use standard environment variables. ``` ### B — Bold, Italic, and Bold-Italic Standard inline font formatting styles: * **Bold**: Wrap in double asterisks `**text**` * *Italic*: Wrap in single asterisks `*text*` * ***Bold-Italic***: Wrap in triple asterisks `***text***` ### C — Code Blocks & Inline Code * **Fenced Code Blocks**: Wrap in triple backticks. Add the language identifier right after the opening backticks (e.g., `python`, `javascript`, `bash`). The compiler automatically adds a **Copy** button and a language badge. * **Inline Code**: Wrap in single backticks `` `code` ``. *Example:* ```markdown Here is `inline code`. Below is a fenced block: ```python def greet(name): return f"Hello, {name}!" ``` ``` ### D — Definition Lists Useful for dictionary-like terms or quick glossaries: * Write the term on its own line. * Follow it immediately with lines starting with a colon `:` and a space. *Example:* ```markdown API : Application Programming Interface. : A set of protocols for building and integrating application software. ``` ### E — External Links & Images * **External Links**: Written as `[text](url)`. If the URL starts with `http` or `https`, the compiler automatically appends `target="_blank" rel="noreferrer noopener"`. * **Bare URLs**: Plain URLs in text like `https://example.com` are automatically converted to clickable links. * **Images**: Written as `![Alt Text](image-path "Optional Title/Caption")`. The title/caption is shown beneath the image, and images are lazy-loaded by default. ### F — Footnotes Used for references or sidebar explanations: * Insert a reference inside the text using `[^key]`. * Define the footnote on its own line using `[^key]: Explanation text`. * Footnotes are automatically numbered and back-linked at the bottom of the compiled page. *Example:* ```markdown According to a recent study,[^1] Python is highly preferred. [^1]: Developer Survey 2026. ``` ### G — GitHub Repository Badges Any link pointing exactly to a GitHub repository URL (e.g. `https://github.com/owner/repo` or a markdown link to it) is automatically converted by the compiler into a styled inline badge containing the GitHub icon and the `owner/repo` path. This supports both dark and light modes with smooth interactive hover states. *Example:* ```markdown Check out [Howdoi Bot](https://github.com/MKishoreDev/Howdoi-bot) for the code. Or just write the bare URL: https://github.com/MKishoreDev/Howdoi-bot ``` ### H — Headings * Use standard ATX headings: `# Header` to `###### Header`. * **Note on H1**: Since the article's title is automatically treated as the page's `

`, any H1 `#` inside the body is automatically demoted to H2 `

` by the compiler. * Headings up to H3 `###` are automatically indexed into the sticky sidebar Table of Contents. ### I — Inline Horizontal Rules Create clean section dividers using three or more asterisks (`***`), dashes (`---`), or underscores (`___`) on a line by themselves. ### J — Glitch & Neon Inline Highlights * **Glitch Text**: Wrap text inside `[glitch:text]`. Applies a continuous neon glitch distortion effect. * **Neon Glowing Text**: Wrap text inside `[neon:text]`. Applies a color-matching soft neon glow. *Example:* ```markdown This is [glitch:glitchy text] and this is [neon:glowing text]. ``` ### K — Keyboard Keys (KBD) Render keyboard shortcuts with standard CSS keycaps by wrapping the key name in double square brackets: * `[[Ctrl]]` → Ctrl * `[[Ctrl]] + [[C]]` → Ctrl + C ### L — Lists (Nested & Task) * **Unordered lists**: Use `-`, `*`, or `+`. * **Ordered lists**: Use numbers followed by a dot or parenthesis (e.g., `1.` or `2)`). * **Task lists**: Use `- [ ]` for unchecked and `- [x]` for checked items. * **Nesting**: Indent nested items with two or more spaces. *Example:* ```markdown - [x] Write prompt guide - [ ] Implement features - [ ] Nested child task ``` ### O — Bento Column Grids (Block) Create clean multi-column layouts (like Bento Cards) that automatically stack vertically on smaller mobile viewports. * Start with `:::grid columns=N` (N defaults to 2 if omitted). * Wrap columns inside `:::col` tags. * End the grid block with `:::`. *Example:* ```markdown :::grid columns=2 :::col #### Card 1 This is the left side card content. :::col #### Card 2 This is the right side card content. ::: ``` ### P — Paragraphs & Line Breaks * Separate paragraphs with a blank line. * **Hard line breaks**: End a line with two spaces (` `) and then press Enter. ### Q — Stepped Timeline Steps (Block) Render nested ordered lists as a modern timeline steps stepper. * Start with `:::steps`. * Put an ordered list (`1.`, `2.`, etc.) inside the block. * End the steps block with `:::`. *Example:* ```markdown :::steps 1. **Prepare Workspace**: Clone repository. 2. **Install dependencies**: Run script. ::: ``` ### R — Raw HTML Blocks (Pass-Through) The compiler directly passes through five block-level HTML tags without modification: `
`, `
`, `
`, `
`, and `