9,464 karma · joined December 17, 2013
As an investment vehicle, it's exactly as you say; there is no fundamental value it represents. As a currency, it has no governmental backing, and while it's possible to trade in currencies, the profit lies in the trade, and the various differing rates of exchange, NOT in the underlying currencies themselves. No one holds currency expecting deflation to make them better off.
That said, every agile process needs to be treated for what it is; maybe a decent starting place, and probably a collection of good ideas for the context it grew out of, but not directly transferable; the whole point of a retro (the one meeting that the agile manifesto actually stipulates) is to modify the process for the team.
I.e., "fixed possible race condition where..." is a patch.
It may be that a consumer relied on a particular bug when developing, yes, and that fixing it now 'breaks' their application, but that's a definite minority, and why you communicate out the fixes (and for auto-adopting patch releases, you ideally still have automatic tests to validate).
The point is that most patch upgrades can just be run through a test suite and accepted. That may still lead to breakages, something that seemed minor and non-breaking to the developer could instead be breaking for a given user, but the point of semver is to convey actionable meaning and intent, which it does.
-You- said "But the actor formulation is too awkward for all but Erlang-specific use-cases". I was simply commenting that it's not awkward at all, for all sorts of use cases that aren't Erlang specific. Perhaps you'd like to define your terms better if you want to avoid people saying "hey, that statement as it comes across is flawed". Maybe you meant Erlang isn't the right tool to generalize to all use cases - no one would disagree. Maybe you meant what it sounds like, it's too awkward to use except for certain degenerate cases, in which case I strongly disagree; it's quite easy, and switching back to running N isolated units of execution on < N threads, and sharing memory between them, feels like a chore. Or maybe you meant something else entirely.
Maybe if you don't want to "get dragged into" a conversation on something...don't mention it on a public forum with such a badly worded statement?
Err? I mean, it requires rethinking a bunch of the lessons you learn when concurrency is hard and expensive and to be minimized, sure. But when concurrency is easy and cheap and to be embraced, a bunch of things become a lot easier and more natural to write.
My go to example, from a production system, was a complicated task scheduling system (with user and hardware interrupts to handle). Sure, we could have written it using threads and a priority queue or something...instead we just had one Erlang process per task, with interrupts routed to that process as messages (and linked timer processes that fired messages to those processes for the scheduled stuff, essentially just another type of interrupt/message). Super simple to write, super simple to reason about, never had any sort of race condition or locking issues, across years of development and production use.
Go has a couple of deviations; channels aren't queues unless you are careful to size them > the number of things you'll ever put in them (else the thing trying to put something on a channel deadlocks; you can of course timeout on it, but it presents tight coupling in that case, the goroutine sending has to care about the state of the thing receiving), goroutines aren't dedicated to channels (that is, there is an m-n relationship between channels and goroutines which can lead to a lot of incidental complexity), and, you can see what is on a channel if you have a breakpoint, but that assumes you can get the code to break inside of something containing a reference to the channel.
So what a person is saying when they say non-binary can vary, and is also quite personal. Which is another reason to use the pronouns they provide (so you can respectfully refer to them using the categorization they provide), and to recognize that what is going on with their genitals, their chromosomes, etc, is not relevant to you.
But that said, what is super normalized is referring to others by their pronouns. "Becky? Oh she's..." etc. Providing pronouns in a place you don't need them avoids awkwardness, mislabeling, and normalizes it to where it's safe to ask for your preferred ones. I.e., "Hi, I'm Becky; my pronouns are she/her" makes it safe for those whose gender doesn't match what they present (or is ambiguous) to clarify how they wish to be identified, and is easy to roll with even for those who "aren't woke" or whathaveyou, whereas "Hi, I'm Becky; I'm a woman" would have no beneficial effect (it doesn't break the binary, since "non-binary" is still calling out the otherness from what is expected, and it also invites challenge by those against transness, i.e., exactly what we see GOP bills doing, demanding examination of a girl's privates and etc), and would likely cause you to be stared at like you're an alien for most situations.
That's kind of the point of using them though. The goal is to -stop- saying "you either fit into this gender binary, or you are 'other'".
It's kinda like normalizing the use of "partner" instead of "husband/wife" even for the straight married people; it helps normalize relationships that fall outside of monogamous, state recognized marriage, and doesn't force gender definitions (what if you're in a committed relationship, or married, to an NB person?) or force releasing sexuality just to indicate you're in a relationship (i.e., the person maybe doesn't want the fact they're gay to come up in this setting).
Providing your own pronouns, even if you're cisgendered, is a form of allyship; you're normalizing it, and helping create space for those whose pronouns don't match how they present to provide theirs.
Those particular pronouns may imply being a woman (I don't know enough to venture an opinion there; certainly I've seen people use combinations of pronouns such as "she/them" that don't make such an implication straightforward), but calling out the pronouns she uses to identify herself seems like a perfectly natural response to correct someone using the wrong pronouns, and not some sort of 'gotcha' to differentiate someone being trans (doubly when it's not at all apparent she's trans), especially when the person in question...identified themselves with those pronouns.
You'll have to learn a few when you start. That's okay. What you're feeling as senioritis is basically "I've been doing this same shit for the past 4+ years", and by this point, even in a 'new' class, it feels largely the same, and it's a bump on the road to the outcome you want, and no longer interesting.
Remember how you felt as a freshman though? Coming in when you knew nothing/comparatively little, and having to actually learn something, everything ahead was just one big mess of possibilities?
Well...that's what getting a job offer for the first time is. For about 4-6 months. After that, most of the time, the rose tinted glasses come off and you realize "oh. I know what I'm doing at this point. I've learned what I need to learn. And there's not really anything left except for me to come in, work toward a known outcome, and then go home". Companies don't adopt new technologies if they can avoid it. They don't care about you learning new things. They just want you producing, so they can capture the value you generate and pay you a part of it. What's left to learn is the business domain and the specific combination of decisions others made in the past that you now have to navigate.
Which, if you have a rich enough life outside of work, the job isn't too demanding, and are paid enough to be comfortable, can be fine for some people. The feelings of security a predictable, well paid job provides can fund what they actually care about in life. For others, it feels like they're spinning their wheels on the activity they spend the majority of their time on and they want something else.
How you, personally, respond, is going to be something you figure out as you go. And it can change. I was a lot more "I need fulfillment from my job" when I was younger; now I just need a good enough paycheck and enough freedom in hours and such (WFH is a must) to be able to do the stuff I actually care about and find value in.
So my advice is don't worry too much about it. Mentally prepare for the process of applying all over the place and potentially not getting an offer for a while, but once you get something you'll almost assuredly be excited and eager to prove yourself, and you can start figuring out what is important to you.
If they have a personal (outgoing) mailbox that they are putting just the one piece of mail into, the mail person can skim over it, see the marker, and make decisions.
If it's a post box that is filled with a bunch of people's outgoing mail, no postal worker is going to read over it that way. Further, if you've blacked out the 'to' address with a marker (as I do), and written 'Return to Sender', they then are faced with either returning it to sender...or treating it as a dead letter that is undeliverable. They won't do the latter if there is a sender they can return it to, ergo...back it goes.
Give the vendor a heads up so the engineers can sleep.
First, most tech companies provide -paid- paternity leave. Which was my point. The burden on most companies isn't the pay for that period of time, it's the loss of capacity.
Second, the companies that object to that loss of capacity often either misunderstand the nature of the work, or have built their teams without any slack and so have set themselves up for failure. In the former, the teams are fine with the person going out even though management doesn't like it; in the latter they aren't, which is why legally mandated parental leave is so important, since otherwise, as we've seen, a badly run company will make it so you can't take time off.
Third, parental leave tends not to affect multiple members of a team at once. PTO and UTO can. Having too open a policy can lead to half a team being gone for a month, in such a way context doesn't transfer well and actually costs the team a whole month, which will have a lot more effect on productivity than one person being gone for a a couple of months. Obviously you can still have a policy that allows people to do it, but it requires thoughtfulness on the part of someone to ensure it still works out. Again, pulling from example, the big pushback I had to having a person formally reduce their hours by 20% is "what happens if multiple people on the team ask for that?" and that's also why it's easier and less risky to the business to have the person take a day off every week, paid. It means that it can be more easily managed if others taking simultaneous time off is a problem, since pay isn't involved (i.e., you can ask the individual to return to 100% hours until everyone else is done with their vacation, say, and then return to 80%, without having their pay also having to seesaw, which is a *process*)
Even as a manager, it's easier for me to let someone have one day off a week PTO, with a wink and a nod, than it is to formally get someone to work 80% hours. And that barely is perceptible to upper leadership.
That said, the situation you describe gets solved by the org adopting a retro itself. The team lead raises the broader issues up at a retro with other stakeholders/higher level management/etc, who -can- fix it.
People get so caught up in the process trappings of "agile" they miss the point.
If you mean recession, as defined by two consecutive quarters of dropping GDP - if GDP drops, stock markets drop. Not sure the directionality there, but the two are usually part and parcel.
If stock prices drop, it's a great time for acquisitions if you're sitting on cash.
I suspect any time stock markets drop sufficiently, you'll see increased M&A activity, regardless of whether it is prolonged enough to count as a recession.
Feels like an arbitrary distinction to what I said. "Efficiency" is an axis that doesn't make sense when the scale and scope are massively different, for all the reasons mentioned above.
>> We know that's a bad idea because the experiment has been run
So many issues with this. First, your claim is "Efficiency is about benefit per dollar, and governments are really really bad a(t) that"; you make a claim about all governments. Cherry picking data points is not helping that claim; you have to show that government is never, and can never, be more efficient than private industry. I'm pointing out why even trying to make the comparison at national scale is difficult. Second, where has this example occurred? Again, I think your choice of data points is telling.
Food is actually a super interesting example where, again, the scale of the operation doesn't really make for direct comparison. Grocery stores are obviously the way consumers get access to food, but their stock happens via multiple wholesale distributors, who themselves are middle men between multiple suppliers. That is, while Ralphs/Kroger/King Soupers/etc may be as near a nationwide grocery store in the US as I'm aware of, they're stocked by Sysco, US Foods, etc (who are carrying multiple, sometimes even competing, brands), as well as sometimes specific distributors for a large enough company (Coke may have their own, for instance), and who transport product between warehouses using separate longhaul trucking companies, etc etc. There is a LOT of inefficiency involved in that, a lot of middle men collecting along the way, and as we saw during the pandemic, a lot of places the supply chain can break down. And you're comparing it to...what? Russia during peak communism? The closest the US has had is when the government got involved during WWII with rationing, and that actually worked really well, given the shortages we had.
Let's try going the other way, and scaling government down. I too will cherry pick some data - municipal broadband. Oh, wow, now we have something way more efficient than 'the free market', even without tax subsidies, in every market it exists in; so much so that the only way private industry can compete is via legislation to prevent municipal broadband from expanding.
That said, I don't think it's in any way related. The people expressing the least confidence in the US' system of voting are railing against mail in and late cast votes, things that are done on paper. Electronic votes would give you a count instantly, and could be easily summed and tallied; it's any delay caused by counting paper ballots, or confirm from paper audit trails, that has led to a particular political party undermining the integrity of the elections. That's -with- "pick only your top choice". Ranked choice isn't going to change that equation.
Maybe I should clarify, especially if English isn't your first language, saying something "isn't comparable" doesn't mean you literally can't compare them, but that doing so is unhelpful and misleading.