4 ms·

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 c

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.

epcoa 2y ago
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.
- raggi 2y ago
  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
- Rinzler89 2y ago
  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.
- stavros 2y ago
  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.
  - bboygravity 2y ago
    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.
    - stavros 2y ago
      So you're saying that the people who've been with us for years that do things 10x faster than their peers did the same things last month?
    - khazhoux 2y ago
      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.
      - fl0ki 2y ago
        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.
  - deleted 2y ago
    [deleted]
- khazhoux 2y ago
  Yes, I totally grant that this was someone experienced in this specific discipline, who was not starting from blank slate. 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?
  - 8372049 2y ago
    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. (The numbers are not meant to be taken literally)
devwastaken 2y ago
[flagged]
sibit 2y ago
I don't think you can compare the productivity of someones passion with someone who's writing code they're told to write at a job.
moritonal 2y ago
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?
- Rinzler89 2y ago
  IDK, but isn't it public knowledge already the everyone goes to work at FANGs to "rest and vest"?
  - dagmx 2y ago
    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
    - Rinzler89 2y ago
      >That’s just what people outside FAANGs say as copium. No it's something FAANGers themselves openly admit under anonymity on social media.
      - dagmx 2y ago
        If it’s anonymous, how do you know it’s true?
        Rinzler89 2y ago
        How do you know it's not?
- khazhoux 2y ago
  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?
foldr 2y ago
You have to look at the total time (crucially including future maintenance and bug fixes) not just the time to get to a basic working prototype.
Panzer04 2y ago
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.

epcoa 2y ago

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.

raggi 2y ago
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
Rinzler89 2y ago
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.
stavros 2y ago
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.
- bboygravity 2y ago
  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.
  - stavros 2y ago
    So you're saying that the people who've been with us for years that do things 10x faster than their peers did the same things last month?
  - khazhoux 2y ago
    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.
    - fl0ki 2y ago
      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.
- deleted 2y ago
  [deleted]
khazhoux 2y ago
Yes, I totally grant that this was someone experienced in this specific discipline, who was not starting from blank slate. 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?
- 8372049 2y ago
  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. (The numbers are not meant to be taken literally)

devwastaken 2y ago

[flagged]

sibit 2y ago

I don't think you can compare the productivity of someones passion with someone who's writing code they're told to write at a job.

moritonal 2y ago

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?

Rinzler89 2y ago
IDK, but isn't it public knowledge already the everyone goes to work at FANGs to "rest and vest"?
- dagmx 2y ago
  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
  - Rinzler89 2y ago
    >That’s just what people outside FAANGs say as copium. No it's something FAANGers themselves openly admit under anonymity on social media.
    - dagmx 2y ago
      If it’s anonymous, how do you know it’s true?
      - Rinzler89 2y ago
        How do you know it's not?
khazhoux 2y ago
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?

foldr 2y ago

You have to look at the total time (crucially including future maintenance and bug fixes) not just the time to get to a basic working prototype.

Panzer04 2y ago

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.