samstokes

Code being expensive would be one reason to plan, but hardly the only one. Some other reasons: cost of failure (don't leak customer PII), maintenance, unclear requirements, unclear success criteria.

Most of the comments so far are responding to the first few paragraphs of this article. On reading further, I thought this was actually an unusually balanced take on how to use LLMs in a software org.

I can't help but cringe at the "cost of code is now zero" meme that this article repeats because in my experience the biggest cost of code was always the activities around the code - planning, communicating, reviewing, validating. This author, despite repeating the meme, seems to agree. Their emphasis on writing PR descriptions and specs for humans rhymes with my experience and it sounds like a nicer way to work than chasing some dark factory fever dream.

I also thought the "Two Modes of Working" section was useful. People get wildly different results from coding agents depending on how they use them, but I've not seen a lot of actual guidance on when to do X vs Y.

Personally, I've been using what the author calls "sidekick mode" since last October - before the supposed "AI got good now" threshold - and agree it's a more useful default for an engineer than "delegate mode".

I don't have an MBA or anything but is it common practice to describe "revenue - capex" as "profit"?

The post says they wrote a custom harness that orchestrates work between multiple separate model invocations. That is different from running Claude Code (which is a specific existing harness around the Claude models).

The post takes a while to get around to saying that, and could have included more detail besides the workflow diagram and table (which they flag as only "an example of" such a harness), but it does answer the question. It's a different kind of tool because it's a model rather than a harness+model pair.

I wouldn't agree that LLMs are a higher level of abstraction, but I've found they do help me think at a higher level of abstraction, by temporarily outsourcing cognitive load.

With changes like substantial refactors or ambitious feature additions, it's easy to exceed the infamous "seven things I can remember at once":

  * the idea for the big change itself
  * my reason for making the change
  * the relevant components and how they currently work
  * the new way they'll fit together after the change
  * the messy intermediate state when I'm half finished but still need a working system to get feedback
  * edge cases I'm ignoring for now but will have to tackle eventually
  * actual code changes
  * how I'm going to test this

  * wiring a new parameter through several layers
  * writing a test harness for an untested component
  * experimentally adding multibyte character support on a branch

The main benefit is to defer the concern until I have a mostly working system. Then I come back and review its output, since I'm still responsible for what it delivers, and I want better than "mostly working".

Does it? Claude the chatbot is available for free, and it can write code, but Claude Code is a separate product that as far as I know is only available on paid plans. Source: https://claude.com/product/claude-code

Bit of a buried lede:

For a limited time we're including Codex with ChatGPT Free

Is this the first free frontier coding agent? (I know there have been OSS coding agents for years, but not Codex/Claude Code.)

https://five-eights.com

This seems lazy. It's ad hominem but not even, since you don't know what inept bureaucracy I am defending. Is there any argument that you couldn't level this accusation at?

One could interpret the title that way, but not consistently with the rest of the article, which includes assertions like "in the realm of societies, governments and economies, systems thinking becomes a liability".

I think there's plenty to agree with in the article's descriptions of failure and hubris. What the critical commenters are taking issue with is that the article blames those symptoms on a straw man. It's a persuasive article, not a historical review, so it's reasonable to debate its conclusion and reasoning as well as its supporting evidence.

The title of the article is an intentional conflation of "systems thinking" with "magical thinking", which is not a compliment.

What an interesting and strange article. The author barely offers a definition of "systems thinking", only names one person to represent it, and then claims to refute the whole discipline based on a single incorrect prediction and the fact that government is bad at software projects. It's not clear what positive suggestions this article offers except to always disregard regulation and build your own thing from scratch, which is ... certainly consistent with the Works In Progress imprint.

The way I learned "systems thinking" explicitly includes the perspectives this article offers to refute it - a system model is useful but only a model, it is better used to understand an existing system than to design a new one, assume the system will react to resist intervention. I've found this definition of systems thinking extremely useful as a way to look reductively at a complex system - e.g. we keep investing in quality but having more outages anyway, maybe something is optimizing for the wrong goal - and intervene to shift behaviour without tearing down the whole thing, something this article dismisses as impossible.

The author and I would agree on Gall's Law. But the author's conclusion to "start with a simple system that works" commits the same hubris that the article, and Gall, warn against - how do you know the "simple" system you design will work, or will be simple? You can't know either of those things just by being clever. You have to see the system working in reality, and you have to see if the simplicity you imagined actually corresponds to how it works in reality. Gall's Law isn't saying "if you start simple it will work", it's saying "if it doesn't work then adding complexity won't fix it".

This article reads a bit like the author has encountered resistance from people in the past from people who cited "systems thinking" as the reason for their resistance, and so the author wants to discredit that term. Maybe the term means different things to different people, or it's been used in bad faith. But what the article attacks isn't systems thinking as I know it, more like high modernism. The author and systems thinking might get along quite well if they ever actually met.

You're right, you're not his caregiver, or obliged to be. Sorry if it sounded like I was suggesting that.

I doubt the staff would expect or pressure you to take responsibility for him. If anything you might have trouble getting them to even discuss his case with you - different states vary but in some cases they won't share case details without explicit permission from the patient. (If that sounds frustrating given your first hand experience of his symptoms and their progression - I sympathise.)

The support groups in particular may be useful despite that, just because you mentioned he's a housemate, so he may continue to be in your life. When I attended there were spouses, parents, but also just friends who wanted to help out their friend and understand what they were going through, without adopting responsibility for them.

I'm sorry this is happening to you and to your friend. I have some similar experience and want to share some advice I wish I had heard earlier.

It sounds to me like you did the right thing - situations like this can get worse if left unchecked and have serious consequences for the person in question and those around them. I'm not diagnosing your friend - I'm no expert, and various disorders can have those symptoms - but there are resources out there about (e.g.) mood disorders [1] that might give you some perspective and advice.

Treatment can help, and can make a huge difference. Hospitals are unpleasant but can sometimes be the only way for someone who needs treatment to receive it. I am certainly no legal expert, but I think if he was forcibly committed to a hospital and police were involved, he's unlikely to be released without accepting treatment.

You might find it helpful to join a support group for caregivers (e.g. [2]). In my experience it's common for friends as well as family members to attend those. People will offer resources and advice, as well as just sharing their experience, which can provide perspective and help with feeling lost.

Also consider (if you're not already) finding a therapist of your own. People in one of these episodes can push boundaries, say things to you they wouldn't normally mean, and generally be hard to be around while maintaining your own health and boundaries - particularly if you're invested in trying to help them.

[1] https://www.dbsalliance.org/education/ [2] https://www.dbsalliance.org/support/chapters-and-support-gro...

The same artist has some excellent tutorials on how to implement a lot of those effects: https://bleuje.com/tutorials/

I wanted to see whether this sound could also be used to amuse my cat, and I can conclusively report that she is not amused.

This makes some good points about misuses of these AWS services, but the title is misleading. The article is actually more like "tempting but inadvisable use cases for AWS services".

My employer uses three of these heavily (ElastiCache, Kinesis and Lambda) and we get quite a bit of leverage out of them.

ElastiCache in particular surprised me. At first glance I mistook it for a transparent (and expensive) wrapper around sticking Redis on an EC2 instance, but if your usage is heavy enough to need multi-node clusters (e.g. read replicas or full Redis Cluster), its orchestration features are pretty useful. We can resize instances, fail over to a replica, and reshard clusters, with zero downtime, by clicking a button (or a one-line Terraform change). And never having to install security patches is nice too.

It certainly is expensive, though. (But if you're not willing to pay a premium for managed infra, what are you doing on AWS in the first place?)

I may have lost people with lower confidence in their abilities and a greater fear of failure.

That HBR article I linked in the other thread actually addresses that. Their survey indicates that people are deterred less by lack of confidence in their abilities, and more by lack of confidence in your process to assess their abilities in the absence of a credential. The top-given reason (from both women and men) for not applying was “I didn’t think they would hire me since I didn’t meet the qualifications, and I didn’t want to waste my time and energy.”

Now maybe you're actively looking for people who hustle and won't take no for an answer (which isn't quite the same thing as "confident in their abilities"). Maybe that's your team culture, or your company culture. That's certainly your choice if so.

And kudos for doing that - but what about candidates who don't read Hacker News (or happened not to see this exact thread)? HN isn't exactly the most welcoming environment for women either.

In case you're not aware, there is evidence [1] that this sort of "required but not really" job posting deters a lot of people, and especially women, from applying even if they would actually meet the (unstated) actual requirements.

Making it explicit that you will accept "experience and a good resume" in place of a CS degree might increase the diversity of your applicant pool.

[1] https://hbr.org/2014/08/why-women-dont-apply-for-jobs-unless...

That's the "monitor from the customer's point of view" approach the OP alludes to. If you use tools like Honeycomb [1] that can easily and routinely answer questions like "show me the 95th percentile latencies for each of the 10 customers experiencing the worst latencies", then situations like you're describing are a lot easier to discover.

[1] https://honeycomb.io. Disclaimer: I used to work for them.

The glowing tower contains molten salt, used to store the focused solar energy. [1] I never knew that was a thing until I too drove past it. It was one of the more memorable sights on a 3000 mile road trip.

[1] https://en.m.wikipedia.org/wiki/Solar_thermal_energy#Molten_...

How about describing the intended use of the collections? E.g.

    var usersByUsername map[string]*User
    var usersToEmail []*User

Since this has become yet another discussion about "the pipeline problem" instead of a discussion about a tactic major tech companies are using to duck accountability, this Twitter thread might be informative: https://twitter.com/Code2040/status/1092853501766467585?s=19

It's from an organisation (Code2040) that spent 10 years working to build a pipeline of qualified Black and Latinx candidates, only to find many companies had hiring processes that wouldn't hire their candidates anyway.

You've italicised "pipeline" as if you believe this is a novel insight, but actually it's very common to dismiss diversity and inclusion efforts by redirecting attention to "the pipeline problem". Unfortunately there is evidence that the pipeline is far from the only problem, and even after successful interventions to swell the pool of qualified diverse candidates, companies' representation is still extremely skewed, and those candidates still encounter hiring barriers that other demographics do not.

Here's one thread from an organisation that spent 10 years working on the pipeline and found many companies wouldn't hire their candidates: https://twitter.com/Code2040/status/1092853501766467585?s=19

(Edit: gah, pasted the same link twice instead of the Twitter thread I meant to post)

And some more links on the "pipeline problem": http://isitapipelineproblem.com

The submission title is misleading (“License Changes for Confluent Platform (Kafka)” at time of commenting) - the license changes do not apply to Kafka itself, as the article specifically states.

WHY NOT BOTH? (OP here. I figured the prominent company branding was sufficient disclaimer that yes, we do have a product to sell; but we built the product because we see a better way of doing things, rather than vice versa.)

TL;DR: use probabilistic logging (x% chance of logging, with x chosen by dev for each log statement) instead of importance levels (ERROR, WARN, INFO, etc) to keep common events from flooding log files. Is that it?

Basically. But if your volume is high enough to have this problem, you're probably past the point where humans reading logs is a reasonable use of time, so you need machines to help humans consume the logs (e.g. to produce summary statistics and graphs).

So as well as probabilistic logging, annotate the logs you do emit with the probability of emission. That way the machines consuming the logs can continue to account for the logs that were dropped.

"Terrible idea" is a rather aggressive way to dismiss hours of someone's work because you don't like the name.

a) You don't have to take VC funding to be a startup.

b) If you do take VC funding, you don't have to adopt VC culture too. (VCs don't even get a board seat until the series A.) Some startups do adopt VC culture anyway, but it's not a forgone conclusion.

That's true, but any incentive structure at all has similar hazards. (Ever seen the software quality bar lowered in order to meet a deadline?) So long as the company does have standards, and processes it trusts to enforce those standards, it's possible to guard against that failure mode, just as you'd guard against any other employee misbehaviour.

If you do have employees (or execs) bypassing the process or lowering their standards in order to meet short term goals, that in itself is a cultural problem the company would want to address.

Edit: it's worth noting that every manager who has more planned work than they can execute with their current head count already has a short-term incentive to lower their hiring bar and get someone in the door quickly. Managers get measured on executing to plan, so that's probably a stronger incentive than any bonus structure.

So my point isn't that lowering the bar to game the system will never happen, but that it's a failure mode that already occurs and that the system should already have defences against.