Ask HN: What trick of the trade took you too long to learn?

387 points by unsupp0rted ↗ HN
Every week for the last 3 months I’ve learned a new trick when it comes to getting whatever LLM I’m using at the time to produce better output. That’s my trade, but lots of HNers have more interesting trades than that.

In my case, only recently I learned the value of getting an LLM to write and refine a plan.md architecture doc first, and for it to break that doc down into testable phases, and then to implement phase by phase.

Seems obvious in hindsight. But it took too long to learn that that should be my approach. I had been going phase by phase myself- no overarching plan.md for the LLM.

What Trick of the Trade took you too long to learn?

146 comments

[ 2.7 ms ] story [ 127 ms ] thread
I only learned this in the last five years: do less, automate less, do more by hand, and use the limited capability of the manual method to really choose projects that are worthwile, rather than aim for maximum efficiency.
Similar to this: if you want to optimize your productivity*, do so on a timescale of at least weeks if not months or years.

Simple example: Can you get more done working 12 hours a day than 8? Sure, for the first day. Second day maybe. But after weeks, you're worse off in one way or another.

It's easy to chase imaginary gains like automating repetitive tasks that don't actually materialize, but some basics like sleep, nutrition, happiness, etc are 100% going to affect you going forward.

* I actually hate that word, and prefer saying "effectiveness". Productivity implies the only objective is more, more, more, endlessly. Effectiveness opens up the possibility that you achieve better results with less.

How do you maintain tests, in order for LLM edits to not keep breaking things?

  - As a formal test suite in the program's own language?
  - Or using a .md natural language "tests" collection that must pass, which an LLM can understand?

To answer the OP, I learned use different models for reasoning vs. coding.
Writing tests first is a good way to end up with testable code. If you skip that, retrofitting tests is incredibly difficult.
While it can be a useful forcing function, I find it also just fits into a higher velocity workflow in general, one I would describe like so:

1. Make PRs small, but not as small as you can possibly make them.

2. Intend to write at least one nice-ish test suite that tests like 50-80% of the LOC in the PR. Don't try to unit test the entire thing, that's not a unit test. And if something is intrinsically hard to test - requires extensive mocking etc - let it go instead of writing a really brittle test.

3. Tests only do two things: help you make the code correct right now, or help the company keep the code right long term. If your test doesn't do either, don't write it.

4. Ok - now code. And just keep in mind you're the poor sod who's gonna have to test it, so try to factor most of the interesting stuff to not require extensive mocking or shit tons of state.

I've found this workflow works almost anywhere and on almost any project or code. It doesn't require any dogmatic beliefs in PR sizes or test coverages. And it helps prevent the evils that dogmatic beliefs often lead you into. It just asks you to keep your eyes open and don't paint yourself into a corner, short term or long term.

And only write tests against the API you are responsible for.

Never let tests depend on implementation details.

I'll add that retrofitting good tests is almost impossible. Too many people write tests against working code that just tests what they know the code already does. At best these are regression tests. If you write tests first you are forced to think about what you want the behaviour of the software to be before you've gone deep into a solution and forgotten about the original problem.
I'm not disagreeing with you but there's a large number of programmers who viscerally disagree with "test first".

https://www.youtube.com/watch?v=NyiMOmCqu00

Casey is a game programmer.

In tests in a web application/api, your tests can actually be real use cases quite easily and design your api around real use cases.

How would you do that in a game? Check a frame looks a certain way?

I have done proper testing a puzzle game where the game can be represented by abstract state. But modern 3d rending is hard to test well.

I think it's easy enough to design code that is easy to test - simple single-purpose functions/methods that are self-contained and don't change any global state, etc, and obviously you need to document what the input/output guarantees are, and I would normally add assertions at time of coding to enforce those.

Where you are going to run into difficulty in testing is if your APIs are so complex that it's all but impossible to exercise all code paths by testing with different parameters, or if functions have global side effects (bad practice).

