Excellent points on documenting the intention and design decisions, not just the "what".

I also use the following metaphor using an airplane:

There are three types of documentation:

1. 800 page manual with page 1 being "Congratulations on purchasing your 747!"

2. 10 page "How to change the oil in the engine"

3. 5 item checklist "How to deal with a fire in the engine"

Too many people think documentation is just one of the above. And if you are a developer, #1 feels overwhelming to write but the SREs may only want #3 (and may even help you write it).

I think of this is answering the questions of what vs why. When what is being done is self-evident, that's readable code. When why it's being done is evident, that's good documentation. And, you need both.

"// Divides by 2" is the worst kind of comment and the unfortunate part is that thanks to "AI autocomplete" these will only be merged even more often [raises hand for forgetting to delete this instruction]

This is also why you should write your tests before you write the code. Far too many tests just test what the code already does. I don't care what it does, I care what it was supposed to do.

One life trick I learned way too late is that you're allowed to have fun, on your trade or on the side. One should enjoy a few light-hearted or relaxed moments every week. For some reason I was convinced that one should seek productivity at every moment, which is the fastest way to burn out.

Some might object to this analogy, but I view life like investing in an index fund. It’s a diversified bet across many aspects of life and many projects (akin to how an index fund is a diversified bet across companies, sectors, geographies). Many of the bets will fail (much like many companies in the market will crash or delist), but some will deliver so much return they carry the rest, but you don’t know which ones and when ahead of time. It will be volatile, but if you persist and survive in the long run the expected outcome tends upwards.

Whenever I start thinking along these lines I end up imagining how damn difficult life must be for many others on planet Earth, and how easy we've got it.

While we don't know what the purpose of life is, it is definitely not to beat death at the individual level.

Do things because you enjoy and care about them. This way if you have to start over it's yet another gift, because it's always your choice.

> Tomorrow is a new day

Today is a new day.

> you could be dead by next morning

I feel like this is often overlooked in financial planning. Everything is aimed at planning for (early) retirement. Meanwhile, the '$1 today is more valuable than $1 tomorrow' trope isn't just true for monetary value, but also for the value $1 might bring.

$1 today can buy memories for the rest of your life. It can bring experiences with family members and friends. Having $1 million in the bank in 40 years will never buy back time you may have wasted working to save that money.

I'm not saying that people shouldn't save or invest money for the long term, but I do think more people should take into account what they lose today by only focusing on the long term... Especially when that long term might never come.

Just like all things, even when viewing the outcome of the long run, will see noise/errors along the way that just didnt have any real impact in the end.

An insanely nerdy analogy lost to most... A car may run rough at idle but strong at high RPM, because any ground loop noise is lost in the high frequency output.

damn

This is maybe just me, but I need to remind myself of the opposite: All solutions are temporary and imperfect. So just do something, I can always go back and correct it.

For me this means that I'm allowed to store away 3 things from the moving box, even though I don't know where to put the rest yet. To invite others even though I don't know what to cook yet or to write a bad implementation quickly, instead of spending hours figuring out the best one.

I think a balance of perfectionism and can-do is important. But as people are predisposed differently, either advice might make sense in different circumstances.

Also, even after you learn this, other people will refuse to believe it, and will boldly agree to commit to months of work that is utterly pointless and even a net negative contribution to the world, because they will never do the other few months of work that was needed. And then when you say “no, we shouldn’t do this” to the 45th project plan, they get offended and swear on their own heart that they will force the second part to happen or, or, or nothing. And 6-12 months later they’ll do it again! Like fucking goldfish!

16 years ago when I was starting at my current employer as a contractor, they gave me some test data. I put it in a table called {domain}Temp. That table still exists, and about half of our production data flows through it. And yes, we've been talking about changing it for 15 years. (oof)

I'm kind of the opposite. I mark it as an issue or bullet somewhere to do and if it never happens or becomes a brain splinter, it probably never needed to happen.

This is a lesson that I've learned the hard way over the course of my life.

I do know a second way to prevent temporary solutions from becoming permanent solutions. You can just try out new things temporarily. Take your sofa example. If you choose to just try a different arrangement of furniture for a short time, that gives you can opportunity to remember to replace the sofa. The hard part is being willing to experiment with changes, but I find that it reframes things from fixing an old problem to trying something new, which can be more exciting and motivate additional improvements.

This is decent. Make tickets for the todos ahead of time and make sure your PM gives them priority.

Oh damn.

I guess I've learned something.

