rasteau

The trade off is not installing Little Snitch.

No need to wonder. https://www.npr.org/2020/03/19/818327945/israel-begins-track...

"Prime Minister Benjamin Netanyahu ordered the country's Shin Bet domestic spy agency, usually tasked with monitoring Palestinian and Israeli extremists, to launch the cellphone surveillance. It locates people who could have the virus and messages them.

"Meanwhile, late Thursday Israel's Supreme Court stopped the police from using the data to enforce quarantines, which it had started doing. The court also said it could scrap the program unless it goes through parliament or if the country is put on a total lockdown."

For most scenarios where estimates are asked of development, there's usually an alternative approach that will yield better results.

Cost-benefit analysis scenario:

Request: We need to know how long it will take to build X so we can decide if we want to build it.

Response: What is the maximum amount of time to build X, such that if it took any longer, you wouldn't have us build it?

Rationale: Estimating whether a project will be over/under a time given frame is more likely to be accurate than estimating a specific span of time.

Dependencies scenario:

Request: We need to know how long it will take to build X because marketing needs to know when to start preparing.

Response: What is the amount of time marketing needs to prepare?

Rationale: Estimating that development is some amount of time away from completing is more likely to be accurate than estimating the entire project.

----

Underlying most arguments for estimates from development is an unwillingness by those doing the asking to do their own estimation.

I wonder if they were inspired by https://queue.acm.org/detail.cfm?id=3321612

Regarding cybersnowflake's comment, I think this is relevant: https://en.wikipedia.org/wiki/Poe's_law

The algorithm is secondary to the user group.

Neither is secondary; both are essential to the socio-algorithmic evolutionary process.

The algorithms are intended to optimize toward some user group behaviour. As the user group's choices influence the behaviour of the algorithms, so too do the algorithms' choices influence the behaviour of the user group.

Amen!

My last three companies were moving from a monolith to microservices. In every case, the rationale for the move was little more than "monolith development is slow, therefore microservices".

Unfortunately for all of them, the true reasons for the slow development was poor separation of concerns, insufficient and brittle tests, and years of accumulated hacky shortcuts to ship new features "faster".

The folks pushing the microservice panacea were "proven right" in that development was much faster... initially. Without years of cruft in their way, devs were able to churn out new stuff (after a significant time spent ramping up on infrastructure code).

Eventually, and in every case, the fundamental flaws resurfaced, this time increasing in severity now that changing the system often required multiple service changes. As well, a host of new kinds of problems emerged: distributed transactions, network failures, client/server versioning, debugging across services, etc.

I'm now a microservice skeptic. Whatever your solution, it should be at the same "level" as the problem. A massive change in technical architecture will not solve the accumulated cost of your poor engineering quality choices.

HTTP was initially designed for transfering static files and static data over potentially unauthenticated connections.

It may be more useful to view "transfering static files and static data over potentially unauthenticated connections" as the first application of HTTP. While there are parts of HTTP that are useful for static data transfer (e.g., Cache-Control), there are parts of HTTP that would have no relevance if that were the only use case (e.g., 409 Conflict).

it's not suitable for handling complex dynamic data

I would agree that HTTP was not designed to support applications pushing data from server to client, but that is a communication directionality issue separate from the issue of whether the data itself is complex or dynamic.

It's an issue with the responsive layout. If the window is wide enough the overlap goes away; narrow enough the TOC goes away.

what happens if two users modify different fields/properties of the same resource at the same time?

https://tools.ietf.org/html/rfc7231#section-6.5.8

   6.5.8.  409 Conflict

   The 409 (Conflict) status code indicates that the request could not
   be completed due to a conflict with the current state of the target
   resource.  This code is used in situations where the user might be
   able to resolve the conflict and resubmit the request.  The server
   SHOULD generate a payload that includes enough information for a user
   to recognize the source of the conflict.

   Conflicts are most likely to occur in response to a PUT request.  For
   example, if versioning were being used and the representation being
   PUT included changes to a resource that conflict with those made by
   an earlier (third-party) request, the origin server might use a 409
   response to indicate that it can't complete the request.  In this
   case, the response representation would likely contain information
   useful for merging the differences based on the revision history.

That said, it may be reasonable to develop reusable conflict resolution mechanisms for reusable definitions of "conflict", allowing for composition of separate concerns as needed. This seems preferable to inventing a new system that binds concerns together with a single, irrevocable notion of "conflict".

[1] Using PATCH does not obviate conflicts that the application design otherwise allows.

What you describe could also be used to argue that prices are higher than they would be in a competitive market, i.e., that for the 30% ratio it's not that the numerator is too small, but that the denominator is too large.

an unreasonable number of independent codebases must have identical bugs

Entertaining[0] badpun’s skepticism, it is not necessary they have identical bugs, only that their bugs yield similarly biased results.

For example, if a significant number of bugs are identified by their affect on the results, then bugs contributing to “wrong” results might be more likely to be identified and fixed.

[0] In the Aristotelian sense.

The electronic strip search machines are still optional; they'll (eventually) give you a pat down instead.