Start as early as possible in investing (in index funds) and otherwise being financially savvy. It is very beneficial to realise early on that growing your hard earned money and spending it wisely is way more important as it will in the future lead to some unexpected benefits. Freedom of thought and action!
Call Vanguard: 877-662-7447

An investing prof at Chicago puts this on the whiteboard at the start of semester, saying this is really all most people need to know and this class is unlikely to learn anything in his or any class that will let them, personally, do better.

Get a financial advisor that you trust.
My mistake was not starting early, because the numbers were small and it didn’t seem worth the time. The habit and systems are important to build, so that when the numbers do get bigger it goes to the right place.
Compounding interest is a powerful force.
When I realized that a) `screen` exists and b) what it does, I felt like an utter fool for having gone for years—YEARS—without benefiting from it.
Observe as much mastery as possible at what you would like to do.
That macros ruin everything they touch. I used them extensively for maybe 15 years, stopped adding them, and then a bit later removed them all from my code. My C/C++ code was a lot nicer without them.
I agree, with this as it relates to C/C++, but I *love* rust macros when used judiciously.
Most problems (including analytically intractible ones) can be modeled with a relatively simple monte-carlo simulation. Most simple monte-carlo simulations can be fully implemented in a spreadsheet.

Using timing coincidences in particle physics experiments is incredibly powerful. If multiple products from the same reaction can be measured at once, it's usually worth looking into.

Circular saws using wood cutting blades with carbide teeth can cut aluminum plates.

You can handle and attach atomically thin metal foils to things by floating them on water.

Use library search tools and academic databases. They are entirely superior to web search and AI.

Technical skills will only take you so far in most orgs. Learn to play the soft game.
The big one, for keeping my focus on the power of repeated, consistent action, and prioritizing my "future selves":

What is likely to happen if I do (or don't do) this thing one thousand days (or times) in a row?

Examples:

- exercising 2h per day and eating right --> I'm going to look and feel great and my health will be far better than that of my peers

- Should I buy these cookies along with the rest of my groceries? If I do that 1,000 grocery trips in a row …

- spending 30+ minutes per day reading the highest quality material I can find; taking notes; and figuring out ways to implement the knowledge and ideas I gain --> …

Measure everything. There are two benefits to this.

1. Discarding the bullshit. A consistent practice of weighting assumptions and conclusions on evidence/numbers helps identify biases and motives from other people.

2. Measures allow for value identification and performance. Most people just guess at this. Guessing is wrong more than 80% of the time and often wrong by multiple orders of magnitude.

Most people don’t think like this and find this line of thinking completely foreign, so I often just keep my conclusions to myself. To see a movie about this watch Money Ball.

> What Trick of the Trade took you too long to learn?

"Everything worth doing is worth doing badly"

And as a corollary, every complex system that works came from a simple system that works.

I learned this in programming, but now I apply it on everything from motorcycle maintenance, home appliance repair to parenting.

--

Often the easier way to fix a complex system is to pretend that it could be simpler and then reintroduce the complexity-inducing requirements.

I had a professor who taught debugging as a whole another skill from programming and used to say "Most of programming is starting from an empty editor and debugging until your code works".

The debugging "lab" in Java course (in the year 2000) was one of my transformational after-school classes - where I got a java program which fits within 2-3 pages of print code with a bug and was told to go find it in print for ~20 minutes, then given 40 minutes with a debugger instead.

I'll add, from Soul of a New Machine, "Not everything worth doing is worth doing well."
Always have a stack of deli cups handy.
Make use of L1 wetware cache by learning how to do common things and dont make AI do them.
Environment variables can be expanded at the command line, just like files. Believe I started before it was a thing and never thought to check until twenty years later(?), when I hit the tab key by mistake. :-D
read something new every day before going to bed

journal before you start your day

buy some sort of electric kettle

(comment deleted)
Learning that it is more important to know how to communicate, how to promote myself and the art of persuasion to get ahead than any technical skills I could know.
Easy transfers between different people's iThings with Airdrop. I got my CompSci degree over 30 years ago and yet my 74yo aunt taught me this - the shame!