Kernel developer write a USB driver in 3h for Apple Xserve front-panel [video]
youtube.com
youtube.com
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
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.
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.
I hope you don't give views to those asinine videos that take 30 minutes to 'summarize' a 90 minute movie.
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
Since it would be great to learn about sharing such channels, I would love if others can share other such channels as well.
Here's another I know: https://www.youtube.com/@LowLevelLearning Not stritly programming, but big fan of this channel as well: https://www.youtube.com/@StuffMadeHere (Amazing engineering channel)
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.
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.
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.
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.
My main concern is needing more than 8 channels or a higher sample rate.....and those are so expensive.
Its also hard to tell who is telling the truth on spec sheets.
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.
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
If you write something like Linux kernel, write doc comments.
"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...
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.
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.
The person who did it in a week wrote a thousand lines of terrible code, the second person replaced it with fifty lines.
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.
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.
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.
Perhaps one reason that there are so many low-productivity developers is because there's not as much opportunity to specialize and hone one's skills?
(The numbers are not meant to be taken literally)
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
No it's something FAANGers themselves openly admit under anonymity on social media.
But what's your own experience been? Have your own teams been absolutely full of high-productivity developers, everyone contribute roughly the same amount?
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.