polygotdomain

>try stuff out and don't be afraid to break things. It's just software.

When I was taking 3dsMax in college, my professor said something very similar. If you want to try something, save a copy and try it. Nothing lost. I've learned quite a bit in both 3d modeling and programming by not being afraid to break things.

Unfortunately that's not really an option for most business software, and it's also not always very apparent what various functions in business software actually does (in terms of secondary implications). My first programming job was developing tools to ingest reports from various front of the house systems into back office accounting systems. I would have users sit down with me and go through what reports they used, what data they wanted, and pull the sources for that data from the system.

It's amazing how many users would not know how to do much of anything beyond clicking exactly where they expected to in order to do the half a dozen or so day to day functions they needed to perform, to the point of not knowing where individual reports where because they were all run at the end of the day as a report package rather than on demand. Even clicking on menu items to see what the options were would get people on edge. Running reports should be something that's an idempotent operation, but there would still be reluctance. That being said, there also were reports that would have implications when run as they would either close things for the day, or various counters would be reset.

That's a long way of saying "just break things" isn't really good advice for users. Fixing things takes time and skill, neither of which the user might have. "Breaking things" might have far more significant implications that just going back to your last saved file. It also implies that the user knows when things are "broken". The longer it goes that they don't realize things are "broken", the more likely there will be problems and the more work was likely lost. That's also assuming they realize things are "broken", which is a point some users may never get to.

>I've heard that theory but it still doesn't quite make sense to me.

At a high level commercial real estate valuation cares about the cash flows for the entire building (usually over 10 years) and a discount rate to get to a number on what the building is worth. When we see empty space, we think it's not making money, but all landlords assume that a space will be empty at some point and for some amount of time, so that's already baked into those cashflows.

Without getting into the specifics, you'll generally push out your assumptions on leasing that empty space rather than drop your price on cost of the space. Pushing out assumptions typically means taking a slight hit because the cashflows you were already expecting are just hitting the books a little later. Dropping the cost of the space generally decreases market value, so that makes all of the space in your building cheaper which has a much more significant impact on the cash flow for the entire building, rather than just one space.

The other significant factor is that landlords typically have significant upfront costs in base building improvements and free rent credits that they give to tenants. This means that there's a certain amount of time, generally a few years, where the landlord has paid out more money to the tenant than they've received. Landlords need to be confident that the tenant is going to be paying rent beyond that break even point, or else they've lost money in addition to losing out the ability to rent it to another tenant and any legal fees associated with evicting a tenant.

Between how valuations are structured and needing to hit that breakeven point with a new tenant, there are relatively few incentives for landlords to just "lease the space".

>>+ Economic mobility is significantly worse

>I don't think that is true. Do you have a cite.

https://www.brookings.edu/blog/up-front/2022/06/29/stuck-on-...

There's also studies out there that show where you were born/raised can have a significant impact on mobility

>>+ Stagnated wages relative to inflation for much more than 20+ years

>That's an odd way to say things aren't different from what they were 20 years ago.

That's not what I'm saying at all. I'm saying that wages have gone up at a lower rate than inflation, therefore leaving the majority of the working class with less buying power than they used to have.

>>+ Significantly more income inequality than 20+ years ago

>This is slightly true. Gini index when I was born was 38ish and now it's 40ish. So slightly worse but also because the rich have gotten richer. Not because the poor have gotten poorer in an absolute sense.

I think there's more than just the Gini index. Here's an interesting chart that shows the slight rise in Gini that you referenced, but combined with other measures that factor into income inequality. The data is only until 2015, but I doubt it's gotten any better since then.

https://www.chartbookofeconomicinequality.com/inequality-by-...

>>Health insurance costs that significantly outpace inflation

>Anyone talking about health insurance is just not remembering how it was. If words like "HMO" and "pre-existing condition" and "Lifetime maximum" don't send shivers down your spine then you're not correctly remembering how terrible it was. For all the flaws the US health care system has it's simply miles ahead of what it was pre-Obamacare.

