Hacker News new | past | comments | ask | show | jobs | submit | Greed's comments login

> If I were in one of these high crime neighborhoods where people are getting shot, I would want more surveillance and police. This position that they're being exploited by surveillance is mostly a rich white cosmopolitan belief rooted in fantasy

But ARE you though? I'm in Chicago where we're in the tail end of phasing this system out specifically because it did not address the problems it claimed to. All it did was aggravate and harass locals _after_ the fact that had nothing to do with the initial crime.

The deterrence factor was not insignificant, but it definitely wasn't worth the far greater instances where it was not only creating false positives but also proactively CREATING crime in accordance with other "high tech" solutions like predictive crime algorithms which only really served to reinforce existing biased patrolling practices (which were driven by data generated by shot spotter, in part).

See: https://www.theverge.com/c/22444020/chicago-pd-predictive-po...


I think this is a lot more common than one might think. The trend of hiring "Only Seniors" puts a downwards pressure on both engineers and those managing them to focus on titles over pay increases. The engineer gets the title thinking they can leverage it for more pay at a different position, but in reality they end up trapped at their current employer because they are from then on interviewed as a senior level engineer and unable to pass merit by that benchmark. Should they aim for a non senior role, they automatically face negative hiring bias because the hirer assumes (probably accurately) that they will demand more pay for the same role compared to non-senior applicants with the same years of experience.

Strange catch 22 situation where the title promotion actually locks them in where they are for at least another few years.


I've always wondered what exactly that "useful productivity" cap is for programmers on average. I've been gifted with the capacity for 100% productive eight hour days, but it's definitely easy to recognize that as extremely unusual talking to coworkers for more than ten minutes over the years. In discussing the idea of "maximum productive hours per day" I've found that not only is the variance on the teams I've been a part of huge, but also that it's pretty hard to correlate that number with work ethic. Great engineers often know when they're out of that maximally effective window and pivot to other things for the rest of their day.

A related aside: I've noticed anecdotally that as you become more senior you get pretty good at feeling out what that number is for each of your teammates and it becomes a pretty useful metric to leverage in your day-to-day toolkit. I'd be curious to see what a workplace would look like if folks were actually allowed to be transparent about that (without repercussions) rather than it having to be guesstimated.


Life isn't about this. Watch office space.


It's too bad that SASS has fallen out of favor. With SASS, that would have been:

```

  a.link
    border: red

    &:hover
      border: blue
```


Yes, I did use SASS before Tailwind (and Compass back in the day), and got a lot of value from them. Where it started to get painful is when I have:

    a.link {
    
    }

    a.another {

    }

    <a class="another link">...</a>
It was easy to fix, but hard to scale the fixes over different codebases, timelines, and developers. That's the problem Tailwind solves for me.


CSS nesting will be available to us mortals (in production) within a year and we might be able to use it just a guess as early as 2026?

https://webkit.org/blog/13813/try-css-nesting-today-in-safar...


That misses the point. This is still worse than seeing all your styles in the place where they apply. SASS/LESS just make it faster and more succinct to write styles in css files rather than in the components in which they live and even more importantly—on the actual ELEMENTS that they apply to.


Fallen out of favor with who?


Your usage of Kashmir as the representative for democracy in this context is a little less credulous given the region is generally synonymous with fascism, ethno-nationalism, and extreme corruption driven by startling inequality and poverty.

I don't think you're wrong to say that it can happen to nominally democratic countries too, but India as a whole (and ESPECIALLY the smaller states) is probably not the best example to prove the point.


>I don't think you're wrong to say that it can happen to nominally democratic countries too, but India as a whole (and ESPECIALLY the smaller states) is probably not the best example to prove the point.

do you need to show proof from every state of india to "confirm" that india does this? as opposed to even 1 case of silencing dissent is good enough to prove a point?


>extreme corruption driven by startling inequality and poverty.

you talking about bihar?


What makes it so that only 4chan users would have empathy for the death of other programmers? Terry's death was quite tragic and his work was often discussed in technical circles for it's novelty...despite his eccentricities. Love him or hate him, no human being deserved the circumstances of his life or of his death.

RIP Terry. A. Davis


The difference is that you can see it. If you have two highly skilled contributors with very different programming styles, they can still collaborate within the same codebase given a goal and the end-result is the same for your users. When a code contribution is marginally better or worse in its approach than another the difference is negligible to the project as a whole. By contrast, users notice when a single color is different for design elements. And they complain extremely loudly about it.

On the contributor side:

- Visual style guides require much more time and skill to create (relative to style guides for code) and still generally fail to achieve anywhere near the aesthetic unity of a single great designer with total control.

- If you commoditize your design elements to the point where it is easy to contribute them, then it is no more difficult to do it yourself to begin with.

- Delegation of design work still requires that you funnel it somewhere to be judged on qualitative measures, rather than the pass/fail nature of code

Generally the best you can do is collaborate very, very tightly and then funnel it through a single person in the end anyway a la Python's BDFL in a very trial and error fashion.


The difference is that you can see it. If you have two highly skilled contributors with very different programming styles, they can still collaborate within the same codebase given a goal and the end-result is the same for your users. When a code contribution is marginally better or worse in its approach than another the difference is negligible to the project as a whole. By contrast, users notice when a single color is different for design elements. And they complain extremely loudly about it.

On the contributor side:

- Visual style guides require much more time and skill to create (relative to style guides for code) and still generally fail to achieve anywhere near the aesthetic unity of a single great designer with total control.

- If you commoditize your design elements to the point where it is easy to contribute them, then it is no more difficult to do it yourself to begin with.

- Delegation of design work still requires that you funnel it somewhere to be judged on qualitative measures, rather than the pass/fail nature of code

Generally the best you can do is collaborate very, very tightly and then funnel it through a single person in the end anyway a la Python's BDFL in a very trial and error fashion.


You can test this pretty easily, it's not like that model doesn't exist. Play your average driving videogame at 30fps in first-person mode. Crank up the brightness until you can barely see if you like. We do it just fine because the model exists in our head, not because there's some inherent perfection in our immediate sensing abilities.


Realistically when you buy a phone you have a choice between two storefronts-- what are these other phones with no storefront you're referring to? Surely you can't be presenting conventional flip phones as an alternative here.

Blackberry now produces Android phones and the Windows phone is defunct. That just leaves the myriad of fly-by-night Kickstarter phones that wouldn't be able to run these apps in the first place.


So i'm lost though, is the implication that, because it's difficult to buy comparable phones that Google should offer their infra for free? At what point does Google have a right to make decisions on their own infra? If they're hosting your app they don't get a say in what they host?

And again, i already said i think you should have a right to run what you want on your phone. But most of the comments here seem to want to dictate what Google does with its own infra. That they don't get a choice in this.


The difficulty in criticizing Bitcoin and what it could have been is that everyone willing to engage you on it is quite literally invested in being right.

Zealots betting the house can't afford to be wrong because it would often make them bankrupt.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: