From a CMS in a College Dorm to Full Stack Engineering: My First Two Years in Tech

Aman Thakur Posted on Jul 12 From a CMS in a College Dorm to Full Stack Engineering: My First Two Years in Tech #programming #beginners #career #webdev I still remember the first time I saw a production bug crash right in front of a client, live, during a demo. My hands went cold. That was in 2021, during my internship at Deep Info Lab, and it taught me more about engineering in five minutes than any semester of college had. This is the story of how I got from there to here — not a highlight reel, but the actual path, mistakes included. Where it started: a CMS and a lot of late nights I built my first real production feature as an intern — a Content Management System using Django Rest Framework and React. It sounds simple written out like that. It wasn't. I was learning JWT authentication, request routing, and Nginx configuration at the same time as I was supposed to be shipping the thing. What I remember most isn't the tech stack, though. It's the moment our CEO personally acknowledged the work. That's when something clicked for me: good engineering isn't about knowing every tool going in. It's about being willing to sit with the discomfort of not knowing, and figuring it out anyway, on a deadline, with people depending on you. Learning that frontend and backend aren't separate worlds At floc, I stepped into Flutter and Firebase to build a real-time social discovery app. It was my first time owning something end-to-end — design, auth, testing, deployment. I set up CI/CD with Docker and GitHub Actions for the first time, mostly by trial, error, and an unreasonable number of tabs open on Stack Overflow. Looking back, this was the internship where I stopped thinking of myself as "a frontend person" or "a backend person." I was just someone trying to make something work end to end. That mental shift mattered more than any specific skill I picked up. The projects that actually taught me to think in systems Smarter.Codes had me building data analytics interfaces — dashboards that had to make sense of messy business data at a glance. Smarter.Codes had me shipping across three different production products simultaneously: Hybrid.Chat, NayakAI, and TalkingDB. Different codebases, different constraints, same underlying question every time: how do you build something that won't fall apart in six months? This is where I really started caring about architecture. I refactored backend logic chains that had grown so nested nobody wanted to touch them. I built an NLP pipeline that had to parse multi-turn conversations and pull structured meaning out of them. None of it was glamorous. All of it taught me that the unglamorous work — the refactor nobody asked for, the test suite nobody wanted to write — is usually the work that actually matters a year later. Where I am now Today, at eQ Technologic, I spend my time on things that would have felt out of reach two years ago: leading refactors across legacy modules, building internal tooling that other engineers rely on, sitting in sprint planning and actually having opinions worth sharing. I've gone from being the person asking "how do I even start this" to being someone junior engineers sometimes ask that question to. I'm not writing this because I think I've figured it all out. I'm writing it because two years ago, I would have loved to read something like this — not a highlight reel, just an honest account of what the climb actually looks like. What I'd tell someone starting out A few things I wish someone had told me directly, instead of me learning them the hard way: • The unglamorous work is often the most valuable work. Nobody hands out awards for a clean refactor, but everyone feels the pain when it doesn't happen. • Ownership matters more than expertise. I learned more from owning a feature I didn't fully understand than from being handed tasks in a domain I already knew. • Ask for the "why," not just the "how." Understanding why a system is built a certain way will teach you system design faster than any course will. • Ship on a deadline, then go back and make it better. Perfection before shipping is usually just fear wearing a productivity costume. I'm currently exploring SDE 2 opportunities where I can keep building on this — deeper system design, more ownership, more mentoring. If any part of this journey resonates with you, or you're earlier in yours and want to compare notes, I'd love to hear from you. I'm Aman Thakur, a Full Stack Software Engineer working with React.js, Node.js, and NestJS. You can find me on LinkedIn or GitHub. MongoDB Promoted • What's a billboard? • Manage preferences • Report billboard Build fast on MongoDB Atlas without the fear of outgrowing. Don't let your database dictate your speed. With MongoDB Atlas, the same document model you use for your MVP handles global scale across AWS, Azure, and Google Cloud. Start free and stay fast as you grow. Start Free Top comments (0) Subscribe Create template Templates let you quickly answer FAQs or store snippets for re-use. Dismiss Code of Conduct • Report abuse Are you sure you want to hide this comment? It will become hidden in your post, but will still be visible via the comment's permalink. Hide child comments as well For further actions, you may consider blocking this person and/or reporting abuse I still remember the first time I saw a production bug crash right in front of a client, live, during a demo. My hands went cold. That was in 2021, during my internship at Deep Info Lab, and it taught me more about engineering in five minutes than any semester of college had. This is the story of how I got from there to here — not a highlight reel, but the actual path, mistakes included. Where it started: a CMS and a lot of late nights I built my first real production feature as an intern — a Content Management System using Django Rest Framework and React. It sounds simple written out like that. It wasn't. I was learning JWT authentication, request routing, and Nginx configuration at the same time as I was supposed to be shipping the thing. What I remember most isn't the tech stack, though. It's the moment our CEO personally acknowledged the work. That's when something clicked for me: good engineering isn't about knowing every tool going in. It's about being willing to sit with the discomfort of not knowing, and figuring it out anyway, on a deadline, with people depending on you. Learning that frontend and backend aren't separate worlds At floc, I stepped into Flutter and Firebase to build a real-time social discovery app. It was my first time owning something end-to-end — design, auth, testing, deployment. I set up CI/CD with Docker and GitHub Actions for the first time, mostly by trial, error, and an unreasonable number of tabs open on Stack Overflow. Looking back, this was the internship where I stopped thinking of myself as "a frontend person" or "a backend person." I was just someone trying to make something work end to end. That mental shift mattered more than any specific skill I picked up. The projects that actually taught me to think in systems Smarter.Codes had me building data analytics interfaces — dashboards that had to make sense of messy business data at a glance. Smarter.Codes had me shipping across three different production products simultaneously: Hybrid.Chat, NayakAI, and TalkingDB. Different codebases, different constraints, same underlying question every time: how do you build something that won't fall apart in six months? This is where I really started caring about architecture. I refactored backend logic chains that had grown so nested nobody wanted to touch them. I built an NLP pipeline that had to parse multi-turn conversations and pull structured meaning out of them. None of it was glamorous. All of it taught me that the unglamorous work — the refactor nobody asked for, the test suite nobody wanted to write — is usually the work that actually matters a year later. Where I am now Today, at eQ Technologic, I spend my time on things that would have felt out of reach two years ago: leading refactors across legacy modules, building internal tooling that other engineers rely on, sitting in sprint planning and actually having opinions worth sharing. I've gone from being the person asking "how do I even start this" to being someone junior engineers sometimes ask that question to. I'm not writing this because I think I've figured it all out. I'm writing it because two years ago, I would have loved to read something like this — not a highlight reel, just an honest account of what the climb actually looks like. What I'd tell someone starting out A few things I wish someone had told me directly, instead of me learning them the hard way: • The unglamorous work is often the most valuable work. Nobody hands out awards for a clean refactor, but everyone feels the pain when it doesn't happen. • Ownership matters more than expertise. I learned more from owning a feature I didn't fully understand than from being handed tasks in a domain I already knew. • Ask for the "why," not just the "how." Understanding why a system is built a certain way will teach you system design faster than any course will. • Ship on a deadline, then go back and make it better. Perfection before shipping is usually just fear wearing a productivity costume. I'm currently exploring SDE 2 opportunities where I can keep building on this — deeper system design, more ownership, more mentoring. If any part of this journey resonates with you, or you're earlier in yours and want to compare notes, I'd love to hear from you. I'm Aman Thakur, a Full Stack Software Engineer working with React.js, Node.js, and NestJS. You can find me on LinkedIn or GitHub. MongoDB Promoted • What's a billboard? • Manage preferences • Report billboard Build fast on MongoDB Atlas without the fear of outgrowing. Don't let your database dictate your speed. With MongoDB Atlas, the same document model you use for your MVP handles global scale across AWS, Azure, and Google Cloud. Start free and stay fast as you grow. Start Free I still remember the first time I saw a production bug crash right in front of a client, live, during a demo. My hands went cold. That was in 2021, during my internship at Deep Info Lab, and it taught me more about engineering in five minutes than any semester of college had. This is the story of how I got from there to here — not a highlight reel, but the actual path, mistakes included. Where it started: a CMS and a lot of late nights I built my first real production feature as an intern — a Content Management System using Django Rest Framework and React. It sounds simple written out like that. It wasn't. I was learning JWT authentication, request routing, and Nginx configuration at the same time as I was supposed to be shipping the thing. What I remember most isn't the tech stack, though. It's the moment our CEO personally acknowledged the work. That's when something clicked for me: good engineering isn't about knowing every tool going in. It's about being willing to sit with the discomfort of not knowing, and figuring it out anyway, on a deadline, with people depending on you. Learning that frontend and backend aren't separate worlds At floc, I stepped into Flutter and Firebase to build a real-time social discovery app. It was my first time owning something end-to-end — design, auth, testing, deployment. I set up CI/CD with Docker and GitHub Actions for the first time, mostly by trial, error, and an unreasonable number of tabs open on Stack Overflow. Looking back, this was the internship where I stopped thinking of myself as "a frontend person" or "a backend person." I was just someone trying to make something work end to end. That mental shift mattered more than any specific skill I picked up. The projects that actually taught me to think in systems Smarter.Codes had me building data analytics interfaces — dashboards that had to make sense of messy business data at a glance. Smarter.Codes had me shipping across three different production products simultaneously: Hybrid.Chat, NayakAI, and TalkingDB. Different codebases, different constraints, same underlying question every time: how do you build something that won't fall apart in six months? This is where I really started caring about architecture. I refactored backend logic chains that had grown so nested nobody wanted to touch them. I built an NLP pipeline that had to parse multi-turn conversations and pull structured meaning out of them. None of it was glamorous. All of it taught me that the unglamorous work — the refactor nobody asked for, the test suite nobody wanted to write — is usually the work that actually matters a year later. Where I am now Today, at eQ Technologic, I spend my time on things that would have felt out of reach two years ago: leading refactors across legacy modules, building internal tooling that other engineers rely on, sitting in sprint planning and actually having opinions worth sharing. I've gone from being the person asking "how do I even start this" to being someone junior engineers sometimes ask that question to. I'm not writing this because I think I've figured it all out. I'm writing it because two years ago, I would have loved to read something like this — not a highlight reel, just an honest account of what the climb actually looks like. What I'd tell someone starting out A few things I wish someone had told me directly, instead of me learning them the hard way: • The unglamorous work is often the most valuable work. Nobody hands out awards for a clean refactor, but everyone feels the pain when it doesn't happen. • Ownership matters more than expertise. I learned more from owning a feature I didn't fully understand than from being handed tasks in a domain I already knew. • Ask for the "why," not just the "how." Understanding why a system is built a certain way will teach you system design faster than any course will. • Ship on a deadline, then go back and make it better. Perfection before shipping is usually just fear wearing a productivity costume. I'm currently exploring SDE 2 opportunities where I can keep building on this — deeper system design, more ownership, more mentoring. If any part of this journey resonates with you, or you're earlier in yours and want to compare notes, I'd love to hear from you. I'm Aman Thakur, a Full Stack Software Engineer working with React.js, Node.js, and NestJS. You can find me on LinkedIn or GitHub.