kcexn

I feel like there is a lot of nuance around this topic that is getting lost in the noise.

The direct and indirect financial impact of technical decisions are indeed hard to measure. But some technical decisions definitely have greater financial impact than others. Even if it's hard to precisely quantify the financial costs/benefits of every decision. It is possible to order them relatively. X is likely to make more money than Y. So we do X first and Y later.

There is a significant amount of chance involved in whether a product/feature will even make money at all. So even good plans with measurably positive expected value could end up losing money.

Just because it's impossible to be 100% certain of the outcome of any decision. Doesn't mean we should throw the baby out with the bathwater.

I don't think there is a bias in the field towards a youth narrative. I think there is a bias in the media.

Nobody I've ever met would expect a breakthrough from a 20 something year old no matter how much of a genius they are. Communicating a breakthrough requires time, effort, and credibility to begin with, which nobody has at that age.

Your 30's are when you can start to really do great things. And then depending on the field you can kind of just keep going as long as you have the energy for it. But lots of people begin to wear out into their 40's (for lots of different reasons).

In terms of great breakthroughs. If you haven't had your great idea by 40. It's probably increasingly unlikely that you'll have one later in life (but not impossible). Not everyone needs to have a paradigm changing idea to have a successful career though.

Isn't this the fundamental problem of all AI chatbots? If the problem is costing thousands of dollars (a week?), why not hire a person?

If it's not costing thousands of dollars, why would I hire a software engineer to build this for me.

I can imagine a future where writing that is considered sloppy today is considered good because of LLMs.

I don't think they're suggesting we reduce the amount of faculty. They're suggesting that you ask all the faculty to share less space, increasing the efficiency of the real estate holdings. Also by reducing the number of schools, you reduce the amount of expensive ancillaries.

Technically it's the same. But behaviorally it's not. When pulling in more dependencies is so easy, it's very hard to slow down and ask the question do we need all of this?

Mucking around with cmake adds enough friction that everyone can take a beat for thoughtful decision-making.

There's a softer component to healthcare which is that people can overreact to medical results. If a doctor administers a scan, finds a handful of likely benign things but wants to administer another scan later on down the line, I'm probably much more likely to look for a second opinion that tells me to cut them out (even if it may not be medically necessary) than trust my doctor that "it's probably fine".

It's probably more accurate to use a software analogy about performance metrics. We measure random request spikes now and again that strain the system. It's probably fine, but later on down the line, something could change that results in an outage during one of these spikes. Do we proactively fix the problem even if no change is expected? Or do we wait till there is definitely a problem before taking action?

Did power tools not cause layoffs? That seems like a dubious claim to me. Building a house today takes far fewer people than 100 years ago. Seems unlikely that all the extra labor found other things to do in construction.

Maybe. I'm not sure its that different though? If one person can do the work of two because of power tools, then why keep both? Same with AI. How people feel about it doesn't seem relevant.

Maybe the right example is the role of tractors in agriculture. Prior to tractors you had lots of people do the work, or maybe animals. But tractors and engines eliminate a whole class of labor. You could still till a field by hand or with a horse if you want, but it's probably not commercially viable.

They should have known better. It was their job to sell the box. Instead they wasted a tonne of their clients money on a proof-of-concept for something that was never going to work. Using the word 'impossible' was probably also a big error. If it can perform computations, nothing is impossible, but some things are certainly not recommended.

I think this is partly an education problem, and partly an industry culture problem. Lots of young developers are incentivized to 'contribute' to open-source as a way to demonstrate that they can actually write software. So open-source becomes a way of signalling competence when at a broader scale it's just extracting wealth from the vulnerable.

Open-source seems to be fragmented into three groups now. Large enterprise open-source like Kubernetes or OpenStack where the license seems more like a legal agreement amongst vendors to not sue each other. Legacy open-source projects that are getting by on brand recognition and sheer willpower. And a whole bunch of noise from people who are looking to leverage open-source into a job of some sort.

I'm not sure what the solution is...

As people get more comfortable with AI. I think what everyone is noticing is that AI is terrible at solving problems that don't have large amounts of readily available training data. So, basically if there isn't already an open-source solution available online, it can't do it.

If what you're doing is proprietary, or even a little bit novel. There is a really good chance that AI will screw it up. After all, how can it possibly know how to solve a problem it has never seen before?

Because developers are incentivized to have marketable software skills. Not marketable build things that are cheap and profitable skills.

Moore's law was supposed to make it simpler and cheaper to do more computationally expensive tasks. But in the meantime, everyone kept inflating the difficulty of a task faster than Moore could keep up.

I think some of this is because of the incredible amounts of capital that startups seem to be able to acquire. If startups had to demonstrate profitability before they were given any money to scale, the story would be very different I think.

The problem with Wikipedia as an Academic source is that it's impossible to cite. You have no idea whether the information on there today is going to be there tomorrow or was there yesterday.

The "move to a farm" dream seems like it would be nice if one didn't have any financial stress. So, more like retire to a farm.

It's a shame that Fleming misremembered his process of discovery and created a myth of accidental discovery.

I like the Root-Bernstein narrative more. That in the monotonous execution of routine experiments for something unrelated an unusual observation 'forced' them to discover penicillins antibacterial properties.

