I think it’s becoming more and more performative. We’ve never been less focused on the actual product — the software — than we are now. The focus is increasingly on how someone generates code, despite that not having much to do with the product.

The software is not getting better. Generating code faster does not result in better software. Software continues to be slow, unreliable, complex, and counter-intuitive. AI has not improved on the metrics that matter.

AI, as amazing as it is, has not actually changed the process of software development and as a consequence, the resulting software has not changed. The job hasn’t either, except insofar as you’re judged for tokenmaxxing.

The fact that someone has billions of dollars and still chooses to spend 40-60 hours/week going to the office to work on Facebook seems psychotic. He can do practically anything he wants, and he chooses to work on Facebook. It’s mind bending.

At that level it’s not the luxury hotels and fresh mangoes flown in from Miami that appeals, but the influence to effect outcomes on a global scale. Megalomaniacal more than psychotic.

Are they? I think it could be the opposite, ironically. Trump is in many ways the result of news media directed at voters, which was mostly misinformation and propaganda.

If it quacks like a duck... An account has a single Personal Data Server (PDS), right? The DID links to a PDS which is the canonical data feed for a user, and where a user's writes go. Data can be replicated but the PDS is treated as canonical. That's much closer to client/server architecture than distributed architecture. There's no P2P database. There's no writes into a DHT or peers. You write to your PDS, then those writes are optionally mirrored. Also discovery happens via DNS, so you don't even ask peers for data. You connect to a relay not as a peer but as a client asking a server for a copy of data that's canonically hosted by the PDS. I don't think it's a stretch to call the PDS an instance and the relay a mirror.

Yeah sure that’s a fine way to phrase it. It’s not what most people who talk about Mastodon mean by “instance”. In Mastodon, “instance” is a coupled and inseparable data hosting + app + community + moderation pairing.

From a user’s perspective: To use Bluesky I need to create an account, and to create an account I need to choose the server where that account is hosted. Once I have an account I can follow any account even if hosted w/ someone else. That’s the same UX as Mastadon (leaving aside that moving PDS might be easier in ATProto than ActivityPub).

Well I think "can move later" makes all the difference because the initial choice doesn't matter to the individual user. It isn't even blocking. Most people don't know they're making that choice, and I think that's fine. In Mastodon, the choice is very high stakes.

Frontends and relays are far closer to “quacking like an instance.” That’s where your sysop’s power lives. The PDS itself isn’t very powerful - can’t meaningfully limit who you can talk to, for example.

The most effective contributors at your job remove more code than they add? That doesn't sound effective that sounds like digging ditches to fill them. Every line of code removed is a line that was previously added.

We had a library written by a former employee who was a prolific producer of code. He insisted we needed it and spent over a year developing it in company time.

The library was a masterpiece of what if driven development. It was about 50k LoC, and it had 300k LoC of dependencies. It was a nightmare to modify. And no one wanted to take over maintenance so people would submit PRs to the former employee when they did modify it.

I wanted to change something in the library to support a large migration I was in charge of. When I went digging it turned out that we were barely using any of the features in the 2 years since he’d finished it. I replaced the 50k LoC library and 300k LoC of dependencies with 300 lines in less time than it would have taken me to modify the library (a few days).

Every line of code is a liability. A potential security breach. An error waiting to corrupt customer data. A maintenance burden.

Turning inefficient, unreadable code into efficient, readable code often results in an overall reduction in LoC.

High-quality code and high-volume code are highly anti-correlated. Incidentally, low-quality code that is excessively long just so happens to be common complaint with AI-generated code.

Rewriting code to be more compact is orthogonal to productivity.

