For my first co-op term (one of six), I joined the FreeBSD Foundation as a Junior Software Developer Intern. I had been contributing to FreeBSD since May 2021, so I came in with an existing project backlog and a list of ideas I wanted to pursue. My supervisor, Ed Maste (emaste@), gave me the freedom to drive my own roadmap, which made the term especially productive.

Main Projects

I focused on two primary areas this term: HMP (heterogeneous multi-processing) scheduling, and improvements to LLDB kernel debugging.

HMP Scheduling

I wrote the initial patch for the hmp(4) framework, which serves as an interface between the provider (which reports CPU state) and the scheduler. This work will be presented at BSDCan 2026, and I've also been drafting an accompanying paper in LaTeX.

LLDB Kernel Debugging

The goal here was to bring LLDB to feature parity with KGDB for FreeBSD kernel debugging. This had originally been proposed as a Google Summer of Code project, but since no suitable candidate was found, I picked it up as part of my co-op work.

The work included fixing significant bugs such as kernel debugging on FreeBSD 14+ on arm64 being completely broken. I also extended support to less common architectures like riscv and ppc64le. By the end of the term, every supported platform on FreeBSD 14+ works, with the exception of i386 and armv7, which have limited support. These changes will ship in LLVM 23, and I plan to backport them to FreeBSD's in-tree LLVM as well.

Exploratory Work

I also spent time on two exploratory projects that didn't reach a meaningful outcome before my last day:

Forgejo CI scripts. FreeBSD developers are currently evaluating Forgejo as a potential successor to Phorge for our source forge. Due to limited hardware resources on my end, I wasn't able to run as many script experiments as I'd hoped.

EEVDF scheduler. This was a side project I used as a testbed to evaluate how far LLM-assisted development ("vibe coding") could take me. I'll go into more detail in a separate post, but the short version is that even Claude Code with Opus 4.6 got me only about 70% of the way to what I wanted.

Acknowledgements

First and foremost, thank you to Ed Maste (emaste@), Senior Director of Technology at the Foundation and my co-op supervisor. Despite a heavy workload, Ed consistently looked out for me and the other co-op students, pointed me to useful resources, and tagged the right reviewers on my Phabricator revisions. I wouldn't have been able to land nearly as many changes on the FreeBSD and LLVM sides without his support.

Thank you to Li-wen Hsu (lwhsu@) for rebuilding the network setup at the Kitchener office, maintaining and upgrading the FreeBSD clusters, and organizing AsiaBSDCon 2026.

Thanks to Siva Mahadevan (siva@) for troubleshooting network issues at the Foundation, recovering my desktop after a panic from a -CURRENT update, and supervising the three of us co-op students.

On the FreeBSD project side, thanks to Olivier Certner (olce@), Konstantin Belousov (kib@), Warner Losh (imp@), and John Baldwin (jhb@) for reviewing my patches and offering constructive feedback.

On the LLDB side, thanks to Jessica Clarke (jrtc27@), Sheng-yi Hung (aokblast@), and David Spickett (@DavidSpickett) from Arm for reviewing my FreeBSD kernel debugging patches.

Finally, thank you to the HR team at the Foundation for supporting the co-op students and helping arrange my travel grant for AsiaBSDCon 2026.

Devsummit

The Developer Summit ran for two days, 10 AM to 5 PM each day. Most sessions were short presentations covering topics like FreeBSD on WSL 2 and Ansible on FreeBSD. Between talks, developers worked on patches, followed up on mailing-list threads, and reviewed one another's work — I got some useful feedback on my LLVM pull requests during these gaps.

The AsiaBSDCon organizer handed out Kuai Kuai, a popular Taiwanese snack that comes in a bright green package. The tradition is to place it on top of your computer as a good-luck charm — the idea being that your code won't break as long as the snack hasn't expired. Think of it as the Taiwanese equivalent of holding a blessing ceremony in a server room before it goes live.

So I guess it's something similar to having religious ceremony in a server room before it opens to public.

AsiaBSDCon 2026

The main conference began right after the summit and drew roughly three to four times as many attendees. Each participant received a copy of the AsiaBSDCon 2026 Proceedings as part of the welcome package. The book itself was well produced, though the formatting across papers was inconsistent — most followed the IEEE Conference template, but font weight, size, margins, and layout varied noticeably, and a few papers used entirely different templates. It would be great if future committees provided a strict template and enforced compliance. A PDF or EPUB edition would also be a welcome addition.

Talks That Stood Out

Rethinking the forms of OS functionality development

Kenichi Yasukata presented his work on a portable userland TCP/IP stack. He outlined the performance advantages of running the network stack in userspace but highlighted a persistent challenge: portability across operating systems due to divergent APIs.

His solution is a userland TCP/IP stack that deliberately omits OS-specific code. That sounds paradoxical — how can a TCP/IP stack function without OS bindings? The answer is that developers supply the OS-specific low-level glue themselves. This separation lets the core stack remain portable while still achieving strong performance.

Kenichi also discussed techniques for intercepting system calls without relying on LD_PRELOAD. His approach uses binary overwriting, which requires architecture-specific hooks: svc-hook on arm64, and zpoline (a trampoline through an alternative syscall entry point) on x86-64.

Faster, smolBSD! Boot! Boot!

Pierre Pronchery showcased smolBSD, a container-oriented NetBSD variant. By stripping the kernel down to only the necessary drivers and bypassing the traditional UEFI boot path, smolBSD achieves bare-metal boot times under one second.

Pierre demonstrated PicoClaw and SSH server images that can be instantiated much like Docker images — an impressive feat for anyone who has waited several seconds for a standard container to come up. He also showed ZFS-on-root running on NetBSD, though this still appears to lag behind FreeBSD's mature ZFS support.

Run Time Reoptimization for Modern Heterogenous Systems

George Neville-Neil argued that modern hardware — CPUs, GPUs, NPUs — has evolved far beyond the PDP-11 model, yet Unix-like operating systems still carry assumptions rooted in that era.

He dove deep into CPU microarchitecture: cycle-level penalties, cache misses, branch mispredictions, and the like. The core idea is to capture these runtime penalties and feed them back into LLVM, which he highlighted as a strong abstraction layer across diverse hardware targets. This feedback from live profilers is passed through optimization pipelines that produce architecture-specific binaries, which are reloaded without exiting the program.

I'll admit this talk was hard to follow in real time — partly because I was multitasking — and I plan to revisit the recording to better understand the benchmarking results.

Bringing memory safety to BSD with CHERI

Brooks Davis presented the CheriBSD upstreaming effort, with a strong emphasis on CHERI's security benefits. Two examples stood out. First, the team asked an LLM to inject 13 memory bugs into NGINX; CHERI caught all 13 plus two additional bugs the LLM introduced unintentionally. Second, while porting Chromium to CheriBSD, the two-person team uncovered numerous memory vulnerabilities that were later assigned CVEs — matching or exceeding the output of over 100 security researchers on the Chrome team, thanks to CHERI's memory-safety guarantees.

The upstreaming roadmap targets completion by FreeBSD 16, expected in December 2027. CheriBSD will be the first time-sharing operating system with full CHERI support, covering both Arm Morello and RISC-V CHERI (RV64Y). On the Linux side, a CHERI port is in progress, but organizational challenges — what I'd describe as significant process and priority shifts — appear to be slowing adoption.

What's Next?

BSDCan 2026 — I'll be presenting a talk on hybrid scheduling. Unfortunately, a midterm exam will keep me from the hackathon.

EuroBSDCon 2026 — I'm eager to attend, pending travel approval from my second co-op employer.

AsiaBSDCon 2027 — During the closing session, Li-wen Hsu announced that next year's conference will be held in Singapore. As George put it, making it happen requires "volunteers, volunteers, volunteers — and sponsors, sponsors, sponsors." If you're based in Singapore and can spare four days, please consider volunteering. If your company is in a position to help financially, sponsorship goes a long way.