I didn't say that health insurance isn't better than it was. All I'm saying is that costs have outpaced inflation. It doesn't matter because the US healthcare system is still a massive farce and simply exists to leach profits off the American public. Even those that make well into the 6 figures are just one accident or diagnosis away from being massively in debt or driven into destitution just to afford medical care.

I'm going to disagree that "the world is way better". Don't get me wrong, there's been progress, but there's also a lot of ways it's objectively worse.

+ Significantly more income inequality than 20+ years ago

+ Stagnated wages relative to inflation for much more than 20+ years

+ Economic mobility is significantly worse

+ The education system is in worse shape than 20+ years ago

+ Higher education is more costly, and no longer improves prospects of gainful employment nor additional earning potential

+ Health insurance costs that significantly outpace inflation

+ Kids today will be living under a surveillance state from day 1

Yes, technology has advanced, and some social issues have made progress, but others have had significant setbacks (rollback of Roe v Wade, uptick in far right ideologies).

> E.g., "blue is totally the wrong color for that."

That's a little of what I was getting at with some of the points above. Tons of criticism is just plain subjective. How do you evaluate the validity of someone else's subjective decision? The ultimate answer is that you can't if your response to it is to flip the table and leave the room.

>There is an issue with some people who are just not structurally fit for that sort of thing, where the slightest criticism can make them collapse into a heap of self-loathing and depression.

I agree, but I think that in and of itself is a bit of a different problem. A key aspect of the modern human condition is being able to deal with criticism. If the slightest bit of it will "make you collapse" then that's a strong indication that you need some professional help to learn how to deal and process things.

>Discretion and discernment are important so that you don't break a fellow human. So the flip side is that being a part of critique juries is also training in how to give criticism, which is an important skill in and of itself.

I don't disagree that teaching people how to criticize will help have that criticism be better structured, less aggressive, and more constructive overall, but the reality is that we can't expect everyone to have "the proper training". There absolutely were jurors that I had that were more about tearing you down than trying to help improve. Dealing with those people was a learning process in and of themselves.

>And programmers tend to spend a lot of time up in their heads. And they tend to be rather blunt about their opinions. Getting some time in the reviewer and reviewee seat is useful.

This points to the social nature of giving and receiving criticism. There needs to be emotional awareness from both perspectives. Programmers, as a generalization, tend to be more anti-social than other professions. A key aspect of social interactions is empathy; being able to see things from others' perspectives. When I look back at some of poorest delivered criticisms or responses to criticisms I've experienced in my professional career, they've come from the most anti-social developers.

Bluntness can have two interpretations, being straight to the point and/or not going into details. "This is poorly structured" is blunt, but doesn't attack or make things personal. "This is crap" is just as blunt, but has a far more negative connotation and interpretation to it. Neither is all that great of a criticism if they're not expanded on or explained.

>"Anti-fragile attitude" when it comes to criticism is not built by tolerance. Quite the opposite actually.

I agree with your overall statement, but I think the specific point above could be misinterpreted in a nonconstructive way. What it seems like you're trying to say is that we shouldn't just be learning how to deal with criticism by tuning it out or building up defense mechanisms against it. That I agree with. However, another interpretation that could be implied from your statement is that one should not be seeking out criticism, which is not good.

What I think OP is getting at is that learning to process criticism comes by experiencing criticism over and over again. Some of the worst responses I've seen to criticism have come from those who constantly make concerted efforts to avoid it. Understanding that you are not the sum of your output is important, but it's really hard to remember that when you're right in the thick of it. Being able to control your emotions and thoughts within that moment come from having experiencing those moments over and over again.

The point of criticism is to learn and improve, but in order for that to happen one has to be able to actually hear and process the criticism being offered. One needs to get past the emotional response to criticism in order for that to happen. The two big pieces of that are decoupling the value of what we're being criticized on from our inherent self worth, AND being able to control our emotions in the moment. The latter is really only done by having enough exposure to it, and that's the "anti-fragility" component.

