9,624 karma · joined August 21, 2020
Has that actually been interpreted by a court in that way or are you proposing a hypothetical? Your interpretation makes all dashcams illegal, which makes many Tesla and Toyota cars illegal.
The way I interpreted it was that people who are not part of a scene need to maintain some distance for safety.
---
The legality of filming police is thorny. For instance, a number of states passed laws after LivePD became a thing that barred the filming of traffic stops. That, however, contradicts the abilities of citizen journalists to document traffic stops and interactions.
Personally speaking, I don't want to be filmed during a traffic stop unless its my own footage. When I was arrested and went to jail the police posted my mug shot to every local paper and crime reporting website. It took quite a long time to scrub the internet of all of that once charges were dropped. Footage would be much worse because at one point after my head was driven into the ground I was sobbing. My instance also involved the police roughing me up because they perceived me to be "strong".
As others have pointed out the issue likely isn't the distance. It's that police can enforce their own measures here without accountability.
On the note of DORAs quality, I don't think they've ever actually released any datasets. The excuse they give is anonymity but their collection surveys always stated that the surveys are anonymous. It's impossible to determine the quality of their research beyond their own statements.
Uranium and Thorium decomposes into Radium, which themselves are found at 450m but the gas then rises through the Earths crust as it moves. I could see this kind of constant agitation releasing significantly more at least within a radius.
If you're looking for an idea of whose best, I'd say ThoughtWorks is by far one of the most forward looking companies when it comes to determining future trends.
Maybe I've worked at all the wrong companies but in my experience any comp that's based on "data" will be gamed until it's meaningless. There is no "data" because reading impact data is often like reading tea leaves.
Frankly, what I think is going unsaid here is that corporate executives make a disparately large amount compared to the people who do and plan the work. While executives can make a great difference, so can a great manager or a great engineer. I wish we'd see executives as just another role, taking on different tasks rather than something substantively more valuable when it's not, especially in large orgs.
I'm not sure what, if anything, I materially gave up other than that all of those components have a contracted API now so all future components will need to adhere to that API.
One thing that I think I may deviate with on this article is that mentoring shouldn't be started after coding; you should really be mentoring all along the way in your career. If the first time that you mentor is when you hold the title "Senior" then you're bound to screw up in some major ways and those screw ups will be amplified because of your perceived power and position. If you're a senior and haven't mentored up until this point I'd spend a good while mentoring people of your own level before you take on juniors.
Another piece of unsolicited advice is to drop any kind of perceptively fake facades; people will very much pick up on if you're git clone --depth=1 around them. Use that time to really invest in and get to know someone, and as the article points out, let them get to know you.
My last piece of advice is be there with them through their trials, especially in the lows. I once had a Marine that was going to get the equivalent of a PIP for behavior and none of the other NCOs wanted to go to our equivalent of HR with him because they knew they'd be dressed down by a man whose very existence was validated by dressing seniors down for their reports behavior. Of course, if a senior wasn't present he'd happily give that tongue-lashing to the junior. Without missing a beat I said I'd go. The worst place you can leave someone on their dark days is alone.
Most servers in the world use a constant amount of electricity, regardless of load. Generally the way to make DCs more green is to build them around a renewable plan with batteries (that they already need). Save for the fact that the whole thing is made of rare earth metals and lead, and you've got yourself something pretty green.
Sure, but low order definitions of "code" being something that takes an input and produces a different output do not relate to the real world unless you believe modern word processors require programmers.
> Referring to someone as a beginner is not discriminatory, we all start as beginners and it's okay to not know things.
I think you're missing the point that the statement you made applies to a wide variety of discussion, not simply binary code|not_code discussions.
> Most of the gatekeeping of what is and isn't "coding" is done by novices who don't really know what they're talking about
This statement would also imply anyone trying to sort out coding from formatting, from styling as a novice. There's a reason we separate these activities in programming that has to do with how you model applications not to mention empowering the people who have expertise in doing them.
While I agree that code|not_code is not helpful, trying to make the definition of code so low order that it's meaningless is also not helpful. There's a bar there that belongs in the middle and I think you both have missed it. I was merely calling out equally harmful wording that you were using to correct harmful wording.
I disagree. There's a meaningful distinction between what is code and what is formatting because the concerns are quite different. This distinction is more apparent on frontend applications where the code bits are actually dealing with the fact that there's a single process doing all these seemingly asynchronous things, the use of very infrastructure-like components (eg: pubsub implementations, stores, etc). Formatting and design doesn't need to deal with the how, it needs to deal with the why. The powerhouse of a developer is knowing both.
Trying to shoehorn peoples attitudes into discriminatory experience levels based on your perception of that rhetoric is an odd behavior unto itself. These topics merit talking about because ultimately they affect how we think, reason, and organize on different layers of projects.
You actually somewhat proved my point with your example of CSS. It more recently became capable of more "code like" qualities, but it can definitely be used for just styling and formatting. Without discussion someone may never know the difference or why you'd use some of CSSs computational capabilities. Another crossover is YAML; YAML can be very markup language oriented but it also supports aliases, pointers, etc.
This is incorrect. We consolidate most of our decision making at the small team leader level. Title and role, because of that, are explicitly not intwined. Lance Corporals can lead Sergeants if they possess the experience to do so. This is more common in the infantry. Small team leader have always practiced servant leadership; the idea that you eat last, take first watch, are the first in and last out on patrols is as old as time herself.