Not an accidental discovery by good fortune in a serendipitous sense. An accidental discovery of a brute force exhaustive search. The narrative of we spent months meticulously examining hundreds of samples is less romantic, but is one that supports the importance of funding scientific inquiry.

We won't make progress by hoping people leave culture plates out on window sills. We make progress when we fund meticulous exhaustive efforts of discovery.

A large part of that training is done by asking people if responses 'look right'.

It turns out that people are more likely to think a model is good when it kisses their ass than if it has a terrible personality. This is arguably a design flaw of the human brain.

Seems sensible in Europe to tie "open source" eligible for financial incentives to a European licence like the EUPL.

It's hard to write about the broader context with any expertise in a blog post written from personal experience.

My own thinking is that the big competitive advantage that big tech firms have over small ones is the power to mobilize very large numbers of developers onto a project.

Large projects that don't depend on a small core group of irreplaceable competent individuals are more repeatable for a business. So it makes sense to focus on making the repeatable processes more likely to succeed than simply hope that you happen to have the right team assembled for the job.

Assuming that any of your engineers are above or below average hurts the ability for the business to plan.

This is a position that seems to be as unenforceable as AI can't be trained on code whose copyright owners have not given consent.

The main reason for being unwilling to merge AI code is going to be that it sets a precedent that AI code is acceptable. Suddenly, maintainers need to be able to make judgement calls on a case-by-case basis of what constitutes an acceptable AI contribution, and AI is going to be able to generate far more slop than people will ever have the time to review and agree upon.

They're not getting promotions because they produce promising ideas. They get them because they convince other people to build their ideas for them.

As you get better at something you become more opinionated at what you need your tools to do. You demand more specific and tailored things from your tools and so you start to lean towards things that are more adjustable.

There is also the case that once your entire livelihood depends on something, consistency and muscle memory matter a lot. Lots of world-class athletes, drivers, and performers probably use tools that closely resemble the tools they learned and trained with their whole lives so they would probably seem kinda anachronistic to a newcomer.

I think this talk speaks to an idea that is true for early stage and small businesses. That is software development is a strategic investment not a tactical one. Maybe I don't need a product database and an API just yet, I could use a spreadsheet. But I choose to do it because software can enable teams to capitalize on opportunities more effectively.

Of course, once software becomes mature there will be tactical decisions in the margins. But greenfield software is usually a strategic decision.

GCC has come a long way in terms of features and complexity since the 90's/00's when Stallman made these decisions. Today, building a compiler from scratch would be a huge undertaking, and would be prohibitively expensive for most organizations regardless of licensing.

If the requirement was still just to implement a "simple" C89 compliant compiler, and I was worried about software freedom. The GPL is probably still a good bet.

I'm not sure that there is a recession of corporate support from C++. Just that the proportion of companies that need C++ is smaller than it once was.

I like the safety promise of Rust. But the complicated interop story with C and C++ hurt it a lot. I mean, in a typical codebase, what proportion of bugs will be memory-safety related vs other reasons? Ideally, we could just wrap the safety-critical bits in a memory-safe wrapper and continue to use C and C++ for everything else.

The theoretical link that is missing is that AI isn't supposed to reduce knowledge work, it is supposed to free labor to concentrate on higher value work and investment.

Nobody knows what that work is though, and nobody wants to talk about it lest everyone realizes this all might be a house of cards.

It's a little bit more complicated than that if you were running a business.

You would want to add the cost of your network+hardware depreciating over the timeframe, and you probably can't just ignore the first 185W since if you are Anthropic it doesn't seem likely that the idle power draw would be needed if they weren't expecting to serve AI traffic.

So, let's say $0.02 per hour ($1/50 roughly). That's about $15 per month per user. Let's call it $10 per month per user since users aren't constantly hammering the service. To support a big sales and marketing engine, you would like to be selling subscriptions for $100+ per month. I'm just not sure people are prepared to pay that for AI in its current form.

poll is the POSIX specified I/O multiplexer so it has the advantage of being portable. Windows even supports a version of poll called WSAPoll.

If you must implement your own event loop and you want your application to be portable, poll is still a good place to begin.

O(N) demultiplexing time in the pollfd array is also not as brutal as it seems on modern hardware. The pollfd structure itself is only 8 bytes wide, so you can comfortably pack thousands of them into the L1 cache. Copying all of the elements that have an active event into a new smaller array before processing them is going to be fast enough for most cases.

The problem is that the best research is not a competitive process but a collaborative one. Positioning research output as a race or a competition is already problematic.

This is such a nuanced problem. Like any creative endeavour, the most powerful and significant research is driven by an innate joy of learning, creating, and sharing ideas with others. How far the research can be taken is then shaped by resource constraints. The more money you throw at the researchers, the more results they can get. But there seems to be a diminishing returns kind of effect as individual contributors become less able to produce results independently. The research narrative also gets distorted by who has the most money and influence, and not always for the better (as recent events in Alzheimer's research has shown).

The problem is once people's livelihoods depend on their research output rather than the research process, the whole research process becomes steadily distorted to optimise for being able to reliably produce outputs.

Anyone who has invested a great deal of time and effort into solving a hard problem knows that the 'eureka' moment is not really something that you can force. So people end up spending less time working on problems that would contribute to 'breakthroughs' and more time working on problems that will publish.