How to Stay Motivated as an Engineering Student

Many engineering students in demanding engineering fields like aerospace, computers or electronics struggle with motivation. Inspiring professors are rare, and universities are largely designed around assessment and abstraction, while motivation comes from interacting with meaningful, real-world problems. So how can a student stay motivated when overwhelmed with coursework?

A common idea is to postpone real projects: “I’ll just collect ideas during the semester and build things in the summer.” It sounds practical but it often fails. By the time summer arrives ideas have lost their emotional appeal, context is forgotten, getting started becomes difficult. Engineering is not something you can “batch” into a single productive period. It requires continuous contact with real problems.

Instead of doing large projects during the semester, the goal should be to stay lightly connected to real engineering work. Forget big, impressive projects. Don’t treat coursework and projects as separate worlds. Instead turn assignments into something slightly more real and connect theory to a simple experiment or simulation. Focus on tasks that fit into an additional 1–2 hours per week to maintain momentum:

• Ask AI where the theory is used and what other alternative theories exist
• Simulate a simple control loop
• Analyze noisy sensor data

A successful session is not “I finished something”, it is “I tried something and learned something real”. This shift removes pressure and keeps the loop alive. To build engineering judgment, ask:

• What surprised you?
• What didn’t work?
• What would you try next?

Write down your work in a medium like Google Docs. During the summer expand those into deeper projects. This way, summer work starts with context and direction, not a blank page.

An experienced engineer like me can help you come up with ideas, suggest simpler starting points, show what matters, discuss your results. This turns 6 hours of confusion into 2 hours of progress and keep you motivated. The goal is continuity, not performance.

Motivation comes from feeling that your actions meaningfully interact with reality. A good mentor helps rebuild it quietly, consistently, and without adding pressure. Even a thin thread to real engineering work can make the difference between burnout and long-term growth.

Music: Finley Quaye - Dice

The future of computer engineering

With AI, one engineer can now:

• build prototypes quickly
• explore many design alternatives
• automate testing
• generate large codebases
• document systems

Due to cheaper microcontrollers and AI code generation, software will expand into almost everything. While the amount of software increases, so does productivity per engineer. That might lead to more software but fewer engineers needed to build it. This has happened before in other industries:

• In 1900, about 37.9% of the US workforce worked in agriculture. Today in many developed countries it is below 2%, yet food production is far higher. Reference PDF: The Roots of Agricultural Productivity Growth, p.5
• Automation dramatically increased factory output while reducing the number of workers.

Demand will decrease for engineers whose main role is implementing detailed specifications or writing code from tickets, because AI can do it faster, better, and much more cheaply. The field will shift from many average engineers to fewer but more capable engineers who can:

• detect valuable problems to solve and define them clearly
• design systems using domain intuition (which constraints matter, what trade-offs are acceptable)
• implement designs with AI orchestration
• integrate hardware and software
• handle non-functional requirements like cost vs performance, reliability vs development time, long-term maintainability and safety

In the past, juniors spent months just learning syntax and frameworks, which is now of relatively low value. AI might help juniors develop senior thinking faster because they can:

• ask questions interactively
• explore many implementations quickly
• generate and test edge cases rapidly

These opportunities only help if you actively seek them. AI accelerates learning, but curiosity and initiative determine who benefit the most.

Music: Coolio - Gangsta's Paradise (feat. L.V.)

How I Can Help You Make Good Choices

As an engineer with 30 years of experience, my main value to you as a student or junior engineer is focusing your energy on the most promising path by asking the right questions:

• What should I study?
• I’m not a software engineer, how can I become one through self-study?
• Should I focus on CGPA, double major, or projects?
• How vital is a professional network, and how can I grow mine?
• Should I work/study abroad?
• How should my CV be?
• Which companies should I apply to?
• What should my salary expectations be?
• What should I do during my initial months on the job?
• I have a startup idea, what should my next step be? Should I look for investment? How can I increase my chances of securing investment? How can I prepare a financial projection for the business plan?
• Is AI a threat to the modern workforce? How can I use AI to become a better engineer?

Music: Papaoutai (Afro Soul) - Stromae

Three levels of AI usage

When researching a topic, there are three levels of AI usage:

1. Ask "what" (better Google search)
2. Ask "why" (requires curiosity)
3. Ask if a specific alternative could be used (requires experience)

Examples:

1. What is the difference between a mutex and a semaphore?
2. Why would I choose a microkernel architecture over a monolithic one for this specific embedded system?
3. I'm currently using FreeRTOS for this task, but would an Event-Driven State Machine be more power-efficient for this specific low-power MCU?

