ようこそ
Career

You’re not behind, you’re just at the beginning

Feeling lost in first year and wondering whether any of it is still worth learning. The long answer: fundamentals, building real things, and the skill I wish I had started on earlier.

September 13, 20268 min read
A dotted world map in white on black, split either side of a single blue folder labelled “projects”.

If you’re in your first year of an IT or computer science degree, there’s a good chance you feel lost. You’re working through algorithms, pseudocode, flowcharts, maybe Java. Meanwhile you keep seeing people who look impossibly far ahead of you, and somewhere in there you start wondering whether any of what you’re studying is still worth learning.

I want to answer that properly, because “just keep studying and everything will be fine” is not an answer.

One thing first, so you know where this is coming from. I’m a 4th-year student myself. I’m not in the corporate world yet — most of what I know comes from freelance work and clients, mostly in the US. I’m still learning and I don’t have this figured out. What follows is what I’d tell myself at the start, not advice from someone who has arrived.

Stop comparing yourself to other people

Seriously. Different strengths, different starting points, different opportunities, different circumstances. When you look at someone who seems far ahead, you are seeing the output and none of the input — not the years, not the access they had, not the things that went badly for them along the way.

Comparison is also just a bad instrument. It tells you where you rank against a sample of people you can see, which is not the same as telling you whether you’re improving. The only comparison that means anything is against yourself six months ago.

The fundamentals matter — but they aren’t the finish line

When I was in first year I started where you are. Variables, data types, operators, conditionals, loops, arrays, functions. We used Python. I didn’t learn all of it perfectly, and I don’t expect school to teach everything the industry currently uses. No curriculum moves that fast.

That doesn’t make those subjects useless. Algorithms, pseudocode, flowcharts, programming logic, learning to actually think a problem through — all of that holds up. The mistake is a different one: thinking that passing those subjects means you’re becoming a good software engineer.

You aren’t. You’re building the foundation. Those are not the same thing.

Get curious about how things are actually built

Once I had the basics, what pulled me forward wasn’t more syntax. It was wanting to understand how real applications fit together:

  • How does a website actually work, end to end?
  • How does a mobile app talk to a backend?
  • How does a game manage its systems?
  • How does a database connect to everything else?
  • How do separate parts of a system communicate?
  • How do you structure a project so it doesn’t turn into a mess?

Those questions taught me far more than memorising syntax ever did. Syntax is lookup-able. Knowing what should exist in the first place is not.

You don’t need ten programming languages

Learn one well enough that you genuinely understand variables, functions, conditionals, loops, data structures, object-oriented programming, error handling — and how to think like a programmer. After that, the next language is mostly new syntax, a new ecosystem, and new conventions. The concepts carry over.

So don’t be intimidated when you see a language you’ve never touched. You should get comfortable with that feeling, because it never really goes away and it stops being a problem surprisingly fast.

When I start something, the question I ask isn’t:

“What language have I already memorised?”

It’s:

“What actually makes sense for this project?”

For a website that might be Next.js, TypeScript, Tailwind and PostgreSQL. For a game it’s whatever engine and language fit what I’m building. Forcing every project into the one language you already know, because it’s comfortable, is a decision you make about the project on behalf of your own convenience.

The goal isn’t to become “the Java guy” or “the Python guy.” The goal is to become someone who can build things and pick up whatever tools that requires.

On Java specifically

Yes, keep going with it. It’s a perfectly good language to learn properly, and the discipline it enforces around types and structure will serve you elsewhere.

But don’t try to master every feature of it before you build anything. Learn enough that you understand how programming works, then start making things. That’s where the actual learning happens.

Make a calculator. A CRUD app. A small game. A website. Something that solves a problem you personally have. It does not need to be impressive. It needs to exist.

You’ll hit bugs, bad code, incomprehensible errors, Git problems, databases, APIs, deployment, and a hundred things nobody taught you. That’s the job. You fix them one at a time, and eventually they stop being frightening.

The part I wish I’d started earlier: agentic engineering

If you take one thing from this post, take this one. Learn to work with AI as an engineer.

How software gets built is changing quickly. A lot of working developers are no longer typing every line by hand — they use AI tools and coding agents to write, modify, debug, refactor, test and understand codebases. Being the fastest typist is not the moat it used to be.

That’s a real skill, and it is not the same as prompting “make me a website.” It means learning how to give an agent the right context, how to break a problem into tasks it can actually execute, how to plan an implementation before anything gets written, how to review what comes back, how to test it, and how to notice when it has confidently done something wrong.

That last one is why everything above about architecture matters so much. The AI can write the code. You have to know what code should exist in the first place. Before I hand anything to an agent I want to understand what I’m building, why, how the pieces connect, and what the result should look like. Then the agent becomes the implementation tool instead of the decision-maker.

Put plainly: the valuable person is the one who can take an idea, design the system, communicate it clearly, review the implementation, catch the problems and actually ship the thing.

So learn Java. Learn the fundamentals. And alongside that, learn how the modern tools work — use Claude, ChatGPT, Codex, whatever you have access to. Learn how coding agents behave. Learn Git properly. Practise handing an agent an existing codebase and having it understand and modify that project. Above all, learn to review generated code instead of accepting it because it ran.

That combination is worth far more than memorising syntax ever was.

Don’t ignore the people around you

Talk to your classmates. Talk to your professors. Make friends. Work with people. You are not in college only to acquire technical skill — you’re also building the network you’ll have for the next decade.

And be generous with what you know. If a classmate is stuck, explain the concept. Share your notes. Walk them through the thing you figured out last night. Teaching something is also the fastest way to find out whether you actually understand it, so this is not charity — you get the better end of it more often than not.

Be clear about where the line is, though. Helping someone understand their work is not the same as doing it for them, and it isn’t the same as passing answers during graded work. The first builds something real for both of you. The second puts your academic standing at risk and leaves them exactly as stuck as they were.

The classmate you help today could end up a software engineer, a security specialist, a project manager, a founder, or the person on the inside at a company you want to join. You have no idea where people land. Some of them will be in a position to help you later, and the ones who remember you as generous are the ones who will.

Software engineering or cybersecurity?

You don’t have to decide right now. You’re in first year. Deciding now would mean deciding with the least information you will ever have.

Try both. Build software. Learn networking and operating systems. Pick up some security fundamentals. Pay attention to which one you keep drifting back to when nobody is making you — that signal is more reliable than any career guide.

And don’t pick a field because it’s popular or because someone told you it’s in demand. Demand moves. Pick the thing you’re willing to keep learning when it gets tedious and hard, because every one of these fields eventually does.

You’re not behind

Don’t let more advanced people scare you off. You’re a first-year student. You’re supposed to be a beginner. That isn’t a gap to close, it’s just where the road starts.

If you picked up some HTML, CSS or JavaScript before university, that counts — it is a real starting point, and more than a lot of people have at your stage. If you didn’t, you are still fine. You are learning your first language now, which is exactly when you are supposed to be learning it.

Learn the fundamentals. Build things. Break them. Fix them. Understand how applications actually work. Learn to use AI properly. Stay curious about unfamiliar technology instead of avoiding it. And stop measuring your progress against someone else’s.

And if you’re teaching yourself something on the side right now — Java or anything else — keep going with it. I would much rather see you build five small things and struggle through every one of them than spend six months watching tutorials and finishing nothing.

Good luck. Go build something.