bmhin

That is my prediction as well. It's unfortunate as we'll enter the unindexed web where all that helpful content you can find by appending "reddit" onto any search will no longer be getting produced. All of it hidden in discords, out of sight.

Who knows, maybe there will be an easy way to get stuff published out to the proper web. Things like community FAQs or guides that would be broadly of use. I think the loss of the conversations about minutiae will just be a fact though if that migration happens.

I mean, taxes are a real thing and you have to pay them based on where you (the employee) live and do work. In the US for state income tax, it's a confusing mix of both lived location and worked location in various amounts by governments with a "claim" and with plenty of exceptions to go around. Consulting companies have had to deal with it forever (and states have "handled" forever), because you live in Miami, doing work for a company based in LA, and you travel to your client in NYC for 3 days a week for the whole year (60% of your income "generated" there). This is now a complicated Florida, New York, California scenario.

So the choice isn't Big Brother companies who want to know where you are at all times and respectful companies who allow you to get your work done how you want. It's between companies who are following the applicable tax laws or those who are not. A company that is structurally opting to not follow laws seems untenable. A company is a legal construct in many ways. Whether or not the employee can commit something like tax fraud is perhaps a less interesting question, because, yeah, you can probably cheat on your taxes.

Elixir was one of the few languages I saw in companies (albeit, infrequently) that wasn't like Java, C#, Python, or JS (Scala here and there). Was always curious about it as perhaps something that could be reasonably pitched as having some nominal uptake.

Pure anecdata there also. Literally just ones I have personally seen on clients or heard about from coworkers.

> Maybe it bothers me that using ask as a noun is passive voice, like the request is disembodied. I'm not asking, the ask just appeared there!

I think the latter is the key to corpspeak as a whole and it has ramifications beyond just stripped emotion. It always erases causality from the communication. Everything is just "appearing" with no thought to how or why things are the way they are. Businesses are really, really bad about asking "Why?" at times and this kind of language reinforces that. There is no "Why?", things just materialize into existence and are and you (have to) deal with them.

The emotion part makes sense, because often the answer to a "Why?" is because someone has made a mistake or done something dumb and it provides cover. However, it also leads to rote, wasteful, inefficient behaviors. It doesn't necessitate that there is no reason "why" things are being done, but it does mean that a reason isn't required either.

"Why are we having this sync meeting?" "Well, to sync of course!"

> After the 10th "SMS Service" is created, no one knows what any of them do

Yeah, that's always been my concern. "Descriptive" is a very precarious strategy because it takes very little to go from maybe descriptive to generic and confusing. Multiple variations of the same "descriptive" name are another common issue. I see often a lot of very similar named services that are the bane of naming in my opinion. Someone made a User Management Layer and then someone else made a Person Data Service and next thing you know you see a User Data Service and now it's just confusing. Factor in that each one of those things gets called the UML, PDS, and UDS and it just gets worse (did I mention they each connect to the Person/User Data Store/base).

It's hard to think about because I feel like when they work I don't think about them at all. And when they don't work I think about and stew about them excessively. So the good cases I forget about completely and the bad ones are stuck in my memory.

SDLC is a frequent pain point. Often non-existent or hacky, e.g. export this giant XML doc and you can re-import it if needed. If any step requires clicking on buttons it generally leads to that kinda pain. Almost fundamentally, if I need to go copy paste or click on something for the product to work, I won't be able to automate it. Hence, it needs to be completely automatable. Similarly, if the config / set up / customization one does is obfuscated after it is specified it can be a headache to try to work around. Also maybe not the end of the world but many also decide to "handle" version control on your behalf, which can maybe be fine, but will also then almost by definition be divorced for your usual approach and processes.

On the last question, I think this boils down to how well can one operate at the surface level. It is not uncommon in these low code apps to have to understand in detail what is happening below the hood. So yeah, the top layer abstraction might be very simple in practice, but if working with it frequently necessitates me knowing how that abstraction will be executing it leads to an extra layer of complexity that has not abstracted anything. In a way they often function like a second language going through a translator: if I have to be considering the Spanish version the no-code cares about and also how and what it will be translated to in English under the hood, it's just extra confusing for perhaps little gain. What makes it extra pernicious is you can be operating entirely off intuition for what that under the hood English really is, rather than some open spec you can at least drill into.

Worst part here is I feel like this is really often something that will come with using the product. Often the use cases documented and sold really seem like all you'll need.

It likely depends on the broad culture behind it. If someone sends a "Hey" and then is a fast enough typer and immediately can get the context going as I look, that's not a huge deal. Sometimes it's an opening to a more synchronous conversation and then it's less of a big deal because we're gonna be going back and forth with quick messages. Part of the irritation is you can still just always open a message with "Hey, something something something" and keep it all in one.

The problem is people who send a lone "Hey" and then... nothing.

Some will wait for you to say respond with your own greeting (which is all you can respond with because you don't know what you're even talking about yet). Other's don't wait but do delay and the initial greeting was just a warning or something that a "real" message is incoming. I've had folks ping me the "Hey" and then I respond immediately with a "Hey" (to stave off the above "permission to speak" people) and they get distracted and say nothing else for 10 minutes.

Some will message you while you're busy, so you don't respond to their "Hi". You then respond to it a half hour later with the only thing you can say to that contextless message: "Hey, what's up?". Only now maybe they are busy, and they respond again to you a half hour after that. You've had a conversation "opening" for an hour for what purpose?

Some will immediately begin typing out a gigantic block of text and you are sitting there waiting while the "XX is typing" message unwaveringly sits at the bottom. Bonus points here if they were editing and revising as they went and you get an eight word sentence after what appeared to be 3 minutes of continuous typing.

