Hi Hive community!
I'm 
I hope to share some valuable experiences and of course, learn from you as well. I don't claim to be a professional, because I believe academic education and hands-on experience are two very different things. Those who’ve walked this path know exactly what I mean.
I've seen many people who don't have formal academic education, yet they are incredibly skilled. In fact, all you really need is a computer and an open, creative mind. There are no limits for anyone.
You can read many books, but what truly matters is sitting at your computer and writing code. Making mistakes and discovering solutions is the only thing that moves you forward.
I had friends who would open programming books and study them thoroughly. They could answer any question about the chapters, but when they sat at a computer, their code was full of errors. What I want to say is that coding and studying are two separate things. You might even write exactly what's in the book, but still fail to compile and run it!
You may laugh at what I’m saying, but it’s the truth. I’ve seen it firsthand—this is my experience speaking. If someone decides to pursue programming, there’s only one key: practice, practice, and more practice...
Learning should be a constant part of your journey. If my earlier words made you think I’m dismissing the value of studying, let me set the record straight. My point is simple: unless you sit down, write code, compile it, and see what happens, reading even hundreds of thousands of programming books won’t help. It’s practice that turns you into a real programmer.
Writing code and facing compilation errors when it doesn’t compile—that’s what toughens you. When you find the solution, you gain experience. Every error teaches you a lesson in programming.
I still remember one of our semesters when we were learning web development with ASP.NET. For the final project, each group was tasked with designing a complete website using ASP.NET.
That semester, I remember spending countless hours behind the computer. When our professor set a deadline for submitting the projects, my teammate and I decided to meet a day before to run a final check. We used a free slot in the lab to test everything one last time, just to make sure the system was working perfectly and we wouldn’t face any surprises during the presentation.
What the professor expected from us wasn’t just to build a website and hand over the code on a flash drive or CD. He wanted each group to run their code on the lab computer and demonstrate the results with him present.
When we arrived at the lab, I saw that many groups were already there—just like us. We were testing our own code when I noticed a commotion. Several classmates had gathered around one computer, but they couldn’t get the website to run. Every attempt resulted in an error. Everyone was frustrated!
Where was the issue? The deadline was just a day away. Their project had worked flawlessly on their own computer—but here, it refused to run. That moment became an unforgettable experience for everyone.
I remember when their group asked for help, I simply said, "Can you run it once so I can see?" The moment the error popped up, I knew exactly what was wrong. I had faced the same issue myself while coding our site. I told them, "Your code isn’t the problem—it’s the framework". Back then, the lab computer had .NET Framework 3.5 installed, while their project required version 4. I pointed it out and said, "Your framework is 4, but the system only supports 3.5. Look closely—the error message is telling you exactly that".
Surprisingly, they hadn’t even taken the time to read the error message—despite the fact that systems always provide clear error feedback! Their approach had been straightforward: install the tools, learn the basics, design the site, and run it on their own computer. Their approach to training and design was superficial—they paid attention only to how to build and what to design. They hadn’t completed the training properly, and their only concern was to get the project running. They were unaware that version mismatches could lead to errors. In fact, they had entirely skipped the parts of the training that dealt with error handling!
I still remember our first semester computer lab. The professor used to talk about computer systems and their hardware components. He constantly encouraged us to experiment: 'Remove the RAM and power up the machine. Listen closely—learn what the error sounds like. Find a PC case, take out each part, turn it on, and observe what happens. Understand the errors'.
It was the hands-on experience that he emphasized from the very beginning.
Programming follows a singular path: experience. This experience is gained only through actual coding—by encountering errors and learning to resolve them. At times, these errors can be overwhelming. You may struggle to find a solution, spending hours reading documentation and reviewing your code line by line. While it's tempting to believe that the system will always notify you of mistakes, this is not the case. Logical errors—those tied to the reasoning behind your code—often go unnoticed by the system and are the most challenging to detect. Let go of the assumption that every mistake will be flagged by the system.
In any case, I want to start from the beginning. I want to retrace the path I once walked—from the very first step. I want to move forward just like I did on day one. Join me. Point out my mistakes. You, who are more skilled than I am, more experienced than I am—I invite you to walk this path with me. Let me see things from a new perspective. Let’s write code with fresh eyes and enjoy the process together. I’ll be truly happy if you correct me, and I hope that in the end, we become good friends.
Special thanks
Special thanks to 