Thanks :)

old codebases are always, plenty of these

this is great advice!

And telling a customer that what they want a) won't work and b) is not cost-efficient to build can also be a good idea.

You might "lose" a customer, but word will travel that you won't build crap that wastes clients money. Which in turn might bring in more business later on.

Also when building a quick-and-dirty solution, make it LOOK dirty.

A fancy UI with a janky back-end will look like polished software to the customer, keep the user experience in sync with the code progress.

If your backend is WIP, the UI should be only unstyled plain HTML components when demoing it to the customer. If there is no UI, the backend should print all kinds of janky-lookig debug messages that make it clear it's not ready for production.

Definitely "documentation beyond "how to use this" is going to cost you more" is a policy I do for side business outside my day job. That said I do try to spend a bit of extra time to make the API easy to understand, well named, and expose only those things they need. But I just consider those good coding and time well spent when I have to revisit it. What lies beneath is not always be so pretty, depending on what the customer is paying.

> quick-and-dirty exist for a reason. It's easy to say that quick-and-dirty is just dirty, and it's true: in the long run, quick-and-dirty takes longer than the-right-thing

I've started to view this as "quick and dirty pays the bills for me to clean up later".

Yes, it'd be great to have an elegant solution right off the bat - but that's almost always going to take more time/effort. There's also a good chance what you build is completely wrong, so it might get thrown away.

Of course, there are exceptions to this. Particularly, for well-known, well defined things or safety critical things.

> we'll get it in better shape next week, [...]

All of the above is only true if the quoted part is taken seriously and actually acted on.

On that line, it's a good idea to optimize for the integral of business value delivered. It's better to deliver something partial and hack-y quickly so the business can start enjoying it rather than delivering all at once. Not to mention the invaluable interim feedback gathered from your users in the meantime.

Also, it's not enough to build something; you need to make sure people are using it, and using it right, or else you leave value on the table. Run trainings, monitor user engagement, talk to your users. Make sure what you built is used to its full potential and delivers the maximal impact.

I have a similar thing but for putting purchases in context.

If I buy a good quality pair of jeans and I wear them 200 days every year for multiple years, its cost per wear is negligible even if I pay 100-200€ for them.

On the other hand a pair of fancy suit pants I wear for that one wedding and maybe Grandma's birthday is going to have a massive cost per wear -> no need to get the top shelf stuff, maybe just rent? Grandma is fine with business casual so I can go in with a jeans and blazer =)

The same works with subscriptions. Youtube Family isn't cheap - but we watch so much Youtube content that just the ability to skip all ads on every platform without addons or special clients is easily worth the time saved.

(It's also interesting that kids under 13 can't be enrolled to a Family on Youtube and thus are inundated with unskippable ads...)

I like your approach to relating your daily choices to your broader life goals.

I think you'd like Atomic Habits [1] if you haven't read it already.

[1] https://www.amazon.com/Atomic-Habits-Proven-Build-Break/dp/0...

This is a good one. What's gonna happen if I respond to comments on HN for 1000 days in a row? Uh oh.

It takes altogether too long for many people to find out that they have a body.

how do you arrive at 2hrs a day? AFAICT 1hr a day gives you 90-95% benefit of 2hrs.

To put it another way, comparing to 2hrs

    15mins = 50% benefit
    30mins = 75% benefit
    60mins = 90-95% benefit
    120mins = 100%

> I'm going to look and feel great and my health will be far better than that of my peers

Comparing your health (or anything to that matter) to your peers is a great way to boost and maintain insecurities. There is always gonna be a healthier, sexier, younger and so on. Good luck chasing that.

At risk of sounding very banal, comparing yourself to your version from yesterday is the best approach.

I feel like the Monte-Carlo simulation modeling trick is one I picked up intuitively but only recently heard formalized. Do you (or anyone else) have a list of example problems that are solved in this way? Like a compendium of case studies on how to apply this trick to real world problems?

what do you consider top tier library search tools and academic databases these days?

even wood tipped circular saw can cut Al plate...

and academic/library search is indeed so underrated!

Strongly agree with your second point, too many times I had to figure out issues caused by code trying to handle errors but actually hiding them and making it so much harder to debug. The typical antipattern: catching SomeErrorType just to log "error of that type occurred", thus hiding the associated error message and the stacktrace. Even worse: trying to catch every error types.

Don't catch errors unless doing something actually useful with them. Even then, it's often a good idea to re-raise.

