I dreamed of that type of content since I’ve been a teenager. Thank you for sharing, it’s fantastic to see more and more programmers streaming themselves working on fairly advanced projects. That removes so much layers of magic and complexity once you can peek behind the curtain this way
I (not the programmer in the video) started programming 2 years or so during the pandemic during sophomore year of high school. I can affirm - there is a lot to wade throughm it's hard to know what's relevant, easy to learn and useful in real life.
That said, despite the availability of content online I tend to only watch the videos where something is a) summarized or b) something very advanced is broken down (e.g. the micro-gpt from scratch series). Imo, the best way to learn programming is to get excited about bringing your ideas to life, and choosing ideas small enough (at the start) to accomplish.
I am worried though about the rise of machine learning which may increase the barrier to entry in industry jobs and require more expertise to get ones "foot in the door". Additionally I find it hard to resist learning new technologies that are not as widely used / changing quickly do to their ease of use (Svelte, Tauri, V lang, etc).
Anyways, just thought I'd chime in as a kid learning to code
> I find it hard to resist learning new technologies that are not as widely used / changing quickly do to their ease of use
This isn’t a bad thing. I’ve never regretted trying something new, even if it’s just to learn that I don’t like it or whatever. “normal” software engineering stuff (day to day) is so much more about building and maintaining what you have already.
> Additionally I find it hard to resist learning new technologies that are not as widely used / changing quickly do to their ease of use (Svelte, Tauri, V lang, etc).
One thing I'd suggest is to be somewhat critical of what it means to be learning something, and find a way to apply whatever that is multiple times, without spreading yourself too thin.
When I was getting started around the same age, I never bothered repping things out like at a gym or going deeper into how things worked and piecing them back together manually from scratch (such as the micro-gpt project), but those are two ways you can keep things interesting long term, and develop useful/practical knowledge. Instead, what I did was read a book or follow a tutorial and figured that was enough to learn, but it's often just what was possible to teach, or a good jumping-off point, and that's basically what I've been getting from GPT lately. Nothing really gets learned imo unless there's an input and output to the process, such as watching the video and writing all the code from scratch or on paper, and then hopefully building something with it where you'll be forced to push yourself mentally. Very little of the depth might apply in a job, but you'll be better at troubleshooting and understanding what's happening, and repping out gradually more abstract and complex projects using the same technology will make you more efficient. Especially with ADHD that I didn't realize I had earlier, it would have really helped to rep things out more, because only through repetition and expanding complexity do you understand the gritty bits that aren't complete, or areas where you're likely to need another tool, or useful shortcuts and edge cases etc..
Incidentally, NAND2TETRIS is a great example of an end to end course that is totally worth trying and slowly grinding through.
Begging my parents to drive me to every library in the county so I could try and find books on computer graphics and AI in the 1980s. Not very many around then :(
i feel this is a sentiment shared by every generation. “Now with printing presses, kids have access to tombs of knowledge”
Conversely, you used to look at a line of OS code and knew how that translated to registers within a processor. Now i barely know which kubernetes cluster the code is currently deployed in
Sure. On the other hand, the mere fact that it was difficult to find the information means you might have developed skills and perseverance going out for it.
But it's certainly no longer the golden era of the Internet either, with human mass produced clickbait content already on the rise and now we've got the AI variant to contend with as well :(
He hasn’t been uploading much recently but the backlog is full of OS development, applications ported to his OS and his most recent mission, building a web browser from scratch.
I wrote a USB host driver for the STM32F4 a couple months ago, and the most difficult part was the lack of good documentation - the peripheral had r/w registers mapped as read-only in the SVD, there was a bit you had to set that wasn't mentioned in the documentation, and then the whole USB bulk-only-transport pointing to a non-existent SCSI spec. I ended up finding a blog post stating that you have to basically copy what Windows does in order for USB drives to work.
Luckily I had an oscilloscope that could decode USB frames to save me a whole bunch of time to understand why things weren't working.
USB seems to depend on a whole lot of tribal knowledge, which makes it impressive that it is so ubiquitous and works out of the box for the most part.
Not OP, but for USB "full speed" devices (12 Mbps), you can use a saleae logic analyzer clone ($12) with the opensource pulseview which can decode USB frames and streams rather well.
Even with faster devices, you can usually force them down to 12 Mbps with a USB 1.1 hub for analysis and bugfixing of the driver/firmware, and then have the exact same code work fast without the hub.
On desktop, wireshark also has the ability to monitor USB data transfers for a software-only approach.
In a way that makes it worse because while you might get it "working" sooner, you'll never be sure if it's because you got it right, or if you're skating across the ice of a "quirks mode" that you hope will work in the next silicon rev.
Then again, if you don't need to follow the spec for your to work, maybe the spec is overly restrictive and a Vernacular Protocol is more effective.
I started contributing to a decompilation project and while I’m not the best decompiler by any stretch of the imagination I’ve thought about streaming while I’m working.
Is there interest in content like this? Are people curious about tells for when assembly is affected by variable sign, struct vs array access, the bonkers things even 30 year old compilers do with control structures, register reuse, etc. and how to coax code into byte equivalent assembly from classic consoles.
Made an account to say yes, this would be awesome to watch. I’ve been trying to accumulate esoteric reversing knowledge like this but it’s hard to know where to even look!
I am interested. I learned some basic 8086 assembly during university, read some books on reverse engineering, but never went anywhere further. BTW, are you working on a open source project?
The fascinating thing about watching people doing hard things is peering into their thought process. Writing an OS certainly qualifies as difficult. So if you really have the time to do it, please do. I will donate to your cause.
...after numerous more hours of understanding how things work.
Not mentioned in this title is that this is a USB device driver, for a relatively simple device, with existing code available. This is essentially a code-to-code "translation" task. I can see how this looks very impressive, but IMHO it's like watching anyone else skilled at their profession.
> ...after numerous more hours of understanding how things work.
>
> Not mentioned in this title is that this is a USB device driver, for a relatively simple device, with existing code available. This is essentially a code-to-code "translation" task. I can see how this looks very impressive, but IMHO it's like watching anyone else skilled at their profession.
Yeah - the title is a little off. My apologies! I'm not super knowledgeable about the kernel myself and while I did gain some knowledge from watching the video a lot of it looked like pure magic.
If a mod wants to edit the title to remove the "from scratch" and add that it's a device driver that would be great but otherwise, no worries
As much as I love this kind of video, a deep dive tutorial, "from scratch" is kind of a misnomer. "From 10 years of experience doing exactly this" doesn't have the same ring
You don't need to read the nitty-gritty of the USB spec itself, having a general idea of its capabilities is enough. The kernel gives you a bunch of functions to work with. You can learn it by simply reading the code of the most simple driver that you can find in the kernel source. Then you can step up, and find a more difficult one.
It would be better if you could just read doxygen docs or something like this instead of having to reverse-engineer someone's else code. Because the code is just an example of using functions and doesn't give their complete description.
If you write something like Linux kernel, write doc comments.
A good driver API will hide that all and make sure an individual USB driver does not have to care about the USB spec - that’s the job of the shared USB core code.
Not sure why everyone is stuck on "from scratch" part. This is from scratch in all practical terms to me. They would be wasting their and viewer time if not done this way.
Because there are us who have actually done USB device drivers "from scratch", i.e. using the specs or gone through the RE process for an unknown device, while this is basically porting existing code to a new API. Thus it's rather clickbaity.
Sure. But writing drivers via specs is also almost also porting :)
"From scratch" is not interesting or generalizable. Chatgpt can do that, infact I have used GPT to write IMU driver "from scratch" by just giving it a bunch of datasheet pdfs...
Does anyone write a new kernel driver without using reference code for the Linux kernel subsystem? The code is less interesting than the human commentary. Imagine future AI-simulated "coding commentary".
I wonder if this video is painful to watch for people who claim "10x programmers are a myth!"
As an eng manager who's overseen teams at several top FAANGs, I can say without a doubt that most of those engineers would have taken 1-2 months to implement a driver.
This is confusing lack of experience with a specific discipline with productivity.
If you have the specialized knowledge, you’ll know that “writing a driver” is an overloaded term to start.
This guy isn’t going from a blank slate “scratch” either. There is tremendous amount of boiler plate being started with (in addition to the tremendous amount of core driver and USB “library” code in the base kernel)
And for those with experience in writing device drivers nothing here is super human or even not mundane. This is a well documented (existing code) hardware with a simple interface. If you’re already experienced with Linux kernel device drivers, this is not a terribly complex incremental task.
No it isn't. Most programmers just don't have the experience, and don't much care to get it. I've long thought 10x programmers were a myth, until I saw how much faster some of our developers are compared to others. It's pretty close to 10x, some people will do something in a week, someone else in half a day.
The person who did it in a week wrote a thousand lines of terrible code, the second person replaced it with fifty lines.
If you ask me to code something that I worked on during my last project/client, I'll probably do it more than 10x faster.
My point: one person can be his own 10x coder depending on (recent) experience and niche knowledge being applicable to a project. To any manager I will look more than 10x faster than my peers.
But I would definitely not be 10x "better" than my peers at our job in general.
Yes, experience should (in theory) make one move faster.
But that's not the full answer. In company after company, I've seen (and been amazed by) engineers who even at a young age (as in, first job out of college) somehow leapfrog the others and deliver a ton of awesome code, constantly. They simply don't struggle with it. And meanwhile, most of their peers (even older, more experienced ones) hit roadblocks at every turn.
Exactly. That's why it's hard to watch so many people claim it's a myth.
What I'm coming to realize is even worse is that many people do see how much more productive and capable other engineers can be, but make no effort to learn from them how they do what they do.
I have no doubt that natural talent is a big factor, but many specific behaviors can be learned, and they're probably worth trying when they're going to affect every day of a multi-decade long career. Some people understand this and become the best they can be within their natural talents, while most people just keep doing whatever they're doing while watching junior engineers zip right past them.
Exactly. Plus, the author is not totally new to this. According to his resume he's been writing drivers since the late 90's so this probably isn't his first rodeo. He makes it look easy.
Yup, scanned through the video, I don’t think the guy authored a single function, just grabbed skel and parts from other code bases, deleted stuff he didn’t want and fixed a little glue and build code
Depends how you define opportunity. Getting really good at something is 90 % putting in a lot of hours and 10 % talent. Putting in a lot that don't pay isn't for everyone, while the really great devs will do a lot of tech work outside the job as well.
I have to point out that if you're the consistent factor over all these seemingly mediocre engineers, then that really might say more about the manager roasting their own employees on a public forum than them?
Sure, we can ad hominem this all day. I suppose it's entirely possible the reason that in team after team over 20 years, the reason it's always a small number of engineers who get the most done, by a very wide margin, that the problem all along was me. This despite the fact that I consistently see the same gap in teams I don't manage -- where every project has a small handful of standout engineers responsible for most of the codebase, and then a whole bunch of people who inch along.
But what's your own experience been? Have your own teams been absolutely full of high-productivity developers, everyone contribute roughly the same amount?
That’s just what people outside FAANGs say as copium.
The idea that FAANG engineers are somehow just resting on their laurels isn’t borne out in the evidence of how much tech is being pushed by those companies.
Sure, there’s likely some who do so. But there’s also likely tons who do so outside FAANG as well. You just don’t think about them because they’re not associated to something that you think is noteworthy
If you've never written a driver before, of course it's going to take weeks or months to get somewhere (speaking from experience, having written a few of my own as early tasks at a new job)
However, once you understand the APIs presented by your OS, and/or the underlying standard you need to implement, that time will easily reduce to a few days (or hours, in this case). If I've just written a USB driver for one set of hardware, it's almost certainly going to be trivial to write a driver for some other hardware.
