81 Credits and Zero Clue: What University Doesn't Teach You About Software Engineering

81 Credits Do Not Automatically Make Me an Engineer

I currently have 81 university credits.

If you look at my academic progress, everything seems normal. I attend classes, complete assignments, pass exams, and move closer to graduation.

But the closer I get to entering the software industry, the more I realize something uncomfortable: credits only show that I have completed a learning process. They do not prove that I can solve real engineering problems.

During my time studying software engineering at the University of Transport Technology HCMC, I learned many important foundations. Algorithms, databases, software design, and system concepts are still valuable.

However, the speed of technology changes much faster than most university curriculums.

A concept that was introduced in a lecture a few years ago can already feel outdated when applied to today’s development workflow. Modern engineers are expected to work with cloud services, AI tools, automation systems, deployment pipelines, and constantly changing frameworks.

The problem is not that universities are useless.

The problem is that passing courses and becoming a capable engineer are two different journeys.

The Problem With Identical CVs

Here’s the thing.

When I look at today’s graduate job market, I notice many students are trying to solve the same problem in the same way.

They use AI tools to generate a resume, copy common project descriptions, and send applications to dozens of companies.

The result is predictable.

Recruiters receive hundreds of CVs that look almost identical.

Everyone writes:

• “Passionate software engineer”
• “Strong problem-solving skills”
• “Experienced with modern technologies”

But when every candidate describes themselves in the same way, those words lose their meaning.

AI is not the problem.

Using AI without adding your own experience is the problem.

A good resume should not only tell people what technologies you have touched. It should show what you built, what problems you faced, and what you learned when things failed.

A recruiter does not really need another student who knows a list of technologies.

They need someone who can open a broken system, investigate the problem, and figure out what happened.

Learning Outside the Classroom

Real talk: I started changing my learning approach when I realized that waiting for university courses was not enough.

Instead of only studying concepts, I began building my own environment and experimenting with real workflows.

My personal machine is an AMD Ryzen 7 workstation with an NVIDIA RTX 4050 GPU. I used it to create a local development environment, experiment with Linux through VMware, and explore how AI models could assist programming tasks.

I spent time working with tools like Open Interpreter, Llama 3.1, and Cursor IDE.

Not because I wanted another certificate.

I wanted to understand how these tools actually behave when they are used in a real workflow.

There’s a big difference between reading about deployment and actually breaking your own environment while trying to deploy something.

For example, instead of depending completely on graphical interfaces, I practice managing projects through the terminal:

git add .
git commit -m "fix: optimize local environment variables and build errors"
git push origin main

These commands are simple.

But the important part is understanding what happens behind them:

• Why did the build fail?
• Why does the environment variable not load?
• Why does the server behave differently locally and remotely?

Those are the questions that slowly turn a student into an engineer.

The Difference Between Studying and Practicing

I’ll be blunt. I do not think grades are meaningless.

A strong academic foundation still matters.

But grades alone cannot replace practical experience.

A student who only studies before exams may graduate with a degree but still struggle when facing a real project.

Software engineering requires continuous learning because the tools are always changing.

The workflow I am trying to build is simple:

• Read documentation instead of only watching tutorials. Connect to official platform guidelines like Microsoft Learn or Astro Docs to verify core parameters.
• Build projects instead of only collecting certificates.
• Push code to GitHub instead of keeping everything on a personal laptop.
• Deploy applications instead of stopping when the code runs locally.

Plus, recently I have also been building my own technical blog system without relying on heavy management platforms.

I manage markdown files, generate configurations, handle layouts, and maintain the project directly through my local development environment.

It is not a huge commercial product.

But it is a real system that I understand because I built it myself.

The Real Difference Between Students Today

AI has changed software development.

It can generate code, explain errors, create prototypes, and automate many repetitive tasks.

But I do not think AI will simply replace programmers.

I think it will create a bigger difference between people who actively build things and people who only consume information.

A student with AI tools and real curiosity can move extremely fast.

A student who only waits for instructions will find it harder to compete.

For me, the gap between 81 university credits and becoming a software engineer will not be closed by earning more credits alone.

It will be closed by building more systems, making more mistakes, debugging more problems, and understanding how software works outside the classroom.

The next time I open my laptop, I want to spend less time asking: “What should I study next?”

And spend more time asking: “What can I build today?”

What I Didn’t Love

I’ll be honest. The learning curve is steep.

When you start building outside the classroom, everything feels overwhelming. You do not know what you do not know. Every new tool seems to require three other tools just to set up.

Plus, it takes time away from other things. Social life, relaxation, sometimes even sleep.

But here’s the thing. That discomfort? It means you’re actually learning.

The moments when your code breaks and you have no idea why? Those are the moments that matter most.

A university class teaches you concepts.

Struggling alone at midnight with a broken deployment teaches you how to think.

Who This Is For

If you are a student who only cares about GPA, stop here. Your transcript will not save you in a technical interview.

If you are a student who spends evenings building random projects, breaking things, and figuring out why your code works on your machine but not on the server — you are probably on the right track.

The industry does not need more people with perfect grades.

It needs more people who can ship.

My Current Setup

For quick scripts and notes, I still use basic text editors.

For anything serious — anything that matters — I open my Ryzen 7 workstation, fire up VMware, and get to work.

That sounds like overkill. But the thing is, you never know when “quick script” becomes “real project.”

The tools you practice with now are the tools you’ll depend on later.

So yeah. I take my setup seriously.

Even if it just means I can debug my own mistakes faster than anyone else in the room.