> Sometimes* the same code copy/pasted or repeated is much easier to understand than pulling it all into a subroutine.

The Write Everything Twice principle is a much needed sanity check for absurd DRY practices. There are too many naive people arguing with a straight face that writing a base class and two specialization classes saves you the work of writing two classes.

The Rule of Three: “When you’ve written the same code for the third time, that’s when you should stop and refactor it into an abstraction.”

I think it's from Martin Fowler's book Refactoring. (It's been a while).

The gist of it is that with one or two cases you might create the wrong abstraction. When you have three, you can abstract away the right bits without creating a monstrosity of optional parameters and booleans.

I like to think of it as that; you should have principles, such as trying to write DRY code, but any principle taken too far will end up being a bad thing. Don't be an extremist. Practice a sensible balance in everything you do.

This goes beyond programming as well, I think it goes for most things in life.

100%, on all of these. In basically every job where I worked with more than 5 people, I have regretted too many default arguments in functions that were trying to be overly dry, and code that tried too hard to not crash and carry on.

Also sometimes copy paste is faster than trying to abstract a code block into something generalised

Regarding your first point, I feel it's important to understand Liskov's substitution principle, which is basically, the code might look the same now, but it could diverge in the future if the contextual semantics around that code are different. Effectively that heuristic has made me a little more hesitant to do a bunch of consolidation that could end up increasing complexity by a lot if you need a bunch of special cases.

I think I had discussed every one of these items with my junior developer this week alone. Are you spying on me? Are we the same person?

Another disagreeing voice, but I try to employ problem speculation when some problem arises. I'm working in a cross-company, cross-team project, where everyone's input interacts in interesting ways. When we come across a weird problem, getting folks together to ask, "what does x issue sound like its caused by?". This gets people thinking about where certain functionality lives, the boundary points between the functionality, and a way to test the hypothesis.

It's helped a dozen times so far essentially playing 20 questions and being able to point to the exact problem and have it resolved quickly.

This is a semi-embedded system. FGPAs, SoCs, drivers, userspace, userspace drivers, etc. Lots of stuff to go wrong, speculation gives a place to start.

I thoroughly disagree with this sentiment.

In my experience, the most helpful approach to performing RCA on complicated systems involves several hours, if not days, of hypothesizing and modeling prior to test(s). The hypothesis guides the tests, and without a fully formed conjecture you’re practically guaranteed to fit your hypothesis to the data ex post facto. Not to mention that in complex systems there is usually 10 benign things wrong for every 1 real issue you might find - without a clear hypothesis, its easy to go chasing down rabbit holes with your testing.

Love this.

The most dangerous words during debug are: “…but it should work this way!” This is a mantra I try hard to instill in all EEs I mentor.

“Should” isn’t worth a damn to me. You test your way out of hardware bugs - you don’t logic your way out.

Implicit or explicit, you need a hypothesis to be able to start probing. Many issues can surely be found with an oscilloscope. Many others can't and an oscilloscope does not help in any way. It's experience that tells you which symptom indicates which class of issues this could be, so you use the right tool for debugging.

That's not to say that at some point you don't need to get your hands dirty. But it's equally important to balance that with thinking and theory building. It's whoever gets that balance right who will be most effective at debugging, not the one with the dirtiest hands.

this works also in general purpose corporate programming.

Without speculation, what test do you decide to do?

Speculation is fine, but you need to ground it in reality.

That's a good saying.

I once heard: adults are children with older bodies. People seem/try to be rational but we are all so influenced or downright controlled by emotions. The desire to be perceived as rational is one such driving force. Many things we do since "this is the right thing to do" are in fact done to reduce (or control) our anxiety. In this sense we are still children.

Very relevant to most advice one finds on HN

In programming however, the skill and foundational understanding varies greatly, and while everyone is cooking with water, there are big differences how you cook. :P

Everyone's shit smells the same

Whenever people try to argue that small and meaningful commits do not matter, I introduce them to git bisect. I’ve yet to meet someone familiar with it that does not agree.

Similar feelings about git worktree. Being able to check out multiple branches at once without having to deal with stash is a game changer.

And interactive rebase. Master interactive rebase and reflog until you can do it blindfolded.

The amount of times I've used `git bisect` productively can be counted on one hand.

It's a useful tool, but sort of a tool of last resort.

Very useful. What we always say after the fact is "we need more tests".

> Most people really cannot tell you what they want in any reasonable way.

But build them something and suddenly they know exactly what they want and what you built isnt it.

Also half of those people will "tell" you what you need to build and you need to work backwards from there to figure out what their actual problem is before working forward again to figure out what you actually need to build.

Not always true. For example, if you work on your bike's brake, you should make sure the work is correct and well done. You dont want it stops working when cruising at 60mph.

My new life motto, thank you very much! You just made a stranger's day better

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

"Do the simplest thing that works" is one of the few core architecture principles I stick my neck out for time and time again. Why write a simple function when you can spend a week accounting for every imagined corner case and implement modular expansion capabilities! Please... stop...

I empathize with the debugger story. If you're super deep in a language it makes sense to know the debugger inside and out. But stdout is universal and I've never been a specific language developer rather than being able to jump into whatever is needed.

I'd like to give a shoutout to jq for (non-JSON) text processing, and also as an almost-replacement for awk:

  echo "foo bar" | jq -Rr 'split(" ")[0]' # prints foo

People do this, but it feels a bit weird to start a whole new language interpreter which is much more powerful than the pitiful shell language we use, just to split a field. Why not write your whole program in awk, then? It's likely more efficient anyway.

The canonical shell tool to split fields is cut. Easy to use, simple to read.

For the very common use case to set variables to fields, use the shell built-in read. It uses the same IFS as the rest of the shell.

These comments here about more or less clever text processing tools, each with their own syntax, feel like archaic hacks. Using something like Nushell or PowerShell makes this trivial.

E.g. for the `ps aux` example, using PowerShell, selecting a certain column:

  gps | select id

Now imagine what all the LLM copy pasting could do to our skills ..

Why not `… | cut -f1 -d ” ”` though?

I'd say you may be missing the concept of Risk-Adjusted Return, which changes a lot of those calculations.

Home ownership is a huge economic subsidy for the upper-middle class in the US: mortgage interest deduction, cheap leveraged borrowing, real-estate investment, up to $500k of free capital gains, and an inflation hedge. It's pretty hard to beat compared to alternative investments.

A house is something that fulfills your direct needs, unlike S&P500. You 'miss the opportunity' in exhcange for feeling safe about your future, which leads to more rational choices long term.

> - Buying a house: Is this the best return I can get on a downpayment. (Spoiler: It is not).

This depends entirely on how much the mortgage costs compared to the rent you'd otherwise be paying no? It is very much case by case depending on where you live and therefore completely wrong to state as a general rule? In my area mortgages are far cheaper than rent, even if you account for 10% annual returns on your house deposit when renting, you would still come out far behind in the long term

> If you have a paid off home, could you sell it and get a better ROI with the cash equivalent and rent instead? (The answer is yes and you should do it)

Could you explain how that makes sense? I can't see it working except if you are willing to accept a huge risk by putting the money into financial markets. Banks offer around 0% in my country, and with 4.5% inflation keeping cash just burns a hole in your pocket.

>> Buying a house: Is this the best return I can get on a downpayment. (Spoiler: It is not).

It may be the best return. You never know the future, what direction asset prices are going.

It's really sad when you hear about people living this way. Life isn't about profit maximisation.

This is a topic that often comes up, but once you pry, people usually overlook inflation. As an example, let's say you took out a $300,000 mortgage 30 years ago. The inflation adjusted cost of that today is $634,546 [0], so figuratively you end up paying more than double the sticker price just because of inflation.

[0] https://www.calculator.net/inflation-calculator.html?cstarti...

What do you do when the people you're bidding against don't understand this?

If you get a mortgage you're also getting extremely cheap credit compared to other options in many jurisdictions.

One should do proper accounting as things change wildly from one place to another.

Exactly, calculate total cost of loan vs. cost of purchase

Also, there's no shame in renting and it's frequently a better financial decision.

>2. be very careful when using rm command (use alias rm='rm -i' )

and treat mv/cp/rsync like rm

> 3. Have backup of backup of backup.

> 4. keep checking if backups restore correctly. (can have a very rude awakening if it does not work someday )

Your backups are only as good as your ability to restore them (under pressure).

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.

I didn't start investing until I understood it.

This is a fantastic course. It covers a lot of ground.

If you want to actively invest, this will help you learn the mechanics. But in the end, what you really learn, is that you can't beat the market.

https://ocw.mit.edu/courses/15-401-finance-theory-i-fall-200...

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.

Get a financial advisor that you trust.

Rule #5 of Rob Pike's rules of programming[0][1]:

"Data dominates. If you've chosen the right data structures and organized things well, the algorithms will almost always be self-evident. Data structures, not algorithms, are central to programming."

[0] https://users.ece.utexas.edu/~adnan/pike.html

[1] https://news.ycombinator.com/item?id=24135189 (HN Discussion from 8/2020)

Counterpoint, if you're writing business logic - e.g. some math, a HTTP/JSON API, a database, etc - it may be better to start with your domain data and business logic. Write the most clear version of the business logic, then implement the details in their respective layers. That is, the layers may be replaced entirely over time, but your business logic shouldn't change if e.g. the data goes to GRPC instead of HTTP.

I was recently explaining to my non-programmer gf what programming is to me. I said that I first make some bricks and then when I have enough I try to assemble bigger bricks from small ones and then after a while build things from them.

I agree 100%. Bottom up of the way to go if you're doing it without deadlines, requirements or investors with expectations looming over you.

Damn. I would have written the exact opposite.

Moreover, it is counter intuitive, too. The instinct of most juniors is to build foundations first and it took me a long time to learn to do the opposite.

Each layer serves as a customer for the layer above. If you havent figured out what the layer above needs precisely by building it you're probably going to provide the wrong thing to it in the layer underneath if you write it first.

It's also more resilient to requirements mistakes and requirements changes - it's easier to change course on a feature after showing a UI to a stakeholder if you didnt build the lower layers.

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.

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).

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

