Things I Wish I Knew When I Started Programming

I've been programming for several years now. I've built production AI systems, published open-source tools, co-authored IEEE research, and solved real engineering problems that actually mattered to real people. Looking back at where I started, there are seven things I wish someone had told me on day one.

1. Don't Follow Tutorials Blindly

Tutorials are great for a first encounter with a concept. They're terrible for actually learning it. The tutorial always works perfectly — the data is clean, the API is cooperative, the environment is controlled. Real projects aren't.

Use tutorials to get oriented, then close them. Build something slightly different. Break the tutorial project intentionally and fix it. The learning happens in the struggle after the tutorial ends, not during it.

2. Build Real Things as Soon as Possible

I wasted months watching videos and reading books before I started building anything real. The truth is: you're ready to build something real after two weeks of basics. It will be bad. Build it anyway.

Real projects expose you to real problems — input validation, error handling, user expectations, data that doesn't match your assumptions. No tutorial covers these. Only building does. My first real AI project, JARVIS, was terrible code. It also got me the internship at Idyllic Services.

3. Understand Fundamentals Before Frameworks

It's tempting to learn React before you understand the DOM, or Django before you understand HTTP, or TensorFlow before you understand gradient descent. Resist this completely.

Frameworks are abstractions over fundamentals. When a framework fails — and it will — you need the fundamentals to diagnose it. Engineers who only know frameworks are helpless when the framework does something unexpected. Engineers who know fundamentals can figure out anything.

"Every framework will eventually do something you don't expect. The fundamentals are the map you use to find your way back."

4. Errors Are Teachers, Not Failures

When I started, I felt genuine shame when my code threw an error. I saw it as evidence that I wasn't good enough. That was backwards.

Errors are the most specific, direct feedback you'll ever receive about your code. A TypeError: 'NoneType' object is not subscriptable is telling you exactly where your assumption failed. Read errors carefully, all the way through. They're not failures — they're free lessons.

5. Read Other People's Code

I didn't read enough other people's code early on. Looking at how experienced engineers structure their projects, name their variables, handle errors, and organize logic is one of the fastest ways to improve.

GitHub is a goldmine. Find a library or project you use and read its source. You'll see patterns you didn't know existed. You'll see how production code handles edge cases you hadn't considered. This is free mentorship from the best engineers in the world.

6. Don't Code in Isolation

Programming feels like a solo activity. It isn't. The fastest growth I experienced came from showing my code to other people — getting feedback, explaining my decisions, hearing "why did you do it this way?"

Find a community. A Discord, a study group, a college club. Code review from someone with more experience is worth more than ten hours of solo practice. When I became DSA Lead at Hackslash and mentored 300+ students, my own understanding deepened more than any solo practice period.

7. Contribute to Open Source Early

You don't need to be senior to contribute. Fix a typo in documentation. Add a missing test. Improve an error message. The process of submitting a pull request — reading contribution guidelines, understanding code style, getting review — teaches professional collaboration skills that no tutorial covers.

My first published package, integration-smoke-test on PyPI, taught me more about software packaging, documentation, versioning, and CI/CD than years of coursework. Shipping something that other people actually use is the fastest accelerant for growth.

The Thread Through All of These

Looking at these seven lessons, the common thread is: get real feedback as fast as possible. Tutorials are slow feedback. Real projects give fast feedback. Showing your code to others gives fast feedback. Contributing to open source gives fast feedback. Errors give immediate feedback.

The faster you can close the loop between doing something and finding out if it worked, the faster you learn. That's the whole game.