Agree, and I think that's the core of my point.

Not that it's irrational or doesn't make sense to sell tokens for purposes of software dev, but that if tokens were a true game changer for success in software dev, they wouldn't be leading with token sales, the same way they're not leading with token sales for security stuff -- it's more like "Contact Sales".

Something that stands out is that for the strongest use cases, AI companies will prefer to sell the technique as a service rather than its raw output. For use cases where the output is less valuable, tokens are sold. If AI tokens were so magical in creating new value in developing software applications generally, they wouldn't be selling tokens directly. They'd hoard the tokens are use them to dominate SaaS software in any industry they want.

The same way as someone selling an expensive course in the stock market is signaling that they have more to gain by selling the course rather than taking their knowledge and making money in the stock market directly.

12:5712 minutes, 57 seconds on AI coding for real engineers. This has been my most subscribed to course ever. People are going nuts for this. Uh

13:0413 minutes, 4 seconds we're going to have I think around 4,000 4,500 people in there. So, yeah, it's absolutely wild. But if you're enjoying

Matt Pocock https://www.youtube.com/watch?v=mh5XZ-L5SFQ at 13:00

4k x $995 = ~$4 million

During a goldrush, sell shovels.

Comments URL: https://news.ycombinator.com/item?id=48321838

Points: 3

# Comments: 0

Some of the maintenance costs you mentioned are primarily read-only, slam dunk AI use cases. Input from AI to diagnose bugs, trace data flows, and help with reasoning. Tests are something of a gray area in the sense that they are not read-only but they don't affect the logic of the app itself.

The "write" use cases (you mention refactoring and the author seems to primarily focus on writing code) is where the author's point seems to be primarily aimed at.

Definitely agree on the read-only improvements to maintenance. Those are unquestionable slam dunk, high value improvements.

Unfortunately, maintainability is simply bucketed as a "non-functional" requirement.

Maintainability (and similar NFRs) should actually be considered what preserves and enables the delivery of future functional requirements -- in contrast to framing non-functional requirements as simply "how" the software must do what it does vs. the "what"/functional requirements that "actually matter".

From that standpoint, if a steady flow of features/improvements is important for a project, maintainability isn't really a non-functional requirement at all, and amounts to being a functional requirement, in practice, over anything except the shortest of time horizons.

Comments URL: https://news.ycombinator.com/item?id=36488070

Points: 58

# Comments: 18

Also good: "CASHUP" - "Career Advancement over Suitable Technology in the Use of Programming."

TAH syndrome, which stands for "Technology Advancement Hyping."

Comments URL: https://news.ycombinator.com/item?id=35847224

Points: 2

# Comments: 0

https://postimg.cc/TLbvvSzm

https://news.ycombinator.com/item?id=30481230

This is a breath of fresh air. Ever since CNN Underscored started being a thing, I've grown to dislike more and more the swamp of affiliate link promoting content.

Some concent creaters on YouTube for example (like randomfrankp), are able pull it off, but deeply affects the credibility of most content.

https://www.youtube.com/watch?v=l3nn3isshVg - When Delphi reaches the Cloud!

Disclaimer: I'm not a Delphi programmer. This just popped up in my YouTube feed.

When you copy code, ask yourself why you are doing it—and if the same operation is needed in two places, doesn’t this indicate that you need a service in your system?

My boss and mentor Alan Shalloway puts it this way: There are three numbers in software: 0, 1, and infinity. 0 represents the things we do not do in a system (we do those for free). 1 represents the things we do once and only once. But at the moment we do something twice, we should treat it as infinitely many and create cohesive services that allow it to be reused."

It actually came from a 2009 book called "Emergent Design: The Evolutionary Nature of Professional Software Development". Somewhat goes against the grain of the more common wisdom of taking the bullet once or twice. https://en.wikipedia.org/wiki/Rule_of_three_(computer_programming)

Comments URL: https://news.ycombinator.com/item?id=34218921

Points: 4

# Comments: 4

Insecure = no access control/authorization

Direct Object reference = URL

https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Dire...

"Direct Object Reference is fundamentally a Access Control problem."

https://www.law.com/therecorder/2022/03/10/bowing-to-pressur...

https://firstamendmentcoalition.org/2022/02/fac-letter-to-ca...

https://s3.documentcloud.org/documents/21409065/response-to-...

Even if there's enough interest to attract some successful business, I don't think it will fundamentally break out from niche use cases.

Points: 2

# Comments: 3

https://postimg.cc/fVSVkYzq (peak traffic, top of popular subreddits, 1911 active users)

Full resolution screenshots from "Download originnal image" link.

hackernews (695 points)

- https://news.ycombinator.com/item?id=30399881

reddit (46k+ total upvotes)

- https://www.reddit.com/r/InternetIsBeautiful/comments/swq1ch...

- https://www.reddit.com/r/MadeMeSmile/comments/swy4ge/this_ma...

- https://www.reddit.com/r/Superstonk/comments/sx3xqq/257_case...

- https://www.reddit.com/r/bestof/comments/sx2mx6/ujohnnyr1_po...

Comments URL: https://news.ycombinator.com/item?id=30481230

Points: 11

# Comments: 0