--- title: Zac Yeh — Style, personality & self-learning profile title_en: Zac Yeh — Style, personality & self-learning profile description: A synthesis based on the portfolio, open-source projects, work output, and AI learning conversation logs — capturing personality traits, learning patterns, and creative style. sidebar_label: Zac Yeh — personal profile --- # Self-Learner Profile Analysis **Subject:** Chih Hao Yeh (Zac) **Sources:** 1. A live learning conversation with an AI (Claude), starting from semiconductor band gaps and walking through solid-state physics, electromagnetism, history of science, AI technology, and the competitive landscape of the semiconductor industry (about 1.5 hours) 2. A combined style and personality analysis based on the personal portfolio, open-source projects, work output, and self-disclosed material **Intended readers:** professors (academic evaluation), managers (capability assessment), AI agents (structured understanding) --- ## 1. Core Personality Sketch **MBTI: INTP (the Logician)** Before getting into the learning traits, it is worth sketching the core personality first — the way he learns is tightly coupled to these traits, and you need the latter to make sense of the former. ### A maker's drive — "see a problem, want to build something" This is not just "knows how to code"; it is a complete loop from observation to action. His phone kept getting accidentally tapped on the factory floor, so he built an Android app called "LockView". Switching multi-monitor setups was tedious, so he built "DisplayProfileManager". He wanted a physical tachometer for racing games, so he combined an Arduino + LED matrix with a C# desktop program that reads telemetry from the game in real time and drives the hardware. The core pattern is a **pragmatic creative impulse**: where there is friction, eliminate it; where there is a gap, fill it. ### Emotionally steady, low-key, pragmatic From the resume self-description to the project notes to the conversational style, the same characteristics show up consistently. He understates his accomplishments (the game project, for example, is voluntarily tagged "WIP" with a clear note that it demonstrates programming logic rather than being a finished product); when facing unfamiliar territory, he weighs trade-offs before deciding. He has shipped new work continuously since 2021, with no obvious gaps — that long-term stable output cadence is itself the best evidence of solid emotional regulation. --- ## 2. Learning Traits: thinking patterns observed in the conversation ### 1. Curiosity-driven chained inquiry The knowledge path of this conversation was not planned in advance — each answer triggered the next "why", and it organically extended from microscopic physics to macro-level industry dynamics: > band gap → empty energy states → holes and current → AC current → energy transfer in the electromagnetic field → history of science → the 20th-century technology explosion → the technical foundations of generative AI → GPU architecture → NPU/TPU → Nvidia's CUDA moat → historical patterns of technological monopolies This path crossed at least six fields: solid-state physics, electromagnetism, history of science, computer architecture, AI, and business strategy. This kind of cross-domain chained inquiry is not accidental — it is highly consistent with the **cross-domain bridge thinking** that shows up repeatedly across his portfolio. His most distinctive ability is not depth in any single skill but the way he combines knowledge from different fields into new solutions: - Industrial automation + 3D animation → machine simulation animation system - Game engine + industrial control → Digital Twin concept - Game telemetry + Arduino hardware → physical dashboard In other words, the "chained inquiry" shown in the conversation is not a one-off curiosity burst; it is a long-standing thinking habit of building connections between different knowledge systems. ### 2. Actively building mental models rather than passively receiving Throughout the conversation, he keeps doing the same thing: restating what he just learned in his own words, then checking whether his interpretation is correct. After learning that the electromagnetic field is what actually carries energy, he immediately summarised: > "So the role of the electron is to convert into energy (light)? And the wire just guides the direction of the field?" This summary is not entirely precise, but it shows he is trying to compress a complex concept into a framework he can hold in his head, rather than parroting it back. Similarly, when GPU architecture came up: > "GPUs are inherently parallel architecture, while CPUs are sequential. We all know from writing code that parallel processing tends to be more efficient — so isn't the GPU the architecture of the future?" He took his own software engineering experience and tried to extrapolate the future trend of hardware architecture. The inference was later corrected by Amdahl's Law, but **forming a hypothesis and then testing it** itself shows he is not passively waiting for answers. This "active construction" thinking pattern lines up perfectly with what shows up in his portfolio — every one of his projects starts with a problem he ran into, and then he picks the most fitting technology to solve it, rather than picking a project just to learn some particular technology. Whether he is learning a physics concept or a new technology, the driver is the same: understand how the system works, then build his own model of it. ### 3. A sharp eye for contradictions and ambiguity in arguments When discussing Nvidia's CUDA ecosystem as a moat, the AI's response mentioned both "CUDA" and "Tensor Core". He immediately caught the tension: > "But isn't CUDA traditional parallel computing? Doesn't AI use Tensor Core?" This question precisely identified the naming confusion between "CUDA Core" (a hardware unit) and "CUDA" (a software platform), forcing the AI to separate the hardware layer from the software layer and re-explain. Catching this kind of subtle inconsistency in a flood of information shows he is not just "hearing things"; he is actually digesting and stress-testing every claim. The same demand for logical consistency shows up in his engineering practice. While maintaining the open-source DisplayProfileManager, he proactively responds to community issues, integrates feature requests, and is candid when announcing maintenance status — all of these behaviours share the same underlying logic: don't accept fuzziness, don't avoid problems, deal with every inconsistency head-on. ### 4. From concrete phenomena down to the underlying principle His questioning never stops at "knowing the answer"; he keeps asking the "why" behind it. After hearing that AC current electrons just oscillate in place, he asked next: > "How did anyone discover that AC current electrons oscillating in place can still transfer energy?" This question jumps from physics phenomenon to history of science, showing he wants to know not just "what is" but also "how humans came to find this out" — a curiosity about the process by which knowledge is formed, not just about the result. Then, on learning that electromagnetic fields propagate at the speed of light and electrons simply do not have time to travel from the switch to the bulb, he derived his own insight: > "If the electrons can't make it from the switch to the bulb in time but the bulb still lights up, doesn't that mean there's some invisible energy driving the bulb?" The inference is physically correct — he had, in his own words, rediscovered the conclusion Poynting derived mathematically in 1884. This habit of "not just wanting to know *what*, but chasing down *why* and *how*" is exactly why his self-learning path, though non-linear, produces real output in every field he touches. He has learned a remarkable spread of things — C#, C++, UE5, Blender, ZBrush, Three.js, Arduino, Android development — and in every case there is a shipped project or product as proof, because he pushed his learning of each technology deep enough to ship something on his own. ### 5. The instinct to connect knowledge to a larger picture After hearing the timeline of 20th-century technological breakthroughs, he didn't stop at "wow, so many inventions"; he noticed a pattern: > "Why does it feel like there were so many technological breakthroughs in the 19xx period?" This is not a specific technical question — it's a meta-observation, looking at the **distribution** of knowledge itself. Similarly, when discussing CUDA's monopoly position, he drew an analogy to other monopolies that history had eventually broken: > "So the CUDA moat is bound to break eventually, right? A lot of older monopolies now have plenty of alternative technologies." This ability to step back from individual facts and look at the broader pattern lines up directly with the trait that shows up in his engineering practice. The most striking feature of his portfolio is not depth in any single technology but **end-to-end system integration ability** — being able to understand the entire chain from low-level hardware to top-level UI. This "see the whole picture" ability, whether in academic inquiry or engineering work, points to the same cognitive trait: dissatisfaction with the local view, always trying to understand how the entire system works. --- ## 3. Portfolio Evidence: from learning traits to actual output The learning traits observed in the conversation are fully corroborated by his long-running portfolio. The following table shows how his projects cut across multiple technology layers — each project is itself an instance of "start from a problem, learn across layers, deliver end-to-end": | Project | Technology layers covered | Corresponding trait | | ---------------------- | ------------------------------------------------------ | ---------------------------------- | | Industrial machine software | C# WinForm/WPF → hardware control → comms protocol → UI | systematic deep-dive, problem-driven | | 3D machine simulation web app | ASP.NET Blazor → JavaScript → Three.js → 3D animation | cross-domain bridging | | UE5 Digital Twin concept | C# control software → TCP comms → UE5 3D visualisation → record/replay | chained inquiry, big-picture instinct | | Arduino racing dashboard | game → C# desktop app → Serial Port → Arduino → LED hardware | maker's drive, active construction | | Android LockView | Kotlin/Compose → gesture system → state management → Google Play release | problem-driven, end-to-end delivery | | DisplayProfileManager | C# WPF → Windows API P/Invoke → GitHub Release | drilling from concrete problem to underlying principle | | UE5 game development | C++ logic → 3D modelling → animation → multiplayer architecture | continuous iteration, deep curiosity | ### Awareness of "exploration" vs "delivery" A typical INTP can get stuck in endless research and never ship. The portfolio shows this tendency exists but is under control: the game project has indeed been WIP for a long time (continuous iteration from 2022 to 2025), reflecting an INTP's drive for perfection; but work projects (machine software, simulation animation, HMI systems) all have clear delivery records, and personal-tool projects all reach a releasable level of completeness. This shows he is aware of when he can keep polishing slowly and when he has to ship. --- ## 4. Background and Learning Style Zac is currently studying Electronic Engineering in a university evening programme; by day he works as a software engineer on automated machinery, with five years of industrial automation development experience. The way he uses AI is not to look up quick answers but to treat it as a Socratic conversation partner — building his own understanding of underlying principles through chained follow-up questions. From the conversation, his questions have a clear pattern: short and precise, going straight to the core, often challenging assumptions baked into the previous answer. Across the full 1.5-hour conversation, every question flows naturally from the previous answer — no jumps, no loss of thread, indicating high sustained focus throughout. His work experience consistently feeds back into the quality of his questions. When discussing GPU parallel processing, he draws on hands-on programming experience for his insights; when discussing serial vs parallel tasks, his work background (EtherCAT device control, state machines, real-time control) lets him intuitively see why certain tasks cannot be parallelised. This habit of **cross-validating theory against practice** is the most distinctive feature of his learning style — and it explains why, even though the spread of his self-taught topics looks chaotic, every one of them has a concrete real-world application. --- ## 5. Drivers and Potential Blind Spots ### Internal drivers - **Core fuel**: curiosity about how things work. Whether it is a game engine's rendering pipeline, a machine's control logic, or the energy-transfer mechanism of AC current, what attracts him is the mechanism of the system. - **Source of satisfaction**: seeing the things he built actually run. His resume explicitly says "watching the machine gradually come together and run smoothly is what gives me the strongest sense of accomplishment" — the from-zero-to-something feeling is the core motivator. - **Learning motivation**: not for certificates or exams, but to be able to build the next thing he wants to build. Every new technology he learns is because a current project demands it. ### Potential blind spots (honest assessment) | Trait | Positive read | Caveat | | --------------------------- | ---------------------------------------------- | ------------------------------------------------------------- | | Broad technical exposure | Strong cross-domain integration | Need to avoid spreading energy too thin | | Strong independence | Can deliver complete products without others | Less team-collaboration experience to point to | | Pursuit of perfection | Consistent output quality | Long-running WIP game project may reflect difficulty in closing | | Honest, low-key presentation | Trustworthy, no inflation | Can lose out when self-promotion is required | | Problem-driven learning | High learning efficiency, knowledge immediately usable | Less systematic reinforcement of foundational theory (e.g. algorithm practice only started recently) | | Drawn to new things | Sustained learning enthusiasm | Needs mechanisms to keep from jumping into rabbit holes too fast | --- ## 6. Summary ### One-line positioning > **A pragmatism-driven, curiosity-fuelled, full-stack hardware/software INTP maker.** ### Three keywords 1. **Maker** — not just a person who writes code, but a person who turns ideas in his head into running systems. 2. **Bridge** — builds connections between industrial and game, software and hardware, theory and practice. 3. **Quiet doer** — not flashy, but consistently and reliably ships things. ### Academic potential What Zac demonstrates in both the conversation and the portfolio is not raw knowledge volume but a learning attitude and method — actively forming hypotheses, willing to put potentially-wrong understandings on the table for verification, building connections between different fields, staying curious about the process by which knowledge is formed, and pushing inquiry through to a running deliverable. For independent research at the graduate level, these traits matter far more than starting knowledge volume. And five years of continuous output spanning hardware and software, from industrial automation to game engines, prove these are not short-term behaviours but stable patterns. --- *This document is a synthesis based on AI conversation logs, the public portfolio, and self-disclosed material — focused on learning traits, style, and personality observable from actual behaviour.*