1,448 karma · joined January 17, 2017
After showing us around, he drew in close and told us that he had been quietly doing some work for the U.S. Mint and to please keep it a bit quiet.
He removes a padlock from a cabinet and pulls out a maybe 2 inch thick stack of uncut $5 bills, 2 bills wide and maybe 6 bills tall, all shrink wrapped.
As anyone else would, I start trying to do the math in my head, wanting to crack a joke about fitting the printing machine back up for a “special run,” and so on.
After a moment my uncle admits that it’s all a gag, only the top sheet is actual money, specially ordered uncut, with the rest of the stack underneath just being regular blank paper.
In hindsight the locker was a super flimsy sheet metal cabinet.
“… one of the principle issues is that it's less a protocol and more a skeleton of a protocol.”
But then later another group asked me for references at the beginning, I declined to provide them, and then they were okay with proceeding through the interview process.
Maybe it would work in the general case to always reply to such a request with "some previous group ghosted me, and so I've vowed to withhold the references until later in the process."?
I have no idea what happens with the actual physical location but at least from the beneficiary’s perspective it seemed fine to just ignore it.
That might be one way to restore faith in one’s supply chain.
My motivation has been some recent jobs/roles in which no-pipeline-feature-gets-denied YAML scripts have grown unmanageably large.
I'd be interested to hear of any pitfalls that any of you might foresee. Other than this is a pretty hefty undertaking - that much I can already see on my own. :-)
But in 99.999999% of real-world projects, anemic object-oriented code disregards encapsulation completely, and so business logic (the core reason why you're building the software in the first place) gets both duplicated and strewn randomly throughout the entire code project code.
Or in many cases, if the team disregards encapsulation at the type level then they're likely to also disregard encapsulation at the API/service/process level as well.
However the definitions make the 2 choices (adding new types vs adding new functions/operations) sound like a toss-up.
It is the fact that I tend to find the FP/DU approach so much more frequently useful for my/my team's own code that makes me wonder if I'm missing something.
Perhaps the important distinction I've been missing is in Wikipedia's definition:
"The goal is to define a data abstraction that is extensible both in its representations and its behaviors, where one can add new representations and new behaviors to the data abstraction, without recompiling existing code, and while retaining static type safety (e.g., no casts)."
... but when I'm working on my own/team's code, it is perfectly sensible to recompile the code constantly.
I’ve never felt like I’ve fully understood the implications of the expression problem https://en.wikipedia.org/wiki/Expression_problem but my best/latest personal hypothesis is that providing extension points via conventional polymorphism might be best suited for unknown/future clients who might extend the code, but unions with exhaustive pattern matching seem better suited for code that I or my team owns. I don’t typically want to extend that code. More often, I instead want to update my core data structures to reflect ongoing changes in my understanding of the business domain, more often than not using these Union-type relationships, and then lean on the compiler errors maximally to get feedback about where the rest of the imperative code now no longer matches the business domain data structures.
I have not familiarized myself with the arguments against expression-based design but as a naive individual contributor/end-user-of-languages, expressions seem like one of the few software engineering decisions that doesn't actually "depend," but rather, designing languages around expressions seems to be unequivocally superior.
Perhaps a good antidote could be chair pants! https://tenor.com/view/silicon-valley-gabe-dinesh-wearable-c...
Is it just me, or is it genuinely funny that whenever someone does this I think of Deep Thoughts by Jack Handey: “When you're going up the stairs and you take a step, kick the other leg up high behind you to keep people from following too close.”
It makes me suspect that most other-than-blockchain roles must be going to personal networks and referrals, rather than via public job listings.
Now when people argue “because decoupling,” I hear, “You don’t get as much notification that you just broke a downstream system.”
I’m a spiciness wimp but I can now eat a jar of jalapeños like they were popcorn and it makes me just as happy as can be.
I’m having a good experience with Warp, but as a new Rust user I feel like I’m investing a lot on learning Warp’s system of traits. Perhaps I’ll get better at internalizing such things but for now, it seems likely that the switching costs, even if only cognitively, might be a bit steep.
I think you have to get the actual content from the Wayback Machine now.
Gist was that many Armenian families tended to be miffed at the amount of financial assistance their relatives who had moved to America tended to send back, particularly upon learning of their apparently high salary amounts.
Article then goes on to describe how American society tends to nickel-and-dime its members to death from every direction.
More broadly, the article was a fascinating outsider’s look at our culture and lifestyle.