← All articles
Getting started

How to start coding in first year (when everyone else seems ahead)

06 September 2026 · 9 min read

You joined in June or July. Everyone around you seems to already know something. There are eleven roadmaps in your class group and they contradict each other. This is the version that assumes you are starting from zero and have a semester of coursework to survive at the same time.

First: the thing that is making you anxious is not true

The people in your batch who "already know how to code" mostly know how to follow a tutorial. A small number genuinely started in school. Both groups will be overtaken within a year by people who build things consistently, because that is the only variable that compounds.

Starting in first year is early. Starting in second year is fine. The panic is the problem, not the timeline — panic is what makes people jump between five languages in three months and end up knowing none.

Use the language your college teaches

If it is C, learn C. If it is Python, learn Python. Do not switch because a video said another one is better for placements.

Two reasons. Your lab, your exams and your doubts all live in that language, so the help is free and immediate. And the thing you are actually learning — loops, conditions, breaking a problem into steps — transfers completely. The second language takes weeks, not months, once the first is solid.

Months 1–3: get comfortable, not clever

Your only target is that a blank file stops being intimidating.

  • Variables, input and output, and arithmetic that behaves oddly with integers
  • if / else, and writing a condition that says what you meant
  • Loops, including nested ones and pattern printing
  • Arrays and strings
  • Functions — the moment you write your first one properly is when programs stop being one long block

Do the practice. Two or three small problems a day. Not fifteen on a Sunday. Coding is a hands skill, and hands learn by repetition across days.

Months 4–6: build one small thing

This is the step almost everyone skips, and skipping it is why people who have "been learning to code for a year" still cannot make anything.

Pick something you would use. An attendance calculator. A CGPA calculator with your college's grading scheme. An expense tracker that saves to a file.

Build the worst possible version that works. One file, no error handling, ugly output. Then give it to one friend and watch them use it — they will break it in ten seconds and you will learn more from that than from the previous three months.

Months 6–12: two things in parallel

DSA, slowly. Arrays, strings, searching, sorting, recursion. Two problems a day. Not a 450-problem sheet from problem one — that is how people quit in week three.

One project every couple of months. Slightly bigger each time. Something that saves data. Something with a web page. Something that talks to an API.

These two do different jobs. DSA gets you through interview rounds. Projects get you something to talk about in the interview, and teach you the things DSA cannot: finishing, debugging your own mess, and explaining what you made.

Five ways first-years lose a year

  1. Tutorial hell. Watching, following along, feeling productive, retaining nothing. The test: close the video and build the same thing from memory. If you cannot, you watched — you did not learn.
  2. Language hopping. C to Python to JavaScript to Java in one semester, because each new one felt like a fresh start. It is procrastination wearing a productive costume.
  3. Waiting to feel ready. Nobody feels ready before their first project. You build it badly and then you feel ready.
  4. Collecting resources. Forty bookmarked playlists, three purchased courses, one PDF sheet. None opened past day two.
  5. Comparing to the loudest person in your batch. They are usually the one who has read the most and built the least.

What to do this week

Not a plan for the year. Four things, this week.

  1. Install a compiler or interpreter for your course language on your own laptop. Not an online one — your own machine, so it is there at 11 PM.
  2. Make a GitHub account. Do not do anything with it yet.
  3. Solve three small problems. Type them out fully, do not paste.
  4. Write down one thing you would like to exist. Anything. That is your project for month four.

And one thing for later

Somewhere around month five, when you can build something small and you are wondering whether it is any good, enter something with a deadline and a judge — a hackathon, a college competition, anything where a stranger looks at your work and scores it.

You will find out very quickly what you actually know, which is uncomfortable and worth far more than another three months of tutorials. And you will have finished something, on a date, because someone else set the date — which for most people is the only way the first one ever gets finished.

Ready to actually do one?

FirstHack 2026 is a three-round online hackathon built for people who have never done one — idea, prototype, final pitch, with mentors on call and a rookie track judged separately.

Register now Read the FAQ

Keep reading

Resume projects for freshers: what recruiters actually read

What happens to your CV in the first twenty seconds, the four things that make a project worth listing, and how to write the entry in three lines.

30 mini project ideas for first-year students you can actually finish

Sorted by what you know so far — from one semester of C to a bit of web — with an honest note on how long each one really takes.

A DSA roadmap for first year — including what to skip

Most roadmaps are written for placement season two years away. This one is for someone who has just finished a semester of C, and it says what not to learn yet.