Even if you aren't going to do the complete test code just writing down the expected checks for each test makes things so much easier

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.

Could you expand on it? What are the benefits, what have you gained by doing this?

When I stopped trying to be right and I started trying to be friends my career finally took off.

Duplicate or near-redundant functions are either no problem or even useful. But duplicate or near-redundant data structures are a plague on any codebase.

The prophet Perlis declared: "It is better to have 100 functions operate on one data structure than 10 functions on 10 data structures."

Most of the shitty code I've seen has been from poor attempts at reducing code duplication, usually resulting in some overfitted generalized solution or abstraction.

Efforts to reduce duplication should be focused on chunking out reusable pure functions. Trying to dedupe the flow of logic is almost always a fool's errand.

Maybe obvious but also, don't deduplicate if it means adding options or making things too abstract. I don't know if I can think of a good example. Maybe you make a function that compares arrays of strings. Then you decide to add an option to make it case insensitive. Then someone comes along and decides they want to compare arrays of structs. So they had a comparison function option. Most times I've seen this pattern the code gets way harder to understand and more brittle. All the options etc cascade into spaghetti and changes start breaking things because so many paths expect some original behavior. Better to have just kept them separate, most of the time.

Have you set up a copy paste detector that fails the build if you write too many duplicates?

Yes.