On the "anti-fragile" aspect of things, I studied Architecture in college and grad school (buildings, not software/system architecture) before transitioning to programming and the entire education model is built around dozens of critiques over the course of the semester. We don't have final presentations, they're Juries. Each semester culminated in working your ass off for weeks, pulling all nighters for days on end, then presenting whatever drawings and models you had to a panel of jurors who were assuredly going to rip you a new one. They weren't intentionally being mean, but you're a student, and there's plenty to pick apart as there's never enough time to think and do everything. Regardless of how good my projects were, after those final juries were done, I always felt like I'd gotten a heavy dose of criticism.

Going through that process over and over again has been incredibly helpful in my professional life, even though most of the criticism I receive is rarely structured like those juries. The first thing I learned is that it's rarely useful to try and refute or respond to the criticism directly in the moment. If that's your instinct, then chances are you aren't fully thinking through the criticism and responding from a more emotional state, which is not good. The key is to try and actually listen (rather than "shutting down"), remember the key points to process later, and to let the person offering the criticism know that you've acknowledged it.

Second is to realize that nothing is perfect. There is always room for improvement, things that you couldn't foresee, and things you simply didn't have time for. Obviously, the bigger those things are the more concerned you should be, but as your work becomes more and more refined, the criticisms become about smaller and smaller aspects of whatever you've done. The goal is not to get zero criticisms of your work, but to have the criticism that you do receive be about less and less important elements.

Third is that someone will always have something to say. Interpret that in a number of ways. If you're getting a code review, you're soliciting someone's opinion or your development process is dictating it. People will come up with criticism because that's what's being asked of them, and even if it's "perfect", responding with nothing makes it seem like they're not doing what they should. People like to offer criticism because it makes them feel important; they see a "flaw" you didn't, even if they don't really understand the totality of what you did. And while its disappointing to say, some people will criticize you for personal reasons, be it against you directly or because they think they stand to gain something by doing it.

Ultimately, you have to decide what is worth listening to and what is not. If nothing is ever worth listening to, then that's something that's likely more on you than the criticism you're receiving. It's also very tempting to discount criticism from certain sources because of past issues with that source. Process each criticism from them in the same way, regardless of the past, because you never know when they actually might have something worth listening to.

It all depends how the leases are written and who's responsible for the solar panels. Since the panels could potentially be the landlord's, warehouse tenant's, or a third party roof tenant's, it could be written up in a variety of ways. The Landloard is going to be the most concerned about it as A) it could potentially effect the base building, and/or B) tenants may take issue with a leak. Chances are the repair would be rolled up into CAM (Common Area Maintenace) charges, which are generally dispersed to the tenant based on an arrangement in the lease (typically % of cost based on % of sq ft of the property).

The best chance for it to be handled some other way is if the warehouse tenant and the solar tenant are one in the same. The landlord will still likely be involved, but chances are the tenant will do the repair.

>I suspect that those who grow up as social media “natives” will have some social norms that protect them somewhat, whereas many of those who came of age pre-social media will not have learned the social norms that can protect them.

Agreed. A lot of older generations fall for a lot of satire and comment on things as if they're 1 on 1 with you instead of realizing that it's a public forum. However, a lot of younger generations are incredibly aware that everything they do and say could potentially be public or go viral. That brings a whole host of other problems and challenges with it.

The ultimate problem is every incentive goes against a "healthy" social media. Companies don't want a "healthy" social media as they're focused on engagement, screen time, content, and advertisers. Most of the primitive portions of our brains don't want "healthy" social media either, as it craves the rush of more likes and followers. I don't think that the logical, self-aware portions of our psyche are going to change the direction of how things are going.

New Zealand is incredibly beautiful, I just wish I could go back. The US healthcare system suits the rich quite well. The companies that the rich people work for tend to offer significantly better plans that cover a lot of what you hear a bunch of people complain about. High earners and C-suite execs typically get offered a different plan then the rest of the proletariat do. They can cover the out of pocket costs just fine, and cover the elective procedures themselves. They generally have access to better doctors as well just based on location, flexibility with working hours, plans that will pay for them, and/or it being easier to handle the out of pocket costs.

