How to present to investors

You have a commercially promising idea and a capable team, but not enough resources to build it? You can prepare a pitch deck and before taking it to investors, use AI to attack the idea from three different perspectives:

1. Prompt for AI-1: You are not my assistant. You are a skeptical VC who wants to reject this investment. Your job is to find the strongest reasons not to invest. Assume every claim is false until supported by evidence.
2. Prompt for AI-2: Now act as the founder and rebut every objection using only evidence you can actually verify.
3. Prompt for AI-3: Now act as the investment committee and decide whether the rebuttals are sufficient.

What happens if AI-3 (the investment committee) still rejects the idea? Weaken/narrow your claims, gather real evidence, or kill the idea. The goal isn't to use AI to make a weak pitch sound convincing. The goal is to use AI to discover which ideas are actually worth pitching. Remember that extraordinary claims require extraordinary evidence.

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. Since you will be attending higher-level meetings, both inside and outside the company, you may also expand your network more effectively.

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

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

Studying Computer Engineering in Germany: Universität vs Hochschule

If you’re considering studying in Germany, one of the first choices you’ll face is between a Universität and a Hochschule (Fachhochschule / University of Applied Sciences). Both award a  Bachelor of Science (BSc), but they serve different types of students and career goals.

Universitäten focus on theoretical knowledge and research. Professors are evaluated mainly on publications, grants, and PhD supervision, so teaching ability is less emphasized. Class sizes can reach into the hundreds, leaving students with little chance of direct contact with professors. Students dive deep into mathematics, algorithms, and computer science theory, and are largely expected to learn on their own — which can add extra stress for foreign students. This is the ideal path if you want to pursue an academic career.

Hochschulen are industry-oriented. Professors are hired for their industry experience and teaching ability rather than publications. Programs include a mandatory internship semester (Praxissemester) and project-based courses. Class sizes are smaller (often just a couple dozen students), giving students much easier access to professors and helping them graduate with strong connections to employers. This path is perfect if your goal is to graduate as a job-ready engineer.

The most unique feature of DHBW (and all duale Studiengänge in Germany) is that 1 year in advance, you apply first to a partner company (e.g., Mercedes-Benz, Bosch, SAP, Porsche, IBM). The company runs its own selection process. Only if you get a training contract (Ausbildungsvertrag) with the company are you then admitted to DHBW. This is why the probability of graduating in 3 years is high — companies don’t hire people they expect to fail. If you have graduated from a Turkish High School without an IB diploma programme, to apply to the company you first have to either study 1 year in a Turkish university or 1 year in a German StudienKolleg. Since companies take applications for the next year, this would mean losing 2 years. Having an IB diploma saves 2 years.

The dropout rate is around 33% at Universitäten, compared to about 23% at Fachhochschulen, indicating that studying at a Fachhochschule is generally easier.

After graduation, to get a job as a foreigner, the salary offer has to be minimum €43,759.80 yearly gross (as of 2025). This is roughly 1.6 times the minimum wage in Germany.

Türkiye does not have a direct equivalent of the German Hochschule. The closest would be Meslek Yüksekokulu (2-year vocational schools), but those don’t lead to a BSc. All proper engineering BSc programs are run by universities which follow a more research-oriented academic culture and place little emphasis on teaching quality or industry needs. Due to incentives tied to publishing papers, teaching is often viewed as a burden rather than a priority.

Turkish graduates may lack structured internship/practical semesters. To be hired in the tech industry, students must take initiative, actively develop practical skills beyond coursework and demonstrate hands-on experience through internships, freelance work, or GitHub contributions.

AI: More Luck Than Science?

In AI, a lot of progress still comes down to trial and error — and sometimes, plain old luck. We can’t even predict how many images you might need to train a cat classifier to 95% accuracy.

When researchers train giant neural networks, the outcome can swing wildly depending on small, random details. Change the initialization seed, shuffle the data differently, or even let the GPU run in a slightly different order, and you might end up with a model that either crushes benchmarks… or flops.

Big labs try to beat this randomness by brute force — running thousands of experiments in parallel until something works. Smaller teams don’t have that luxury, which is why AI breakthroughs often come from places with deep pockets.

Scaling laws, optimization tricks, and theory give us islands of predictability. But we don’t yet have the “physics of deep learning” — the equations that would let us design a network and know it’ll hit 95% accuracy without a thousand failed runs.

Until then, success in AI will keep feeling less like engineering and more like informed gambling with increasingly sophisticated strategies.

Gaining Experience by Fixing Existing Web Apps

