3 ms·

I fundamentally disagree with the notion that design and discussion, of often very detailed technical aspects, is "non-technical work" of any kind, or that sitt

by anyfoo 4y ago

I fundamentally disagree with the notion that design and discussion, of often very detailed technical aspects, is "non-technical work" of any kind, or that sitting down and writing code is the only "technical work".

hinkley 4y ago
I’m not sure who to reply to in this thread about whether they mean to imply that debugging and simplifying aren’t technical work too. Finding the right spot to make a 2 line change instead of the wrong spot to make 8 five line changes is seriously technical work
eropple 4y ago
Yup. Once you're doing staff-level IC work, most of your technical work is talking.
- throwawaylinux 4y ago
  Maybe so, so long as we disagree with the notion that that the most senior engineers, the ones who are having "discussions" and making technical decisions, should not have to be active in the code, work with the development teams, and have a deep technical understanding about it works today. They don't have to have the highest commit counts, but if they're not the ones the rest of the development team look to for help solving critical bugs and advice about new features and designs etc., then they have no business evaluating technical concerns.
  - eropple 4y ago
    I mean, of course. That's part of the job: you can't search for multiplier effects without knowing what they are.
    - throwawaylinux 4y ago
      Okay, just making sure. I've had experiences where people making technical decisions hadn't written a serious line of code for 10 years. Maybe they used to be good, but they wound up resting on their laurels. They frequently do make great decisions. Some can just muddle though things if they listen to the real technical people, the ones who are incapable of even that are a disaster.
lmm 4y ago
Doing design and discussion without writing code just feels like deliberately hampering yourself. Code is the best language we have for describing things unambiguously! Weeks of plain-English discussion can save you hours of prototyping.
- anyfoo 4y ago
  That works in mostly self-contained projects. As soon as you interface with other teams, or even hardware that is still in development, you better make sure that everyone is aligned on the critical details before plowing ahead. Otherwise it can get very expensive (in terms of time, money, and motivation) to prototype yourself into a corner. Just this week I witnessed some team having built feature without consulting another critical team, and now it has to be reworked and shipped at a much later date.
  - lmm 4y ago
    > As soon as you interface with other teams, or even hardware that is still in development, you better make sure that everyone is aligned on the critical details before plowing ahead. Otherwise it can get very expensive (in terms of time, money, and motivation) to prototype yourself into a corner. Even then, writing a prototype is often a quicker and more effective way to flush out disagreement than endless discussion.
    - anyfoo 4y ago
      But "endless" discussions or disagreements weren't implied at all. For a sufficiently large and complex project, where every participant (individual or entire teams) is only able to fully grasp a relatively small piece of it[1], there is sometimes just a lot of details to talk through, even if all participants are in full agreement and perfectly willing throughout that entire process. To stay in the embedded world for an example, sometimes the actual code is just a few dozen lines with a handful of assembly instructions, or even less. But the danger and potential pain those lines of codes might incur on countless involved subsystems, if not properly thought out, even if seemingly "working" at first, can be immense. [1] To give a sense of scale of complexity in the embedded world for example, the ARM Architecture Reference Manual alone is well over 10000 pages now. And that isn't any actual implementation, and only the "main CPU" itself!

by anyfoo 4y ago

hinkley 4y ago

I’m not sure who to reply to in this thread about whether they mean to imply that debugging and simplifying aren’t technical work too. Finding the right spot to make a 2 line change instead of the wrong spot to make 8 five line changes is seriously technical work

eropple 4y ago

Yup. Once you're doing staff-level IC work, most of your technical work is talking.

throwawaylinux 4y ago
Maybe so, so long as we disagree with the notion that that the most senior engineers, the ones who are having "discussions" and making technical decisions, should not have to be active in the code, work with the development teams, and have a deep technical understanding about it works today. They don't have to have the highest commit counts, but if they're not the ones the rest of the development team look to for help solving critical bugs and advice about new features and designs etc., then they have no business evaluating technical concerns.
- eropple 4y ago
  I mean, of course. That's part of the job: you can't search for multiplier effects without knowing what they are.
  - throwawaylinux 4y ago
    Okay, just making sure. I've had experiences where people making technical decisions hadn't written a serious line of code for 10 years. Maybe they used to be good, but they wound up resting on their laurels. They frequently do make great decisions. Some can just muddle though things if they listen to the real technical people, the ones who are incapable of even that are a disaster.

lmm 4y ago

Doing design and discussion without writing code just feels like deliberately hampering yourself. Code is the best language we have for describing things unambiguously! Weeks of plain-English discussion can save you hours of prototyping.

anyfoo 4y ago
That works in mostly self-contained projects. As soon as you interface with other teams, or even hardware that is still in development, you better make sure that everyone is aligned on the critical details before plowing ahead. Otherwise it can get very expensive (in terms of time, money, and motivation) to prototype yourself into a corner. Just this week I witnessed some team having built feature without consulting another critical team, and now it has to be reworked and shipped at a much later date.
- lmm 4y ago
  > As soon as you interface with other teams, or even hardware that is still in development, you better make sure that everyone is aligned on the critical details before plowing ahead. Otherwise it can get very expensive (in terms of time, money, and motivation) to prototype yourself into a corner. Even then, writing a prototype is often a quicker and more effective way to flush out disagreement than endless discussion.
  - anyfoo 4y ago
    But "endless" discussions or disagreements weren't implied at all. For a sufficiently large and complex project, where every participant (individual or entire teams) is only able to fully grasp a relatively small piece of it[1], there is sometimes just a lot of details to talk through, even if all participants are in full agreement and perfectly willing throughout that entire process. To stay in the embedded world for an example, sometimes the actual code is just a few dozen lines with a handful of assembly instructions, or even less. But the danger and potential pain those lines of codes might incur on countless involved subsystems, if not properly thought out, even if seemingly "working" at first, can be immense. [1] To give a sense of scale of complexity in the embedded world for example, the ARM Architecture Reference Manual alone is well over 10000 pages now. And that isn't any actual implementation, and only the "main CPU" itself!