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!

CV review

From time to time, computer engineering candidates send me their CVs for review. Here are my common responses:

First of all, a CV should not contain any typos; it should show that you are conscientious. CVs usually include a list of projects. For the projects you have worked on, there should be a corresponding GitHub repository. Your GitHub account name should be your real name so that it is easy to tell that it is yours. The repository should not be a random code dump copied from elsewhere or a collection of half-baked code snippets. It should include a decent README and quality code.

In the age of AI, this is fairly easy to achieve, assuming you were highly involved in the project. If I see a GitHub repository without a README, I do not bother looking at the code. It can even work against you, as it may feel like an attempt to pass off unfinished or unclear work. It would also be beneficial to record short videos explaining your projects and upload them to YouTube. I rarely see candidates do this, so it would be a strong differentiating factor.

A well-documented project also shows that you would be easy to work with because you can operate independently. You would not require much hand-holding; when stuck, you would provide timely feedback. Your manager would not have to constantly check on you and would only occasionally need to set priorities and provide direction.

I am also often asked whether certifications are useful. For me personally, they do not mean much. However, if the companies you plan to apply to list certifications in their job descriptions, they can be important for securing an interview. Otherwise, just focus on improving your CGPA and work on projects.

02.02.2026: Another student sent me her CV, here are some more tips:

• When listing your internship experience, try to be as concrete as possible with your contributions. Examples:
• "Built an internal analytics tool" => Add details like "measuring real-time user engagement"
• "Supported CI/testing workflows" => Add "Automated testing pipelines using GitHub Actions and Docker, ensuring backend modules passed unit tests before merging to the main branch"
• In your own Projects section, provide direct GitHub links to each project.

Web/Mobile vs Embedded

Tech evolves at different speeds. In web/mobile development, the landscape resets every few years; React today, something else tomorrow. In embedded systems, the core stays steady for decades. C, RTOS, and hardware fundamentals still rule. Which one should you choose as a career?

Web/mobile shapes how billions interact with information. Embedded shapes how machines sense, move, and endure in the physical world. Both matter, just in different dimensions.

Web/mobile is a newcomers’ arena because it has more job openings than embedded and fast-moving frameworks level the field. Even seniors must relearn constantly, so a quick learner can catch up fast. You can ship real apps in days, no hardware needed. Creativity and adaptability beat deep expertise.

Embedded is a veterans’ stronghold since change is slow but depth matters. Hardware control, timing, and debugging take years to master, and once learned, rarely become obsolete. Senior engineers grow more valuable with each project; their experience compounds.

Web favors fast learners. Embedded rewards deep learners. In web, the new replaces the old. In embedded, the old masters the new.

Curious, fast, and drawn to constant change? You’ll thrive in web and mobile development. Thoughtful, precise, and fascinated by what happens beneath the surface? Embedded systems are your natural habitat.

You could also start with web (especially backend) to learn programming fast (Python or JavaScript). Then move into IoT projects, a perfect bridge between web and embedded. Gradually dive into C/C++, RTOS, and hardware-level concepts.

Work permit in Türkiye for Foreign Students

According to the Turkish Work Permit Evaluation Criteria, a full time foreign software engineer must be paid a gross salary of at least four times the gross minimum wage in order to obtain a work permit in Türkiye. See section A.3 in https://www.csgb.gov.tr/uigm/en/calisma-izni/calisma-izni-degerlendirme-kriterleri. Keep that in mind when you apply for a full time job and they ask you for your salary expectation.

AI Without the PhD: A Developer’s Guide

The AI landscape is vast, but you don’t need a PhD in machine learning to make it work for you. By focusing on practical skills, you can build smart apps without getting lost in the math.

Three levels of understanding:

1. Integration Skills: Know how to call an API that provides AI functionality. Example: Converting speech to commands.
2. Conceptual Understanding: Have a general sense of what training an AI model involves. You don’t need to master neural network mathematics, but you should understand the workflow: Collect data → Split into training/testing sets → Train the model → Evaluate → Deploy.
3. Tool Awareness: Recognize that you can train simple models yourself using online tools (e.g. Edge Impulse) or Python libraries (e.g. PyTorch).

A Practical Example: ESP32 Voice Control with AI (No Cloud Needed!)

1. Record voice samples like “light on” or “light off” as training data
2. To expand the dataset, generate synthetic data automatically with OpenAI's Whisper.
3. Split dataset into 80% training and 20% testing.
4. Train the model with a tool.
5. Test accuracy and retrain if needed.
6. Deploy it to the ESP32 microcontroller.

That’s it. You don’t need to know the inner workings of gradient descent or backpropagation to build something that works in the real world.

And most importantly: create 90% of your code with Claude Code.

Music: Sia - Cheap Thrills