Hitchens responds: https://www.youtube.com/watch?v=jyoOfRog1EM

3) If I'm in a hurry and the author is available I grab them and do an over the shoulder review. You might be surprised how much time this saves.

One concern here is you may ask questions whose answers are then given to you, and you alone. If it's likely someone else in the future will have the same questions, the "answers" should be in the form of improved code.

4) Don't struggle with difficult sections of other people's code unless you have a vested interest in remembering this specific section of code. Ask about unclear areas.

I'm not clear on the distinction between "difficult sections" and "unclear areas"? Either way, one of the outcomes of the review should be to make life easier for the folks that follow us.

Yikes! Demanding a bug fix also remediate unrelated, extant style violations is a good way to ensure nothing improves.

I think the author and many folks here have an unhelpful understanding of code reviews.

I suggest code reviews' primary purpose should not be to catch bugs or trivial style issues; automated tests and linters exist for those purposes.

Instead, code reviews should be primarily thought of as "human comprehensibility tests".

When we write code, we've may have spent a significant amount of time thinking about the problem. This puts us in a bad position to gauge how readily someone in the future can reason about our code in order to fix or modify it safely and easily. Code reviews are a mechanism for showing empathy to our future selves, which accumulates over time into a much more pleasant coding environment.

Relatedly, comments on a PR are ephemeral. A rule of thumb I use: if a reviewer asks a reasonable question -- something someone in the future might wonder about when I'm no longer around, I answer it by first improving the code.

"[T]he English language... becomes ugly and inaccurate because our thoughts are foolish, but the slovenliness of our language makes it easier for us to have foolish thoughts."

I frequently have a driver who is obviously different than the one pictured in the app.

Do you continue the ride? Do you inform the company?

Talk about an industry that needs regulation!

I infer that you use Uber/Lyft/etc despite your concerns. Why not instead vote with your wallet, and use one of those nice, government-regulated taxicabs?

We need to get between grams and a count of molecules, that's the number.

I think that number is only true for carbon-12.

but then we would have some other arbitrary constant we would have to memorize to go from grams to a count of molecules.

I think we already have to do that, hence molar mass.

In practical terms, the mole helps chemists measure stuff. It helps express the amounts of atoms or molecules in a chemical reaction. Cause a half-mole of oxygen molecules (O2) to react with a mole of hydrogen molecules (H2) and you get a mole of water (H2O)—equal to about 18 grams of substance.

Every example I find describing the utility of the mole could just as plausibly substitute "dozen" or "googol" for "mole". I'm not clear on what would be lost to science by instead declaring a new number that is untethered from Avogadro's historical dependence on mass or length. Perhaps the deeper issue is that I'm not clear on why the dimensionless mole is a base unit at all.

Ask them if they like people using words like fa---- and ni---- and b---- in the workplace.

Low hanging fruit. What about using "guys" when referring to a mixed gender collection of individuals, as in "thanks, guys"?

I have seen coworkers publicly shamed by using "guys" in that way. Too often, the negative responses were as if the speaker had said "thanks to the men here only, and not to the women". This, despite knowing that "guys" is colloquially gender neutral [0], and despite knowing that's precisely how the speaker was using it.

I find it troubling that when etymologically gendered words become gender neutral, some people choose to fight to keep those words gendered.

[0] To the point that it is used even when there are no men present.

The prisoner's dilemma hinges on lack of communication between the prisoners. In the original scenario, communicating prisoners would both choose to stay silent. In the above scenario, communicating politicians would choose to never let the bill out of committee.

finding the "joy" of dynamically typed languages and all the "freedom" they give you ... verifying those types at compile-time was actually pretty useful

Indeed one of the "joys" is that one can apply that verification a la carte, and possibly with different approaches [0][1]. Similarly, one may desire to dispatch on type [2], but might sometimes want arbitrary dispatch [3].

After writing the 10,000th unit test that only exists to ensure that you spelled some function/method/hash-key correctly

This too is solvable with a la carte tooling [4].

Everything has trade-offs. Static type systems give a fixed set of benefits with a fixed set of costs. Some folks prefer to use their experience and judgement to choose when, where, and how to pay the associated costs (and that freedom of choice itself has a cost). It's okay to have different preferences.

[0] https://github.com/plumatic/schema

[1] https://clojure.org/guides/spec#_entity_maps

[2] https://clojure.org/reference/protocols

[3] https://clojure.org/reference/multimethods

[4] https://clojure.org/guides/spec#_testing

what can we do to eliminate the need for insurance? Can we have a network of doctors offices in major cities that we pay a monthly fee to access, where the billing and costs are transparent and sane?

We had something like that once, it was called Lodge Practice (also Club Practice and Contract Practice)[0]. Due to their low cost for medical services, physician cartels such as the AMA fought to kill them[1][2][3].

[0] http://www.freenation.org/a/f12l3.html

[1] https://jamanetwork.com/journals/jama/article-abstract/45648...

[2] https://jamanetwork.com/journals/jama/article-abstract/45599...

[3] https://jamanetwork.com/journals/jama/article-abstract/47651...