HN user

hughdbrown

338 karma

online: { stackoverflow: "http://stackoverflow.com/users/10293/hughdbrown", github: "https://github.com/hughdbrown", linkedin: "http://www.linkedin.com/in/hughdbrown" }

Posts1
Comments171
View on HN

I used this entire HN discussion as the input to a design/task SKILL.md. I asked Claude to prepare the design document and a task list. When it was done, I asked it to implement the task list.

I got this: https://github.com/hughdbrown/visualize-grid-layouts.git

You can follow how this all happened by looking in `docs/design/`.

The SKILL.md had this description:

``` Collaboratively designs a new software feature with the developer. Explores the existing codebase to ground all technical decisions in the project's actual architecture, conventions, and dependencies. Produces two deliverables:

1. *Product Requirements Document (PRD)* — what the feature does, technical decisions, how it operates, and ordered implementation stages.

2. *Detailed Task List* — within each stage, test-first scoped steps covering tests to write, code to implement, config changes, environment variables, dependencies, and documentation.

Both deliverables are written to files in the project for reference during implementation. ```

You can get Claude to produce the skill for you, too.

I am not understanding this.

Propane does not freeze anywhere near -60C. Wikipedia [1] says it freezes (liquid to solid) below -187C and boils (liquid to gas) above -42C.

Propane is probably unusable as a fuel below -42C because there is no vapor leaving the tank [not within my experience]. That is different from the propane being a solid.

[1] https://en.wikipedia.org/wiki/Propane Melting point −187.7 °C Boiling point −42.25 to −42.04 °C

This is really interesting, but I need the highlights reel. So I need a script to summarize Hacker News pages and/or arbitrary web pages. Maybe that's what I want for getting the juice out of Medium articles.

I was about to call fake on this -- Americans from south Jersey are largely unfamiliar with the present perfect and would not say "[I] have never heard of" but "[I] never heard of" instead.

But it turns out this grammatical cue is an effective way to discover that the comment is not about an American south Jersey but a British one.

Yeah, but there is a distinct advantage to using a standard.

Suppose you want your agent to use postgres or git or even file modification. You write your code to use MCP and your backend is already available. It's code you don't have to write.

Odd. When I look at it, the first item is my own suggestion for debugging:

In my experience, the most pernicious temptation is to take the buggy, non-working code you have now and to try to modify it with "fixes" until the code works. In my experience, you often cannot get broken code to become working code because there are too many possible changes to make. In my view, it is much easier to break working code than it is to fix broken code.

I am not sure I believe the numbers shown here. More jobs offered in Rust than C++? I would not think so.

I think that many of the hits on 'rust' in the job postings are actually 'trust': ```

>> import requests

>> page_id = 42919502 # Feb 2025

>> url = f"https://hn.algolia.com/api/v1/items/{page_id}"

>> resp = requests.get(url, headers={'Accept': 'application/json'})

>> data = resp.json()

>> sum('rust' in child['text'].lower() for child in data['children'])

42

>> sum('trust' in child['text'].lower() for child in data['children'])

13

```

Check out the gist here: https://gist.github.com/hughdbrown/f41f5f3c072067c2351460d8d...

It shows that 30-40% of 'rust' is really 'trust': ```

-------------------- 2025-02-01: rust = 42 trust = 13

-------------------- 2025-01-01: rust = 28 trust = 10

-------------------- 2024-12-01: rust = 32 trust = 14

-------------------- 2024-11-01: rust = 28 trust = 8

-------------------- 2024-10-01: rust = 36 trust = 12

-------------------- 2024-09-01: rust = 32 trust = 9

-------------------- 2024-08-01: rust = 36 trust = 10

-------------------- 2024-07-01: rust = 33 trust = 11

-------------------- 2024-06-01: rust = 36 trust = 15

-------------------- 2024-05-01: rust = 42 trust = 14

-------------------- 2024-04-01: rust = 30 trust = 12

-------------------- 2024-03-01: rust = 32 trust = 12

-------------------- 2024-02-01: rust = 25 trust = 10

-------------------- 2024-01-01: rust = 22 trust = 8

```

I have a python repo specifically for finding Rust action in Who Is Hiring: https://github.com/hughdbrown/who-is-hiring

This puzzler, like many other difficult-to-spell food terms (such as hors d’oeuvre), also has its derivation in the French language.

