4 ms·

>There's a lot of complexity to be tamed, and in my experience that can be a very enjoyable part of actually engineering In my experience there is almost no co

by Zvez 4y ago

>There's a lot of complexity to be tamed, and in my experience that can be a very enjoyable part of actually engineering In my experience there is almost no correlation between complexity of the project and time needed to do 'non-technical' work. Quite contrary, the most complex things I did as a dev required me to do a lot of coding - to prototype, to experiment, to load testing and so on. And at the same time the easiest project in the larger corporations required me to write down design docs for trivial stuff and spent months in meetings to 'align' with people, who don't have time to even read your design doc, but want you to have bi-weekly meeting about it. So no, I don't buy this excuse anymore. Unless you are building space ship or do very unique work, there shouldn't be any need to spend 80% of your time in non-strictly-technical work.

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!
oaiey 4y ago
The problem is essentially the following: in a know-all situation (prototype, reduced domain, startup,..) situation it is easy to ditch the 90%. No sync needed, no docs needed, no tests needed, ... Once you scale up to large systems (ignore complexity) with hundreds of developers then you do and can not know it all. At that moment the churn starts. And unfortunately, once you get big, regulators, lawyers, audits and other things become a drama as well.

by Zvez 4y ago

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!

oaiey 4y ago

The problem is essentially the following: in a know-all situation (prototype, reduced domain, startup,..) situation it is easy to ditch the 90%. No sync needed, no docs needed, no tests needed, ... Once you scale up to large systems (ignore complexity) with hundreds of developers then you do and can not know it all. At that moment the churn starts. And unfortunately, once you get big, regulators, lawyers, audits and other things become a drama as well.