What "trick of the trade" took you too long to learn?
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?
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.
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.
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!
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.
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.
Observe as much mastery as possible at what you would like to do.
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.
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 --> …
Git bisect. For certain classes of software regressions, it makes life easier. Many people (me) don’t know this feature exists and end up reinventing the wheel on their own. https://git-scm.com/docs/git-bisect
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.
Make use of L1 wetware cache by learning how to do common things and dont make AI do them.
Always have a stack of deli cups handy.
read something new every day before going to bed
journal before you start your day
buy some sort of electric kettle
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
Most things you see in the world are a reflection of self.
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!
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.
A shell script has to start with "#!" with no spaces before it. I spent about a week figuring that out 25+ years ago.
You can memorize the correct opening moves in chess. For maybe my first year playing chess, I just YOLO'd the opening moves. My judgement there was probably not much worse than the rest of my play, but with other players playing engine moves in the opening, I was probably in a losing position early on in most of my games. I gained about, I think, 100 ELO after learning some 3 or 4 move opening combinations.
When you buy a house and get a mortgage, you are going to be paying MUCH more in interest (than expected). Over the course of the mortgage, you are going to be paying MUCH more than the sticker price. Between closing costs and taxes and fees maintenance, you will need more cash than you think.
My advice is look at the numbers very carefully and choose something that is (below) or fits your budget. Sudden financial issues like the loss of a job or new vehicle purchase can put a big strain on all this.
Always fix errors in reverse order, from the bottom of the file to the top. That way the line numbers don't change as you go.
If you're selling something physical, always have free shipping. Include the price of shipping in the price of the product.
I guess people now expect free shipping via Amazon and boy does this make things sell faster.
Understanding the concept of Opportunity Cost and how it applies to everything in life.
- Buying a house: Is this the best return I can get on a downpayment. (Spoiler: It is not).
- Accepting a specific job offer: Is this the best way to spend 8 hours a day?
- Not making a successful trade, is as much as a loss than losing money explicitely on a trade.
Making sense of probability and statistics and incorporating them in day to day life.
Claude Code recently showcased how powerful it can be when you don’t have to memorize commands. My AI agent works similarly. It finds the right CLI commands instead of relying on Playwright or an MCP server to perform tasks. What’s interesting is that even the agent doesn’t know many commands upfront; it simply uses the help option to discover what’s available.
Excellence in anything is a byproduct of having fun. Fun is a byproduct of understanding. Understanding is a byproduct of going slow. Going slow is a byproduct of curiosity. Curiosity is a byproduct of saying "I don’t know," of shunning beliefs and attending to what is in front, with zero baggage or impositions of your own—shunning the ego in the moment, moment by moment. Excellence comes when each piece is as equal as any other, when preference is shunned, when space is created to allow what is in the moment, without resistance, without insistence.
Realizing that buying a house is absolutely not a good investment. And that the whole society is on that narrative to convince more and more people to blindly buy.
Doing the real math is the trick of the trade. The math for owning has been made so that it looks like a good deal while in reality it is not at all. Most people will literally compare mortgage to their rent, or "I sold my house I bought for 500k for 1M$, therefore I made 500k$".
Treat owning as a luxury item. The same way you would own a sport car or travel on a private jet. And do the (real) math. Owning is costing you money.
Most people really cannot tell you what they want in any reasonable way. So expecting good specs for software without a very laborious interview and review process is pure wishful thinking. People "know what they like when they see it", so spend time rapid prototyping.
Smaller and more recent: iTerm has deep tmux support. Just do `tmux -CC` to start your session or `tmux -CC a` to attach to it and you don't have to memorise all the tmux commands.
You should never look at code and say "this should work". If it "should" work it would work. If it doesn't work, you definitely made a mistake. Poke every assumption one by one. Preferably with an interactive debugger.
This may seem obvious but when I was younger I used to spin out in frustration at bugs.
duplicate code is not that bad. reduce duplication over time as you find the common patterns/abstractions, instead of trying to build abstractions that don't fit the use cases
Learn how to stab your colleagues in the back and play petty mean spirited office politics games. That's most of what being employed in this industry actually is, and if you accept that now and optimize yourself around it you can save decades wasted trying to actually get good at doing tangible (albeit economically useless) things.
It's easier to tell the truth then maintain a complex web of lies.
1. Write exhaustive automatic tests against the API you are responsible for.
2. Don't write tests for anything else.
If you are responsible for implementing a server/service, the API is the protocol for the server/service. If you are responsible for implementing a module/library, the API is the public interface to your module/library.
The tests are basically a specification for how any implementation of the API needs to behave. So you can give the tests to another developer, who has never seen your implementation, and they should be able to re-implement everything based on your tests.
“Everything around you that you call life was made up by people that were no smarter than you” Steve Jobs
Id heard this a hundred times, but around 30 years old it clicked and has fundamentally changed how I view things.
good code may not look like you expect
- duplicate code isn't always bad
Sometimes* the same code copy/pasted or repeated is much easier to understand than pulling it all into a subroutine. It seems logical when writing code, but kills understanding when reading code. Predictable is better than compact a lot of times.
- code should fail early
Sometimes "being robust", correcting errors or continuing after an error is the wrong thing to do. When something unexpected happens, failing, and failing quickly might be important.
there are probably thousands of these things. All are opinion, like camelcase sucks and indent should be 4, but not with tab characters.
* not always
It took me two decades to finally decide to memorize "... | awk '{print $1}'" as a command pipeline idiom for filtering stdout for the first column (... "awk '{print $2}'" for the second column, and so on).
All it required from me was to intentionally and manually type it down by hand instead of copy-pasting, on two purposeful occasions (within two minutes). Since then it's successfully saved in my brain.
That pretty much all modalities of resistance training work, no individual training session matters all that much, and what's really important is just doing it consistently for years.