Yes and people try to put Lebron side by side with Jordan but he's not even the best Laker in my opinion. I'd pick 3 Lakers ahead of him if I was doing an all-time draft.
1,324 karma · joined November 11, 2013
In most cases, sisters going a different route would be the smarter play. And even in this case, it could have gone really wrong if the creep had a weapon and was aggressive or killed someone after speeding off. But that didn't happen and the stalking didn't escalate. So sometimes... courage and strength mixed with some recklessness is the best resolution. And I don't think this guy should be dragged across the coals for saying his sister was lucky to have three brothers. This IS a 3 brother type of solution to a problem.
On the aggregate, you know I'm right. Not saying there can't be a pack of three sisters that would respond similarly, but it would be a rare exception. Do I need to update my statement to say "499 of 500 sister pairs would not have gone this route" and "Nor would 499 in 500 women allow their sisters to go vigilante for her".
Do we really need to preface every statement that has a rare exception? If so, I'm not sure we can talk about much. We couldn't even say that humans have 5 fingers on each hand because not everyone does.
There are real differences between the sexes. I don't get all sensitive about that fact.
Or get all sensitive when someone who gets a positive resolution and risked their safety for their sister doesn't write in a professionally sensitive, west coast manner. The guy expressed his story in a rather tame macho manner and people are getting upset after his victory protecting his sister lol.
Three sisters would not have gone this route and the police would likely have done nothing until after the stalking had escalated further. Also, 1 brother might not have attempted this either, especially considering the guy was a large creep and smart enough to wear a mask.
Nor would a woman allow her sisters to go vigilante for her.
These guys were quite restrained. I know families with 3 or more brothers and at least 1 sister. And for them, at best, the stalker would not be walking for awhile.
Brothers can be protective, and enraged and activated in a different way. Not saying that's the best route for this situation or others. But in many cases, it IS the best solution. Stalking can escalate very quickly.
Everyone that is like "oh they were so dumb" likely 1) doesn't understand that brother/sister dynamic, 2) hasn't had much experience with the police and/or 3) has never been violated by a stalker/home intruder/etc or very close with someone who has.
I've helped get someone arrested and charged before. I had video of the man breaking into my neighbor's car. I confronted him with my neighbor in real-time. We got him out of the car and questioned him and checked to see if anything was stolen or damaged. We called the cops, they eventually showed up after the guy left. Asked me some questions and they tried to downplay it as a likely homeless person looking for place to nap which it clearly wasn't as I saw him going through the car.
I'm talking with the cops and I see the man down the street. He never left the neighborhood. I tell the cops "there he is"! They keep asking me questions and I'm confused at their inaction. Yes he didn't take anything. But he entered the vehicle, was trespassing and going through the glovebox. Go question him!
They respond slowly and head the man's way. They do nothing. Later that night, guy comes back and is seen by the neighbor from the car incident. He sees him attempt to break into the neighbors garage. Then succeeds in breaking into the house. Cops come and take it more serious. They clear the house and arrest the guy later down the street. I submitted evidence from the earlier incident and he was charged.
Without any resolution, these criminals escalate.
It's easy to say - don't confront criminals, call the police, it's their job and they're trained. But that's what people who haven't experienced these things or had to rely on the police say.
Welcome to entrepreneurship. This is a good sign from my perspective. At some point you will figure out how to worry about and ideate for your app/business and still learn to enjoy vacations.
> Don’t get me wrong, I love working on DisplayBuddy and it's incredibly fulfilling to wake up to messages from my users about how useful the app is for them, but it often gets really tight with my job, and I live with this constant feeling that I could do more for DisplayBuddy than I’m currently doing.
You'll probably always have that feeling. I've built several successful businesses (service based, SaaS, marketplace). Still get that feeling on occasion. I sold my interest in one business because that feeling was too strong! It was like shedding a "job" which was tough but refreshing. For another SaaS, I reinvested profits in paying for dev work that I could have done myself. But saving my time was important. You have to just triage your time and revisit that share regularly. And accept that your time is all you have, and it is limited. Do not give up steady income though; I think it is best to move more time to your app biz as revenue grows. It will be harder to build a new business with the pressure and anxiety from giving up that income.
> What've I've lately realised is that building a business is hard, even harder when you have a full time job.
For my marketplace, to get it going, I had to spend a lot of nights and weekends doing nothing but programming as I had a good full time job. Friends and family and SO didn't understand it. My significant other thought I was wasting my time and was not really supportive. When it became successful they were then supportive LOL. It can be lonely but you need to push through. Most aren't willing to do what's needed to start and build a successful business.
> What've I've lately realised is that building a business is hard, even harder when you have a full time job. No matter how much influencers on TikTok and Instagram talk about starting a side hustle for “passive” income, to be honest there’s nothing passive about any income.
I had two truly passive income businesses (kept one). It can happen. Usually takes a few years of hard work though to get it to that place. And you'll probably have to hire with the profits to remove you from the equation and be truly passive.
Personally, I'd re-invest profits into acquisition and try to build a profitable campaign. And then invest a good chunk of income from the day job into scaling it. I wouldn't quit your day job to try and keep building new features.
If people are paying for it, can you scale it now?
I built a marketplace. Then we got to $1k/mo recurring. Then reinvested money into more acquisition. And it added $1k/mo recurring revenue almost every month like clockwork until it hit almost $40k/mo recurring. We delayed taking profits until we could turn it into a small business. If you want side income, it's fine to take profits early, but that's probably the extent of how big it will be.
Attempt to scale now and reinvest all earnings and use your steady income if needed to figure out an acquisition campaign that will provide ROI. It's unlikely that quitting your day job and continuing to build new feature will be the best use of your time and money, even though it feels like it might.
When Eric Ripert, the chef of Le Bernardin, renovated the kitchens of his Manhattan apartment and Hamptons beach house, he nixed the gas, instead choosing sleekly powerful induction cooktops by Miele and Gaggenau. “After two days, I was in love,” Mr. Ripert said. “It’s so much more precise than watching a flame. You can really focus on your cooking and pay attention to what’s inside the pan, not what’s underneath it.”
He hasn’t yet converted his restaurant kitchens.
“It would be a big expense to replace stoves that still work well, but, if the gas stove broke, I’d consider it,” he said, adding that he thought his cooks would adapt quickly. “After a few days, they’d all love it.” That is just what happened with the chef Justin Lee of Fat Choy in Manhattan, although he wasn’t expecting it.
When he opened the Chinatown restaurant in September 2020, there was no gas hookup. “Most restaurants wouldn’t open without gas, but we couldn’t wait,” he said, “so we had to find our way with electric.” It was a lot easier than he had anticipated, and he’s come to prefer induction for its consistency at high and low temperatures.
On the gentlest setting, he confits garlic and other ingredients for his XO sauce without having to watch it. “You can walk away, and it won’t ever burn,” he said.
“For us, it’s a workhorse,” he said. “It can boil water in minutes, which, for cooking noodles, is significantly faster than gas.”
Mr. Lee discovered other advantages over the summer: His kitchen did not get as ferociously hot as it would have with a gas stove, and the absence of open flames also led to a decrease in burns.
I know plenty of people that think they can cook with their nice gas stoves and don't have a grill or smoker or know what sous vide is.
If I went to one's house and they had neither method available, I could easily say "they don't cook". And it would be a more fair statement than "induction are for people who don't cook".
Not very fair though.
I know people that can cook with just a skillet on any heat source. Ones that only use a grill or smoker. Ones that mostly use an oven. Some that mostly use slow cookers.
Plenty of people worldwide that can cook and don't give a shit about ANY type of oven or stovetop style or technology.
My wife has the same issue with hot coffee which drives me a little nuts. She uses a normal mug most of the time. Because she isn't certified in coffee temp detection like I am; she waits and waits, gets distracted, and eventually it becomes too cold. So she reheats it in the microwave, usually to the point where it's too hot, and that cycle continues after it gets too cold again. She's probably reheated coffee in the microwave up to 4-5 times a day at times. It's hilarious and ridiculous. As an engineer, admittedly, I enjoy the hilarity so much I'm not sure if I care about it being resolved!
The issue is two-fold:
1) She lets the coffee hit the outermost parts of her lips and subjects herself to getting destroyed by the high temp lol. I don't understand why this is so difficult for people. Your outermost lips are more sensitive. Don't do that. You don't attack hot coffee like it's a fine bourbon. Also you can feel the temp and steam to know not to even attempt based on your preference and tolerance.
2) She isn't sitting at a desk consistently like most of us. She's everywhere in the house and then leaves, and her coffee intake isn't a priority like many of us.
If I put her coffee in a stainless steel mug with a lid, then it takes too long to cool to her temp. She leaves the lid off to cool and then forgets about returning to it in time. And she doesn't end up drinking the coffee because it becomes too cool. So now she would have to transfer to a microwaveable mug to reheat and start that cycle so she doesn't even bother. If I'm prepping her a roadie coffee, I must pour it, leave the lid off for a period of time and then place it back on so she will attempt drinking it in time in the car to commit to it. If it's too hot, she will more than likely just abandon it and not check back in before we reach our destination.
I got her an Ember mug so she can read the actual temp and control it. But it's not dishwasher safe of course. So she doesn't tend to use it. And from the fresh brewed carafe to the Ember still is too hot, unless the lid is off for some time like the stainless steel mug, lol.
The ideal mug for her would thus be an Ember mug that is dishwasher safe and thus have some sort of twist mechanism to disconnect the battery and status/controls portion from the core mug function. And probably have a vent mechanism on the lid (maybe a double pop on the Ember lid to vent more?) to more quickly get the temp down from initial temp, as the heated mug portion can ensure the set temp is hit anyway.
Someone please build that and save me! Or don't, and I'll enjoy the entertainment derived from the struggle. :)
That's the best strategy to prevent the masses from investigating further. You shouldn't label something like you did if you haven't done your research.
> legally literate enough to understand the court opinion you attached
I think you are literate enough to read and understand the key part I included in quotes for you, from the ruling which completely refutes your prior position, and attitude, with hard evidence. It's as clear as day!!!
> McKinsey is the root of all evil and secretly influences governments and companies
Well they've had a lot of bad looks, especially with their role with Purdue Pharma and OxyContin. Their former alumni was CEO of Enron which they consulted for 15 years. "But up until the very end, it was promoting Enron’s business model, especially its off-balance sheet accounting practice, and encouraging others to follow suit." They "recommended ICE save money on food served to the detainees or send the migrants to facilities in rural areas to cut back on expenditure" They agreed to pay $100M to South African government in a corruption scandal [1]
Last year, one of their private investment funds agreed to pay $18M to settle an SEC issue regarding insider information gleaned from the corporate consulting business. [2] They have a hedge fund which makes bets on the advice they sell.
Here's another one regarding McKinsey & their investment office (MIO) and Valeant Pharmaceuticals which buys out other drugmakers and jacks up prices. "Four top Valeant officials, including Mr. Pearson, were McKinsey veterans, and the firm was advising Valeant on drug prices and acquisitions." Later in the article, "a federal judge in Virginia last month reopened a coal-company bankruptcy case after learning that McKinsey had not disclosed, as required by law, that it was also among the company’s secured creditors, through MIO". Further down: "An investigation requested by the oversight board found that MIO had five direct and indirect investments in Puerto Rico’s debt while McKinsey advised the island". [3]
So you start to look at all these big corporate consulting firms and if you are being unbiased, you can see it's systemic. They wield a lot of power and influence. They get their alumni and friends placed in government and huge companies and then make deals and institute their strategies to make a ton of money.
> The truth is much more mundane and boring though.
Yes from your position it would be. You aren't the one placing CEOs, making kick back deals, getting involved with foreign governments and corruption, writing strategy for Encron, ICE or OxyContin, investing in company government debt on one side and advising on it the other. The system isn't designed for people like you to be included in that part of the business.
In my opinion, people fall into one of these buckets - pawn, shill, or informed. In an information age, isn't it remarkable that most STILL fall into the pawn category?
[1] https://www.trtworld.com/magazine/the-many-times-mckinsey-ha...
[2] https://www.nbcnews.com/business/corporations/investment-fun...
[3] New York Times - https://archive.ph/ZSDBH
One example in the last few years: BCG and NCR Corporation.
"It is undisputed that Mr. Benjamin, as an officer of NCR, owed NCR a fiduciary duty that includes a duty of loyalty. The Counterclaims allege sufficient facts to show that Mr. Benjamin breached that duty by entering into a secret agreement with BCG to promote and expedite his candidacy for CEO. The Counterclaims further allege sufficient facts to show that BCG worked with Mr. Benjamin to negotiate a one-sided contract, and remove and replace employees who opposed adoption of the contract, and that BCG advocated for Mr. Benjamin’s promotion to CEO in hopes that he would award BCG with a discretionary bonus." [1]
[1] https://law.justia.com/cases/federal/district-courts/new-yor...
This was also many years ago, where we had - let's build apps mainly with HTML/CSS and sprinkle in some JS framework sugar and dynamic capability on the client side. Ok, Angular/Ember and then Vue worked VERY well. We made a hop from jQuery to more sophistication but still easy to read and develop compelling and maintainable, interactive frontends. Then we did SPAs which worked well for a few things but were vastly oversold.
React came along which was nice, but early on, it was not needed for many projects even though many devs started implementing it.
We had a demand for more rich web apps and they got MORE complex and dynamic. We decided, maybe we shouldn't sprinkle in all these sugary JS framework tags and corresponding logic in our HTML.
Then we had a ton more university-educated programmers entering the frontend scene that used to just be comprised of a megaton of jQuery heroes (no offense, they got shit done and went out to lunch most days while the more sophisticated frontend devs went hardcore on semantic HTML/CSS, VanillaJS, spending countless hours on browser bugs and QA cycles and using divs to render tabular data for fun/ego?).
We also got more interest in React from non full-time frontend devs (ex: fullstack and even backend devs) that were like, hey building frontend doesn't suck like it used to in VanillaJS! Count me in!
Coupled with the Stackoverflow copy-paste dev era and the nightmarish third party library upgrade scenarios... now we have a TON of shitty React codebases and people have, and will, migrate away from them. This cycle I'm describing gives rise to challengers like Svelte.
I like React (and React Native), but the many codebases I've inherited have not been good. In fact, I've probably inherited as many decent React codebases as decent jQuery codebases but what does that say? Not much because I haven't inherited many good examples of either.
I'll still choose inheriting a shitty React project over a shitty jQuery project any day. Great progress has been made (although you could argue much of the progress was in cross-browser standards and advancements in browser technology).
But I still feel like the truth that everything that is old becomes new again cannot be avoided.
And in that - it's web components and/or more HTML sprinkled JS frameworks for the win to me. I haven't used Svelte, although some on my team like it, but it looks like a return to a get-shit-done dynamic websites/apps framework.
And I'll likely still continue using React for larger, more rich and dynamic apps that require a larger dev team.
You can watch this old video where he brags about he subverted SEC laws and regulations at a hedge fund and fomented stories in the media and told lies because it was a lucrative game:
If cooking with oil, everything cooked with safflower oil tastes better to me.
With a deer your best course of action is to try and stop but mow it over if necessary.
With a person swerving on a bike or moped, you may not be able to stop in time and most likely swerve.
That are broken all the time. This means nothing. It's a cost of doing business to many corporations and organizations and the corporate veil and some fines usually absolves everyone.
> People will just try to do their job, and if they don't see an explicit (i.e. written) mandate somewhere that they need to prevent nuclear power plants from being built, then they won't do it.
This isn't the case in discussing anything of significance.
A few examples: the 2008 crisis, automakers and emissions, Wells Fargo fake account scandal, DuPont toxic chemical leak and cover up, Monsanto dumping into the ocean.
People are easily manipulated and most of the time they know what they are doing is wrong. The more people that are involved or the more their superiors are enabling it, the easier it is for them to do it.
I'm not informed enough on the topic at hand, but your opening argument is baseless.
Not saying that's a good thing, but supply constraints and build costs are here to stay for the major metros. Interest rates and remote work being indefinite should help with prices and create buying opportunities for some in larger cities.
But it's better to play the real estate game by being pragmatic about what you can afford where (buy elsewhere and move, invest elsewhere before buying a primary, etc) and how to get to the next level instead of feeling entitled.
I accepted the reality years ago and did 2 investment properties in other cities before buying my primary in the city I wanted to live in.
It sucks to have to do that and take so long to buy a primary, but the game is about capital. And real estate is one of the few beautiful assets in a sea of bullshit you either 1) don't need or 2) doesn't provide any joy.
I know a lot of people on here have contempt for real estate investing but if you aren't in it, IMO, you are depriving yourself and your family of the absolute easiest way to make money and build wealth. And there are plenty of places where you don't need a ton of cash to get started.
As a simple example, you may send an entity to be updated and then the frontend makes a decision to say, you changed this value, then alter this other value so that the update request has the values we want (ie: one property may need to be blanked if another property has a certain value). Your frontend has logic it shouldn't and you should be enforcing your data on the backend anyway.
However, I was referring more to a situation where a frontend dev has an API request that it can work with but needs in another format or structure. And then logic is added to that data based on the user inputs or to simply do client side aggregations. Maybe it takes the user's chosen store location and filters out the out of stock products from the API on the client side.
Instead of sending the inputs to the API and have the API's logic handle it and provide you with the dumb data for your frontend to render - here are the products you should render; don't think about anything. So your frontend isn't growing into this brittle thing that is doing too much and is more likely to end up with dupe code as multiple frontend devs get tasked with new but similar components and recreate the wheel.
> In any case, Graphql may have capabilities that look like they help keep business logic in the backend, but it doesn't stop programmers from putting business logic in the front end anyway.
I'd argue that it in many cases it promotes frontend devs adding more business logic. Because your devs can query for whatever they want on the schema, transform the data, do whatever logic in the components instead of relying on an API contract for said data.
It means there's really no thought into: what does this client actually need?
So the frontend devs don't have to involve a backend dev or team to get most of their tasks done, which may be a great thing for their situation.
But the business logic gets pushed more and more into the frontend and gets bloated and brittle.
UI using REST server tends to centralize the API client, call the endpoint(s), and make that available to all components.
UI using GraphQL often has frontend devs doing their components, running their ad-hoc queries for "just what they need". More network calls.
So overfetching like with REST tends to lead to less network calls unless you are extra diligent on a GraphQL project.
In order to prevent the frontend from doing that, I have to be sure to enforce usage of another layer. Devs need to use fragments and relay and not just fire off their own ad-hoc graphql queries.
Which is interesting, and thanks for sharing. I would move toward implementing this on any graphql project, especially an inherited, network chatty graphql project.
But I still prefer keeping the frontend really dumb and just sending the data it needs, that has been identified.
Most of the time a REST or REST like API endpoint is sufficient, and it doesn't matter if you overfetch some data, you avoid extra graphql layers (now enforcing fragments/relay, extra resolvers, potential performance issues, multiple schemas and access concerns).
I like GraphQL but it seems like a lot of overhead for little gain for many projects. One project has 3 different graphql schemas. Can't be exposing the whole tree to every user type.
I can see why frontend devs would like it though (need this data, probably already available), but a REST or REST-like API is more enjoyable for me unless I'm building a framework or on top of a framework or a client that needs ultimate ad-hoc query ability where it really shines to me.
I wrote some custom resolvers yesterday to extend graphql on a Cart entity and it works well for that.
I used some existing repositories the backend already had but was not yet available on the GraphQL side.
All the resolvers can lead to extra performance issues of course, but I suppose you can adjust your schema as needed and tune it with more efficient queries or code (ex: move some properties to nested and resolve with a single tuned query)
Simple example:
1. header component - dev queries user for first name to do a welcome message.
2. sidebar component - another dev does a query for first/last/avatar/profile/etc.
Your app sends 2 network calls. Certainly it doesn't have to, but I've seen this chattiness get implemented.
So you avoided overfetching of data like official REST APIs but now you have more network calls.
One component just needs 2 pieces of data = graphql call. Another needs more data and they're doing another similar call. And so on. You got query flexibility but now you are drowning in additional network requests because it's so easy for your team to just "query for what they want".
To me, if your application doesn't need to have the flexibility in querying, then it isn't worth it. Is your dataset so large you don't wish to overfetch data (you can do that without graphql anyway)? Do you need ad-hoc querying in your UIs?
Think about your data, how you will need to expose it and expose it.
Ex: you are building on top of third party ecommerce software.
You need to add more data to the Cart entity because you have a custom module/plugin/etc. You write a graphql resolver, extend the schema and the Cart type. You can use the existing built-in endpoint to query your new data.
So it's nice to be able to extend a framework and data access in that manner.
In general though, I do prefer REST APIs and then writing custom endpoints if I need data for a specific UI, like for visualizations.