4 ms·

This is very good example how engineering discussion should proceed: The project lead (Linus) pushed back first with reasonable-looking point, but it is hit ba

This is very good example how engineering discussion should proceed: The project lead (Linus) pushed back first with reasonable-looking point, but it is hit back by a thorough research. And finally a clever workaround broke it through. It was very energizing to me who has habit to rely on non-engineering tools to push through these kind of discussions.

zamalek 5y ago
And engineering in general, it is a great day when someone notices that something is unused and pushes for its removal.
- bityard 5y ago
  Speaking as someone who maintains a fair bit of legacy infrastructure for a living, the hard part is knowing what is unused and what isn't. That's the whole rationale behind Linus' "don't break user space" policy.
  - duxup 5y ago
    > knowing what is unused and what isn't Or what I run into “Is this used …. and does it even ‘work’?!?!”
    - girvo 5y ago
      My "favourite" answers to those two questions at work are "yes" and "not really..." -- that's always a sign I'm going to have a fun week or two...
  - inopinatus 5y ago
    Sounds like Chesterton's fence¹. [1] https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
    - ketzo 5y ago
      Y'know, people always cite Chesterton's Fence, but they never talk about ways to figure out why the fence was there... that's the blog post I wanna read.
      - inopinatus 5y ago
        Good thought. Maybe people should learn to put some signage on the damn thing. “Beware of the bull”
        a9h74j 5y ago
        Always comment your fences.
      - jka 5y ago
        It's a process and culture thing: maintain descriptive context and history about all changes, and ensure that references and hyperlinks within those are temporally stable (that is, they'll still refer to the same content when they're examined by a future observer). "Chesterton's Permalinked Fence" is generally straightforward to reason about.
  - KMag 5y ago
    At my previous job, one of the nicest bits of kit was the moribund code logging system. You put a function call into the moribund logging library from a bit of code you thought was unused. The first time a process hit that line of code, it would fire off a UDP packet to a server, indicating the process name and the line hit. (It's nice to still have test coverage on the otherwise unused code, so it's great to see which processes are actually hitting the code.) Another system watched the version control system for who added that line of logging, and sent them status emails. After the moribund logging had been in production for two weeks, the emails turned into nag emails to either remove the code, or at least remove the moribund logging if you decided against removing the code.
- secondcoming 5y ago
  Gotta love raising those PRs that are nothing but red!
  - catlifeonmars 5y ago
    Somehow along the way I think the color convention for showing diffs got mixed up. I think it should green for removals, red for additions :)
__turbobrew__ 5y ago
If only the python devs had a similar attitude.
deleted 5y ago
[deleted]

zamalek 5y ago

And engineering in general, it is a great day when someone notices that something is unused and pushes for its removal.

bityard 5y ago
Speaking as someone who maintains a fair bit of legacy infrastructure for a living, the hard part is knowing what is unused and what isn't. That's the whole rationale behind Linus' "don't break user space" policy.
- duxup 5y ago
  > knowing what is unused and what isn't Or what I run into “Is this used …. and does it even ‘work’?!?!”
  - girvo 5y ago
    My "favourite" answers to those two questions at work are "yes" and "not really..." -- that's always a sign I'm going to have a fun week or two...
- inopinatus 5y ago
  Sounds like Chesterton's fence¹. [1] https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence
  - ketzo 5y ago
    Y'know, people always cite Chesterton's Fence, but they never talk about ways to figure out why the fence was there... that's the blog post I wanna read.
    - inopinatus 5y ago
      Good thought. Maybe people should learn to put some signage on the damn thing. “Beware of the bull”
      - a9h74j 5y ago
        Always comment your fences.
    - jka 5y ago
      It's a process and culture thing: maintain descriptive context and history about all changes, and ensure that references and hyperlinks within those are temporally stable (that is, they'll still refer to the same content when they're examined by a future observer). "Chesterton's Permalinked Fence" is generally straightforward to reason about.
- KMag 5y ago
  At my previous job, one of the nicest bits of kit was the moribund code logging system. You put a function call into the moribund logging library from a bit of code you thought was unused. The first time a process hit that line of code, it would fire off a UDP packet to a server, indicating the process name and the line hit. (It's nice to still have test coverage on the otherwise unused code, so it's great to see which processes are actually hitting the code.) Another system watched the version control system for who added that line of logging, and sent them status emails. After the moribund logging had been in production for two weeks, the emails turned into nag emails to either remove the code, or at least remove the moribund logging if you decided against removing the code.
secondcoming 5y ago
Gotta love raising those PRs that are nothing but red!
- catlifeonmars 5y ago
  Somehow along the way I think the color convention for showing diffs got mixed up. I think it should green for removals, red for additions :)

__turbobrew__ 5y ago

If only the python devs had a similar attitude.

deleted 5y ago

[deleted]