Elizabeth AyerApr 4

I'm a big fan of this explanation/rant from Andrew Murphy.

Taken as a whole, there are many bottlenecks in a corporate software development process. The "load-bearing" calendar is a great example!

Speeding up code creation just increases pressure on the bottleneck, which decreases throughput.

https://andrewmurphy.io/blog/if-you-thought-the-speed-of-writing-code-was-your-problem-you-have-bigger-problems

If you thought the speed of writing code was your problem - you have bigger problems | Debugging Leadership

AI coding tools are optimising the wrong thing and nobody wants to hear it. Writing code was already fast. The bottleneck is everything else: unclear requirements, review queues, terrified deploy cultures, and an org chart that needs six meetings to decide what colour the button should be.

Debugging Leadership
Show threadElizabeth AyerApr 4

So why are we still trying to optimize code creation?

For decades, people with power - executives and product people - have been shifting the blame for strategy failures and poor market insight onto development "productivity."

This AI moment should be incredibly clarifying. Like, it should be the reductio ad absurdum of a productivity-centric approach.

Show threadElizabeth AyerApr 4

The fact that we are *not* seeing wildly improving software all around us tells us everything we need to know.

There is no flourishing of value delivery, new product categories, more needs being satisfied better. It’s the opposite.

All we are seeing is decreases in quality, because 👏 code 👏 creation 👏 is not 👏 the problem.

Show threadDavid PollakApr 5
@elizayer @hbons give me some time. I’ve only been using LLMs to code for a few months… so far I’ve only managed to write an operating system https://codeberg.org/dpp/meows
A new scripting language https://codeberg.org/dpp/meowscript
An eBPF to FPGA converter https://codeberg.org/dpp/lycaon
And some misc utils
But this is weekend work
meows

A vibe coded OS that is a blend of microkernel and Erlang

Codeberg.org
Show threadpoleguy looking for lost tools4d ago
@dpp @elizayer @hbons can you quantify by how much llm made your work faster? Or would you have simply not been capable of doing the work without an LLM?
Show threadpoleguy looking for lost tools
@dpp @elizayer @hbons I looked at your eBPF to FPGA project. (I'm an FPGA guy by day.) I think it is pretty clear _what_ you want it to do, but I think I'm struggling to understand the motivation. Maybe you just haven't got to writing a README.md where you would record such motivation, but I would love to understand why you wrote this or what end application you have in mind.
Apr 8 at 4:19pmTusky
Show threadDavid Pollak4d ago
@poleguy @elizayer @hbons much of eBPF is used for managing network traffic. Many high end NICs have onboard fpgas. Being able to unify the code (eBPF in low end, fpga in high end) seemed interesting.
Show threadpoleguy looking for lost tools3d ago

@dpp @elizayer @hbons Thanks for the responses. It's not clear to me that general purpose eBPF translation into FPGA code is a valuable route. It seems to be optimizing for ease of development while at the same time trying to hit high performance (or else, why the FPGA?).

I understand you to be mostly exploring here, correct?

It doesn't seem you actually got to synthesis or performance measurement.

The only need for eBPF in the first place would be to run user code in the kernal, right?

Show threadDavid Pollak3d ago

@poleguy @elizayer @hbons you’re right. I don’t know enough about fpgas to go beyond “it blinks pretty lights” to “its production ready”

Part of the meta exploration has been “beyond assembling a common app (a web site) how much domain knowledge does the human need to get a good result?”

The answer seems to be I need deep domain knowledge… thus the fpga exploration… I don’t have the domain skills to make this a production reality

Show threadDavid Pollak3d ago
@poleguy @elizayer @hbons otoh, going from “eBPF which is guaranteed to halt” to “let’s make a circuit out of code that’s guaranteed to halt” has a nice feel to it even if the circuit is absurdly slow