There are some jobs like that, maybe especially in areas like web development, but obviously it depends on what you are building. If you are working in areas like embedded programming or robotics, for example, than obviously you are more likely to be mostly coding from scratch, even if there are libraries that you may be using.

We should all play Chess690 so we don't have to waste time learning openings, right?

Technically it doesn't... If you drop

    echo "hello world"

You technically only need the shebang to set a specific shell, or options.

... This little quirk allows you to commit crimes like:

    //usr/bin/cc -o ${o=$(mktemp)} "$0" && exec -a "$0" "$o" "$@"
    #include <stdio.h>
    int main(void){
        printf("hello world\n");
        return 0;
    }

(don't)

Similarly, it's `XXX=123`, and cannot be `XXX = 123` or `$XXX=123`.

Shellcheck (and Wooledge) are crucial!

For anyone interested, here’s how I achieve the same in i3wm: it works with the Print key and lets you select the area using only CLI tools.

bindsym --release Print exec "scrot -s '%Y:%m:%d:%H:%M:%S.png' -e 'xclip -selection clipboard -t image/png -i $f && mv $f ~/Pictures'"

On Windows WinKey+Shift+S opens a snapshot tool that lets you click+drag over part of your screen and puts it into your clipboard

Is this advice also for mac users? If so, whats the benefit to using this over the built-in screenshot tool?

Is it better than Cleanshot?

Dry days is a really interesting idea. I wonder if it’s doable to do this in a working day when you need to work at a screen, might be too tempting to procrastinate at work. But maybe 1 of the weekend days could already bring benefits like you describe.

Also you don't have to remember your lies if you tell people the truth

A related (restated?) point I like to keep in mind is: acting produces motivation, but you can't count on motivation to produce action.

Taking even the smallest step (or working on something for even 30 seconds) often overcomes the inertia that keeps the task/project unfinished. A little nudge is all I need to start building the momentum that will carry through to completion.

I'm not saying you're wrong but it seems so backward. I didn't love computing as a kid because I had a habit of computing already. I got that because I was motivated to play with the computers. The motivation came first, not the habit.

Same with learning a 2nd language. First I got motivated to learn it. I didn't get the habit first. In fact I can't name anything I got a habit for before being motivated.

Again, I'm not saying you're wrong. I've heard this advice many times. And maybe forming a new habit leads to motivation. It's just counter intuitive based on what think is most people's experiences.

Apprentice, journeyman, master: worked for millennia, will work for millennia more.

But don’t fall into the trap of that’s all you do. This can lead to procrastination of the thing you’re trying to do.

escape + . for repeating the last argument from the last command

There are other commands to grab other arguments [0].

[0] https://stackoverflow.com/questions/4009412/how-to-use-argum...

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.

Oh I learnt the opposite lesson, as later errors might be spurious and just exist because of earlier errors, especially in single pass compiled things like C

But I also do M-x compile, and emacs is clever enough to still find the right line when doing next-error, even if I edit things before.

Import transaction history into spreadsheet reversing the rows if necessary to start with 1st Jan at the top. This way you can make calculations mid year or mid month then complete them after receiving full statement only by appending rows, hitherto row numbers remain unchanged.

As I grew older (and hopefully wiser), I have internalized investment returns is a lot more than sanitized numbers. I did the numbers and as a result did not buy much real estate when I was yonger. It was pretty clear, if I put the same cash outflow into stocks, I would come out ahead... Way ahead!

The things is, I didn't put the same cash outflow in stocks. For various reasons. But mainly, it was just not psychologically palatable to max out my investments on equity by streching my finances. With hindsight, given the buffer in most real estate investments (left with tangible assets, banks shouldering some of the risk etc.) it would have been a lot more psychologically palatable to investment my max in real estate.

My point is not that real estate is "best". But merely, there is a lot more to returns than cold numbers. If you think you already understand it, and are under 30, you are likely underestimating the significance of that. I know I did.

I find this logic shortsighted and I don't think the right chapter of math is being applied. You need the probability theory not calculus.

Yes, renting is often better than owning on average. However, as any good poker player knows, having a positive strategy on average is nothing unless you control the standard deviation. You need to have reserves deep enough and to be able to play long enough for your average to consistently manifest itself.

In lifetime investment choices the human lifespan is the major limitation. You won't be able to live long enough to absorb multiple economical collapses and surges — which indeed had always been profitable in the end, just not necessarily for you. You draw your card and you play your hand. In such circumstances a strategy with less gains but also less variability is usually preferable.

A good analogy is insurance: having insurance is always worse on average than not having one, otherwise insurance companies won't exist. Buying insurance for something small, some loss you can absorb yourself, like your phone or bicycle, is in most cases a bad idea. However, buying insurance for your house or your health is usually a good deal. You pay money to tap into reserves that are bigger than yours, you get slightly negative mean expectation with near-zero variance. Even the insurance companies themselves do it when they judge their reserves are not deep enough for a given contract — and resell parts of it to other companies to spread the load.

By and large, I agree with you. Especially if you are single, owning real estate represents a massive commitment, both financial and to the local place, that nobody forced you to take. People need to remember that the default for real estate is to fall into disrepair and turn back into the dust of the earth; as someone who owns real estate, you are responsible for fighting that entropy, as is everyone else in your neighborhood, as living in the only well-maintained house on a block full of abandoned blight isn't going to rescue your property value.

With that said, sometimes you want to make that commitment, because it's a socially good choice, rather than a financially good choice. Children need stability. Moving houses, neighborhoods, schools is not good for them. Good parents make sacrifices for their children, including staying in jobs where they might make a little less compared to Yet Another Move.

For most families who want to provide stability for their children, the choice is between purchasing a house, or a long-term rental of an apartment owned by a public housing authority that is bound by law or regulation to keep rent increases down and renters in-place, so long as they continue to pay their rent. In the US, most people do not have access to the latter, or the latter are only found in bad neighborhoods where the public housing authority was underfunded and mismanaged. That leaves purchasing real estate as the only option.

This is obviously not true. You don't have to do the math to realize: when you pay rent, every moth, an important part of your salary simply disappears, leaving nothing for the future. When you pay a mortgage, your paying the house you'll own. Of course, there are interests and fees and whatnot, but you'd need to pay huge amounts so that it becomes unviable; I can't imagine a single scenario where that occurs.

*> Most people will literally compare mortgage to their rent, or "I sold my house I bought for 500k for 1M$, therefore I made 500k$".

I’ll bite: what’s the problem? If anything mortgage is even more favorable than rent because part of it goes to paying off the principal. Which is still your money, just in a different asset. But I guess you include this and still reach the opposite result?

Are you talking about taxes or maintenance or something ? Which country / locality? What time span? How many places are there where you would’ve been better off renting than buying in recent memory… not where I’ve lived but you never know!

Did you account for leverage? I agree with you all the way, however, the top reason it can actually be beneficial to most people is the fact, that they can leverage their money.

Putting it a bit simple, it would mean, that for most people, ncr_(real estate)^t > c*r_investing^t

It all depends where in the world you are, but most places have easier access to loans for real estate than investment, and everything else being equal, the risk is also higher. There might be this line of thought in wake of the financial crisis, that real estate carries close to or as much as the same risk. It doesn't. It's just not zero, and that is the lesson learned.

There are a couple good resources on this. The nyt rent vs own calculator is good but also there is a great podcast episode (tailored for Canada but mostly the same in the us) https://rationalreminder.ca/podcast/323

Another positive is that you're morally clean.

"A place to live is an financial investment" is a perverse idea to begin with. You won't be a passive participant of one ill in the society. HN is quick to debate often about how housing is one core issue in many socially bad phenomenas but look at that, when you question the fundamental premise causing that everyone comes out trying to dismiss that. It's easy to lament "societal" issue when it's some other group (society) but it's all justifications that comes out when money is involved and it's pointed out that it's the individual actions that causes it (yours).

Which is kinda why we are at the point we are. "everyone needs a house right?!?" and someone realized (artificial) scarcity is a way to milk money out of that. Everyone bought it. Now every middle class person and their bank are in the game. "housing always increase in price" is a goal that is turned to a belief/principle. It was made a social issue by all the people who bought in to it

Go to a place where housing is not considered a financial investment but a consumable,(such as Tokyo) and you'll realize the mode is not as bad or an unalienable truth as many think. It's rather a symptom of a inefficient use of wealth, as a society.

I just penciled out several home buying scenarios in HCOL, according to the calculators you posted, it only very recently became a questionable purchase if you don't plan on staying 7+ years in a home.

At any other point in the last 20, maybe 30-40 years if you re-finance well, it was always better to buy if you intended on living in an area for any reasonable amount of time.

Let's simplify by assuming you can choose between two scenarios:

1. The bank lends you £1m to buy a house, you pay them 5% interest for this service = £50,000 pa.

2. You rent a £1m house from a landlord and pay £50,000 pa for this service.

Financially these are identical. And in either case if you stop paying you will lose your home - because it's not really yours, it belongs to the bank/landlord.

However surely 1. is always preferable?

* You can make any change you like to your living environment up to and including moving walls around

* Assuming you do continue to pay you have the absolute right to live there and will not be forced to leave

* Rents can rise out of your control, even to the point you can no longer afford it. Mortgage rates can change over time too but you get to choose your level of risk appetite explicitly by fixing for the period you prefer.

I'd phrase this quite differently: realise that buying a house might not be the optimal investment strategy, depending on life circumstances, goals and economic conditions. Boiling it down to "not a good investment" is overly reductive IMO.

"Buying saves you $176,000 over ten years."

Also the chart tells me that if your rent costs more than $1,000 a month, to buy.

It also says if you stay longer than 5 years, to buy.

I fucking signed up for this. Fuck. Now I get to go cancel...

> This calculator get most things right.

It's paywalled. I also doubt it gets most things right. I've been pointed to so many and I have not yet found that that takes into account all the variables (and there's so few, so if they're leaving it out I'm suspicious!)

> A lot of research shows that once people buy they lose flexibility,

They lose that once their kids are in school.

> feel more stuck,

They're stuck anyway, once the kids are in school.

> cannot access higher paying job in a different places etc.

They cannot do that anyway, once the kids are in school.

All of those disadvantages you list are not even noticed by people with kids in school, hence they don't count as disadvantages.

The only advantage you realistically realise from renting vs owning is the ability to move within a month's notice. If you have kids in school or a spouse who is working in-person, not remote, you won't be moving on a month's notice anyway.

IOW, why optimise for the use-case "Hey, we can move on a months notice!" when that use-case won't come up anyway?

It's like a vegetarian optimising their life around access to meat-only burger joints. Or someone living 2000km from the nearest sea optimising their life for surfing.

No one optimises their life for use-cases that won't come up.

This is of course true if your house is not income producing. If you rent out rooms of your house, the calculus changes considerably.

…and now having viewed their calculator, I find it disingenuous that they haven’t added this as an additional configurable step, given how many bells and whistles their tool has. The takeaway from the tool is that you should never buy in HCOL areas, but renting out rooms in your unit is potentially a way to make it work out financially.

Yes and: Remodeling. So many regrets.

> 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$".

Can you try to offer some explanation for your reasoning?

I mean, for blue collar or even white collar workers, lower monthly payments for a mortgage does increase disposable income. When you eventually pay off your mortgage your expenses drop to zero.

> This calculator get most things right.

I think you need to educate yourself. There are rent vs buy calculators that allow you to do parametric tests and eventually arrive at the rather obvious conclusion that renting is marginally advantageous only in short time windows (up to around <5years) whereas buying is advantageous beyond that point.

While financially this is true, it does not account for aggressive landlords deciding to spike rent and/or deciding to sell and evicting. Housing stability can be worth a lot. (Of course, strong tenant protections help mitigate this issue.)

Do you have any examples of ways you incorporate them into your day-to-day?

Everything powerful is also potentially destructive. Macros have their places, but most of the time they are not the right solution. I too have removed most of my macros, and have a few that are worth to keep. Usually time saved with macro cleverness is paid off with time debugging with cryptic compiler behavior.

When there is no other way, wrapping multi-line macros in a do while and #define constants in parenthesis can definitely help.

My early C code would have been awfully slow without them. We needed enums and good inlining before we could ditch (most) macros. When did Zorland/Zortech C become good enough?

There are still a few special cases where macros are useful, such as the multiple #include trick where a macro #defined before the #include determines what the macro invocations in the include file does -- really helpful for building certain kinds of tables.

Can you please elaborate here?

Counterpoint: there are many things that are interesting to do. Explore and learn from them.

The fact that there's an entire country mostly unaware of the utility and ubiquitousness of a simple electric kettle, blows my mind. But then again, I'm a product of the Empire (British) not a North-American.

But while the idea of using a stove top kettle (have done so in the past) is fine, the thought of using a microwave to heat up a cup of water for tea seems abhorent. (although it's really not)

I guess it came about because 110V not being as efficient? Or more American's are coffee drinkers?

I won't be able to have enough sleep then.

This is interesting. I’ve often thought about building a dashboard for my personal life, comparable to the dashboards I build for growth teams.

And then iterating on it over time, and I find what’s valuable and what’s not.

I like the quote up until the word "people" because it is quite an epiphany to realise that anything that was made can be remade.

I don't buy the "no smarter than you" part though.

My personal version of this was realizing that the bar for being a functional, relatively successful adult is FAR lower than I realized as a kid. Many adults can't get things which I find fairly rudimentary right and it explains a lot.

One other benefit, if it happens to matter to you, is that Airdropped files like photos or videos retain their original quality as opposed to taking a slight hit to quality when being transferred via text or email.

man tmux

You must be my former colleague whose behavior convinced me to quit my job

That is not my experience at all (30+ years here working in different countries).

I have only experienced this kind of environment once. And the fix was to quit and join a functional company instead.

To a friend but not to prod.

I wholeheartedly agree! And would add:

3. Make sure your API test suite runs fast, runs locally and is easy to use. Effort put into the test suite and tooling pays dividends for a long time.

Like this https://www.themusicstand.com/Drum-Rudiments-Playing-Cards-p... ?

Man, I'm dating myself by admitting that I know what a drum card is.

>Excellence in anything is a byproduct of having fun

absolutely not. fun is a byproduct of excellence.

do people like playing the piano well? yes.

do beginners like taking piano lessons and practicing in between? no.

prodigies can enjoy lessons, that's why we have a word for them, they already excel due to some unusual internal wiring

I don't think understanding leads to fun in most people. It probably is the case for most people here on Hacker News, but I doubt it's universal.

This is relatable. Once one gets over the frustration of failing and making mistakes (thousands of times in some cases), it becomes fun and easier to stay curious.

I've seen a lot of people play cricket and soccer all their lives, they had a metric ton of fun, and im sure I will not put them close to the word excellent in any aspect of their lives. Im not sure any of the statements you made are agreeable in fact.