Live data from Hacker News

"Maybe later" was a feature

arnorhs.dev

21–30 of 37 posts

Re: "Maybe later" was a feature

#21

Everything is search. Software development is search through the space of useful/interesting automations. Business is search for product market fit (at the intersection of expertise, capital, problem, etc.) Writing is search for lossless, efficient idea transfer. AI software development is more search . If we search more, will we find a bunch of garbage? Hell yes. We'll find a TON of garbage. That's not new, though.…

One of my favorite things about AI is that I don't have to execute the curation and criticism at the "page of monospaced text" stage to anywhere near the degree, difficulty, or criticality. I love being able to build it, try it, say "No, no I don't think I will do this, this is amazingly awful"

Funnily enough, I live for the page. I would love to do my whole job with pen and paper and ignore the computer even.

Re: "Maybe later" was a feature

#22

Earlier quoted context omitted.

One of my favorite things about AI is that I don't have to execute the curation and criticism at the "page of monospaced text" stage to anywhere near the degree, difficulty, or criticality. I love being able to build it, try it, say "No, no I don't think I will do this, this is amazingly awful"

Funnily enough, I live for the page. I would love to do my whole job with pen and paper and ignore the computer even.

I actually in a lot of ways agree with you, I could probably do my job via paper letters :) but especially for more UI-heavy work which I'm pinch hitting on it's really difficult for me to translate large features from page to reality for that kind of curation.

Re: "Maybe later" was a feature

#23

Everything is search. Software development is search through the space of useful/interesting automations. Business is search for product market fit (at the intersection of expertise, capital, problem, etc.) Writing is search for lossless, efficient idea transfer. AI software development is more search . If we search more, will we find a bunch of garbage? Hell yes. We'll find a TON of garbage. That's not new, though.…

I agree with this take.

My immediate thought on reading the piece was along the lines of, “Yeah, but lots of the people who pick what we should work on aren’t very good at picking the right things to work on, and even the ones who are a bit better at it generally can’t do it consistently.” (And I’m not implying I’m better at it.)

So in that sense, being able to simply build more - perhaps a lot more - of what’s on the backlog gives you a much better chance of implementing some of the ideas that will be winners.

Re: "Maybe later" was a feature

#24
I agree, but I think this is a skill in all parts of life. Some design has always been add, add, add. The skill to remove and simplify has always been valuable, but few do it.

In weight loss, many people take the approach of add and it doesn't work. Do what you are doing now and take this pill or run further or do more. But mostly the secret is eat less.

In design and engineering, it's often removing things instead of overcomplicating them.

In communication, it's often, remove lots of your side points and just focus on your core argument.

We may have removed a constraint that allows people to do more, but the skill has always been to choose, prioritize and remove the things that are making it worse

Re: "Maybe later" was a feature

#25
post #12
post #9

Doesn't this just mean we need to get better at the active deconstruction and disassembly process? Like it's too easy to build, so we build more things we realize later that we shouldn't. Now, a comparable energy budget we used to use "deciding what to build" (because labour was scarce) is now energy we can divert toward "unbuilding stuff that was a mistake". I'd much rather learn to live in the latter world. That wo…

> Now, a comparable energy budget we used to use "deciding what to build" (because labour was scarce) is now energy we can divert toward "unbuilding stuff that was a mistake" The hard part is that you very quickly become Salesforce or Jira or . You have thousands of users who love your product and pay lots of money and find the features absolutely essential to their workflow. Everyone says your product is bloated and…

Great point. It's probably obvious from my take that I build a lot of bespoke software, and have blind spots about the pitfalls of building at scale :)

Re: "Maybe later" was a feature

#26

Sometimes it is, but sometimes it isn’t. I can remember plenty of times in my career there were some “nice to haves” that we didn’t get to, and not having them continued to waste our time over and over again as we kept putting it off. Time saving work for our software lifecycle that we spent so much time working around. Some of those things we finally did get to, and then spent the next few months wondering why we ha…

Yeah, this right here. It's a cute and pithy blog post, but it's one-dimensional.

Backlogs may have plenty of dead-ends, but there's just as likely the same amount of legit work that would be useful. For every company with a security breach, there's probably a related ticket that got pushed to the back burner because it wasn't part of the core product roadmap.

Re: "Maybe later" was a feature

#27
post #15
post #6

Definitely agree with this. Even without a large backlog, one of the things I find working on my personal project/product where I'm simultaneously the engineer/designer/project manager is it's really easy to ask the LLM to implement an idea I've been mulling for an hour or two, it one-shots it and I'm happy, and then a week or two later it starts to dawn on me that the feature was maybe not a great idea. Which isn't…

The good thing is since the feature was cheap to implement, you can just say "this was a bad idea" and remove it, as long as adding that feature wasn't a one way decision. People are typically more reticent to remove things that were hard to implement, even if that's the right thing to do.

That's the problem, even with an LLM, removing a feature two weeks later can be a nightmare because things have grown to depend on it. In a way it's even harder because the velocity of stuff piling in is much greater.

Re: "Maybe later" was a feature

#29

Sometimes it is, but sometimes it isn’t. I can remember plenty of times in my career there were some “nice to haves” that we didn’t get to, and not having them continued to waste our time over and over again as we kept putting it off. Time saving work for our software lifecycle that we spent so much time working around. Some of those things we finally did get to, and then spent the next few months wondering why we ha…

+1, I can think of many things in my career that could have been that much better if we had the time and resources to do all the bells and whistles that we wanted.

Re: "Maybe later" was a feature

#30
post #18

Earlier quoted context omitted.

One of my favorite things about AI is that I don't have to execute the curation and criticism at the "page of monospaced text" stage to anywhere near the degree, difficulty, or criticality. I love being able to build it, try it, say "No, no I don't think I will do this, this is amazingly awful"

I agree but the practical cost is most heavily paid in a collaborative work setting. Now everyone at all layers of a company is doing build prototype exploration but without the intermediary internal-filter check. Instead, these explorations get a straight line to production, for reasons I'm not exactly sure. Because it can I guess?

That's the part that surprises me. I have only ever shared one prototype I made with AI, and only because we were presenting on how we were exploring AI use and with constant mention that it was a proof of concept prototype.

I feel like putting any prototype, even if it was hand written, would be really risking my credibility if I put it into production without having it at least to the point that it wouldn't matter if it was vibe coded, via a few weeks of using the project myself.

Post reply on HN