4,295 karma · joined December 8, 2015
Socials: - github.com/mrkev - aykev.dev
---
There might be bias here if one remembers one's own teenage years, because I'm sure many teenagers _think_ their parents don't have influence over them. If you ask the parents though I'm sure many would agree aren't fully in control, but do notice they have a lot of influence still.
Personally, the older I grow, the more I realize how much influence in general my parents actually had over me.
For I second I thought this employee was talking about what's healthy for the user. Certainly not though; they mean what's healthy for the "user-base". I find very interesting how this sort of language leads to certain employee behaviour. Using the concept of "health" to mean retention and engagement, might overcast thinking about health from a user's perspective— it's similar terminology but very different, and sometimes even opposite, goals.
And while we're at it, I'd like to know, why are people still building new and different game engines, programming languages, web browsers, operating systems, shells, etc, etc. Don't they know those things already exist?
/s
Joking aside, what's wrong with finding a new way of doing something? This is how we learn and discover things.
RSC doesn't impede this. In fact it improves it. Instead of having your ORM's objects, to be converted to JSON, sent, parsed, and finally manipulated to your UIs needs, you skip the whole "convert to JSON" part. You can go straight from your ORM objects (best for data operations) to UI (best for rendering) and skip having to think about how the heck you'll serialize this to be serialized over the wire.
> With JSX on the server side, it's abstraction when there's no need to be. And in the wrong place to boot.
JSX is syntactic sugar for a specific format of JavaScript object. It's a pretty simple format really. From ReactJSXElement.js, L242 [1]:
element = {
// This tag allows us to uniquely identify this as a React Element
$$typeof: REACT_ELEMENT_TYPE,
// Built-in properties that belong on the element
type,
key,
ref,
props,
};
As far as I'm aware, TC39 hasn't yet specified which shape of literal is "ok" and which one is "wrong" to run on a computer, depending on wether that computer has a screen or not. I imagine this is why V8, JSC and SpiderMonkey, etc let you create objects of any shape you want on any environment. I don't understand what's wrong about using this shape on the server.[1] https://github.com/facebook/react/blob/e71d4205aed6c41b88e36...
They became significantly more attentive when I got an internship offer from a competing big-tech company, but as much as my recruiter seemed to try, the process just seem to be deficient beyond their capacity to do anything about it. It had to go through many steps, and be reviewed by many people who seemingly had better things to do.
Eventually they reached to the right people to tell me my decision before my other deadline. I _was_ going to get an offer. They couldn't get me the actual offer letter, or tell me if I had guaranteed host-matching though. I happened to know Google can send intern offers that don't guarantee you'll be matched to a team, and if you're not, the internship just doesn't happen. In my book that's not only as good as no offer really, it's also just disrespectful. I knew people who had this type of offers and didn't get teams.
I took the other offer. "You will get an offer, the details are just taking a while" is not enough to decide on, and the whole process didn't particularly warm me up to Google. For comparison, and to give credit where credit is due, the other company was Meta (then FB). My recruiter was very response, understanding, and personable, which is especially appreciated as an college student— you're nervous, unexperienced and have a lot going on beyond interviewing. They sent me pictures of their dog to lighten the mood. I had told them I'd appreciate quickness, and by the time I was eating dinner after my on-site, I had the offer letter in my inbox.
In regards to the auto industry, I'm not sure what you mean by "look where auto manufacturing investment in the US is". Most auto manufacturing jobs are still in the rust belt [1]. Most EV Production investment is in the rust belt [2].
[1]: https://engaging-data.com/auto-manufacturing-state/
[2]: https://www.assemblymag.com/articles/98988-ten-us-states-dom...
Side-comment of something this made me think of (again): tech builds too much for tech. I've lived in the Bay before, so I know why this happens. When you're there, everyone around you is in tech, your girlfriend is in tech, you go to parties and everyone invariably ends up talking about work, which is tech. Your frustrations are with tech tools and so are your peers', so you're constantly thinking about tech solutions applicable to tech's problems.
This seems very much marketed to SF people doing SF things ("Cursor, Gmail, Slack, even your terminal"). I wonder how much effort has gone into making this work with code editors or the terminal, even though I doubt this would a big use-case for this software if it ever became generally popular. I'd imagine the market here is much larger in education, journalism, film, accessibility, even government. Those are much more exciting demos.
In broad terms, this is related to the error the USA made. Manufacturing in China was a very profitable deal for the USA. A lot of companies view labour first and foremost as expense, wealth as as the goal, and power in wealth— so it's not surprising as a whole the industry opted to "contract out" labour across the globe.
A lot of power lays in labour though. Money doesn't produce, invent, move, feed, etc— money is only good if someone will take it at the amounts you have it to do that specific labour you need for you.
I still think Grapefruit is great. Nonetheless a lot of her work, especially her recent work, seems kind of disconnected form its historical context, not very daring, deep or metaphorical. It doesn't really propose anything new or seem distinctively hers. It's almost performative, like someone doing conceptual, installation and performance art "as a brand" rather than as a means to achieve something that can't be achieved via other mediums.
> Ph.D. Computer Science, November 2004 > University of Wisconsin, Madison
> M.S. Computer Science, May 2001 University of Wisconsin, Madison
> B.S. Physics, June 1999 Stanford University
[1] https://pages.cs.wisc.edu/~kovar/cv.html
EDIT:
Went on to work at IL&M for 5 years and has been at Google for 14 [2]. My guy did indeed end up rolling in cash haha
1. Musk owned an estimated 80% of X and an estimated 50% of xAI [1]. We don't know the specifics of the deal, but we do know it's an all-stock deal, so in theory this should help Musk own more of xAI, which sounds like better-performing and more promising company atm.
2. Tesla has been a big name in AI for a while now, but has been awfully MIA when it comes to generative AI. It's always focused most on vision, sure, but it's not hard to see how other types of AI could fit it's strategy.
Imagine a conversational virtual assistant in your car, or in their robots, or the possible manufacturing applications. In my opinion the device manufacturer + AI lab combo, especially for a device that sells on its promise of cutting-edge technology, makes more sense social network/LLM combo. Beyond the product applications Tesla would greatly benefit from the prestige and marketing of cutting-edge AI.
Nonetheless Musk owns only about 12% of Tesla [2]. It makes more sense for Musk's fortune to ride the wave of this new industry with a private venture he owns. This 12% ownership is down from 22% in 2018 btw [3], before the Twitter acquisition in 2022, which was largely funded by liquidating his Tesla stock [4]. Musk seems to be very much divesting from Tesla— both in effort and in money.
3. Where does this leave Musk, Tesla, and xAI?
- I think it leaves xAI in the position of being the most important company for Musk right now. Best-case, it becomes a "big tech" company. I'm sure we'll keep hearing much more about it, although I don't rule that Musk could try to sell it or merge it if it gives him control of a tech company with a solid business model or strategic importance.
- Musk I think is definitely in a better position than before, fortune and power-wise. He's been diversifying away from a company that's had an insane PE ratio for a while [5], but most importantly, he's been doing so in a pretty smart way. If he had just sold Tesla to buy government bonds, the share price would've crashed. Instead everyone buys into the "he's eccentric and went through a divorce" story. Social network ownership has given him plenty of political power— I don't doubt unbanning Donald Trump is how he got close to him the first place. And now he's converted imaginary wealth from unattainable hype at Tesla into ownership of private company riding the hot tech wave of the moment, concrete political power and self-regulation via his seat in government, and evergreen influence/relevance via his own social network— a tech baron's dream.
- Tesla is not doing great, and Tesla investors are the ones getting the short end of all this. I think Musk realized self-driving is too hard, be it due to tech or regulation. I think he realized he can't compete vs Chinese automakers. I think he's pumping and dumping. If he can get a good deal he might try to merge it with xAI in a way that offers him full control of the company (maybe even private ownership), but otherwise I think Musk is ready to let go of it. He's used its insane valuation to get himself better assets.
[1] https://www.barrons.com/articles/xai-buys-x-musk-twitter-2e5...
[2] https://www.investopedia.com/articles/insights/052616/top-4-...
[3] https://www.thestreet.com/investing/stocks/how-elon-musk-con...
[4] https://abc7.com/post/elon-musk-accused-improperly-selling-7...
[5] https://www.macrotrends.net/stocks/charts/TSLA/tesla/pe-rati...
Also, to be clear, it's a common understanding in Marxism that capitalism is a stage of socialism. The "capitalism and socialism are opposites" rhetoric is too simplistic.
Socialism is different but built upon capitalism, in a similar way, for example, to how electric cars are different but built upon gas cars. Marxism opposes neoliberalism and other forms of governance that leave capitalism unchecked, but doesn't reject everything about capitalism— "just the motor, gas tank, and other harmful parts" you could say.
[1] https://www.reddit.com/r/CapitalismVSocialism/comments/vlxxv...
[2] https://www.reddit.com/r/CapitalismVSocialism/comments/1g5kd...
I'm not implying that, and I don't think my manager was implying that either. I think rather there were 2 things going on:
1. It's often hard to connect bug-fixing to metrics.
A specific feature change can easily be linked with an increase in sales, or an increase in usage. It's much harder to measure the impact of a bugfix. How can you measure how many people are _not_ churning thanks to a change you pushed? How can you claim an increase in sales is due to a bugfix?
In your case, I'm sure some team at Microsoft has a dashboard that was updated the minute you used one of these features you bought Microsoft 365 for. How could you build something similar for a bugfix?
Bugfixes don't tend make the line go up quickly. If they make the line go up it often is a slow increase of regained users that's hard to attribute to the bugfixes alone. Usually you're trying to measure not an increase, but a "not decrease", which if possible is tricky at best. The impact is intuitively clear to anyone who uses the software, but hard to measure in a graph.
2. A ruthless prioritization of the most clearly impactful work.
I wouldn't have minded working on something less-clearly measurable which I nonetheless thought was important. But my manager does care though because their performance is an aggregate of all those measurable things the team has worked on. And their manager cares, and so on and so forth.
So at the end of the day, in broad strokes, unless the very top (which tends to be much more disconnected from triage and edge-cases) "doesn't mind" spending time on less measurable things like bugfixing, said bugfixing will be incentivized against.
I think we all know this impacts the bottom-line. Everyone knows people prefer to use software that is not buggy. But a combination of "knowing is not enough, you have to show it" and "don't work on what you know, you have to prioritize work on what is shown", makes for active disincentivizing of bug-fixing work.
> In short ways, four forces of change – Kerala’s reintegration with the global economy, remittances from the Persian Gulf, strong welfare policies from a legacy of Leftist government, and private investment from individuals and businesses who shared the remittance flows – have combined to form the structure of Kerala’s miracle of human wellbeing with economic growth.
There were a lot of smart people, very interested in fixing things— not only because engineers tend to like fixing things, but also because we, and everyone around us, were users too.
For example, many things related to text input were broken on the site. Korean was apparently quite unusable. I wanted to fix it. A Korean manager in a core web team wanted to fix it. But we couldn't because the incentive structures dictated we should focus on other things.
It was only after a couple years, and developing a metric that linked text-input work with top-level (read, revenue-linked) metrics, that we were able to work on fixing these issues.
I find a lot of value in the effort to make incentives objective, but at a company that was already worth half a trillion dollars at the time, I just always felt there could be more room for caring about users and the product beyond the effects on the bottom-line.
We're in a strategic industry with lots of investment, and a lot of us who check Hacker News have good enough resumes to be in demand, but this doesn't change the fact we —software engineers as a whole— are workers. We might be well-paid, but we're still working class.
If you go outside the top-school bubble, or the usa-tech bubble, this is more evident. Take the money and generous stock grants away and the job is basically indistinguishable from any other white-collar job. Most software developers around the world can't work from Thailand when it's winter. Or take a gap year to reinvent themselves. Or find freelance work that'd allow them to live comfortably with only a dozen hours of work a week.
The incentive of companies is always to have their workers produce more, for less. Thankfully in the USA especially the stars are aligned to give "top software engineering talent" enough leverage to enjoy career mobility and cushy pay. We're at the right place at the right time.
The incentive of companies is always to have their workers produce more for less, and trust me, they're trying. It might be AI, it might be a growing supply of developers, it might be a change in investment strategies— that "top software engineering talent" pool will shrink and a lot of developers will be hit with the realization they weren't some permanent exception in the system. We might feel like we're part of the bourgeoisie because we get big cheques from the companies we work for, but we're much closer factory-line work than a lot of people realize.
At one point I was unsure about joining a startup and it was them who suggested doing a temporary contract as a way to test the waters. In that case it was only a week but it was also enough for me to decide to join full-time. If joining full-time is a possibility you'd consider, I'd also mention that to the startup early on.
Porting to Go was the right decision, but part of me would've liked to see a different approach to solve the performance issue. Here I'm not thinking about the practicality, but simply about how cool it would've been if performance had instead been improved via:
- porting to OCaml. I contributed to Flow once upon a time, and a version of TypeScript in OCaml would've been huge in unifying the efforts here.
- porting to Rust. Having "official" TypeScript crates in rust would be huge for the Rust javascript-tooling ecosystem.
- a new runtime (or compiler!). I'm thinking here an optional, stricter version of TypeScript that forbids all the dynamic behaviours that make JavaScript hard to optimize. I'm also imagining an interpreter or compiler that can then use this stricter TypeScript to run faster or produce an efficient native binary, skipping JavaScript altogether and using types for optimization.
This last option would've been especially exciting since it is my opinion that Flow was hindered by the lack of dogfooding, at least when I was somewhat involved with the project. I hope this doesn't happen in the TypeScript project.
None of these are questions, just wanted to share these fanciful perspectives. I do agree Go sounds like the right choice, and and in any case I'm excited about the improvement in performance and memory usage. It really is the biggest gripe I have with TypeScript right now!
No, I disagree. The alternative, as the original comment said, is to measure access to calories, nutrition, or other metrics like prevalence of starvation, access to shelter, access to sanitation, prevalence of certain health issues, etc.
Measuring poverty via the international poverty line has often been criticized [1][2][3].
[1]: https://www.researchgate.net/publication/337335330_A_critiqu...
[2]: https://www.jasonhickel.org/blog/2021/3/28/extreme-poverty-i...
[3]: https://www.aljazeera.com/opinions/2014/8/21/exposing-the-gr...
> “the most southernmost lunar landing and surface operations ever achieved”.
> “This area has been avoided due to its rugged terrain and Intuitive Machines believes the insights and achievements from IM-2 will open this region for further space exploration.”
I wonder if this 250 mile error is why they ended so far south in the first place.
EDIT: or a horizontal lander, packed on it's side for takeoff.
I'm sure it's more complicated than that, but landing something this tall seems quite complicated too in the first place.
Does this mean delays for Artemis, or do we not know yet?
1. The first microcomputer predates VisiCalc, yes, but it doesn't predate the realization of what it could be useful for. The Micral was released in 1973. Douglas Engelbart gave "The Mother of All Demos" in 1968 [2]. It included things that wouldn't be commonplace for decades, like a collaborative real-time editor or video-conferencing.
I wasn't yet born back then, but reading about the timeline of things, it sounds like the industry had a much more concrete and concise idea of what this technology would bring to everyone.
"We look forward to learning more about its strengths, capabilities, and potential applications in real-world settings." doesn't inspire that sentiment for something that's already being marketed as "the beginning of a new era" and valued so exorbitantly.
2. I think as AI becomes more generally available, and "good enough" people (understandably) will be more skeptical of closed-source improvements that stem from spending big. Commoditizing AI is more clearly "useful", in the same way commoditizing computing was more clearly useful than just pushing numbers up.
Again, I wasn't yet born back then, but I can imagine the announcement of Apple Macintosh with its 6MHz CPU and 128KB RAM was more exciting and had a bigger impact than the announcement of the Cray-2 with its 1.9GHz and +1GB memory.
Seeing that Winamp skin screenshot was especially interesting to me, because I'd assume Winamp is itself a digital representation of an audio player— an abstract standalone device, turned digital, again, in a way, turned standalone, haha.
Very impressive!