The first rule of convincing others: Don't be a jerk

We are often raised on the romantic myth of the lone genius. We love the story of the visionary who sees a truth no one else can see, fights the ignorant masses, and eventually is proven right. The 19th-century Hungarian physician Ignaz Semmelweis is the poster child for this myth. 

Semmelweis discovered in 1847 that doctors were literally carrying death on their hands. By mandating a hand-washing protocol at the Vienna General Hospital, he slashed maternal mortality rates from 18% to less than 2% almost overnight.

However, he was a diplomatic disaster. When his colleagues didn't immediately adopt his findings, he didn't refine his argument or seek allies. He called his peers murderers and irresponsible ignoramuses. Most people would rather believe the data is wrong than believe they are monsters. His life ended in a mental asylum, beaten by the guards.

The antiseptic revolution required the arrival of Joseph Lister, a man who was as tactful and methodical as Semmelweis was erratic and angry, to finally make the idea stick. The twenty-year gap between Semmelweis’s data and the medical world’s adoption of hand-washing represents thousands of preventable deaths.

If you believe you have discovered something vital, you have to be likeable enough to be heard. If your language attacks the listener’s intelligence or character, they will stop listening to your data. If you ignore the human element of your truth, you aren't being a martyr, you’re being an obstacle to your own cause.

Advice for a New Avionics Software Engineer

A new computer engineering graduate who started working at an avionics company last week was given documents such as DO-178C to read. As you might guess, this is rather boring, and he asked me how he could make the initial learning phase more interesting. He is already using NotebookLM to convert the documents to audio and to ask questions.

Since avionics involves safety-critical software development, where we don’t just care whether the code works but also how it fails, I suggested that he write a toy software project in which he simulates sensors (such as an angle-of-attack sensor) and asks an AI about typical failure conditions. The sensors might produce out-of-range values, stop working for some time and then start again, they could stay within bounds but have sudden jumps (e.g. GPS positions under spoofing) and so on. On sensor error, his code should first enter a degraded mode (using the previous good value and displaying a warning message) and, if the sensor error persists, transition to a safe mode (displaying an error message). He could then ask the AI which types of hardware defects can be detected by software (hint: Error Correction Code). This exercise would make the concepts of safety-critical software development more concrete.

The next step would be to understand how avionics sensors actually work, which would increase his domain knowledge. Adding simple mathematical models for the sensors and a bit of digital signal processing to his toy project would also be a very useful learning experience.

He could ask experienced engineers at his company how they arrived at the safety level for the system they are currently developing. What kinds of hazards did they take into account? How did they calculate their probability values?

For more low level topics, he could look into hard real-time concerns, such as interrupt latency and jitter, how cache misses, pipelining, and branch prediction adversely affect determinism and worst-case execution time (WCET).

Lastly, he could read about or watch analyses of software and aircraft failures to get an idea of how systems fail. For example, he could ask AI why the Boeing 737 MAX MCAS did not use both angle-of-attack sensors, despite the aircraft already having two. Finally, he could ask whether a relatively simple solution could have been found while staying within the original cost constraints. One possible answer for MCAS might be: if the designers had limited MCAS to a single input and ensured that it disengaged when the pilot pulled back on the yoke, it would have preserved the commonality assumption in normal flight while also preventing the catastrophic failure mode.

Avionics is a fascinating field, offering endless opportunities for exploration. By being curious and working hard, he can become a valuable engineer who not only solves problems correctly but can also spot problems worth solving within a few years.

Music: Khaled - Aicha

Teaching in the Age of AI

This fall semester, I taught Embedded Systems as a technical elective for fourth-year computer engineering students. 

Since most homework and many projects are now trivially solvable by AI (Large Language Models, LLMs), they are no longer worth the instructor’s effort to assign and grade. Therefore, I did not assign any homework. Instead, I encouraged students to use LLMs during class as a tool for active learning.

For each topic, I presented a short, real-world embedded example and then posed a question, such as “calculate the amount of stack used by the given C function.” Students asked their LLM for an answer right there in class. Ten minutes later, I invited one student to the board to explain the solution using a marker and whiteboard.

The LLM produces an answer but the student must defend it. "Why does this approach work?",  "Where does it fail?" I step in to guide them when they are unable to answer. This is far more fun than just explaining everything myself. It also gives me time to take a break from constantly speaking. One could even argue that this simulates a job interview.

For grading, I used traditional pen-and-paper exams with multiple-choice questions; no LLMs were allowed during the exam. However, I prepared the questions with the help of LLMs, of course!