The one thing AI has done really well is generate all the signals of "intelligence" that SV tech folks care about. It's verbose and meaningless, confidently-asserted bullshit wrapped in the right packaging. It's like a Markov chain generator with a Stanford degree.
That's not a great argument for it being impressive, though, which is the original remark in this thread.
A car that unpredictably explodes and kills all its occupants, but which can be made safe by installing a widget, is not impressive (or at least, not in a good way).
It's verbose because it was finetuned to be "helpful" (the way OpenAI sees it). You can fix it with a system prompt, or finetune the base model with the format you want. Same with grounding it with RAG. Sure if you take a vanilla LLM and make no effort to adapt it to your app's needs, it's going to have subpar results. At least, verbosity is not an inherent problem of LLMs, it's a specific issue of a specific finetune. Hallucinations are a real problem indeed. However, being wrong and being very confident about your answer is something LLMs share with humans. LLMs can already have value if they're wrong less often than the average human (and some benchmarks suggest so).
I would argue the biggest issue for talented musicians is economic inequality and the rapid increase in the cost of living. If you want to do music as a main job you need to survive on your partner's income or have generational wealth. There's just no room for someone who is talented to keep themselves afloat playing gigs without having 10 roommates and a day job.
The biggest issue for everyone is economic inequality. You could make the same point about an increasing number of mainstream jobs.
The underlying question is: what are the values of the culture? Predatory selfishness is thrilling [1] for the winners, but ultimately self-defeating - literally suicidal from a sustainability POV, physically and socially.
The neoliberal definition of "freedom" is exactly synonymous with predatory selfishness, so everything else can only suffer.
But it's not everyone's definition of freedom. Plenty of people have other motivations, and this economic model aggressively disenfranchises their values.
Hormonal birth control is extremely common and generally presents minor issues. This is a relatively uncommon anti-seizure drug that has extremely high risks of causing developmental issues in children.
Sure, if you compare anything to hormonal birth control it will be relatively uncommon - they hand that stuff out readily and even consider making it OTC. This antiseizure drug is still commonly prescribed in many countries.
"extremely high risks"
A 700% on a 1.6% base rate, right? How does that compare with cumulative risk increases for cancers or vascular issue with hormonal birthcontrol? For example, they see a 60% increase in cervical cancer risk alone. That's pretty significant too if it's not being disclosed for patients to make an informed decision.
Keep in mind, my argument was never that the risk of hormonal birth control were more than this drug or any other drug. My argument is that patients are still not informed of substantial risks that may not be as readily apparent as the minor issues that are more common.
While I agree that medical communication can and should be better, it’s worth pointing out that hormonal birth control also lowers the risk of endometrial, ovarian, and colorectal cancer by a similar amount according to cancer.gov (see: https://www.cancer.gov/about-cancer/causes-prevention/risk/h...).
So 35% of the Ute Nation's GDP vs 1.3% of the Phillipines. OP is clearly either uninformed or biased. Or just doesn't understand Tribal Sovereignty status in the US.
There is no "removing Hamas from Palestine". The only way to remove the desire of the Palestinian people for freedom is to remove the Palestinian people themselves. And that is what the IDF is trying to do.
In "The Population Bomb" (1968) Robert Ehrlich claimed that within 10 years there would be catastrophic famines because of exponential population growth.
A lot of people have blind faith in just extrapolating numbers out into the future with no context.
My read is that he was one of those early employees that is a huge pain to manage. They want to do what they think is fun and interesting and they have strong opinions about shit that is ultimately inconsequential. It's a nightmare to manage an IC who is friends with the CEO and doesn't think you're making the right choices. But ultimately they don't accept accountability for any decisions, they just move bop around and cause problems.
One tell-tale sign is endpoint security and using his own device. It's the kind of permissive cultural thing that does not scale because of compliance issues and developer productivity overhead. But it's very hard to wrench these long-time devs away from their preferred Linux distribution which requires conditional build stuff everywhere to support. Use a work computer for work, let them monitor the updates and stuff, as long as they're not using the webcam to record you who cares?
The database backup story - my guy you were on the database team. Backing up the databases is job 1. You can't just passive-voice away "oh there were no backups". But of course he's more interested in fighting about sharding architecture than actually keeping the site running day-to-day.
His big takeaway is that Gitlab didn't spend enough time on performance for their hosted offering which was a huge money loser. Just because he thinks performance stuff is fun to do, if the hosted offering is a money pit of course they're not throwing more resources at it. You have to make an actual business case for why your thing is more important and makes money more than another project. You don't just engineer in a vacuum for the fun of it.
Your read lines up with another point in the article that I found to be stated in strangely absolute terms:
> you need to be able to deploy your code fast, i.e. within at most an hour of pushing the changes to whatever branch/tag/thing you deploy from.
This sweeps under the rug all of the potential issues with fast deploys. I guess it depends on the product. I work on a managed database service, and one category of potential bug is that we accidentally delete or corrupt customer data. We have to be much more careful and can't just deploy what was submitted to mainline in the last hour without doing significant regression and performance testing.
But anyway essentially the main reason they give for fast deploys is:
> being able to see your changes live is nice because you actually get to see and make use of your work.
I think this is true. But, it lines up with this negative interpretation of this article. The author seems to prioritize themselves over the health of the product they're working on.
> It's a nightmare to manage an IC who is friends with the CEO and doesn't think you're making the right choices
Since I find this take harmful, let's rotate the scene: what if you have no business being in the manager's seat above that IC in the first place, and you are effectively being used as a tool by someone who is not the CEO, but, say, a newly-appointed CTO? What if you _are_ making the wrong choices? What if that IC is one of the few people in the org having the experience and the knowledge to tell you that you are? What if that IC is making the right calls and suggestions, but your implicit directive you got from the newly-appointed CTO is actually to manage that IC out "because they are such a pain for everyone"?
I have been on both ends of this situation and I do believe most scale-ups are _not_ doing a good job retaining and nurturing their early-stage staff+ ICs into their larger era. This has multiple reasons, but it does often feel like there is a lot of value to be had if just those staff+ ICs weren't so horribly mismanagemed. A hire-above-from-the-outside is prime example.
And if I sound bitter - let's just say I have experience being "that IC". It wasn't pretty, and no - I was not an asshole.
In every startup I've been in, there was undue deference to long-time ICs. They didn't normally stir up public fights with execs but they would openly undercut line managers and then move around in the org as people tried to stop being responsible for them.
It's not really clear what you do with a staff+ long-term IC. A lot of them don't want to manage or be involved in leadership, but they want to pull down a huge salary and just do work that is frankly replaceable by a senior eng.
To be clear I do believe there are levels of IC experience above staff, but being 21 and joining a startup doesn't make you a Principal Engineer just because you hung around until you're 30. Especially if you've only worked at that one startup.
> It's not really clear what you do with a staff+ long-term IC
Set clear expectations in the first place. "I want to run things my way here, I'm the new management and I don't like you" is not an expectation - and that's what I have observed happen all too often.
Sure, you could argue such people are needed only at the early stages of a company, and counterproductive when the company gets bigger. But I don't buy that. Why then are big companies asking all the time: "Oh, where's our internal startup spirit? How can we bring it back?" Right after firing the people who encapsulated that spirit, for being "hard to manage".
I think this trend to talk about startup practices in large orgs is more executive nostalgia and a complaint about all the processes put in place to catch mistakes that have been made before.
The same people as developers would be pursuing rewrites of rock-solid 20+ year mature software projects because there's a trendy framework.
Large organizations don't have 'startup spirit' because 'startup' companies fail. Employees of large mature orgs with 6000 employees didn't sign on to a company that's got a good chance of not existing next quarter. They're not taking massive risks and throwing halfbaked features into a brand new product with 1 client hoping to get bought by facebook or maybe an insurance company.
If those big companies are really complaining about not having startup spirit maybe they should provide an exit for the VCs and aquihire (briefly because the engineers will all leave asap) a startup!
Sometimes it is not even about the "startup spirit", but more like "why is it that we didn't do any projects of significance in the last year, and why is our incident rate 3x from what it was just 3 quarters ago, and why are all these migrations not finished yet?"
Because sometimes all they're after is for slideware on GenAI. The people they fired encapsulated a spirit of innovation that doesn't fit the operating model and therefore is of no value to them.
I can assure you that me being a pain to manage wasn't the problem, nor was it ever brought up. In fact, the only negative/improve-upon-this-thing kind of feedback I got once or twice was to adjust my communication style to be less blunt/harsh, something I agreed with and did end up improving upon.
I can also guarantee you that the work I did very much did good work instead of "cause problems". Feel free to ask anybody that worked at GitLab during the same time (or is still there) and see for yourself :)
> I didn't get along well with this manager,The resulting conflict lead to a "performance enablement plan"
Respectfully, in your post you literally say you got a new manager who PIPed you for being hard to work with. The whole tone of the article feels like rehashing old disagreements.
Respectfully, I didn't. I specifically wrote the following:
> I didn't get along well with this manager, The resulting conflict lead to a "performance enablement plan", a procedure meant to get things back on track before the need for a "performance improvement plan" (PIP). A PIP is meant to be used as a last attempt at improving the relationship between an employee, their work, and their employer.
Not getting along with someone doesn't imply or mean that a person is difficult to manage. Instead, it means there's simply friction between two people.
In this specific case, the main source of friction was that my messed up working hours resulted in me performing tasks later than expected (though still within any deadlines), though I recall those time frames not being well specified to begin with (i.e. it was more of an implicit assumption that X would be done by hour Y).
I believe I was also a little late for a meeting because I'd overslept. That's not good, but it certainly isn't a case of "Wow this person is so difficult", instead more of a case of "This person needs to get his schedule back together".
Either way, you seem to be interpreting the story in a way different from what's written down. I doubt I can change that, so I'm going to leave it at this comment.
how can you assure that? it seems like a classic self-fulfilling prophecy of arrogance.
changes bring some adjustment uncertainty, and sometimes it goes well, things get better, sometimes it gets worse. with enough time you'll draw a short stick. it sucks.
> how can you assure that? it seems like a classic self-fulfilling prophecy of arrogance.
Because colleagues have told me so, and the annual employee reviews were positive as well. In fact, outside the PEP the only actionable/to-improve feedback I got was essentially "Sometimes you can be a little harsh/blunt", which is vastly different from "this person is difficult to work with".
The dev who makes shit work and and tracks measures the ops gains / reduced headcount needs and reports their impact up the chain. Who also gives talks on how everyone can make their stuff run as simple as they do.
Do you think the American government can't already find Russian ships? America gets their ass beat consistently in unwinnable wars against guerilla armies, but in terms of identifying giant warships I think they're pretty capable.
I think it'd be more accurate to say the US consistently signs itself up for wars based on political or economic motivations with little intention of doing what would be needed to actually "win" the war.
Specifically, we either don't define metrics for success or we define completely unrealistic metrics. Worse, we go to war with no intention of destroying an enemy that has left us with no alternative other than to risk many, many human lives to stop them. We go for political wins at home, to claim ground in a geopolitical power struggle, or for natural resources.
Finding them is actually likely much less of a problem than listening in, though providing the Ukrainians with additional ways of finding and tracking their enemy without us directly providing intel does offer the US plausible deniability.
It never really has to be believable, it just needs to be enough that you can deny direct involvement in a specific attack. I have little patience for politics and which we didn't let pur world be run this way, but that's the way we do it.
Guerilla tactics just raise the cost of steamrolling an opponent to an unpalatable level, hiding among civilians, civilian infrastructure, etc. American loses these matchups not because they can't blockade a country, raze their farmlands and wait a few seasons while they all starve, but because fully eliminating and "winning" would be the worst possible choice.
I'd still argue that the problem is not defining "winning" beforehand. That could mean any number of thing, but without defining that first we can't weigh the likelihood of success or cost of tactics that will be required.
I agree I'm not sure when a goal of eliminating the enemy completely is one that I could support, though interestingly enough that is precisely what Israel's claimed goal currently is with regards to Hamas. I believe its also the stated goal of Russia, though I'm not familiar with what faction of neo-nazis they claim to be targeting or whether they even exist in any meaningful numbers in Ukraine.
Chevron Reference is the idea that when a statute is ambiguous the agencies can interpret it according to their expert opinion.
The alternative is requiring Congress to write every single rule explicitly and pass a law adapting to any change in circumstance or technology. In practice this means "no regulation" because Congress is pretty slow and adding more detail would only make them slower.