That's the whole story: people who don't know French (or any foreign language, likely) cannot spell a French word.

When 99.9% of posted jobs are fake (including in HN's Who's Hiring)

Okay there a lot of fake jobs, maybe not as high as 99.9%, though.

But what's the basis for saying that "Who's Hiring?" is fake? Why would a business seek out a relatively lower traffic job venue, field the traffic of submissions, and then ghost everyone who applies (or whatever is done by 99.9% fake jobs)? Why wouldn't employers just save themselves the effort and do nothing?

Your JSON schema says this: ``` "location": "City, State", ... "workField": "Industry Field" ```

But: `location` can be an array: ``` "name": "Shopify", "location": ["Ottawa, ON", "Toronto, ON", "Montreal, QC", "Waterloo, ON"], ```

and `workField` is an array: ``` "workField": ["Banking", "Financial Services"] ```

And if it is for Canada, why identify locations as `"location": "City, State"`?

This scientific-academic synopsis gives me only the faintest idea of what kind of animal this might be:

A new supergiant species of Bathynomus A. Milne-Edwards, 1879 from Vietnam is described. Bathynomus vaderi sp. nov. is characterised by its wide, rectangular clypeal region with parallel lateral margins, concave distal margin, and narrowly acute apex; the distally narrowing and posteriorly curved coxa of pereopod 7; and the presence of 11 upwardly curved pleotelson spines.

"Curved coxa of pereopod?" "Curved pleotelson spines?" "Wide, rectangular clypeal region"?

He is currently a naturalized American citizen. For him to lose that status, he would have to be stripped of it by a legal process, commonly called denaturalization. [0] It is not enough for people to accuse you of having committed fraud in naturalization.

There’s no valid path to naturalization

I think it is correct to say that your naturalized status can be unwound if a prosecution against you is successful, but until that happens, you are considered an American citizen. Presumption of innocence and all that American stuff.

[0] https://en.wikipedia.org/wiki/Denaturalization

Let me reformulate then.

Take the wikipedia article on debugging[1]. The first sentence identifies what debugging is: "In engineering, debugging is the process of finding the root cause, workarounds and possible fixes for bugs." I'd say this is implicitly about taking broken code and finding the error in it.

The second paragraph is clearer on this point:

For software, debugging tactics can involve interactive debugging, control flow analysis, log file analysis, monitoring at the application or system level, memory dumps, and profiling. Many programming languages and software development tools also offer programs to aid in debugging, known as debuggers.

All of the debugging tactics listed are about working with an existing broken piece of code.

Further sections on debugging tools, debugging process ("debugging process normally begins with identifying the steps to reproduce the problem"), and techniques are also about working with broken code.

Completely rewriting the code is certainly a way to resume progress on a software project, but as the practice of debugging is imagined, rewriting is not debugging.

[1] https://en.wikipedia.org/wiki/Debugging

The quickest solution, assuming learning from the problem isn't the priority, might be to replace the entire chain of lights without testing any of them.

So as a metaphor for software debugging, this is "throw away the code, buy a working solution from somewhere else." It may be a way to run a business, but it does not explain how to debug software.

In my experience, the most pernicious temptation is to take the buggy, non-working code you have now and to try to modify it with "fixes" until the code works. In my experience, you often cannot get broken code to become working code because there are too many possible changes to make. In my view, it is much easier to break working code than it is to fix broken code.

Suppose you have a complete chain of N Christmas lights and they do not work when turned on. The temptation is to go through all the lights and to substitute in a single working light until you identify the non-working light.

But suppose there are multiple non-working lights? You'll never find the error with this approach. Instead, you need to start with the minimal working approach -- possibly just a single light (if your Christmas lights work that way), adding more lights until you hit an error. In fact, the best case is if you have a broken string of lights and a similar but working string of lights! Then you can easily swap a test bulb out of the broken string and into the working chain until you find all the bad bulbs in the broken string.

Starting with a minimal working example is the best way to fix a bug I have found. And you will find you resist this because you believe that you are close and it is too time-consuming to start from scratch. In practice, it tends to be a real time-saver, not the opposite.

Canadian-born, 26 years in US:

- 65% English, 10% Dutch, 9% Russian

- 90% English, 3% Spanish, 2% German

- 89% English, 5% Spanish, 3% Russian