It doesn't need to be a kernel you write, I believe that if you write any sufficiently complex piece of software from scratch with the intent of making it scalable and extensible, you will come out on the other side with a much better idea of design patterns and clean code architecture. While I have not built a kernel, my baby is a static site generator, Orchid, and a complex game can also be a great example.
Projects with a clear focus that is comprised of many disparate pieces are the best, as you have to find ways to manage each system independently while also having them play nicely together as an entire system. A kernel runs processes, but that requires filesystems, networking, and memory management, which are all very different. Orchid builds large static websites, but requires knowledge of parsers, filesystem abstraction, and I even implemented a simple HTTP server for an admin panel. A game has a pretty clear goal of playing the game, but involves a rendering/graphics engine, a game logic engine, data storage and state management, maybe even AI.
To do this, you'll have to give yourself strict constraints and promise to stick by them, which is much easier said than done. You have to go slow and constantly refactor, and find that single code path which everything else is attached to. If you don't explicitly find this path, then you run the risk of doing too much with too little governance, which is where code rot starts to creep in. In strongly-typed languages like Java, you can have the compiler enforce this with package boundaries and multi-module Gradle projects. In other languages, you'll have to be the one enforcing these rules of which methods are allows to be called, which fields are allowed to be changed, etc.
In building Orchid, I actually kind-of "rediscovered" several GoF design patterns, just because I got backed into a corner and needed to really think about how to find my way out. And when you start working on a way to get out of the corner, actually take the time to go and apply that same solution to other areas in the app, and see if it stands the test of scaleability. If it doesn't, refactor and find a better way. If it does, you've now got a new tool in your toolbelt to help you solve even harder problems.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
It doesn't need to be a kernel you write, I believe that if you write any sufficiently complex piece of software from scratch with the intent of making it scalable and extensible, you will come out on the other side with a much better idea of design patterns and clean code architecture. While I have not built a kernel, my baby is a static site generator, Orchid, and a complex game can also be a great example.
Projects with a clear focus that is comprised of many disparate pieces are the best, as you have to find ways to manage each system independently while also having them play nicely together as an entire system. A kernel runs processes, but that requires filesystems, networking, and memory management, which are all very different. Orchid builds large static websites, but requires knowledge of parsers, filesystem abstraction, and I even implemented a simple HTTP server for an admin panel. A game has a pretty clear goal of playing the game, but involves a rendering/graphics engine, a game logic engine, data storage and state management, maybe even AI.
To do this, you'll have to give yourself strict constraints and promise to stick by them, which is much easier said than done. You have to go slow and constantly refactor, and find that single code path which everything else is attached to. If you don't explicitly find this path, then you run the risk of doing too much with too little governance, which is where code rot starts to creep in. In strongly-typed languages like Java, you can have the compiler enforce this with package boundaries and multi-module Gradle projects. In other languages, you'll have to be the one enforcing these rules of which methods are allows to be called, which fields are allowed to be changed, etc.
In building Orchid, I actually kind-of "rediscovered" several GoF design patterns, just because I got backed into a corner and needed to really think about how to find my way out. And when you start working on a way to get out of the corner, actually take the time to go and apply that same solution to other areas in the app, and see if it stands the test of scaleability. If it doesn't, refactor and find a better way. If it does, you've now got a new tool in your toolbelt to help you solve even harder problems.