Should you be a manager?

A computer engineering student asked me whether he should pursue a technical career or transition into management. Having done both, here's my perspective.

I spent about 10 years as a department and project manager. Eventually, I realized that managing people was no longer something I enjoyed, so I stepped away from all of my management roles. For the past 15 years, I've been an individual contributor while continuing to mentor engineers, but I'm no longer responsible for their performance.

Despite that, I recommend that everyone spend at least a few years in a management role. It gives you valuable experience that is very difficult to gain any other way. Volunteering for responsibilities beyond your formal role and building relationships beyond your immediate team will increase your chances of moving into management.

When you become a manager, you get to see behind the curtain. You discover that many unpopular decisions are driven by budget constraints, deadlines, conflicting stakeholder requests, or information that isn't visible to the rest of the team. You learn more about yourself and about other people (for example, that employees can also be biased or unfair), develop an appreciation for different perspectives, and become more effective in dealing with others.

A good manager doesn't just do things right, they also make sure the right things get done. They know how value is created and say no to work that doesn't have enough value. You will learn that saying no is much harder than saying yes because you have to deal with the pushback. By ensuring that the right work is carried out with high quality, you create a multiplier effect that improves the performance of everyone on your team. A great engineer can double their own productivity. A great manager can increase the effectiveness of a team of ten people by 50%, creating a far greater overall impact.

At the same time, don't neglect your technical skills. If you ever decide to step away from management, maintaining your technical expertise will allow you to return to an engineering role. If your technical skills become outdated, your career options become much more limited.

Of course, it's not easy to be both a good manager and a good engineer. Excelling at both requires more effort than most people are willing to invest, and it's only possible if you're genuinely interested in them.

A realistic take on the subject: Waltzing with Bears

Music: Modern Talking - Cheri Cheri Lady

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:

• analyze and close existing PRs much faster
• explore many design alternatives by building prototypes quickly
• take on more ambitious projects and generate large codebases
• undertake optimizations that wouldn't be economically viable with manual labor because it would take too much time

Due to cheaper microcontrollers and AI code generation, software will expand into almost everything. While the amount of software explodes, 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.

09.04.2026: DHH's take on AI's effect on the workforce

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