A space where I document my journey as a developer—one project, one mistake, and one lesson at a time. This blog is my digital notebook for sharing what I build, what I learn, and the ideas that shape the way I think about software.
Every developer has a first blog post. This is mine—not because I've figured everything out, but because I don't want to forget how I got here.
For years, most of what I learned lived in notebooks, unfinished GitHub repositories, browser tabs I promised myself I'd revisit, and projects that never made it beyond my laptop. Every debugging session, every late-night experiment, every mistake that taught me something valuable slowly faded with time.
but , I found myself asking a simple question:
What if I documented everything I learned instead of letting it disappear?
That question became the reason this blog exists.
This isn't a place where I'll only share polished projects or technical tutorials. It's where I'll document the entire process of becoming a better developer—the ideas that worked, the ones that didn't, the lessons hidden inside bugs, the decisions behind projects, and the thought process that often matters more than the final result.
To explain why that matters to me, I have to go back to where it all started.
I was around sixteen, nearing the end of my intermediate years, when programming first caught my attention. I knew Computer Science would eventually introduce me to coding once I joined college, but curiosity had other plans. Waiting for a classroom or a syllabus didn't feel right. I wanted to understand how software actually worked before anyone told me I had to.
Curiosity Built the Developer I'm Still Becoming | Blog | Deekshith Goud
How does this actually work?
After asking my brother-in-law where I could start learning, he introduced me to Tech With Tim's Python tutorials. That simple recommendation ended up becoming one of the biggest turning points in my journey.
I had no roadmap, no long-term plan, and no idea where programming would eventually take me. All I knew was that I wanted to understand.
So every night, usually around 10:30 or 11 after everyone at home had gone to sleep, I'd put on my earbuds, open YouTube, and continue wherever I had stopped the previous night. Sometimes I'd watch for thirty minutes, sometimes longer, depending on the topic. The next day, I'd sit at my desk and try everything I'd watched the previous night. If something didn't make sense, I'd keep experimenting until it did.
The interesting part was that it never felt like studying.
I wasn't forcing myself to complete another lecture or ticking topics off a checklist. There wasn't a schedule to follow or a deadline to meet. Every concept answered one question while creating three new ones, and that was enough to keep me coming back the next night.
Looking back, those late-night sessions taught me something much bigger than Python.
They taught me how to learn independently.
No classroom was asking me to practice. No exam depended on it. The only thing keeping me consistent was the excitement of discovering something I didn't know the day before.
One thing I loved about those early days was that I never worried about having the "perfect" setup. Long before I knew what Visual Studio Code was, I was using Replit. I had seen it on my brother's phone even before I knew anything about programming, and once I started learning Python, it naturally became my first development environment.
Whenever an idea came to mind, I'd open Replit or my laptop and simply try it. There was no pressure to build something impressive. Most of the time, I was just curious to see if I could make an idea work.
One of those ideas became my first real project.
It was a small menu-driven Python application that answered questions about me. Looking back, it was a very simple program built using conditions, loops, and user input. If I were to build it today, it would probably take me only a few minutes.
But back then, it felt like something much bigger. After finishing it, I handed my laptop to my brother without saying a word. He explored the program for a while, selected different options from the menu, and casually said, "Yeah, it works."
After that moment, it became something else.
I realized software wasn't just about writing code.
It was about taking an idea that existed only in your mind and turning it into something another person could interact with.
That feeling is difficult to describe, but every developer remembers the first time they experience it.
After spending quite a time learning Python, I reached a point where I started asking myself, "What's next?"
Python had given me a strong foundation and, more importantly, the confidence to learn on my own. But I wanted to understand programming beyond syntax. I wanted to know how larger applications were built, why experienced developers preferred certain approaches, and what actually happened beneath the code I was writing.
That's when I discovered Apna College and started learning Java.
The transition wasn't as easy as I expected.
Coming from Python, I often assumed that if a particular method or functionality existed there, Java would have something similar. It didn't. More often than not, Java expected me to build the logic myself instead of relying on built-in conveniences.
Later, I realized it was exactly what I needed.
Python had taught me how to write code. Java started teaching me how to think.
Eventually, I realized that was exactly what made Java such a valuable teacher.
Then came Object-Oriented Programming.
Until then, most of my programs were just... programs. They accepted an input, processed it, and produced an output.
OOP changed how I viewed software. Instead of writing isolated pieces of code, I began thinking in terms of systems. A bank wasn't just a collection of functions anymore; it became customers, accounts, transactions, and relationships. A restaurant wasn't just taking orders; it became menus, tables, staff, and workflows.
It started feeling like designing real-world systems.
Around the same time, I also found myself spending hours solving pattern problems. Triangles, diamonds, butterflies, Floyd's Triangle—problems that many students see as repetitive became something I genuinely enjoyed. They forced me to slow down and think before writing a single line of code.
Programming begins long before your fingers touch the keyboard.
By the time I started my B.Tech, programming no longer felt unfamiliar.
While many of my classmates were learning their first programming language, I had already spent months exploring Python and Java on my own. That didn't make me a better developer—it simply meant I had started earlier.
The biggest advantage wasn't knowing more syntax.
It was having more time to think.
When Python became part of our curriculum, I found myself diving into topics like file handling, CSV data, directory structures, and libraries like Matplotlib. While everyone was understandably focused on learning the basics, I kept asking myself a different question:
"What can I actually build with what I know?"
That question led me to one of my favorite early projects—a student performance analyzer.
The application organized student records, read information from CSV files, tracked academic performance over multiple examinations, and generated visual reports to help understand progress over time. It combined everything I had been learning about file handling, data organization, and visualization into one practical project.
Like every beginner project, it came with plenty of bugs. Some took minutes to fix, while others had me staring at the screen for hours before finally asking my faculty for guidance.
I kept wondering how it would feel for a student who opened the application only to see that their performance had dropped compared to the previous exam. Would it motivate them, or would it discourage them even more?
I never found a perfect answer. So the project stayed on my laptop.
Good software isn't measured only by what it can do. It's also measured by how it makes people feel.
Console applications had taught me how programs worked, but I wanted to build something people could actually use. That curiosity naturally pulled me towards web development, where I started learning HTML, CSS, and JavaScript.
Like every beginner, CSS humbled me more times than I can count. I'd fix one layout only to accidentally break another. Some nights, I spent more time figuring out why a <div> refused to move than actually building the page. It was frustrating, but every mistake taught me something new. Slowly, things started making sense.
The first website I built was a simple invitation page. Looking at it today, it isn't anything extraordinary. But at that moment, seeing something I had built come alive inside a browser felt completely different from running programs in a terminal.
Around the same time, AI started becoming part of almost every developer's workflow.
Like everyone else, I was fascinated.
The first time I used ChatGPT, it genuinely felt revolutionary. Problems that would've taken hours to solve suddenly had answers in seconds. Learning new frameworks became less intimidating, debugging became easier, and experimenting with unfamiliar technologies no longer felt overwhelming.
Naturally, I embraced it.
At first, AI was exactly what I hoped it would be—a productivity booster. It helped me understand concepts faster, overcome roadblocks, and build projects that would've felt impossible only months earlier.
From the outside, it certainly looked that way.
I was building more. Learning more. Shipping projects faster. But growth isn't always measured by what you're producing. Sometimes it's measured by how you're thinking.
Without realizing it, my habits began to change. Whenever I got stuck, I asked AI before asking myself.Whenever I saw an unfamiliar concept, I summarized it instead of reading the documentation.
The flowcharts I used to draw disappeared. The rough notes became prompts. The hours I once spent debugging slowly turned into minutes of copying an error message into ChatGPT.
None of it happened overnight. That's what made it so difficult to notice.
My projects were getting better. But I wasn't sure I was.
The turning point came during a conversation with one of my friends.
Vibe coding isn't actual coding.
At first, I didn't agree.
I was still building projects. I was still learning new technologies. I was still improving... wasn't I? The more I thought about it, the more uncomfortable the question became. Eventually, I realized what had been bothering me all along
AI hadn't made me a worse developer. It had made me feel full while I was still hungry.
That sentence perfectly described what I couldn't explain before.
I was completing projects. But I wasn't always understanding them.
I was getting answers. But I wasn't asking enough questions.
I'd mistaken speed for progress. I had started believing that finishing something quickly meant I was learning quickly.
It didn't.
That realization completely changed the way I use AI today.
I still use it almost every day.
The difference is that our roles have changed.
Today, I think first. I sketch ideas. I design workflows. I break problems into smaller pieces. I build my own understanding before asking AI to build anything else.
Now, AI reviews my ideas instead of replacing them. It challenges my thinking instead of doing the thinking for me.
I've stopped looking at AI as a shortcut.
Now, I break problems into smaller pieces and build my own understanding before asking AI to build anything else. Only then do I bring it into the conversation—to review my approach, challenge my assumptions, explain concepts more clearly, or suggest improvements I might have missed.
AI now reviews my ideas instead of replacing them. It challenges my thinking instead of doing the thinking for me.
That lesson changed far more than just my workflow. It changed the way I approach learning itself.
Looking back, I think I should've started writing much earlier.
Not because I knew more back then—but because I was learning so much that I never wanted to forget.
Over the past few years, every project has taught me something beyond code. Every bug I spent hours fixing, every conversation that challenged my thinking, every mistake I made, and every project that didn't go as planned shaped the way I approach software today.
The problem is that those lessons don't stay with us forever.
Over time, they quietly disappear.
They're buried inside old notebooks, forgotten repositories, browser tabs, screenshots, or simply lost to time.
For a long time, I told myself I wasn't ready to start a blog.
I thought I needed more experience.
More projects.
More knowledge.
More achievements.
I wanted my first article to be "good enough."
But eventually I realized something.
I wasn't waiting until I was ready.
**I was waiting until I was perfect.**
And perfection never arrives.
The struggle I once tried to avoid was actually where most of my learning had always happened.
Maybe that's the real reason this blog exists.
Not because I have everything figured out.
But because I don't.
I want a place to document the projects I build, the mistakes I make, the lessons I learn, and the way my thinking changes over time.
Some of the opinions I have today will probably change a few years from now.
Honestly, I hope they do.
Because if I'm still thinking exactly the same way years from now, it probably means I stopped learning somewhere along the way.
This blog isn't a collection of answers.
A reminder of where I started, how far I've come, and how much there is still left to learn.
And maybe, years from now, I'll come back to this very article, smile at how differently I think, and be grateful that I finally stopped waiting and simply started writing.
Maybe this blog will help someone else.
Maybe it won't.
But years from now, when I look back at these pages, I hope they remind me of something I never want to forget:
Comments