3 ms·

I did not feel super sympathetic when reading the breakdown of percentages (with only 10% "actually writing code"). Yeah, those specific percentages were a bit

by anyfoo 4y ago

I did not feel super sympathetic when reading the breakdown of percentages (with only 10% "actually writing code"). Yeah, those specific percentages were a bit egregious, but working on a big project it's not uncommon at all to spend more time thinking and talking things through than to actually write code. There's a lot of complexity to be tamed, and in my experience that can be a very enjoyable part of actually engineering. This however: > And the worst part is, I feel like the product we were shipping was really bad. It was slow and kludgy. It was the opposite of the qualities I value in software products. I didn’t feel like I was adding any value, and I was miserable. Yeah, there is absolutely no excuse for that. And if that is the case about the product you're working on, what I said just before about "enjoyable engineering" will never apply. Good for getting out of there.

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
- 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 anyfoo 4y ago

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
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.