The Skills That Actually Matter Are Rarely on the Syllabus.

An engineering student can complete every assignment, submit an impressive final-year project, and graduate with good academic results, yet still find it difficult to build a simple application independently.

That is an interesting gap in how we approach technical education.

When we discuss what makes someone a good engineer, the conversation usually revolves around programming languages, frameworks, certifications, and technical expertise. These are important, of course. But through my own experience in software engineering, I have come to appreciate something that receives far less attention: work ethic, intellectual curiosity, and the ability to take ownership of one's learning.

These qualities are difficult to measure through examinations or academic grades. They do not necessarily make a résumé more impressive. Yet they often become apparent when someone is faced with an unfamiliar problem, an incomplete solution, or a system that refuses to work as expected.

And I believe the foundations of these habits are best developed while we are still learning.

Completing a Project Is Not the Same as Building One

Most engineering students have worked on practical assignments, mini-projects, and final-year applications. There are requirements to satisfy, deadlines to meet, and demonstrations to prepare. Naturally, the immediate objective often becomes getting the project completed and ready for evaluation.

With the abundance of tutorials, open-source repositories, and ready-made applications available online, reaching that point has become considerably easier.

There is nothing inherently wrong with using these resources. Reading someone else's code, following a well-explained tutorial, and studying existing implementations are all valuable ways to learn. Professional developers rely on documentation and established solutions every day.

The problem begins when completing the assignment becomes more important than understanding what has been built.

A project may look impressive during a demonstration, but how much has someone actually learned if they cannot explain why a particular database was chosen, how the application handles errors, or what would happen if a key component stopped working?

The most valuable part of building something is often the work that never appears in the final demonstration.

It is the time spent figuring out where to begin, understanding why two components are not communicating, identifying an unexpected bug, or discovering that an initial approach was unnecessarily complicated.

These experiences can be frustrating. They can make a relatively simple project take much longer than expected. But they also develop an understanding that is difficult to gain by simply reproducing a finished solution.

I would argue that a student who independently builds a modest application and understands its limitations may gain more than someone who submits a sophisticated project without understanding how it works.

The value of a project should not be judged only by what it can demonstrate, but also by what its developer learned while building it.

Work Ethic Becomes Visible When Things Go Wrong

One of the lessons professional engineering teaches us is that technical knowledge and professional dependability are not necessarily the same thing.

Someone may be comfortable with a programming language, familiar with modern frameworks, and capable of writing functional code. Those are useful abilities, but they do not automatically guarantee that the person will approach problems carefully, communicate clearly, or take responsibility for the quality of their work.

A large part of engineering involves dealing with situations where the answer is not immediately obvious.

An application behaves differently in production. An integration fails without a useful error message. A seemingly minor change introduces an unexpected problem elsewhere in the system. The documentation does not fully explain the behaviour we are seeing.

In these situations, knowing the syntax of a programming language is rarely enough.

What matters is how we respond. Do we investigate the problem systematically? Do we question our assumptions? Are we willing to read the documentation carefully, trace the execution flow, and understand the underlying cause rather than settle for a temporary workaround?

Equally important is knowing when to ask for help and making the effort to understand the explanation.

This is where work ethic becomes visible. Not necessarily through long working hours or constant activity, but through patience, consistency, attention to detail, and a genuine sense of responsibility.

Working hard should not mean spending more time on a problem than necessary. It should mean making a sincere effort to understand the problem and solve it properly.

These habits are not developed overnight, and they do not begin with someone's first professional job. Students have plenty of opportunities to practise them through coursework, personal projects, and everyday learning.

Build Something Without Waiting for an Assignment

If there is one thing I would encourage engineering students to do more often, it is to build applications outside their prescribed coursework.

Not necessarily because they need another project on their résumé, but because independent development forces us to make decisions that structured assignments often make for us.

Start with a problem that genuinely interests you. It does not need to be an original idea or an ambitious product. A simple application with a few meaningful features is enough.

Build the first version yourself. Decide how the information should be stored. Think about what happens when a user enters invalid data. Consider how the interface should behave when a request fails. Try deploying the application and making it accessible outside your local development environment.

As the application grows, you will begin encountering questions that were not obvious when you started.

Should this logic belong in the frontend or backend? Is the database structure appropriate? How should errors be handled? What happens when multiple requests arrive simultaneously? Is there a simpler way to implement this feature?

You will not necessarily have the right answers immediately. That is part of the experience.

Use documentation, tutorials, libraries, and development tools wherever they help. There is no value in avoiding useful resources simply to prove that everything was written independently.

But make an effort to understand the decisions behind the code you use. When something breaks, investigate before replacing it with another solution you found online.

Over time, you begin moving from following instructions to making engineering decisions yourself.

And that transition is far more valuable than the number of frameworks listed on a résumé.

Not Every Project Needs to Be Impressive

There is also a tendency to evaluate personal projects based on how impressive they appear to other people.

Students may feel that a project is only worth building if it uses the latest technologies, includes several advanced features, or resembles a commercial product. That expectation can make even getting started unnecessarily difficult.

But learning does not always produce something worth showcasing.

Sometimes, a small experiment that teaches you how authentication works is valuable enough. Sometimes, rebuilding a familiar application helps you understand a concept you previously found confusing. Sometimes, spending an afternoon investigating a bug teaches you more than adding another feature.

Not every project needs to become a startup, and not every experiment needs to become part of a portfolio.

Some things are worth building simply because you want to understand how they work.

Of course, academic performance, theoretical foundations, and formal education remain important. Students also have different responsibilities, resources, and opportunities to practise beyond their coursework. Independent learning should complement education, not become another unrealistic expectation placed on everyone.

The point is not that every student must follow the same path. It is that curiosity and personal initiative deserve a place alongside academic achievement.

What Remains When the Technology Changes

Programming languages evolve. Frameworks gain popularity and eventually make way for newer alternatives. Tools that seem essential today may become less relevant a few years from now.

This is a normal part of working in technology.

What tends to remain valuable is the ability to approach unfamiliar problems, learn what is necessary, question assumptions, and keep improving the quality of one's work.

Technical expertise gives us the foundation to solve problems. Work ethic and curiosity influence how consistently we develop that expertise and how responsibly we apply it.

Looking back, I think engineering education would benefit from placing greater emphasis on these qualities, not necessarily through additional subjects or examinations, but by encouraging students to experiment, build independently, make mistakes, and understand their own work.

Because ultimately, the goal of engineering education should not be limited to producing graduates who know how to use technology. It should also help develop people who are capable of understanding problems and taking responsibility for solving them.

That may not be a skill explicitly mentioned on the syllabus.

But it is certainly one worth developing.