[0]: Various people I know do not even have the luxury of that one good company. Also, it -- unbelievably -- sounds much worse at other companies.
1,154 karma · joined August 25, 2010
webpage: https://galacticbeyond.com
github: github.com/galactic-beyond
github-legacy: github.com/nickziv
[0]: Various people I know do not even have the luxury of that one good company. Also, it -- unbelievably -- sounds much worse at other companies.
The existence of _two_ books, published by the same publisher, within a few years of each other, is a kind of tacit acknowledgement, that there are two categories of people (Owners/Founders and Developers/Coders), that have a kind of symbiotic relationship with each other. That relationship has always been a relationship of convenience and gain, not resonance and understanding and appreciation.
It is, in a way, similar to globalization: nations will support it, only to the extent that it can make them (or their elites) wealthier, and not because they actually care about peace, or the magnificent diversity of human culture and creativity.
Just as the globalized economy is fraying, so is the symbiotic relationship between Founders and Coders. I think it started with the pandemic, which caused (without pointing any fingers) a tension between Founders and Coders, and has been accelerated by LLMs. In some sense, the tactics that were use by Tech companies to wow and win customers outside of Tech, are now being used by Tech companies on other Tech companies. And those tactics involve making grand promises to people who have knowledge-gaps, and are otherwise easily impressed.
I did not realize that there even was a symbiotic relationship, until I analyzed US degree-completion-rates for 1970 to 2011[1][2]. I suppose it should have been obvious, but these things are difficult to perceive from the inside (even if you've been working in the industry for an entire decade). The big problem is that the symbiosis is asymmetrical: founders get the money, and pay the coders, and are able to fire and replace coders at will, while coders can do none of this to the founders. This may have been fine, in an era where layoffs were rare, and getting a replacement job was less uncertain. But I suspect that the contest we are going to see in the next few years is: can Founders out-code Coders, or can Coders out-found Founders. Note that the Viaweb story (the archetypal startup-story for HN), is a story of Coders out-founding Founders (the equivalent of the late 90s era, did not found companies so much as administer small parts of them).
[0]: This is not a criticism of the author/interviewer, nor the interviewees -- the subject matter simply did not intersect enough with my own obsessions and fixations. I wish it did. It feels like I have some kind of color blindness, when it comes to "founder-y" things.
[1]: You can find a (fair warning: long) PDF here: https://galacticbeyond.com/pdf/two-percent-programmer.pdf
[2]: If you do not want to read all of that, here is a TLDR. The percentage of informatics-degree-completions never drops below 2% (which confirms an informal observation Knuth has made many times -- see his 3 or 4 oral histories and his interview in Coders at Work). The percentage of informatics-degree-completions rises and falls with business-degree-completions (the symbiosis is visible here). It never exceeds 4.5%, and such doublings coincide with bubbles (the dot-com bubble, and the 1980s AI-bubble -- there is a history section that helps narrate these numbers). Most intriguingly, informatics-degree-completions are _perfectly inversely correlated_ with healthcare-degree-completions -- their first-derivatives are nearly perfect mirror images. Also, the majority of graduates are business-graduates (accounting, administration, etc -- economics belongs to social-sciences instead of business), and their numbers have doubled since 1970, at the expense of social sciences and education (I suspect that this has had an impact on our (both global and American) culture akin to the impact that climate-change has had on our planet, but I have no data to put behind that suspicion, yet).
What I am saying is that the paper pushers are allocated elsewhere, they are more miserable and shallow minded now, and they have a corrosive long-term effect on society and culture, even though they contribute positively to economic growth. In way, it is trans-generational debt with extra steps.
> and we got “Greed is Good” Geckos running things since
This phrase is the opposite of an exaggeration. It sounds like it should not be true, but it really, really is. To be fair though, if you told me in 2015 what the headlines for the 2020s would look like, I would assume you are some kind of satirist or comedian.
So, it is very hands-off, but also very expensive, and it is never clear if optimizing the fitness function is worth it, because the fitness function itself may be insufficiently or incorrectly specified.
However, I do think that people should try, even with just a whiteboard or a notebook, to design a fitness-function, for their problem, as if they were going to try to evolve it, because (1) it forces them to explicate their correctness constraints, and (2) they may discover that the program that they are trying to write _is equivalent_ to the fitness function.
I'll give you an example for point 2. Many years ago, I had to parse a gnarly language, and I chose to do it via Chomsky Grammars (that automatically build a tree based on the grammar-spec). Chomsky Grammars are cool, in that they are basically just a state-machine, but they are incredibly difficult to debug: when they work, they might work incorrectly (malformed tree), and when they fail, they give no reason for failure (because even with a trace, you are trying to figure out which backtrack should not have happened). So, out of desperation, I started to consider using genetic programming to just evolve a correct Chomsky Grammar. It became clear that there are only 2 possible fitness functions (1) a function that tests a hand-picked input against a hand-crafted tree-output (which is vulnerable to over-fitting), and (2) a function that is not (well, is much less) vulnerable to over-fitting, but is effectively a pre-existing, correct grammar that can produce those trees.
If you are in situation 2, then the genetic programming is not necessary, unless you are trying to create an optimized (or obfuscated) parser, and even then the optimization may be overfit to the test-inputs (even if they are generated test-inputs from the grammar itself). If you are in situation 1, then you are better off re-evaluating your approach (I abandoned the Chomsky Grammar notation, and invented one that is much easier to understand and debug, without losing any of the expressiveness -- it also happens to be slower, but fast-and-broken is worthless compared to not-so-fast-and-works-fine).
One place where genetic programming has been consistently awesome, is in parameter-search style problems (e.g. your genome is a long list of floats, representing weights and/or anti-weights, and you need to find out which weights give you more fitness (or less error)). I hear good things about variable-neighborhood-search, but have yet to try it.
Having looked at the process (RFD 3 and original post on dtrace.org), and contextualizing it with the oversubscribed-problem (which was mentioned somewhere else in this thread), I cannot help but think that there is a kind of solution that can help both the applicants and oxide and (yes) the industry as a whole.
The kinds of materials that the RFD asks for, seems like it would make for very interesting reading, regardless of whether it is read by a hiring-manager or a computer nerd. So why not, instead of (or in addition to) writing 11 pages, and sending them to the inbox of someone who (even without the additional responsibility of sorting thousands of applications in order hire-ability) is already extremely busy (this is, after all, a very demanding job), you publish them on your webpage?
In addition to taking some of the pressure off the oxide hiring-pipeline, you also get more exposure to people, who may work at organizations that would benefit from such a pipeline, but cannot afford to burn the political capital to replace the old pipeline. In a way, people who would appreciate your materials would, over some amount of time (and time should not be an issue, because it seems like it takes (at least sometimes) a long time for oxide to respond anyway), find them and possibly reach out.
I am basically a nobody, but if people started publishing things in the format of an oxide application, I would _totally_ read them. I am not saying I would necessarily _like_ them, but I would certainly read them[1]. Also, if disclosure is an issue, people can be published pseudonymously.
[1]: If for no other reason, than to see the multitude funny ways in which other people are wrong ;)
[0]: https://galacticbeyond.com/two-percent-programmer/
[1]: https://web.archive.org/web/20260620162923/https://galacticb...
[2]: In both the economic sense, and in the completion-rate sense, because those two things are correlated. And they have been correlated since the 1980s, because a lot of the healthcare industry became de-regulated and more profitable as a result, since at least 1978 (when hospitals were de-forbidden from making profits).
The solution may be to modify the incentives. Maybe federally cap all salaries to 90k or so, to filter out the serial job-hoppers and con-artists, and to also prevent poaching and "nerd-hoarding"[3]. Has the additional benefit of forcing rents and property prices to go down, and stops gentrification in its tracks (I mean I would expect this to be partially true, though it might force people to instead seek massive loans to compensate -- which should also be capped by salary to prevent it). And since we are already talking about federal limits, maybe a federal guarantee that covers healthcare and housing would further improve things.
[1]: This depends on context. If the IP is already open source, then there is no laundering. But I know people who have been building the same software system for the last 3 employers, and they do it (ostensibly) from scratch each time (but in fact they are permuting/improving the old version -- which does not actually belong to them -- and are over-reporting how much time they spent working on it). My point here is not that employees are ruthless rogues, but rather that the incentives are set up in a way that encourages the rapid dilution of the value of IP (it is effectively non-exclusive, which makes industrial espionage _unnecessary_), and discourages any kind of mutual responsibility between employer and employee (in a different knowledge-work field, I hear from a friend, seniors give juniors only minimal training because they do not expect to have to deal with them in two years -- and this was true since at least 2017, and has only gotten more true since 2020).
[2]: With or without LLMs, the biggest winners of this dynamic are the quasi-monopolies (or, more precisely oligopolies and duopolies), like MSFT, GOOG, META, etc. Everyone else will lose, and if they happen to win, they will get acquired (not for the tech, which is probably slop anyway and cannot run at hyperscales, but for the clients/customers/users -- why else would MSFT buy LinkedIn and GitHub, why else would startup incubators like YC be such a huge success (I doubt YC would have been possible in the 70s or 80s)). Software is awesome, and I love it, but the software _industry_ has always been an operation designed to extract money and data from the populace, using deceptive and predatory practices (see: Uber, Theranos, Celsius, Alameda for outright fraud, and Oracle for mere deception and plunder).
[3]: Sorry, could not think of a better term. The idea is basically the corporate equivalent of nerd-sniping, but instead of sniping by offering interesting problems/puzzles, you snipe by offering large paychecks and golden handcuffs.
Also, would bet money that the derived data from the meeting-summarizers is being sold to hedge-funds, to give them a bit of an edge.
I have a friend who works at a large-ish company that imports and manufactures things (in one of the clerical/quantitative professions). A few years back, they had the IT department go on a kind of "inquisition", wherein they forced employees to disable the summarization function that came with MS Teams, and threatened to fire them if they did not. The resistance to this demand was surprising -- most people are clueless about the cost of their own convenience. Worst of all, people would zone out of meetings, because the AI was producing summaries, which they would then never read.
The effect of the technology was that it made meetings infinitely more expensive, because the supposed benefit of meetings was nullified by complacency, _and_ it made the meetings a liability (incorrectly summarized meetings, that could be used in the discovery process, sure, but could also be sold by MSFT as a kind of market-research-data to competitors in the space).
Nothing illegal has to happen in these meetings at all, for this tech to cause an infinity of problems for the corporation. Every employee that uses these is effectively an unwitting spy. And if that is the case, then the meetings might as well be recorded and uploaded to YouTube (or whatever people watch these days)[1].
[1]: Maybe this is the future. Which I am okay with, but only if the entire planet has to do it, and the penalties for not doing it are irrecoverably severe.
I wonder how much of the multi-file (and increasingly multi-repo) code-organization is just a manifestation of Conway's Law (https://en.wikipedia.org/wiki/Conway%27s_law).
[1]: It makes navigation and iteration much faster, and obviates the need to use indexers. It also forces you to only put _orthogonal_ programs in external files (I recently had to write a kind of quasi-SAT-solver, and that was code that was complex enough to require its own "namespace", and it was also something that was reusable across projects). One thing I noticed, maybe in 2025, is that LLMs struggled to navigate large single-file programs, but were quite good at navigating multi-file programs. It is interesting that they (according to my 2025 experience and the quote you give) prefer to _write_ code in ways that make it difficult for them to _read_ code.
It just means that you will have to evaluate prose on its own merits (aesthetic, logical, etc).
The main problem with LLM-assisted writing is that effort-to-write is now much lower than effort-to-read -- the LLM-prose-style is simply an imperfection that can sometimes help the reader bail on a piece (and there might be false-positives).
Most people are already biased against reading long pieces, and seem to skim them more often than not. These people are _probably_ a little worse off than before, but they are not paying full-price for being hoodwinked. The people who end up paying full-price are probably going to become more sophisticated in how they choose what to read. I can't tell if this will be good/bad for publishers and/or advertisers.
Interestingly, I also converged on the "reverse dictionary" usage of LLMs, in around 2024[1], mostly to indulge in (human) language-learning.
An excerpt from the post below:
``` It is a phenomenal reverse dictionary (i.e. which English words mean "of a specific but unspecified character, quality, or degree"). It not only works for English, but also for Esperanto (i.e. which Esperanto words mean "of a specific but unspecified character, quality, or degree"), as well as my own obscure native language. This is a huge time-saver when learning languages (normal dictionaries won't cut it, and bi-lingual dictionaries are limited, if they are available at all). Even if you are just using a language you are fluent in, a reverse-dictionary-prompt can help you find words and usages, and can also help you find "dark spots" in the language's lexicon. ```
[1]: https://galacticbeyond.com/chat-room-dispatches-intelligence...
Basically, I am prepared to accept that there is a friction that LLMs lubricate away, but what is the source of the friction, and why am I (and a bunch of other colleagues) not feeling that friction daily in our practice?
[1]: And if so, where did we programmers and computer scientists go wrong? Were subroutines and macros not sufficient for automating all of that excess typing? Were Emacs and Vim simply not saving enough keystrokes? Did people forget how to touch-type?
Just to emphasize my point, China is not being deprived of chip _designs_ (via export bans of ASML-made lithography equipment), but rather of the actual physical machines that rearrange the atoms.
It's a breeding ground for Edisons and Morgans, not Teslas. It is profoundly depressing that SV is doing everything it can (knowingly or unknowingly, not sure which is worse) to get the entire planet to stop taking it seriously and to shun it.
I feel like LLMs[1] are going to cause a kind of "divorce" between those who love making software and those who love selling software. It was difficult for these two groups to communicate and coordinate before, and now it is _excruciating_. What little mutual tolerance and slack there was, is practically gone.
Open source was always[2] a fragile arrangement based on the kind of trust that involves looking at things through one's fingers (turning a blind eye may be more idiomatic in English), and we are at the point where you just have to either shut your eyes, or otherwise stop pretending that the situation can be salvaged at all.
Just a thought I had: some people think that LLM-shaming is declasse, and maybe it is, but I think that perhaps we _should_ LLM-shame, until the AI-companies train their LLMs to actually give attribution, if nothing else (I mean if it can memorize entire blocks of code, why can't it memorize where it saw that code? Would this not, potentially, _improve_ the attribution-situation, to levels better than even the pre-LLM era? Oh right, because plagiarism might actually be the product).
[1]: Not blaming the tech itself, but rather the people who choose to use it recklessly, and an industry that is based almost entirely on getting mega-corporations to buy startups that, against the odds, have acquired a decent number of happy-ish customers, that can now be relentlessly locked-in and up-sold to.
[2]: I mentioned a specific example of good old fashioned, pre-LLM, human plagiarism here: https://news.ycombinator.com/item?id=46540608
I could go on, but Tienanmen does not compare to most of the things the US has done outside of its own borders from 1946 to the present. And no, we (I am American) cannot justify a body count in the millions, just because our victims are communist/authoritarian/theocratic. Note also that we only number 5% of the world's population, and that if we compared body-counts as percentage of populations, instead of as absolute numbers, I doubt we even have enough people to settle that debt.
Even worse, if the world internalizes that it is fine to murder millions of foreigners, just because they are oddballs that their citizens cannot empathize with, the _we_ are going to have a big problem -- we appear much more odd to the world than the world does to us.
I am surprised that our shenanigans have been tolerated for nearly a century.
I could go on, but Tienanmen does not compare to most of the things the US has done outside of its own borders from 1946 to the present. And no, we (I am American) cannot justify a body count in the millions, just because our victims are communist/authoritarian/theocratic. Note also that we only number 5% of the world's population, and that if we compared body-counts as percentage of populations, instead of as absolute numbers, I doubt we even have enough people to settle that debt.
Even worse, if the world internalizes that it is fine to murder millions of foreigners, just because they are oddballs that their citizens cannot empathize with, the _we_ are going to have a big problem -- we appear much more odd to the world than the world does to us.
I am surprised that our shenanigans have been tolerated for nearly a century.
Around the time of the pandemic, a company wanted to make some Javascript code do a kind of transformation over large number of web-pages (a billion or so, fetched as WARC files from the web archive). Their engineers suggested setting up SmartOS VMs and deploying Manta (which would have allowed the use of the Javascript code in a totally unmodified way -- map-reduce from the command-line, that scales with the number storage/processing nodes) which should have taken a few weeks at most.
After a bit of googling and meeting, the higher ups decided to use AWS Lambdas and Google Cloud Functions, because that's what everyone else was doing, and they figured that this was a sensible business move because the job-market must be full of people who know how to modify/maintain Lambda/GCF code.
Needless to say, Lambda/GCF were not built for this kind of workload, and they could not scale. In fact, the workload was so out-of-distribution, that the GCP folks moved the instances (if you can call them that) to a completely different data-center, because the workload was causing performance problems, for _other_ customers in the original data-center.
Once it became clear that this approach cannot scale to a billion or so web-pages, it was decided to -- no, not to deploy Manta or an equivalent -- but to build a custom "pipeline" from scratch, that would do this. This system was in development for 6 months or so, and never really worked correctly/reliably.
This is the kind of thing that happens when non-engineers can override or veto engineering decisions -- and the only reason they can do that, is because the non-engineers sign the paychecks (it does not matter how big the paycheck is, because market will find a way to extract all of it).
One of the fallacies of the tech-industry (I do not mean to paint with too broad a brush, there are obviously companies out there that know what they are doing) is that there are trade-offs to be made between business-decisions and engineering-decisions. I think this is more a kind of psychological distortion or a false-choice (forcing an engineering decision on the basis of what the job market will be like some day in the future -- during a pandemic no less -- is practically delusional). Also, if such trade-offs are true trade-offs, then maybe the company is not really an engineering company (which is fine, but that is kind of like a shoe-store having a few podiatrists on staff -- it is wasteful, but they can now walk around in white lab-coats, and pretend to be a healthcare institution instead of a shoe-store).
Personally, I believe that the tech industry sustains itself via technical debt, much like the real economy sustains itself on real debt. In some sense, everyone is trying to gaslight everyone else into incurring as much technical debt as possible, so that a way to service the debt can be sold. Most of the technical debt is not necessary, and if people were empowered to just not incur it, I suspect it would orient tech companies towards making things that actually push the state of the art forward.
While I am here, I might as well give you a brief Esperanto lesson. Mono = money, ero = piece/quantum. So, "pano" = bread, "panero" = bread-crumb. Thus, "monero" = coin.
Many previous international currencies (all of them created with Swiss involvement), were also given Esperanto names: Spesmilo (thousand speso's (speso is analogous to "penny")), Stelo (star).
There is even a luxury watch-brand (from Switzerland) called "Movado", which is Esperanto for "Movement" (made back when watches were made with mechanical movements).
And I also learned, from the linked thread (disclosure, I am a participant), that there is a soft-drink called "Mirinda". This is an adjective that means "awe-worthy".
[1]: https://www.reddit.com/r/Esperanto/comments/1sobiko/comment/...
https://nickziv.wordpress.com/wp-content/uploads/2014/02/vis...
I used whatever I could find on the internet at the time, so the comparison compares both algorithm and implementation (they were all written in C, but even slight changes to the C code can change performance -- uuavl performs much better than all other avl variants, for example). I suspect that a differently-programmed skip-list would not have performed quite so poorly.
The general conclusion from all this, is that any data-structure that can organize itself _around_ page-sizes and cache-sizes, will perform very well compared to structures that cannot.