I recently got a letter from the bank that owns my tesla loan, informing me that I can buy the car at the end of the loan. Previously that wasn't an option. Plus, it was for $28k (at the end of a 3 year loan).
Got another letter trying to get me to buy a new 3 with 0% interest for 60 months.
I've heard many reports of GLP-1 reducing addiction behavior, but more like alcohol and gambling. Never heard anyone reporting on social media reduction. IMHO it looks like it should, I just haven't seen any data / anecdotes.
Oof just watched a video from the Pear.ai guys and was happy to hear they made it into YC. I don't know much about the project, but they seem like good people.
"What we're doing isn't technically illegal so stop talking about it" isn't generally a phrase used by what I'd call good people, but we'll agree to disagree.
The beauty of forking/open source is the ability to contribute back to the original project or take over an abandoned project. In this case, the original project Continue.dev isn't abandoned and actually has more traction/commits than the PearAI fork. But what PearAI did not do is a traditional fork. They took the commit history, re-branded everything to PearAI, pushed it up to their own repo, and claimed that the contributors of VSCode & Continue were their own contributors on Twitter.
That's not the spirit of open source. I'm sure the authors of Continue.dev did not intend for their work to be used this way, even if the license is permissive of it.
I'm not sure how to parse this, and one possibility is worse than the other.
Did they go through and alter each commit in the history, making it look as if the committer was talking about brand B instead of brand A at the time they made the commit?
Or did they clone the commit history, and add commits to rebrand, while keeping the historical commits intact?
That's because there's literally no such thing. It's a licensing choice, not a seance. If you don't want people to use your code, license it correctly.
There's a difference between forking to make a OSS project better and forking to create a clone just for the sake of VC funding that doesn't trickle down back to the original code.
Even if it's allowable by the permissive license of the original code, it's not a net positive for OSS.
I think the assumption people are making is that the YC selection team are dumb idiots, and don't understand that all the founders of that project did was fork an open source project and ask them for some money.
(I'm not saying this is what happened; I know nothing about this project. I am saying this seems like the assumption the author of the article and some people in this thread are making. I bet that's not what happened, but if YC is actually full of dumb idiots who do zero due diligence whatsoever, then I guess I have to agree with the article's thesis.)
Pretty nice guy, too. Back in the early-mid 90s I was a teenager and got on some kind of David Brin fan site (this may have been on Prodigy it was so long ago), where the man himself would sometimes reply. He once responded to a message I posted, and it just about made my year.
A few months ago I started a job where I inherited a JS code base that is around 250,000 lines. It was one big class, with several sub classes, that did everything. Some files were 30k lines long.
No frameworks, no reactivity. If you click a button, you had to update everything on the screen with event listeners manually.
Took the guy years to write it. It's like a monk got locked in a cell for years with a basic book of javascript.
I started by refactoring into web components, because I had to do it piecemeal. It's been a big help, and I've cut 50k lines of code so far. But the real point was to just learn everything the old code was doing before I start a rewrite.
> I started by refactoring into web components, because I had to do it piecemeal.
Yes. The key to making an old and arcane code base understandable to yourself, is to refactor one small part of it at a time. That you're redoing with web components is just one way that would achieve this. I applaud you for not just throwing everything it away and starting anew.
On risk of this approach is that you get some way though and then move on to some other project, and someone else comes along and inherits the old project and starts refactoring in their own style, and so now you have an old arcane code base in three different styles... it still beats a rewrite of a 250.000 line code base in one go.
Seconded. I used Personal Capital for a while but the links to my accounts broke frequently. Moved to Monarch and paid for it and its way less of a hassle.
Flashbacks to high school CS back in the 90s. Started with basic then moved on to this. I understand now they use Java to teach kids, and I can't imagine trying to learn to code with that language.
Awhile back I was on project A that got absorbed by the management of project B. Project b mandated that all engineers wore pagers. A guy on project A decided he didn't want to. The job he was hired for didn't require it when he was hired, and if the pager went off, he'd just have to call someone on project B anyway.
Good for that guy, sounds like he got out of a bad place. I'd absolutely quit if someone tried to force me to be on-call without an enormous pay raise (e.g. at least local minimum wage for every hour I have to be responsive to calls, regardless of whether a call actually comes in).
Maybe I'm naive, but doesn't it depend a lot on the situation? If I'm being told to be on-call for a system I don't know and can't debug, then I would set the expectation that I'm going to reduce my availability for other work while I learn this new-to-me system to the point where I feel confident that I can debug prod issues (to the degree that any of us can debug prod issues, anyway), understand the major risks to that system and common operations, etc. If they say, "sorry, you have to be on-call for this new thing and also keep working 100% on something else", then I fully agree - bad situation, incompetent management, time to go. But needing someone to be on-call for a system isn't a bad sign - in a different viewpoint, it's a good sign that someone is anticipating a future problem and actively planning ahead.
The issue is the change in workload. If I'm going from "40 hour work week" to "40 hour work week plus on-call" then you need to compensate me for the increased workload. If you're not going to increase my compensation, then I'm not going to agree to increase my workload.
I agree that that would be fair, but we should also acknowledge that usually an IC doesn't actually have any leverage in this situation, although this depends on your location and particular employment situation. Typically (and maybe this is changing) a US software developer is employed overtime-exempt at-will, right? So, you can ask for this, but as per your employment agreement, they can absolutely demand this of you and let you go if you don't agree. I'm not arguing that is the way that it _should_ be, just that to my knowledge that's the way it usually is.
Edit - you say you're willing to quit if they don't agree, so I guess you're up for this possibility. More power to you!
Yup. There's a hojillion jobs out there, and I'm a good engineer. I can find another one if my current one decides to piss me off. I value work/home separation very, very highly. No work stuff goes on my personal devices, and I leave my laptop at the office. You want me on-call, you're gonna be paying me for it :)
But regardless, outside of rare exceptional circumstances (sometimes there's a deadline and shit's gotta get done), I'd recommend anyone to tell their employer to pound sand if they ask for more work from you than you agreed to.
Basically, yes, although I imagine that specific scenario rarely happens in practice. That's why I'm saying the guy in the OP got out of a bad situation: his workload increased without any benefit to him, and he got out of that abusive relationship.
In the US, the vast majority of these positions are salaried. You get $X/year to perform the duties you're expected to. Because we don't have unions and 99.9% of people are not expert negotiators, "the duties you're expected to" are never actually defined. That means your employer is incentivized to stack as many duties on as they can, until they approach your breaking point. So long as they don't break you, it's free work for them. Employers regularly abuse inexperienced people and desperate people, who don't have the confidence or financial wiggle room to say "no." I applaud those who normalize saying "no," and encourage forming unions so there's a group of experts in the room whose job it is to fight back against this kind of abuse.
We also have salaried positions where the time unit is a day (this is the typical cases for white collar jobs). You have to work for 217 or 218 days every year and the normal day is 8 hours.
If you are on call then you get paid x% more during that tile and it cannot be more than y hours per month (I do not remember the values). You also have to have at least 11 hours of rest between the days.
The duties are not clearly defined either (despite continuous ideas on how to measure them, which consistently fail year after year) which is a good thing: it is not easy to have this as a reason to fire you (you have to have a good reason to fire in France).
We value work/personal life proportions a lot, but we also are very serious when it comes to work. It is only from the outside that it looks like we are constantly on vacation or having lunch (this is true for some parts of the workforce, to the point of becoming a stereotype).
> If you are on call then you get paid x% more during that tile and it cannot be more than y hours per month
This is required by law? Yeah we definitely don't have something like that in the US (except for life-endangering roles like doctors, truckers, airplane pilots, etc). It's up to each individual to negotiate their acceptable amount of on-call time and compensation.
(Just to be clear, "being on-call" doesn't mean you are actively working, just that you agree to be responsive if someone reaches out to you about a problem. That could take 15 minutes or 4 hours to resolve, but if no one calls then you are not actually working during the on-call time.)
OTOH, I walked into the office at about 9:30AM one day and found a group of people, including the project manager, waiting for me, clearly irritated. PM asked why I didn't respond to my pager (this was about 20 years ago), and I told him that in six months, it had never gone off, so I stopped wearing it. And that was that.
My guess is that they wanted a reason to fire your guy anyway, and he gave them one.
Got another letter trying to get me to buy a new 3 with 0% interest for 60 months.
They're definitely under pressure.