Acknowledgments

As George Neville-Neil noted in the closing session, enormous thanks are owed to Li-wen Hsu (lwhsu@) for making AsiaBSDCon possible. Everyone who worked alongside him knows the effort he poured into the event, day and night. Thank you, Li-wen.

I also want to thank the FreeBSD Foundation for approving and sponsoring my trip to Taiwan.

The Good

Jujutsu's workflow is meaningfully more efficient than Git's. Operations that tend to be friction-heavy in Git—moving commits between branches, rewriting commit messages, and resolving merge conflicts—are noticeably smoother in Jujutsu. Compatibility with existing Git repositories is solid; in most cases I disable Git colocation entirely and work with a fully native Jujutsu repository.

For production use, I rely on Jujutsu for both LLVM development and my weekly reports at the FreeBSD Foundation. Across both of these workflows, it has been completely reliable.

The Bad

Jujutsu is in good shape overall, but a few pain points remain.

No hook support. While it is true that most Git hooks are unnecessary in Jujutsu's model, prepare-commit-msg is the exception I miss daily. The FreeBSD Project uses this hook to inject metadata into commit messages, and its absence is the sole reason freebsd-src is the one repository where I still fall back to Git. I am hopeful that hook support will land soon.

No --fixup equivalent. Git's git commit --fixup has no direct counterpart in Jujutsu. My current workaround is to manually prepend fixup! to the change description, but this means re-typing the target commit message each time. When working on a series of LLVM patches, this gets tedious quickly.

Manual bookmark management. Jujutsu does not advance bookmarks automatically, which makes pushing changes more verbose than it needs to be. Where Git requires a single git push, Jujutsu requires two commands: jj bookmark set -r <revset> foo followed by jj git push --bookmark foo. It is a small friction, but it adds up.

Immature ecosystem. Third-party tooling is still catching up. As a concrete example, Spaceship only gained Jujutsu prompt support last week, and only through a community-maintained plugin. There are other integration gaps as well, though the Jujutsu team is actively working toward full Git compatibility, and progress has been rapid.

Final Thoughts

Despite its rough edges, Jujutsu has become my default version control tool. The workflow improvements over Git are substantial enough that the remaining gaps feel like temporary inconveniences rather than fundamental limitations. If you spend any meaningful amount of time in Git, it is worth giving Jujutsu a serious look.

KGDB remains the preferred tool for many developers, largely because widely used debugger scripts and utilities like crashinfo depend on it. However, KGDB is GPL-licensed and therefore not shipped with FreeBSD. To address this, Moritz Systems ported KGDB's core functionality into LLDB several years ago under contract with the FreeBSD Foundation. One important distinction: KGDB is only available on FreeBSD because it depends on FreeBSD's kvm library — a dependency that also enables partial live kernel debugging through /dev/mem. LLDB's FreeBSDKernel plugin, by contrast, supports two backends: kvm and libfbsdvmcore.

The Problem with the Dual-Provider Model

Why does the FreeBSDKernel plugin offer two separate interfaces? The choice between them isn't made at runtime — it's determined at compile time. The root issue is that kvm is only available on FreeBSD. To enable cross-platform support, LLDB needed an alternative, which led to the creation of libfbsdvmcore (commonly referred to as fvc).

This dual-provider approach introduces several problems.

First, fvc is effectively a clone of kvm with FreeBSD-specific code stripped out and cross-platform scaffolding added in. As a result, it inherits kvm's bugs and limitations. Patches applied to kvm on the FreeBSD side need to be backported to fvc — and when they aren't, things break. For example, if a new minidump format version lands in FreeBSD but isn't reflected in fvc, cross-platform users will be unable to process core dumps generated under the new format.

Second, fvc is a third-party library that isn't bundled with LLDB. The original goal of making FreeBSDKernel cross-platform was to allow developers on macOS or Linux to debug FreeBSD core dumps. In practice, however, distribution-supplied LLDB packages don't include libraries like fvc, meaning those developers would need to build LLDB from source — a barrier high enough that virtually no one does it. This has left fvc largely unmaintained and undertested. I recently discovered, for instance, that it was missing minidump version 3 support on arm64. My ongoing work to bring the FreeBSDKernel plugin to feature parity with KGDB is made considerably harder by having to validate against two separate providers.

Solving the Dual-Provider Problem

The solution, originally proposed by the developer of the FreeBSDKernel plugin, is to integrate kvm's functionality directly into LLDB. I agree with this approach: it enables cross-platform debugging without relying on external libraries, and it allows us to retire both the kvm and fvc interfaces in favor of a single, unified backend — significantly reducing the maintenance burden.

The one trade-off is that changes to the internalized implementation will need to be backported to FreeBSD's in-tree LLDB and upstreamed accordingly. In practice, though, this is far more manageable than maintaining two parallel interfaces.

That said, this is a substantial undertaking involving significant research, implementation, and testing. Since I already have ongoing LLDB improvement work in progress, it isn't the immediate priority. My current target is to complete the in-flight work by LLVM 23, with the unified interface aimed for LLVM 24. In the interim, the most practical step is to remove fvc from the FreeBSDKernel plugin and make it kvm-only. A pull request for that change is currently under review.

Other Improvements to FreeBSDKernel

My broader work on the FreeBSDKernel plugin focuses on improving LLDB's overall FreeBSD kernel debugging support. This was originally conceived as a GSoC project idea, but I took it on as a work item during my co-op with the FreeBSD Foundation. The scope includes adding support for additional architectures, implementing commands and features where FreeBSDKernel currently falls short of KGDB, and other enhancements. Progress is being tracked publicly on LLVM's GitHub issue.

ULE, the default scheduler in FreeBSD, was introduced in FreeBSD 5.1 and became the default in FreeBSD 7.1. You might wonder why FreeBSD still ships its predecessor, 4BSD, even now at FreeBSD 15. The reason is that despite ULE being designed as a replacement for 4BSD, there are implementation issues in ULE that cause it to perform worse than 4BSD in certain scenarios. These should, of course, be fixed — and a developer has announced plans to work on this in the near future. In this post, I'll describe what those issues are and outline possible fixes.

Nice is not well-respected

In the ULE scheduler, nice values are not well-respected. The original ULE paper describes the design as follows:

A fixed part of the priority range in FreeBSD is used for time sharing threads. ULE uses the interactivity score to derive the priority. After this the nice value is added to the priority, which may actually lower the priority in the case of negative nice values.

For context, here is how FreeBSD defines its priority bands and how ULE calculates scheduling priority:

/* from sys/sys/priority.h */
/*
 * Priorities range from 0 to 255.  Ranges are as follows:
 *
 * Interrupt threads:		0 - 7
 * Realtime user threads:	8 - 39
 * Top half kernel threads:	40 - 55
 * Time sharing user threads:	56 - 223
 * Idle user threads:		224 - 255
 *
 * ...
 */

/* from sys/kern/sched_ule.c:sched_priority(), simplified */
/*
 * If the score is interactive we place the thread in the realtime
 * queue with a priority that is less than kernel and interrupt
 * priorities.  These threads are not subject to nice restrictions.
 *
 * Scores greater than this are placed on the normal timeshare queue
 * where the priority is partially decided by the most recent cpu
 * utilization and the rest is decided by nice value.
 *
 * The nice value of the process has a linear effect on the calculated
 * score.  Negative nice values make it easier for a thread to be
 * considered interactive.
 */