Here’s a little secret: most small business web apps… kinda suck. Small businesses usually don’t have the budget for high-quality software engineering, so their apps are often missing important features, are slow, outdated, and not mobile-friendly. But that’s actually an opportunity for you as a student. Instead of building yet another “hello world” project or a to-do list app no one uses, try this:

1. Find a small business with a clunky website or app, e.g. diyetta.
2. Use it on PC and mobile, make a list of improvements.
3. Make a copy of the whole app or parts of it and make it faster, cleaner, easier to use.
4. Demo your version to the owner.

Worst case? You get real-world experience. Best case? You get paid. Either way, you win. You’re not just learning to code—you’re learning how to:

• Create real value (solving actual problems, not just coding puzzles)
• Sell your ideas (convincing skills)

This one simple strategy can turn you from “just another student” into someone who can point to real impact. That looks so much better on your resume than “I built a weather app.”

So… what’s the worst small business web app you’ve seen lately? Maybe that’s your next project.

Startup Checklist for Students

Thinking about turning your hobby or project into a business? Ask yourself:

1. Who wants it? What makes it better than the alternatives?
2. How will people hear about it? A great product is useless if no one knows it exists.
3. How will it make money?

Teknofest Fighter UAV Competition

I am helping an undergraduate team with their Teknofest Fighter UAV Competition. The most difficult technical challenge is autonomously detecting and following other fixed-wing UAVs in the air. Teams must use a single stationary camera—no gimbals are allowed [Specification 6.1].

My first piece of advice to the team was to set realistic expectations and define intermediate success metrics, so that regardless of the final outcome, they can feel good about their progress. Last year's winning team was established in 2017 and reused a UAV they had been improving since 2020, which shows that having a realistic chance of winning requires several years of preparation.

The domains in which you need to be knowledgeable include:

1. Image processing, object tracking
2. Airplane aerodynamics
3. Mechanics
4. Guidance and navigation for autonomous take-off, flight, waypoint navigation, target tracking, landing
5. Embedded software development for UAV avionics, real-time operating systems
6. Ground station software development
7. Telecommunications for telemetry and commands from ground station
8. System identification
9. Manufacturing and system integration
10. Use of simulation tools (e.g., ArduPilot SITL, Gazebo, QGroundControl)
11. Public relations and marketing to acquire necessary resources (~$5,000)
12. Ground testing of individual components and the integrated system
13. Manual flight of the UAV for system identification maneuvers
14. Autonomous UAV flight testing

Mastering all of these domains is beyond the capability of any undergraduate team. Fortunately, systems like Pixhawk Cube Orange and PX4 Autopilot handle autonomous flight, NVIDIA Jetson series can handle object detection, and ready-made airframes like the X-UAV Talon reduce the production burden. This allows the team to focus on UAV-ground communications, tracking the target UAV in the video feed and generating appropriate guidance commands for their own UAV to follow it.

Since the Critical Design Report must not exceed 25 pages [see Critical Design Report Template, p.8], it is more of a system overview than a design report.

In light of all the above, here are my suggested success metrics:

1. Pass the Technical Qualification Form
2. Learn how to use ArduPilot SITL with Gazebo
3. Pass the Critical Design Report
4. Obtain monetary/component sponsorship
5. Ground test all components
6. Submit System Identification and Flight Evidence Video
7. Qualify as a finalist
8. Participate in the competition and complete at least one mission
9. Win a prize in the competition
10. Win first place

This year, I would be satisfied if the team reaches step 4 and pleasantly surprised if they make it to step 7. In any case, they should understand that it will likely take at least another year to be in a position to win any prizes.

Bonus: Python code for generating guidance commands from object tracking.

Music: Shirley Bassey - If You Go Away

Memory and Storage Latency

Below you can see memory and storage latencies and their corresponding analogies. For example, a cache miss that triggers a memory access from RAM, is about 100 times slower than the L1 cache. A skilled engineer can make an app run at supersonic speed instead of at a snail's pace — often the difference between a popular app and a dead one.

Component	Latency	Order	Metaphorical Speed
CPU Register	~0.5 ns	1	🚀 3,600 km/h Supersonic jet
L1 Cache	~1 ns	1	✈️ 1,800 km/h Commercial jet
L2/L3 Cache	~ 5 ns	10	🚅 360 km/h High speed train
RAM (DRAM)	~100 ns	100	🛵 18 km/h Scooter
Flash (NOR)	~10 µs	10⁴	🐢 0.18 km/h Tortoise
NVMe SSD	~50 µs	10⁵	🐌 0.036 km/h Snail

Minor, double major or projects

Engineering students often ask, 'Would doing a minor or double major benefit my career?' My answer is that pursuing a minor or double major is a demanding process. Instead, by working on projects related to your field of study, you can achieve much greater benefits with less effort.