Some will do all of those things so you end up having your attention taken multiple times for minutes at a time for a message that realistically might take you a couple seconds to read, parse, and respond to if it had been sent all at once.

Even more relevant to the question: it introduces complexity that harms citizen's basic needs by putting in place knowledge inequities. You can make the tax code as complicated as you want, and the hyper wealthy will still be able to pay for people to understand it and squeeze out every drop of value because the absolute amount of money in play makes it feasible. Spending $200k to "save" $1million is a good deal. That's maybe a couple full time employees. If you wanted to save $100 instead, throwing $20 at is isn't gonna get you anything.

So all those people who can't "subcontract" their way through the complexity with specialists are left to their own devices. And they don't have the time or expertise to navigate it themselves. So the tests and checks and processes and discoverability weeds out deserving people constantly just in the hopes of preventing some "undeservings" from having access.

It'd be like writing an algorithm and every branch of logic you put in you have to do a random roll and throw an exception some percentage of the time. Each new branch compounding to filter more and more while also costing more and more to facilitate. But that execution reality is ignored so that the pure logic can be focused on in a vacuum.

It's all like the opposite of Blackstone's ratio regarding crime that "It is better that ten guilty persons escape than that one innocent suffer". Social programs are designed such that they would often rather let ten innocent people suffer than one guilty person benefit.

Choice is the real thing though more than actual value add. I feel like I see it less now, but recall seeing how vendors would only accept certain cards and not others (frequently, not American Express) which was as far as I know stemming mostly from higher fees they didn't want to pay. Similarly, places would not accept credit cards at all if they had razor margins and didn't want to eat the fee. I still know of a few places like that, often with an ATM near by so the customer can pay a fee if they are caught unaware.

That was the thing though, a business could decline to accept particular cards or cards at all and still perform transactions. That "opportunity" has generally not extended to the app store world in a practical way. If you want to play, they had their cut and customers and vendors didn't have a whole lot of say in what was reasonable. There is no simple default transaction (like cash) that they were trying to out compete.

Survivor in 2000, American Idol in 2002, The Bachelor in 2002, The Amazing Race in 2001. That always felt to me like when they found their "reality game show" formula that was then replicated off of those base archetypes into the entire rest of the genre. So mid-aughts does feel about right for when the explosion happened.

The more pure reality shows like original Real World or COPS seem more like ancestors than anything and didn't spawn as much of an immediate copy cat proliferation. Real World if anything morphed to be more like those later incarnations.

> First, a lot of this is in the abstract and the difficult part is how it gets applied in any given situation.

A lot of these "genre" of books tend to fall into this camp for me. They feel like trying to hold onto sand: sure in the initial moment you have it grasped, but it just as quickly falls away and there's nothing really there to hold onto.

A classic example is one from this list, "Delusional self-confidence causes you to resist change". If you drill into this, it seems like non-delusional self-confidence is what lets you enact control and not simply let life happen to you. In the other case, delusional self-confidence means you are refusing to accept reality and the changes you can't effect. It might be then reformed to "Rational self-confidence causes you to accept change".

What is the take away then? Seems like it's "Don't be delusional / be rational". Which, sure, but that is basically inapplicable and a near truism. If you knew you were in either camp you don't need any of this advice. "Know when you're being rational and when you're being delusional" feels like the general place a lot of stuff like this reduces down to in the end.

I do like the simple compliment / feedback accepting with a "Thank you" one as it's fairly easy to actually do. You will get thrown occasionally when someone wants to dig after the fact however.

I've used Slack competitor Flowdock in the past which did the more "elevated" approach to threads. Rather than "hide" them from the main branch of a channel, the main branch had every message in the top level and you could collapse to a thread view if you wanted to read it in isolation.

In my experience, the main problem here was that people regularly lost sight that a conversation even was in a thread. So they'd post their response unthreaded right in line. Now the people in the thread view can't see it, but if you were in the main channel it still looked just fine (after all they were one after the other). If it was a nascent threaded conversation (like 2 or so posts only), often the thread was just abandoned and everything was done top level. For bigger threads where you caught after the fact it was a threaded, people would either delete and repost or would just duplicate their post over into the thread again (which means it appears twice in the main channel). The worst offenders were people who refused to thread so even if it was humming along fine they'd just post their response inline always (and repeatedly).

Don't know if I have a particular point there other than both had tradeoffs. I do find that the Slack thread updates disappearing seems to be less frequent of an issue and the threading problems in the alternative were near constant. I think Slack's issue would be largely a nonissue if viewing a thread "subscribed" you to it so you could see updates without needing to post. Maybe reactions are a workaround too. It's fairly easy to unsubscribe if one's blowing you up. Subscribing to all threads regardless seems to reduce some of their usefulness and that's the current solution I believe.

White boarding. We had them everywhere and used them often. The big ones in conference rooms were good and pretty standard, but the tiny ones placed near the actual desks for just quick and slipshod thinking out loud type stuff is what I miss most. For the big group type things I find myself often just pre-diagramming things which is way less efficient, but works as I'd probably be the one drawing anyway.

And part of the problem is that I know there are tools and we've kinda sorta used them every now and then, but at my company at least we don't have a solid broadly used solution. It might be the part mentioned by others about the ever looming "return to office" plans that have lead to it being punted constantly rather than properly addressing the need some way. Part of me hopes that there can be some moment where remote is just accepted and we can take steps to making it work as well as possible (with things like tablets with a stylus distributed) rather than just carrying on in limbo.

So I guess broadly the hardest thing is about how we're still, nearly 2 years later, in a nonideal one foot in, one foot out approach to remote working.