score = imax(0, sched_interact_score(td) + nice);
if (score < sched_interact) {
    pri = PRI_MIN_INTERACT;
    pri += (PRI_MAX_INTERACT - PRI_MIN_INTERACT + 1) * score /
        sched_interact;
} else {
    const struct td_sched *const ts = td_get_sched(td);
    const u_int run = SCHED_TICK_RUN_SHIFTED(ts);
    const u_int run_unshifted __unused = (run +
        (1 << SCHED_TICK_SHIFT) / 2) >> SCHED_TICK_SHIFT;
    const u_int len = SCHED_TICK_LENGTH(ts);
    const u_int nice_pri_off = SCHED_PRI_NICE(nice);
    const u_int cpu_pri_off = (((SCHED_PRI_CPU_RANGE - 1) *
        run + len / 2) / len + (1 << SCHED_TICK_SHIFT) / 2) >>
        SCHED_TICK_SHIFT;
    pri = PRI_MIN_BATCH + cpu_pri_off + nice_pri_off;
}

In FreeBSD, nice values range from −20 to 20 (41 levels), while the timeshare priority band spans from 56 to 223 (168 levels). The nice value is added to the priority linearly without scaling. This means the impact of nice on scheduling priority is relatively small, and the interactivity score can easily dominate the priority calculation, effectively drowning out the nice value.

One straightforward fix would be to multiply the nice value by 3 or 4 before adding it to the priority. However, linear addition has a deeper problem: the perceptual difference between nice 0 and nice 1 is much greater than the difference between nice 18 and nice 19. A proportional approach using an exponential weight table solves this by expressing nice levels as ratios rather than fixed offsets — for example, each nice level corresponds to roughly a 10% change in CPU share.

Linux already takes this approach. The CFS/EEVDF scheduler maps each nice level to a weight via a precomputed table:

/* from kernel/sched/core.c */
/*
 * Nice levels are multiplicative, with a gentle 10% change for every
 * nice level changed. I.e. when a CPU-bound task goes from nice 0 to
 * nice 1, it will get ~10% less CPU time than another CPU-bound task
 * that remained on nice 0.
 *
 * The "10% effect" is relative and cumulative: from _any_ nice level,
 * if you go up 1 level, it's -10% CPU usage, if you go down 1 level
 * it's +10% CPU usage. (to achieve that we use a multiplier of 1.25.
 * If a task goes up by ~10% and another task goes down by ~10% then
 * the relative distance between them is ~25%.)
 */
const int sched_prio_to_weight[40] = {
 /* -20 */     88761,     71755,     56483,     46273,     36291,
 /* -15 */     29154,     23254,     18705,     14949,     11916,
 /* -10 */      9548,      7620,      6100,      4904,      3906,
 /*  -5 */      3121,      2501,      1991,      1586,      1277,
 /*   0 */      1024,       820,       655,       526,       423,
 /*   5 */       335,       272,       215,       172,       137,
 /*  10 */       110,        87,        70,        56,        45,
 /*  15 */        36,        29,        23,        18,        15,
};

With this kind of weight table, nice values are meaningfully respected at every level, and the effect of each increment feels consistent across the entire range.

Fairness Issue

The ULE scheduler is not completely fair. To illustrate what this means: in Linux's CFS and EEVDF schedulers, total CPU usage is tracked per task via a virtual runtime (vruntime). When a task yields the CPU before its time quantum expires, the unused portion is preserved, and the task receives compensation the next time it is scheduled.

ULE does not do this. When a batch-class task in ULE yields the CPU early, the remainder of its time quantum is simply lost. If the task repeatedly yields early — but not frequently enough to be promoted to the interactive class — it ends up receiving less CPU time than it is entitled to, leading to a form of soft starvation. One approach to fixing this would be to track the lost quantum as a credit and apply it the next time the task is scheduled.

Conclusion

Recently, FreeBSD landed a patch that allows ULE and 4BSD to coexist in the same kernel, enabling users to select a scheduler at boot time without recompiling. Once fixes for the issues described above land, users who have been relying on 4BSD due to ULE's shortcomings will be able to properly evaluate ULE's performance. If ULE can be shown to be superior to 4BSD in all cases, 4BSD can finally be deprecated. To follow progress on this work, subscribe to the freebsd-hackers mailing list.

A note before we begin: this advice won’t apply to everyone. Web developers, for instance, may find some of this less relevant. But I believe most programmers will recognize these principles as foundational.

The Best Way to Learn Is From Good Teachers

This holds true across every discipline—music, mathematics, art, science. The fastest, most reliable path to expertise is learning from someone who’s already mastered the craft. Think of teenage pianists who travel across countries to study with legendary tutors. Programming is no different.

Here’s the problem: computer science is barely a century old, yet it’s become one of the most popular fields in the world. The demand for great teachers far outstrips the supply.

But that doesn’t mean you’re out of luck.

We have something better than a scarce handful of mentors: hundreds of excellent books written by legendary programmers. Yes, many students avoid them—they’re long, dense, and admittedly boring at times. But progress in any field has boring parts. Computer science is no exception. And I promise you, working through these books is infinitely more valuable than churning out throwaway projects at hackathons.

For fundamentals, I recommend Computer Systems: A Programmer’s Perspective and Computer Architecture: A Quantitative Approach. For the C programming language, start with C Programming: A Modern Approach, then move to The C Programming Language and Modern C.

Now, some of you might argue that starting with C is outdated—that Python is a better entry point. That’s a reasonable position, but here’s the truth: you’ll need to learn C eventually. No exceptions. Even if you’re a web developer, understanding what C teaches you will make you more effective—whether that’s tracking down why your app is slow, profiling performance, or occasionally digging into browser internals. Languages like C++, Rust, and Zig exist, but C remains the simplest and most direct way to understand how machines actually work.

After that, learn algorithms. Introduction to Algorithms is the gold standard. Once you’ve read it, you’ll find that understanding new algorithms becomes straightforward—often just a matter of reading a Wikipedia page and some example code. LeetCode has its place, but don’t grind through hard problems for the sake of it. Focus on easy and medium difficulty. Instead of memorizing solutions, learn to recognize patterns. When you face an algorithmic challenge at work or in an interview, you’ll spend less time both planning and implementing.

Open Source Is Your Classroom

Now you need real-world experience. But before you start writing code, study how others have done it.