In a similar way to how a radial burn (https://space.stackexchange.com/questions/44608/what-happens...) may be orthogonal to your trajectory but still may be necessary to avoid becoming a fireball in half an orbit's time.

How so? Let's say that over a year, a given section of code needs to be read and understood once a month. Taking some time to keep the code succinct and free of distraction will increase productivity all those occasions, as well as the rest of the lifetime of the system. Say the next decade.

How is that not efficient?

Which is not what is being discussed. Often rewriting code to make it more understandable makes everybody more productive.

Simplification usually requires the most effort and results in simple and elegant systems easy to understand and maintain with reduced error surface.

So overall increases productivity by a lot

you have evidently been blessed to work only in places with acceptable level of quality code and above.

Or he's the one bringing down quality and productivity.

non-coding manager spotted

> The most effective contributors at your job remove more code than they add?

Yes.

> That doesn't sound effective that sounds like digging ditches to fill them.

It sounds effective to me, like removing garbage from sidewalks so people can walk straight instead of walking around the trash.

> Every line of code removed is a line that was previously added.

Correct. Today I cleaned up

  if (a || b)
    return true;
  if (c)
    return true;
  if (d)
    return true;
  return false;

to

  return a || b || c || d;

and contributed various other negative lines of code in multiple areas.

Every line of code removed is a line that was previously added.

Do you have any experience coding before LLMs?

Written exactly like that, yours is obviously cleaner.

But, if that original code had comments and traceability of each condition and return to a specific domain scenario, you would be doing a disservice by collapsing it to the one flat boolean expression. In that case, it may be better in its expanded form, and you should let an optimizing compiler do the collapsing.

There were no comments.

If there were comments for each conditional, it should still be refactored as

  return a || b // comment 1
    || c // comment 2
    // long comment 3
    // on multiple lines
    || d;

Many years ago, "lines of code" was the classic example of nonsense management metrics. Today, there are somehow HN users who argue that lines of code is indeed a good metric and ask "But what if the code had comments?" as if they have never seen comments interleaved with code.

> In that case, it may be better in its expanded form, and you should let an optimizing compiler do the collapsing.

This is nonsense. This optimization is not about compiler optimization for efficiency. It's an optimization for human readability and maintainability.

FWIW, I'm no advocate of "lines of code", or really any KPIs at all. All I'm saying is context matters.

Such branches could make sense if the conditions have to do with underlying domain concepts, but you expect the outcomes to be revised. It could just be a moment-in-time accident that they are all returning True right now.

This kind of tension is also where you often see indirection via configuration files or other auxiliary data structures. Or in the old days, things like bit fields instead of booleans, so that merging the conditions would encode different small integers to use as lookup table indices.

> That doesn't sound effective that sounds like digging ditches to fill them. Every line of code removed is a line that was previously added.

Because they were added doesn't mean they were needed and even if the same person added and then removed them, it doesn't mean they are digging ditches to fill them.

The idea that "I would have written a shorter letter, but I did not have the time" also applies to code, and sometimes later you are blessed with more time than you had when implementing something under deadline pressure.

> Huh? If they weren't needed then adding them was unnecessary and a waste of time.

My previous reply already addressed this?

I can't help but think you are being purposefully obtuse if you can't acknowledge the concept of developers creating known (and hopefully temporary) technical debt due to various forms of deadline related time pressure or changing requirements.

Old guard status games be like

> The most effective contributors at your job remove more code than they add

Perhaps they tackle non-code-editing tasks like architecture, design, mentoring and code review (think staff and principal tasks)

> Every line of code removed is a line that was previously added

Yes. This os not a failure. Code has a surprisingly short half-life.

It’s not a failure that resources were spent writing code that was not needed?

Maybe it was temporarily needed, but the assumptions around it has changed and now it's unneeded. Then people built on top of that not understanding that they could simplify the whole system, and only later was that option discovered.

What would you keep from this?

It's only a failure if perfect information was available at the time, an impossibility for most people.

Write one (system) to throw away...

It's all about YAGNI. Programmers try to be smart covering cases no one thought about, reviewer is happy that corner cases have been implemented, artificial tests report all good. But it's just more to read when you have to change the code.

I definitely agree with the GP, and the point is that most often someone else (or an LLM) added all those LOC that are removed to make the system sensible.

… by some fool who didn’t know what they were doing, since evidently the same behavior could be done with less.

Thought experiment: if you can solve a problem with 100 lines of dependency free code, or with 10,000 lines of code that depends on hundreds of things - which is better?

There's an obvious answer of course. And that is the direction that these effective senior engineers move towards.

Numbers feels like outliers.

Not everybody is good at their job, or requirements changed over time.

Deleted code is debugged code.

You think stock dividends pay out 4x the amount of money that the company pays for salaries?

No parents on HN? The new parental controls are everything I could ask for.

Nobody wants to hear "no". The way you say "no" without saying it is by turning "no" into an option, and attaching costs to options.

"no, I won't be able to make it in time" would be "I can confidently deliver in time if I have X, and we save Y and Z for later."

One hedge I always used to make was, "I think we have all the information we need for now. We'll get you an estimate within 3 business days."

And then I'd sit down and bust my ass trying to find out if it was feasible or not. :)

If it wasn't, we could always come back with a lesser approach and people seemed to be happy with that. ("It turns out Android doesn't widely support [feature x] so we recommend [feature y] instead.")

Exactly this. I'm in a situation where I have to tell a customer that we won't be able to do the thing that I've spent a long time investigating.

My answer won't be "no, we can't do it." It'll be a form of "we have to use this alternate method to get to the goal, how does that affect your budget?"

Well said, and on the flip side the strongest signal that your management sucks is their absurd sense of entitlement and inability to handle "no" correctly. Their lack of curiosity and ambition will cause the business to miss out on so many opportunities.

A naive junior shouldn't stump them, but it really does happen all the time. If all they have to do is ask what it takes to flip it to a "yes", the same information is communicated. The only thing ever truly at stake was someone's ego.

> Nobody wants to hear "no"

Nonsense. The client that made me a job offer as CTO listed the fact that I wasn’t afraid of saying ‘no’ to unreasonable requests or unrealistic deadlines one of the things he valued the most in my work. He had plenty of experience with contractors that would always say yes, promise anything and then find themselves unable to deliver because they underestimated the complexity of the task.

Saying no is what makes a professional so valuable. Of course you always want to offer alternative approaches.

> Nobody ever, ever, wants to hear "no".

Frankly, that's toddler level thinking.

While there are certainly people who are rich enough and spoiled enough that they have probably never been meaningfully refused anything in their lives, that produces terrible people, and absolutely everyone needs to learn how to accept being told "no" when "no" is the correct answer (or a reasonable one).

“AI Engineer” is already out-of-date. You need to be an “AI GTM engineer”.

OpenAI reported ~$20 billion annualized revenue for 2025, up from $6 billion the year before.

And that covers their model training and infrastructure costs?

Is that the case? What about gpt 4.5? o1-pro?

with revenue >2x cost, they can afford to have a miss now and then

If you have a machine that reliably takes $1 and makes $2 you raise debt not equity

care to elaborate? if my machine is doubling my money, why do I have to raise debt?

Presumably there is some time component, i.e you need to use the machine quickly or risk losing it.

Also, it's better to double $2 instead of $1, and then pay back that $1.1 and end up with $2.9 instead of $2.

But it was a more facetious comment than I would have preferred to make, I actually went to delete it but you got in too quickly.

There are many reasons it's wrong, too, eg. at some level of risk debt becomes more expensive or impossible

But the intent of the comment was to say that if you owned as sure a thing as the GP proposed you'd do what you could to avoid selling parts of it.

So their CFO's publicly voiced concerns are unwarranted?

The efficient market hypothesis has taken a real beating in the age of tech industry anti-gravity valuations.

until it doesn't.

scaling laws are a power law, you can only stay ahead for so long when each minor improvement gets exponentially more expensive

exactly