Universal healthcare actually means a downgrade in the experience for these people, which is one of the reasons why they don't want it. Yea, they might want to make sure that people don't get sent to the poor house just because they came down with some random disease, but god forbid they have to wait their turn behind some plebe in the doctors office.

The replies here are close, but not exactly right. Zip codes largely map to individual post offices. Once mail gets to the correct post office, then it will get sorted into routes for delivery.

The reason why the distinction of post offices is important is that zip codes are not required to follow state boundaries (technically, zip codes aren't an area, but a list of delivery points). In fact, there are a lot more than you'd think that span across state lines, so there may actually be a mismatch between the state for your address and the state for the post office your mail is delivered by.

Not only are their PO Box only zip codes, but there are also zip codes that are associated with various business and government entities. In those cases the USPS literally doesn't care what you put for the address bc they will hand over all the mail addressed to that zip code to the entity and let them handle it.

The most famous example of this is the zip code 12345, which is actually for GE in Schenectady, NY.

This is true. As others have pointed out, all PO Boxes can be appended to a 5 digit zip to get to the box (e.g. ZIP-BOX#) No city or state should be needed (zip covers that), nor name (not needed for mail in general, but might cause other issues).

The US Postal System actually uses a full 11 digit number to identify a "Delivery Point". The "+4" after a zip code is basically a subroute within that zip code, but there are two numbers after that you don't really see that will identify the full delivery point, which is basically a mailbox. The USPS tracks a number of things at this delivery point level, including whether a secondary address is needed, if they are currently delivering to that address, or if service is temporarily suspended (potentially due to a natural disaster or road outage in the case of a more remote rural address).

I'd really love to see if just a full 11 digit number is enough to get mail delivered to my house. I guess I could try, as it's easier than you'd think to find out your code

You sound pretty close to me to be honest. When my wife and I go on a long trip it makes it easy to put on in the car. I tend to have it on when I'm working around the house during the weekend. For me it fills in a void of wanting to listen to something more than background music, but not wanting to choose more than a genre that fits my mood. For whatever reasons all of the algorithmic "stations" that I've had on other services either deviate too much from what I originally wanted, or are too narrow and don't get enough variety.

I think we've gotten into this weird spot where tech companies are almost goading each other into layoffs. I don't doubt that there was some overexpansion during COVID, but it seems to have shifted. Tech companies have signaled to the market that staffing numbers were too high (regardless of profitability), and that investors want to see them brought back down. These layoffs don't really seem to be an indication of company strength, and the golden parachutes that a lot of these companies are offering can't really be that helpful to the bottom line (5mo + unused PTO + benefits in this case for Spotify). It's just playing things up for a certain audience while the general public is largely distracted.

>What some people may not realize is that "executive suites" have been around forever, however they were never looked at as a "hypergrowth" SV/hot startup.

Regus was/is the main player in that space, and it certainly wasn't startup territory at all. WeWork took a very different angle to it, as they were looking to capture small startups that wanted to be in a kind of "incubator" type set up. The buildouts and the target clientele were different concepts than had been tried in that market. I'm not saying that WeWork didn't/doesn't have issues, or that the idea was profitable at it's core, but it was a different take and seen as quite "disruptive".

>They've also apparently had a business model where they don't own the spaces, so the underlying landlords can squeeze them at any time.

WeWork leases have single purpose entities on nearly all their leases with few guarantees from WeWork the company. That basically means that the landlord is holding nothing next to nothing. In fact, it's WeWork that could back out of a lease pretty easily leaving the landlord with little recourse, not the landlords that could squeeze them. And even then, the only squeeze the landlords have would be when renewing a lease, and landlords don't have the upper-hand there at all right now.

One of the things that WeWork did was buy up significant chunks of square footage in well located buildings that had trouble filling that square footage, then WeWork offloaded a lot of the initial capital expenditure for the buildouts onto the landlord. Some of these leases had break even points for the landlord outside of 5 years, which is quite long for leases that big.

So if WeWork goes under or backs out of a given lease, the landlord is left with a huge amount of space, that they likely can't lease, and will likely take a significant amount of capital to either A) break it up, or B) make it amenable for another company to lease out. That means that the landlords are likely going to give WeWork as long a leash as possible, because they don't want that space back.

The writing is on the wall though, and WeWork has been going downhill for years now. It was arguable whether it was a good business model before the pandemic, but I can't imagine it making sense in a post-pandemic world.

While WeWork clearly were squandering SV investor money, don't underestimate how much real estate fat cats made out on these deals. They got these seemingly sweetheart WeWork leases on the books, marked up valuations for the remaining space in the building, and sold the dream to other investment firms to make out like bandits.

I certainly think that role is missing, but I don't think it's at a role of a staff engineer. In my experience, _The Therapist_ has the ear of a lot of senior people, and more importantly their trust. They understand the technical issues as well as the business problems, but more importantly understand the personalities and politics of the organization. These are the people who can convince people that if they give up a little, then they can get a lot in return. They generally tame strong-arm managers that are just looking for more headcount or more prominent projects that tend to drown out other projects or initiatives that are genuinely needed.

Those people are an absolute necessity, and I think it's very tough for someone to be effective in that role if they don't have a solid technical understanding, but I also don't think that an engineer has the clout to wrangle people the way a _therapist_ needs to. In a small organization, maybe, but at a decent size, mid-sized company and larger it will need to be someone working on the business side, not development or IT operations

I'm certainly more in this camp of not looking to switch, but in the past I've moved jobs in the 2-3 year range. Right now, I feel that I'm well compensated, at a place that offers great work-life balance, is tackling interesting problems, and just lets me do my job. Part of the reason I'm not interested in leaving is that this is the first place that really has all four of those things, and given it took me 9-ish years to land at a place like this, there's going to have to be a significant jump in salary (like an extra 25-35%) to get me to move because of factors beyond my bottom line take home pay.

That being said, I've "hopped" jobs earlier in my career, but more in the 2-3 year window rather than 6-8 months. I can only imagine what I'd be making if I was still at the first two places I worked. It'd probably be 2/3rds of what I'm making now at best.

I don't think it's as clear as "always stay" or "always hop". At a certain point in your career, hopping may be looked at as a liability, and staying in a position that's a bad fit or doesn't advance your career doesn't make sense. Ultimately a job and your career is more about numbers, and you've got to optimize for more than just that. Understand when you are leaving money on the table, and when you've got something worth sticking around for.

I had worked at smaller shops, then took what I thought was going to be a next big step at a company who's mascot is a reptile. Friction EVERYWHERE. The TLDR was that I left after 5 months and that company was the most unhappy I've been in my career.

When I started, I had a single monitor machine that didn't have Visual Studio installed. I was told I'd have to wait till the next budget cycle for a second monitor. I didn't get Visual Studio installed for 3 WEEKS and no one seemed to care. I'm not sure why they thought it was fine for a six figure developer to basically be sitting idle for 3 weeks, but that attitude was basically the norm.

When I actually got coding, everything was road blocks. Policies and procedures everywhere. No one had time to explain anything. Everything had to be submitted through a ticketing system. It was just bad. Daily standups where I just made up BS because they'd barely given me anything to work on, and no one seemed to care.

The thing was that when I looked forward at my team lead, my manager, etc., who in theory would've been my next steps at the company I'd have to jump through ridiculous hoops just to get into those positions, and they all fundamentally had very little power. They were still at the bottom tier middle managers, and the BS policies, procedures, and technology decisions all got handed down from managers above them.

I couldn't deal with the environment, but from my coworkers who were there, I got the sense from them that they just accepted things. Progress was slow, jump through the hoops you're told to jump through, but by in large, it was steady well paying work that they could just check out at the end of the day. No harm in that, but it just felt like my career would just stagnate there, and I'd find it very hard to get out once I got comfortable with it. I planned on sticking around till 6 months, then looking. I wound up starting to reply back to recruiters earlier and was out in 5. Best decision I made was leaving.

I don't know why I find articles like this so annoying, but in accordance with Betteridge's law of headlines[0], the answer is no.

>Here’s the thing: If it hadn’t been <form>, it would have been another element—maybe one with a more accurate name, like <money-vacuum> or <robot-food> or <privacy-destroyer>.

This sums up pretty much the entire article in that A) the form tag allowing the web to be a two-way street for data probably would've been filled by another feature, and B) the author is really lamenting about the tracking/anti-privacy/dark pattern world that the web has become. I completely understand the frustration, but it's certainly not an element's fault, but the fault of all the various players who have evolved the web over 25-30ish years. It might be more beneficial to actually explore that than blaming an html element.

>The web was born to distribute information on computers, but the technology industry can never leave well enough alone.

That's called progress.

FWIW, I'd probably say XMLHttpRequest "caused more damage" than the form tag, but I also don't think it's all that worthy of a discussion.

[0] - https://en.wikipedia.org/wiki/Betteridge%27s_law_of_headline...

I agree that shelter(housing) prices increasing at 5% is not good, but when we're seeing inflation of 8.5% there's something else that's driving things up.

When you look at just the energy component of the CPI you'll notice that it began to outpace inflation in March of 2021 at 13.2% and has fluctuated between 25% and 32% since them. The previous chart on that page that breaks down the most recent month's inflation between food, energy, and all other items you see that food is in-line with inflation, energy is crazy, and other items are at 6.5%.

https://www.bls.gov/charts/consumer-price-index/consumer-pri...

We have a lot of problems going on right now, but why the energy sector has been experiencing crazy inflation for the last year might be more of a factor that the other things grabbing the headlines right now.

> Code doesn't deteriorate

Your specific codebase may not, but the frameworks, OS, and hardware it's running on evolves and changes overtime. Software practices change over time as we find more effective ways (hopefully) to do things. If you expect to let code sit and come back to it in 10 years and think that everything will be hunky-dory, I've got a bridge to sell you.

> It is the mismatch between our domain model and how our users think about the domain.

...but the business domain continues to evolve. A new client comes in, another software system is onboarded, the organization is restructured, new regulations are inacted that need compliance. I think the idea that technical debt only exists because we didn't "perfectly match" the domain and our model at the start is a bit short sighted.

> But at some point it started to mean that we had to upgrade our dependencies, that's tech debt, or this kludge that I threw in, that's tech debt

The broadest definition of technical debt that I've seen boils down to technical challenges that impede developer progress that does not have direct concern to the business. One of the reasons that I think that it frames a purely technical issue (i.e how the debt got there and how it needs to be resolved) with something that the business wants (rapid development). While there are a multitude of challenges in resolving technical debt, a significant one is getting the business to allocate time to resolve it. In order to do so, there needs to be some value for the business, not just the developers.

>More broadly, anything that we no longer care for is tech debt. And that's where you really get this idea that it is deteriorating, that's more a measure of our own patience deteriorating, especially as we never seem to have time for the refactors we want.

If you're defining technical debt as "anything you don't like", then you don't have a real understanding of your technical debt. One of the key pieces in the broad definition above is that the debt "impedes developer progress". Old code bases have plenty of things that modern developers don't like, but it works and it doesn't impact the application overall. It's old, but we barely touch it, so it's age or style is of little consequence. If you don't know what technical issues are causing signficant issues for your team or your codebase, then there's little justification for "paying it off". If you can sell the business on it, then you tend to get into long refactoring projects that provide little value than inflating developer egos.

They come up in practice a LOT actually. The challenge with curve/curve intersections boils down to tolerances. Visualize two circles with different radii, with the smaller circle inside the larger circle, that meet at a single point. When understanding those circles as primitives (centerpoint, radius) finding that intersection point is relatively trivial. However when simply thinking of these as arbitrary curves, we have a condition where those curves are getting progressively closer together, but it's really hard to tell if they exactly touch, and exactly where.

Of course at a point we'll get close enough to consider there to be some intersection, but do we get "close enough" for a single point? for a portion of each of the curves? Does the result change with the scale of the circles? Does it scale when the relative radius between the circles changes? Making those kinds of judgement calls within the algorithms is really a challenge, but makes a huge difference when building a geometry library and for usability (for other developers, and end users). Knowing your use cases may be helpful in determining what's the right approach for these situations.

My degrees are not in CS related fields at all (both in Architecture). I know that just being able to "check the box" has gotten me in the door. Only a small handful of the places I've interviewed with over the last 10+ years have cared that my degrees weren't in CS. In some cases I've corrected them, "no, building architecture, not software architecture", and no one's seemed to care.

While you don't have to have a degree to get into tech, having one certainly makes things easier

> There are approximately 93 million adults (civilian noninstitutional population) that don't work

Which includes retired people, people with disabilities who can't work, stay at home spouses (who arguably are working, but not for an employer), students. Those reasons have nothing to do with avoiding "politics and culture imposed on them by managerial talent"

> maybe some study on this portion of the population's reason for not working would be useful

See above

I just want to say that the comments about public transport in DC are spot on. It's incredibly hard to design a system that can actually get people where they need to be because A) people are so spread out, B) everyone is going to different places, C) there is minimal incentive to make public transit better because costs completely outweigh potential ridership.

It's sad, but without a car in the DC area, your options are very minimal and you pretty much have to live in the city.

I lived in the DC area for nearly 30 years and moved out right as Covid hit, and have tried to use public transit at various points in my adult life. Unless you live super close to a metro stop and/or need to go to a metro stop the system will barely work for you, and even then you'll be hamstrung with where you can go and how long it will take you to get there.

What about SELECT * WITHOUT {columns_you_do_not_want} FROM...

EXCEPT is already a keyword and has is used for set-based operations, so I don't think it's good to overload it.

While it does seem like a scam, I think the "following through" aspect was doomed from a business perspective. Credit, and therefore rates, is based on a consumer's history, not their knowledge. While poor financial decisions can certainly be chalked up to not knowing any better, knowledge of what you should do goes out the door when there's bills to pay and not enough money to cover them all.

Remember, LendUp is likely just a middle man and marketer; it's facilitating the loan, not doing the actual underwriting (and therefore rate setting). Following through would mean exposing the business to risk that customers, in spite of climbing their made up ladder, still made payments. Considering the other shady stuff that this thread is talking about, it doesn't surprise me that they didn't choose to take on that risk.

Of course the irony in all of this is that the very thing that would've prevented customers from making the right choice even though they were gaining financial knowledge is the loans that LendUp was handing out. I wonder if the pitfalls of payday loans was part of that knowledge track. I doubt it.

Sagas are definitely what OP should look into here. Quite frankly, transactions are a bit of a fools errand beyond a certain scale, yet are still treated with some absolute purity from the days of Cobb. If you have multiple changes that need to be made, the "all or nothing" approach makes it really simple to deal with and manage.

Sagas are about recognizing the individual changes that are necessary, and dealing with the success or failure of them at a higher level. This is complicated though as the developer and the business now need to have a specific conversation around what happens if A succeeds and B fails? Does A need to get "rolled back"? Does B need to be retried? Does C need to wait until B succeeds before proceeding? That all brings in a level of complexity and the only answer is to manage and use the appropriate patterns and tools to do so. Wanting to go back to a land where you can just wrap it all in a transaction so that you get one nice boolean indicating success at the end is quite frankly just naïve. The real world doesn't work like that.

Having sat in data presentations from credit card companies, the extent of the data that credit card companies have is incredibly detailed. For those customers who they don't make money on from interest and fees alone, I would imagine that data more than covers the difference. These customer are still VERY desirable from a data perspective.

While there are legitimate tracking concerns, the data the credit card companies capture and disseminate is incredibly fascinating. You've got spending data, layered with market segments, layered with location data (both on the cardholder and the business side), and even time of day. Overlay all that with very accessible data from the Census or ESRI, and they can really tell a significant story of how money flows through the modern economy. This is what's feeding the internal fraud detection engines (which have gotten a lot better), but there are also private institutions that are more than willing to pay the credit cards a hefty sum to get access to all this data.