Remember what I said about learning from good teachers? The open-source world is filled with them. Want to see exemplary object-oriented, modern C++? Study the LLVM project. Curious about how operating systems work? Explore FreeBSD, XNU (macOS's kernel), Linux, and FreeRTOS.

Here’s the catch: not all open-source code is worth studying. Even the Linux kernel has its infamous staging drivers—poorly maintained code that exists in a kind of purgatory for a reason. But as you read more, you’ll develop the ability to distinguish good code from bad. You’ll start to sense when something is off.

This “smell”—the instinct that tells you code was written by a beginner, by an experienced developer new to a codebase, or by AI—is hard to articulate, but unmistakable once you’ve internalized it. After reading a few hundred thousand lines, you’ll know. If you ever want to advance to senior-level work, this skill is non-negotiable.

Whatever your area of interest—databases, web servers, quantitative finance, cryptography, blockchain, AI, GPU programming, video games—find the most respected project in that space. Ninety percent of the time, you’ll be learning from the best. (There are exceptions; GPU kernels written in CUDA, for instance, leaves much to be desired.) If you’re unsure, ask around—forums, communities, and colleagues can point you toward the gold-standard implementation of whatever you’re studying.

Unless you’re working on classified military software, you can find source code for almost anything online—including, as a fun fact, leaked Windows XP kernel code.

Conclusion

So yes, becoming a good programmer involves a lot of reading—books and real-world code. Sounds boring? Welcome to professional-level work in any field.

If you’d rather stick to hobby projects and hackathons, that’s fine—but then why pursue a computer science degree? You can do those things without one. Once you’ve committed to this field, it’s time to do what students in every other serious discipline do: learn from the best examples, written by the best teachers.

The shortcuts aren’t shortcuts. The fundamentals are the path.

Courses

If there’s one takeaway from my 1A term in Computer Engineering, it’s this: the curriculum feels designed without much consideration for whether it’s actually realistic for first-year students.

ECE 105 (Classical Mechanics): Easily the hardest and, for computer engineers, least relevant course of the term. I genuinely love physics, which made this experience all the more disappointing. The teaching approach covers principles in lectures while expecting students to figure out applications independently. Tutorial problems are so difficult they never appear on actual assessments—and it seems like even the instructors aren’t sure what the quizzes and exams should look like. The kicker? ECE 105 covers more material and is harder than PHYS 111 and PHYS 121, which are designed for physics majors.

ECE 150 (Fundamentals of Programming): Learning C++ fundamentals in three months is ambitious, to put it mildly. Unless you’ve already programmed in C++ before arriving, expecting above a 70 is optimistic. I feel for the electrical engineering students—most of them will never use this material again.

ECE 190 (Engineering Profession and Practice): This course isn’t really about ethics; it’s about memorizing slides. The exams are full of gotcha questions that test trivia rather than understanding. You’ll need to remember obscure facts (how many undergraduate engineering programs exist in Canada?) and distinguish between nearly identical terms (in “E-coop,” does the “E” stand for “Enterprise” or “Entrepreneurial”?). It’s more IQ test than ethics course.

ECE 198 (Project Studio): The professor allowed AI usage, which was fortunate because I had no time to do anything else. I essentially vibe-coded my way through with Claude Code—GenAI usage isn’t against Policy 71 for this course, after all. The group project was painful; I had a teammate who was equal parts arrogant and uninformed, which is the worst combination. Also, they scheduled our symposium on a Sunday. That presentation was worth around 30% of our grade. Do student labour protections not apply here?

MATH 115 & MATH 117 (Linear Algebra and Calculus): These were manageable. If you finished high school math with 85+ and stayed awake during lectures, you should be fine. The conventional wisdom that university grades drop 15% from high school doesn’t seem to apply here. Credit where it’s due: the Faculty of Mathematics has excellent professors and TAs.

COMMST 192 (Communication in Engineering): Fun and genuinely useful, but the workload was enormous. I spent most of my after-class time on COMMST 192 assignments, which is why I never finished the problem sets for ECE 105, MATH 115, and MATH 117. For me, this course had more work than everything else combined—though for most people, ECE 150 probably takes that crown. My Grammarly Pro subscription expired after reading week, which made catching errors significantly harder without AI assistance.

The Bottom Line: The schedule and workload are brutal for first-year students. It feels like the institution prioritizes tuition revenue over student well-being. If I were an MPP, I’d propose legislation requiring curriculum coordinators to complete their own programs before implementing them.

Co-op

This was the easiest part of my term, though I know it’s the hardest for most people. I was one of the lucky few who secured a good placement quickly. Many friends—including my roommate—are still searching. I’ve noticed tension building as some students without placements grow envious of those who have them.

The fantasy that everyone will land great co-ops for five years and walk into FAANG after graduation is starting to crumble. I knew this going in—friends with older siblings in CS and CE had warned me—but I applied anyway.

I taught myself most of this material before university and had two successful work experiences under my belt. Academically, 1A taught me almost nothing new. What I did discover was an unexpected passion for theoretical physics and pure mathematics. It’s too late to switch programs, though I don’t regret choosing computer engineering. I’m pragmatic enough to acknowledge that physics and math degrees don’t pay the same way.

Health

Now I understand why engineering and math students have certain reputations at this university.

Yes, the gym is open until midnight. But when you’re drowning in assignments, who has time to go? Before reading week, I’d see engineering students working out regularly. Now? I don’t know anyone in my cohort who still makes it to the gym. We’re all burnt out. Even the walk there feels like too much.

Mental health is worse. Friends from high school keep suggesting I date someone. But making a girlfriend—or even talking to women—isn’t realistic here. Achieving 80+ and finishing everything on time requires isolation. The gender ratio doesn’t help either. I don’t have exact numbers (and collecting them would be awkward), but it feels like somewhere between 10:1 and 15:1. We joke that finding a girl in our cohort is harder than finding a unicorn.

When you’re one week from finals, fighting a cold because the university didn’t call a snow day during an actual snowstorm, and you got sick trudging between classes—the combination of physical and mental strain is indescribable.

Food

The best thing about my first 18 years of life was that my mom is the best chef in the world. Food here tastes like sewage and costs a fortune. It’s borderline fraudulent.

I’m fortunate to be in a residence with the best dining hall on campus, but it doesn’t come close to what I ate at home in Ottawa. I’ve also learned that nutritional balance matters more than I thought. I got sick at least once a month because I refused to eat vegetables. The vegetables here don’t help—they’re not the fresh greens I had back home; they taste like they survived some kind of biohazard incident.

I don’t know why I was so stubborn about vegetables in Ottawa. I swear I’ll eat them happily when I go back after finals.

Conclusion

I wish I could have skipped first year entirely. There’s nothing here that matches what I expected back in June. A physics or mathematics degree might have been more intellectually fulfilling, but it would have left me broke after graduation. The current economy leaves little room for idealism.

On the bright side, I’ve discovered a genuine interest in physics and am now pursuing a joint honours. Hopefully this will make my tuition feel less wasted while I continue learning almost nothing new in my core engineering courses.

Resources

If you’re navigating Waterloo, I highly recommend Xierumeng’s “Guide to UW” blog series. It offers detailed guidance for each academic term, co-op terms, and other essential skills for succeeding here.

The Rush to Nowhere

University physics lectures move at breakneck speed. When students struggle with new concepts, they’re left with limited options: figure it out independently or seek help from teaching assistants who aren’t always available. The situation becomes particularly challenging for students arriving from educational systems where these foundational concepts weren’t covered—they find themselves simultaneously learning new material while racing against exam deadlines.

The Memorization Trap

Here’s what makes physics fundamentally different from most university courses: while chemistry, biology, and even engineering mathematics lean heavily on memorization, physics demands something else entirely. Every physics instructor I’ve encountered shares the same philosophy: “The only equation you need to remember is F=ma.”

Of course, this isn’t literally true—students must know formulas for energy, momentum, and wave mechanics to complete exams within time limits. But the underlying message is clear: physics should be about understanding systems, not memorizing solutions.

Consider elastic collisions between two objects. Most students instinctively memorize the velocity exchange formulas, while professors consistently discourage this approach, advocating instead for case-by-case analysis. This disconnect reveals a fundamental tension in how physics is taught versus how it’s tested.

Why Students Choose Shortcuts

The reality is stark: exams reward speed over understanding. When you have 50 minutes to solve five complex problems, methodical analysis becomes a luxury you can’t afford. Students who memorize formulas gain a clear advantage—not because they understand physics better, but because they can navigate the exam more efficiently.

This creates a perverse incentive structure. Physics problem-solving through genuine analysis becomes an IQ test under time pressure. Some students excel at rapid analytical thinking, but many others—who could solve these problems given adequate time—find themselves forced to choose between understanding and grades.

A Better Way Forward

The solution isn’t complicated, but it requires reimagining how we assess physics knowledge. Instead of rewarding formula application, we should structure evaluations to emphasize systematic thinking. Imagine a marking scheme that allocates points like this:

• 30% for system identification: Recognizing the relevant objects and forces

• 20% for visual representation: Creating accurate free-body diagrams and illustrations

• 30% for conceptual explanation: Articulating in words why and how the system behaves

• 20% for mathematical execution: Applying formulas to reach the numerical answer

This approach would make shortcuts through memorization insufficient. Students couldn’t achieve full marks simply by plugging numbers into equations—they’d need to demonstrate genuine understanding of the physical principles at play.

Crucially, such changes must be paired with realistic time allocations. There’s no value in testing analytical thinking if students must still race against the clock.

The Uncomfortable Truth

Despite these clear improvements, I’m skeptical we’ll see meaningful change. While I personally enjoy studying physics in my spare time, I recognize that most students have different interests and priorities. Without widespread demand for reform, professors have little incentive to restructure their courses.

The result? Physics remains trapped in its current form—simultaneously the most challenging and least engaging course of the term for many students. We’ve transformed a subject that should inspire curiosity about the natural world into a high-stakes memorization contest.

Until we’re willing to sacrifice some breadth of coverage for depth of understanding, and until we design assessments that reward thinking over speed, university physics will continue to feel less like an exploration of the universe’s fundamental principles and more like an academic obstacle course.

The Hackathon Gold Rush

Ontario’s hackathon circuit—Hack the North, Hack the Valley, DeltaHacks—follows a familiar formula: teams sprint through 24-36 hours of coding, judges crown winners, and everyone goes home exhausted. These events were designed to reward brilliant ideas and creative problem-solving. That original vision, however, has been casualties of a much larger shift in the tech landscape.

The post-pandemic job market fundamentally altered how students approach their careers. With supply dramatically outpacing demand in software engineering, stories of graduates struggling for years to find work have shattered the once-reliable narrative that a computer science degree guaranteed a pathway to Big Tech. Students who once believed GPA alone would open doors now scramble for any edge they can find.

Enter the modern hackathon: a perceived shortcut to distinction. Unlike GPA, where theoretically everyone can excel, hackathons produce a limited number of winners. Victory promises not just a line on a resume, but face time with senior developers and hiring managers from sponsoring companies. In this new reality, the original purpose—fostering innovation—has become secondary to career advancement.

When Competition Corrupts Innovation

The pressure to win has transformed hackathons into something unrecognizable. While rule-bending has always existed—teams uploading pre-written code to GitHub was once the height of cheating—the rise of LLM coding agents has fundamentally broken the playing field.

Today’s hackathon landscape rewards resources over creativity. Teams with premium AI subscriptions, multiple specialized tools, and access to various LLM models hold decisive advantages. When participants can generate entire project architectures and implementations without understanding the underlying code, we’re no longer measuring innovation or skill—we’re measuring who can afford the best digital assistants.

This pay-to-win dynamic violates the fundamental philosophy of hackathons. Instead of identifying the brightest ideas and most talented developers, we’re selecting for those with the deepest pockets and the most sophisticated AI toolchains.

The Hidden Cost: Technical Debt as Education

Perhaps most concerning is what hackathon culture teaches about software development. The sprint mentality—ship something, anything, in 36 hours—produces code that would horrify any professional developer. No version control, incomprehensible commit messages, zero documentation, and architectural decisions that would make maintenance impossible. These aren’t just bad habits; they’re anti-patterns that actively harm students’ development as engineers.

I regularly review code from serial hackathon participants, and the patterns are depressingly consistent: branches merged instead of rebased, creating labyrinthine Git histories; commit messages that explain nothing; code generated by AI that neither the author nor reviewer truly understands. One memorable submission included hundreds of lines of refactoring with a single-line commit message.

This is the opposite of what industry needs. While hackathon veterans chase the next win, they’re failing to develop the fundamental skills that matter: writing maintainable code, thinking about long-term architecture, collaborating effectively through proper version control, and—critically—understanding what they’re building.

The Wrong Lesson at the Wrong Time

Computer science students should be learning to write good code, not just fast code. They need a learner’s mindset, not an entrepreneur’s hustle. Yet hackathon culture teaches them to prioritize velocity over quality, prizes over understanding, and shortcuts over craftsmanship.

The irony is stark. While students optimize for ephemeral 36-hour sprints, the industry still runs on COBOL systems in financial institutions that have operated reliably for decades. We’re creating a generation of developers who can spin up a flashy demo but can’t maintain a production system, who can prompt an AI but can’t debug its output, who can win competitions but can’t collaborate on real codebases.

A Call for Better

Hackathons could be valuable learning experiences. They could teach collaboration, innovation, and yes, even how to work under pressure. But the current model—driven by job market anxiety and enabled by AI shortcuts—is producing the opposite of what our industry needs.

We’re teaching students to play a lottery rather than develop skills, to generate code rather than understand it, to win at any cost rather than build something lasting. If we continue down this path, we risk creating a generation of developers who view software as something to be generated quickly and discarded, rather than crafted carefully and maintained.

The “move fast and break things” mentality has its place in certain contexts. But when it becomes the primary educational model for our future developers, we’re not just breaking things—we’re breaking the very foundation of software craftsmanship that our industry depends on.

It’s time to reconsider what we’re really teaching when we celebrate the hackathon winner who cobbled together an AI-generated project they don’t understand over the student who spent the same weekend learning to properly use Git, understanding design patterns, or contributing to an open-source project. Because in the long run, I know which one I’d rather have on my team.

The Golden Era

“Microsoft’s favorite recruiting grounds were Harvard, Yale, Massachusetts Institute of Technology, Carnegie Mellon, and a little college near Toronto named the University of Waterloo.” — Hard Drive: Bill Gates and the Making of the Microsoft Empire

For decades, the University of Waterloo has occupied a unique position in North American tech education. While Canada boasts several excellent institutions—Toronto, UBC, McGill among them—Waterloo carved out something different: a co-op program so robust that it became the envy of engineering schools continent-wide.

The formula was simple and brilliant. Students would alternate between academic terms and work placements, graduating with two years of real-world experience. In the golden age of tech expansion through the mid-2010s, this wasn’t just an advantage—it was a golden ticket. The mythology around Waterloo computer science, software engineering, and computer engineering graduates landing FAANG positions wasn’t entirely exaggerated. Software jobs were abundant, companies were in perpetual hiring mode, and Waterloo students arrived battle-tested from their co-op experiences.

When Supply Meets Reality

But mythology has a way of creating its own demise.

As Waterloo’s reputation soared, two forces began reshaping the landscape. First, admissions became brutally competitive as students nationwide—and internationally—competed for spots in these “guaranteed success” programs. Second, and more critically, the tech job market underwent a seismic shift, particularly post-pandemic. The industry that once seemed to have infinite appetite for developers suddenly discovered limits.

Here’s the Economics 101 problem no one wanted to acknowledge: When supply surges while demand contracts, value plummets.

Today’s WaterlooWorks platform tells a sobering story. Software engineering positions that once attracted applications solely from computing students now see desperate bids from chemical and biomedical engineers, driven by scarcity in their own fields. The platform simply doesn’t have enough quality positions for its core computer science and engineering cohorts, let alone the overflow from other programs.

The Quality Crisis

But numbers tell only half the story. The more insidious problem is the deterioration in job quality itself.

Modern WaterlooWorks has become a hunting ground for startups operating on questionable foundations. Companies post positions before securing funding. “Teams” consist of two full-time employees supervising ten co-op students—a ratio that screams exploitation rather than education. The crunch culture that Silicon Valley is slowly abandoning has found new life in companies that view co-ops as disposable labor rather than future talent.

Consider this: One New York startup systematically fired half its co-op cohort for “financial reasons,” only to hire the exact same number the following term. The message was clear—conform to our crushing work culture or be replaced.

Most troubling is the persistent complaint, documented across decades of online forums, that the university itself prioritizes corporate relationships over student welfare. The institution meant to protect and educate has become, in many students’ eyes, complicit in their exploitation.

A Path Forward

The solutions aren’t complex—they require institutional courage.

First, implement supply-side discipline. If only 1,000 of 2,000 students secure meaningful co-ops (excluding programs like WE Accelerate), next year’s admission should reflect that reality. Yes, this intensifies admission competition, but it creates a more sustainable ecosystem where admitted students can focus on learning rather than surviving a hunger games-style job hunt.

Second, establish real oversight. The co-op office must evolve from placement facilitator to quality guardian. This means verifying companies’ financial stability, examining their employee composition, and ensuring they offer genuine learning environments. Startups using co-ops as venture-subsidized labor should find no place on WaterlooWorks.

The Waterloo Moment

The University of Waterloo’s co-op program revolutionized Canadian technical education and served as a model for universities nationwide. But models built for one era don’t automatically translate to another.

The question isn’t whether Waterloo can maintain its historical dominance—that ship has likely sailed. The question is whether it can evolve to protect what made it special in the first place: giving talented students real experience in supportive environments that foster both learning and career development.

The current system burns out students before they graduate, exploits their labor while they’re learning, and leaves many questioning whether the “Waterloo advantage” still exists. Without substantive reform, the institution risks becoming a cautionary tale about what happens when reputation outlives reality.

The co-op program doesn’t need to be perfect. But it does need to remember its purpose: education, not exploitation. The students flooding into Waterloo’s programs deserve the opportunity their predecessors enjoyed—to learn, grow, and launch careers, not merely survive.

That’s the promise worth fighting for.

How It All Started

My programming journey began when I was twelve, captivated by the portrayal of hackers in popular media. My first programming book (화이트 해커를 위한 암호와 해킹 (1st Edition) by 장삼용)—a Korean text on cryptography and network security in Python—was far beyond my comprehension at the time. While I can parse it effortlessly now, back then I grasped maybe 60% of the concepts, if I’m being generous.

Some of my earliest engineering experiences still baffle me today. At age ten, I successfully upgraded the network card in my mother’s aging laptop—a feat I still can’t quite explain. The machine shipped with Windows 7, but I was desperate to experience Windows 10’s sleek, modern interface. After multiple failed upgrade attempts, I dove into online forums, searching for others with similar symptoms.

I stumbled upon a blog post describing my exact issue with a nearly identical laptop model. The solution? A network card upgrade—Windows 10 apparently lacked drivers for the older hardware. Armed with nothing but this single blog post and unwavering determination, I ordered the recommended card, completely disassembled the laptop, swapped the hardware, and reassembled everything. The upgrade to Windows 10 went through without a hitch.

Looking back, I’m amazed that my mother trusted her ten-year-old with such a task. That trust would soon be tested.

The Incident That Changed Everything

My next experiment—attempting to dual-boot Ubuntu—ended in disaster. I accidentally formatted the entire drive, obliterating years of irreplaceable family photos and documents. Despite spending hundreds of dollars on professional data recovery, we salvaged only fragments.

This catastrophe convinced my parents that perhaps I needed my own machine for these experiments. When I was twelve, my mother made a unilateral decision to purchase me a $6,000 iMac—a purchase she hadn’t cleared with my father, who was our family’s sole income earner. The tension was palpable, but the deed was done, and my mother’s unofficial veto power prevailed.

I’d justified the iMac request by claiming macOS’s gaming limitations would keep me focused on programming. Naturally, I immediately installed Windows via Bootcamp and played games. But I also kept my promise—I discovered FreeBSD and became obsessed with contributing to its base system.

The Challenge of Finding Direction

Unlike web development, with its abundance of detailed roadmaps and tutorials, kernel development resources are scarce and scattered. This knowledge is typically reserved for third-year university courses, leaving self-taught programmers to piece together their own curriculum.

After years of trial and error, I’ve assembled the roadmap I wish I’d had when starting. While there may be more efficient paths, this one worked for me.

Roadmap to Kernel Developer

This is subjective path that I found and followed. There could be better roadmaps that are more efficient and in higher quality. I only listed books below because I believe that books are the most efficient, high quality, and accurate resources for programming. If you want to be a kernel developer, you’ll need to read a lot of standard documents, papers, and man pages. Learning through books can help you prepare for those situations.

1. Master the C Language

C is non-negotiable for kernel development. You need to read C code as naturally as you read English. The language itself is deceptively small, but its evolution means you’ll need multiple perspectives:

Start here:

• C Programming: A Modern Approach (2nd Edition) by K. N. King — An excellent introduction, though it doesn’t cover the latest standards

Then understand the philosophy:

• The C Programming Language (2nd Edition) by Kernighan & Ritchie — Not for beginners, but essential for understanding C’s design philosophy and machine-oriented thinking

Finally, modernize your approach:

• Modern C (3rd Edition) by Jens Gustedt — Learn how C is written today, which differs significantly from traditional approaches

2. Algorithms and Data Structures

Programming languages are merely tools—algorithms and data structures are what make programs actually do something meaningful.

Essential reading:

• Guide to Competitive Programming (3rd Edition) by Antti Laaksonen — A solid introduction to fundamental concepts

• Competitive Programming 4 by Halim, Halim & Effendy — Advanced material for serious practitioners

For Korean readers: 알고리즘 문제 해결 전략 by 구종만 remains my favorite comprehensive introduction to the field.

3. Computer Architecture

Understanding the machine beneath the code is crucial for kernel developers. You need to know how software and hardware dance together.

The heavyweight champion:

• Computer Systems: A Programmer’s Perspective (3rd Edition) by Bryant & O’Hallaron — Dense, comprehensive, and absolutely essential. This textbook assumes self-directed learning, so prepare for extensive research and problem-solving.

Alternative perspective:

• Computer Architecture: A Quantitative Approach (7th Edition) by Patterson & Hennessy — Highly recommended by the community

4. Operating Systems

After 1-2 years of foundation building, you’re ready for the main event.

Modern and accessible:

• Operating Systems: Three Easy Pieces by the Arpaci-Dusseaus — More current and approachable than traditional texts, available free online (though I recommend print for your eyes)

For Linux enthusiasts:

• 디버깅을 통해 배우는 리눅스 커널의 구조와 원리 by 김동현 — Hands-on kernel hacking (Korean only, unfortunately)

For FreeBSD developers:

• The Design and Implementation of the FreeBSD Operating System (2nd Edition) by Neville-Neil & McKusick — Comprehensive but theoretical; essential for FreeBSD contributors

The Reality Check

This roadmap represents a minimum three-year commitment. Unlike web development’s relatively quick onramp, kernel development demands deep understanding of both software and hardware layers. And this is just the beginning—kernel developers never stop learning, constantly adapting to new architectures, technologies, and paradigms.

I’ve completed most of this curriculum and still consider myself a novice. If you’re serious about kernel development, you need two things above all: genuine passion for systems programming and the humility to embrace lifelong learning.

The path is long, the learning curve is steep, but for those who persist, you’ll gain the ability to work at the very foundation of modern computing. Is it worth it? For me, absolutely.

The University of Waterloo’s co-op program is both its greatest strength and its students’ most daunting challenge. As a Stream 4 Computer Engineering student, I barely had time to settle into my 1A term before the job hunt began. September rolled around, and suddenly everyone was polishing résumés and practicing for interviews. The university requires five co-op credits to graduate—a requirement that feels overwhelming when companies barely glance at first-year applications.

My WaterlooWorks experience was typical: three interview offers, all for web development roles. A California startup reached out directly through my résumé, only to ghost me after I replied. The other two—a company in Oakville and a startup in North York—interviewed me, but my heart wasn’t in it. I’d done enough web development to know it wasn’t my calling.

it wasn’t my calling.

That’s when I remembered where I truly belonged: the world of operating systems.

A Five-Year Journey to My First Co-op

My journey with kernels and CPU architectures began long before university. At thirteen, I submitted my first patch to the FreeBSD Project. That first commit on May 5th, 2021, marked the beginning of a consistent contribution habit that carried me through high school. I spent my free time diving into man pages, updating C17 implementations in the base system, and helping import jemalloc 5.3.0—unconventional hobbies for a teenager, but they were what fascinated me.

I never expected rewards—seeing my name in git logs was reward enough. But those five years of contributions (always balanced with schoolwork as my priority) became my unconventional path to my dream co-op.

Operating systems are typically third-year material at university. Most students don’t touch kernel code until they’ve built a solid foundation in computer science fundamentals. Yet here I was, a first-year student with half a decade of practical experience in the field. After realizing this unique position, I reached out to a developer at the FreeBSD Foundation—someone I’d met during my two BSDCan attendances, sponsored by the foundation.

Against all odds, they offered me my first co-op position.

An Ambitious Roadmap

My plans for these four months at the FreeBSD Foundation are ambitious, perhaps overly so. The review process is strict, and time is limited, but I’m determined to contribute as much as possible:

• Infrastructure modernization: Migrating our code forge to Forgejo

• Documentation enhancement: Creating comprehensive kernel documentation (Doxygen + Sphinx + Breathe + Exhale) inspired by the Linux Kernel documentation

• Performance optimization: Adopting AVX/AVX2/AVX10 SIMD instructions in libc based on simd(7)

• Standards compliance: Implementing C23 and Single Unix Specification requirements

• Compatibility improvements: Matching Linuxulator and Linux KPI functionalities to the latest kernel

• Scheduler optimization: Enhancing sched_ule(4) for hybrid processors (Intel P/E-core, ARM big.LITTLE)

• Continuous bug fixes: Contributing to overall system stability

This first co-op is about mastering operating system fundamentals. Looking ahead, I’m already mapping out my trajectory: exploring CHERI and RISC-V ports for my second and third terms, with companies like Capabilities Limited and Codasip on my radar. Eventually, I want to delve into processor design with HDL and compiler development.

Swimming Against the Current

While my peers chase positions in web development or applied AI—fields increasingly dominated by LLM coding assistants—I’m deliberately choosing a different path. Too many startups treat co-op students as cheap labor, burning them out with repetitive tasks that teach little of value. Big tech companies, despite their prestige, often mean following a manager’s roadmap rather than exploring the technology that fascinates you.

I’m not chasing the highest salary or the most recognizable company name. I’m chasing knowledge in the field that has captivated me since I was thirteen. The FreeBSD Foundation saw something in me—perhaps the same passion for operating systems and CPU architectures that has driven me all these years.

The Value of Hard-Won Experience

Waterloo’s six co-op terms might seem grueling to some, but I see them differently: 24 months of deep, hands-on experience in a field that typically requires years of study to enter. While balancing operating systems work with undergraduate studies is challenging, these co-op terms offer something invaluable—the opportunity to learn by doing, to contribute to systems that power the internet’s infrastructure, and to work alongside developers who’ve shaped the technology we rely on daily.

The FreeBSD Foundation took a chance on a first-year student with an unconventional background. Now it’s my turn to prove that passion, combined with years of consistent contribution, can be just as valuable as a traditional academic path.

Memory safety bugs cause 70% of cyber vulnerabilities, leading to disasters like OpenSSL Heartbleed and the 2024 CrowdStrike outage ($5.4 billion in losses). The CHERI technology, developed over 15 years by Cambridge University and SRI International, prevents these attacks through hardware-enforced memory protection rather than endless software patches.

The momentum is extraordinary. The UK government invested £80 million alongside £200 million from industry, with backing from DSIT, NCSC/GCHQ, DSTL, and DARPA. Industry giants Google, Microsoft, and Arm have joined alongside BT Group and Siemens, recognizing that hardware-level security is no longer optional.

I’m particularly excited about our working groups porting critical operating systems to CHERI. FreeBSD, FreeRTOS, Zephyr, and seL4 have all been ported to run on CHERI hardware, with teams actively developing and maintaining these implementations. This ecosystem work ensures CHERI can protect everything from embedded IoT devices to enterprise servers, making memory safety accessible across the entire computing stack.

Microsoft found CHERI would have prevented two-thirds of their 2019 vulnerabilities. The technology is practical too – existing software often needs less than 0.03% code changes to become memory-safe. As we deploy AI and connect critical infrastructure, we can’t afford to keep patching symptoms. CHERI addresses the root cause.

While I originally launched this Substack to chronicle computer architecture and university life, my passion for operating systems has taken the wheel. Going forward, you’ll find articles, updates, and announcements covering operating systems and CPU architectures—particularly FreeBSD, Linux, CHERI, and RISC-V.

If your company takes cybersecurity seriously, consider joining the CHERI Alliance. We’re building secure-by-design systems and welcome everyone who shares this vision. It’s time to stop playing defense against memory vulnerabilities and solve the problem at its root.

I've been in web development since the end of 2023, for almost two years now. My first project was a summaive project for my Grade 11 English class written in Next.js. After that, I built websites for my school band and city jazz band, again, written in Next.js. At first, it was fun, with all those Tailwind CSS and state management. Unlike other programming areas, I could see the results of my work immediately just by running next dev in my terminal. Compared to SwiftUI, web development felt more easier but more fun, especially with npm libraries that faciltate the development process.

Then, I found Vite and SvelteKit. I was amazed by the compiler approach (which Vue and React now have experimental support for) and the performance of Svelte. SvelteKit was similar to Next.js, so it was pretty easy to learn the fundamentals. I migrated all my three websites to SvelteKit, and it was a breeze. However, I encountered my first challenge in web development — dependencies. In my Next.js projects, I heavily used Motion (it was called Framer Motion back then). It was a great library, as I could apply fancy animations in a few lines of code. But it was binded to React, so when I migrated to SvelteKit, I had to implement the same animations in a different way. I spent almost a week trying to implement the same animations in Svelte, and that was the first time I was disappointed by the web development ecosystem.

First Big Project in My Life

Around the end of 2024, I joined Poliwave, a platform that provides Canadian election projection. I was the only developer with previous experience in the team, and I was responsible for the frontend and backend. I was excited to work on a project that was actually useful, and I was excited to work with a team that was actually professional.

However, it was too difficult to maintain such a large project by myself. I was the only developer, and I was responsible for both the frontend and backend. I was overwhelmed by the amount of work, and since my colleague who maintained the actual electoral projection also wrote the code for the web app, it was really hard to maintain the codebase in a good state. Sometimes the code was deployed even though it failed checks on GitHub Actions, and when I tried to fix the issues, it was too late to fix them without reverting the changes to the initial state.

At last, it reached the state where the website was lagging and it had glitches everywhere, but I was unable to debug and fix the core issues due to the low quality of the codebase. We added patches on the codebase to mitigate the issues, but since the code was already in a bad state, another glitch appeared after the patch was applied.

We also had to migrate between different UI libraries, and everytime we did, it broke the existing codeflow. Since it was really hard to create our own design system in a team of two, we had to use a third party library, and it was painful to find the right components to use. Even though we made a decision on which library to use, our mind changed in a few days, and we had to migrate to a different library again.

I felt too tired of spending so much time and energy on visual side of the project. Unlike other fields of programming, frontend development is mostly about designing and implementing the UI, not the core logic of the project. Instead of building a complete project, I was just destroying and rebuilding the project over and over again without any progress.

For these reasons, I lost interest in most part of web development. Except for reading release notes of SvelteKit, Vite, and Bun, I switched to other fields of programming such as operating systems, embedded systems, AI, and blockchain.

Got a Job

In July 2025, I got a summer student job at CHEO RI, a research institute in Ottawa. I love the work I do there and my colleagues are great, but while I was working on the project, I made my decision to leave web development after this job is over in August.

My team spent first three days on determining the tech stack, which was changed again on the next week. I felt very unproductive and saw myself as a website designer, not a programmer. As a side project, I built a RAG-based chatbot platform with my friend. Because we focused more on the programming aspect rather than the design aspect, it was way more fun than any of my web projects.

I also studied blockchain and AI, and I was amazed by the potential of these technologies. I also had an opportunity to revisit the computer architecture and low-level programming, and although they were more difficult than web development, they didn't cause me as much frustration as web development did. I felt that I was being a computer engineer, not a designer, and that was the time that I decided to leave the world of web development.

Issues with Web Development Ecosystem

The Ecosystem is Too Fragmented

Let me list some technologies you can use to build a web project:

• Runtime: Node.js, Bun, Deno, etc.

• Framework: Next.js, SvelteKit, Nuxt.js, Astro,etc.

• Library: React, Vue, Svelte, etc.

• UI Library: Tailwind CSS, Shadcn UI, etc.

• Package Manager: npm, yarn, pnpm, bun, etc.

• Build Tool: Vite, Webpack, rsbuild, Turbopack, etc.

• Testing Framework: Jest, Vitest, Playwright, etc.

• Linting & Formatting: ESLint, Prettier, etc.

• Typing: TypeScript, JSDoc, etc.

• Database: Supabase, PostgreSQL, etc.

• Hosting: Vercel, Netlify, etc.

• CI/CD: GitHub Actions, GitLab CI, etc.

• Monitoring: Sentry, etc.

• Analytics: Google Analytics, etc.

• and so on...

There are so many options to choose from, and there is new technology coming out every day. In 2025, people complain about the best LLM model being updated every month, but compared to web technologies in 2022-2024, it's not even a big deal. It's really hard to keep up with the latest trends and technologies, and it's hard to find innovation in the web development ecosystem. The last time I remember innovation in the web development ecosystem was when Svelte introduced the compiler approach and when node-rs made using Rust in web development possible. Apart from that, most hyping techonologies that appearaed in that era is not even mentioned anymore (Who remembers Remix, MongoDB, Gatbsy, etc?).

Unsafe Nature of Javascript

No, I'm not talking about memory safety like C/C++. I'm talking about the type safety of Javascript. Although Typescript and JSDoc are great, they are not the core specification of Javascript. I used Typescript in my projects, but my colleague didn't follow the type safety rules, and even deployed the code while the CI check was failing. If this was a C/C++ project, the binary would have been built at the first place, even though they might contain memory safety issues.

Ecosystem that Has Both Legacy and Modern Technologies

In Javascript ecosystem, we see a lot of legacy syntax and technologes and their modenr counterparts. Callback vs async, Webpack vs Vite, CommonJS vs ESM, etc. Some times we need to use Javascript transpilers to run code on old browsers due to lack of something like ABI compatibility. Although this is not a big issue for building a new project, it's quite problematic when you're maintaining a legacy project. Imagine that you are working on two projects, one is relatively new using Vite and ES6 code while the other is legacy project using Webpack and deprecated Vue v2. Yes, it would be very painful to maintain those two at the same time.

You might say that this is the same problem in other fields of programming. But in web development, this happens too frequently. C++98 was used for 16 years until the release of C++11. Although there have been new features in C++20, it was not a major overhaul with breaking changes like CommonJS to ESM or Vue v2 to Vue v3. Note that while using C++11 is not legacy in 2025, Webpack, which people replaced with Vite, was released in 2012.

What's Next?

As I'm going to the University of Waterloo for computer engineering, I will focus on embedded programming and circuit design. I will also study AI and blockchain, although I'm not sure if I will be able to use them in my future career.

Although I will still follow the release notes of SvelteKit, Vite, and Bun, I will completely keep distance from the web development ecosystem. The only reason I'm still following the release notes is because I believe that those three are the only innovative projects left in the web development ecosystem. Others seem to repeating same ideas over and over again, which I'm not interested in.

Edit for September 20th, 2025: For the last two months, I’ve tried many things: infrastructure, database, AI, etc. At the end, I chose operating systems and compilers for my future careers. Even though I’ve been learning those for more than three years now, they are the most interesting and fascinating topics to me.

“If you don't have time to read, you don't have the time (or the tools) to write. Simple as that.”
- Stephen King

My entire life, I was indifferent towards literature, including reading and writing. English has always been my worst course, and I have consistently achieved a high mark (95+) in mathematics and science. Because I have always dreamt of being a computer engineer, I firmly believed that English literature would never be important to me forever. So, instead of digging into homework and assignments from my English class, I focused on maintaining the bare minimum for university entrance. I thought this was a perfect plan then, as I could save more time for programming or preparing for physics tests, and I had made a good decision that I would never regret.

But was it really?

It turned out that there are some reasons that I need to start studying literature again. For academic and practical reasons, my life as a student didn’t quite work out without using moderate and accurate language that can also charm other people. In this article, I would like to explain why studying English literature is important both as a student and a human being and how I will change myself in this area.

Academic improvement in other courses

As a secondary school student who wants to enter a computer science program at a good university, mathematics is the most essential skill in Grades 11 and 12. Why? Because many mandatory and prerequisite courses at universities require them.

In Ontario, courses ending in 3M or 4M are university prerequisites, such as Physics 12 (SPH4U) and Chemistry 12 (SCH4U). Students use mathematics in most courses, including science, pure mathematics, and accounting. Making a math mistake or not knowing a mathematical concept altogether leads to losing marks in these courses. Mathematics can also help us build scientific thinking, which is why most secondary school students study Grade 11 and 12 mathematics before they learn it from school; it is a handy tool not only in our school days but throughout our whole lives.

But things are a bit different for the English language. While we use mathematics in those courses, English is necessary anytime at school. Writing skills heavily influence producing a mathematical or scientific hypothesis, writing a lab report for marks, and writing an essay as an English assignment. Better use of logic and language can lead to a better mark.

Yet, reading and writing is also crucial in our lives

Don’t think we should study literature only because it can improve our marks. Being a proficient reader and writing in English can make you a better person with more opportunities.

As of writing this article, it is mid-February, meaning I just finished writing essays for university admission and scholarship applications. While I was writing for several prompts, I deeply regretted that I didn’t make any effort to improve my writing skills. The outcome could have been different; not just writing a more attractive essay, but I could’ve saved more time and submitted it without being bothered by the pressure of a deadline.

Also, writing with good logic and wording can help you get a job and persuade others. Many misunderstandings come from making a bad word choice or talking or writing before making a deep thought, which we should avoid for good as much as possible.

In my adulthood, which is decades left, writing proficiently in English will give me more opportunities with promising success, maintaining better relationships with others, and more.

So how is improving English skills related to learning literature?

Wikipedia describes literature as follows:

Literature is any collection of written work, but it is also used more narrowly for writings specifically considered to be an art form, especially novels, plays, and poems.

So why do I believe reading and studying literature can improve my English skills?

First of all, it is fun. Let’s imagine a situation where we learn reading and writing like mathematics. Like memorizing formulas, we need to memorize all the different techniques used in writing and be skilled in them. In my opinion, this is the most terrible way of learning any language, and people should not learn a language in such a circumstance.

Instead of memorizing the old-school way, reading books and naturally acquiring the ability to write a good essay is a more natural approach. As babies learn their mother tongue language from listening to conversations, not from dictionaries, exposing ourselves to a collection of carefully chosen works is a better approach to improving our writing skills.

Furthermore, learning from a collection of renowned works can only benefit and never harm us. Experts recommend literary work for good reasons, regardless of whether that is the word choice, topic, or logic. From every aspect of those works, there are always things to learn that will help and inspire us when we do our writing. Word choice we see in Great Gatsby or the message conveyed through To Kill a Mockingbird gives us opportunities to reflect on ourselves and our writing skills. When these lessons accumulate enough, we can write like those authors.

What I’m planning to do and what this blog will be

This post is my first time writing online; I hardly ever express my thoughts through posts or comments.

Yet, writing a blog can help me improve my writing skills. Even though a few people might read my posts, I'm committed to this writing activity. I will focus on it as much as possible.

I have a lot of time for the rest of the semester, and after next week's programming competition, I might be a full-time writer when I'm free.

I'll cover various topics, such as economics, politics, personal experience, and book reviews. Programming articles will be posted on my website. Right now, I have a draft with a bunch of ideas, and I can't wait to finish it.

As my first post, I somehow wrote this article poorly in some aspects. Still, because I achieved my goal as a first personal writer, I'm stopping writing here. I will write another post pretty soon—if I ever write again.