Review of How to Afford Anything

I stumbled upon a great article of Ken Rockwell called How to Afford Anything. Since the article is quite long, here are the points that helped me the most, i.e. were the least obvious to me.

Priorization
In short - buy things that you really want. Don't buy things just because it is so easy.

Never buy a new car - as it is one of the worst investments. New car losts a notable value just by you buying it.

Don't buy a big house - instead, try to live just below your means. Why? Because then you will always have more money than you need. This can be abstracted to the rule - try to spend just below what you have, e.g. the 99% and you won't know what to do with the money. The problems raise if you spend just a little above, e.g. 101%.

Real estates not always make you money - you pay lots of things around the house. So buy the apartment only if you intend to live in there.

Patience
Find plenty of time to research products that you intend to buy.

Thrift
"A luxury, once sampled, becomes a neccesity." Don't borrow or even try fancy stuff. You will think you deserve it and you will eventually have to buy it.

Don't take loans - buy only things you could afford. It takes simple math to calculate that all debts cannot be payed. If there were just one person (or 7 billion) and a bank (or a thousand banks) and the bank would borrow 100 dollars to the person and wanted back 110 dollars, but the only place to get money was the bank, the person has no chance to pay his debt.

Don't rent apartment - rent just a room. The rent money is money thrown away. If you must rent, do it just with one room, as it is all you need untill you have enough money for mortrage.

Embarrasment
Ask for a Deal - always when you can. Read a book about deal negotiation.

Return what you don't want or need.


Addiction
Don't go into the stocks market. This is a nonsense in the long-term.

Comments

Post a Comment

Popular posts from this blog

Notes about the Clean Architecture book

The first look into the contents of the book was a bit scary. Some of these things were already explained in Robert Martin's previous books. Then I found out they are explained from a different (software architect's) perspective. Overall, I liked this book better than Clean Coder, but it was less useful for me than Clean Code book of the same author. Part I - Introduction The foreword contained two useful antipatterns: Too authoritative and rigid architecture. Speculative generality in software architecture. The main point of the preface is that not much changed for the last 50 years in software architecture. The rules of software architecture are the same regardless of any variable (time, type of project, ...). When you get the architecture of the software right, you magically don't need horde of programmers maintaining it. Chapter 1 - What is Design and Architecture? There is no difference between software design and architecture. There is a continuum of
Read more

Notes about the Building Microservices

These are notes for my future self about Sam Newman's book, Building Microservices 2nd edition.  Preface Microservices are an approach to distributed applications that use finely-grained services and change, deploy and release them independently. Microservices have become the default go-to architecture when designing system, which Newman finds hard to justify #surprised and want to share his view on why. Foundation Chapter 1 - What are Microservices? Microservices are independently releasable services modeled around a business domain . They are kind of SOA, but the one which is opinionated about how service boundaries should be drawn and where independent deployability is the key. Microservices should implement information hiding and expose their API in some way, e.g. via REST/JSON API or by emitting events. They should have their own database schema. To highlight that the services are as independent as possible, Newman draws them as hexagons, a homage to Alistair Cockburn's H
Read more

Notes about A Philosophy of Software Design

My notes about the book by John Ousterhout. It is quite a short book. Originally I made a mistake of reading just the Conclusions of the chapters but there is a lot of contents not in the Conclusions. After really reading the whole book, I started to like the Red Flags and other small pieces of hints. Chapter 2 - The Nature of Complexity Complexity is anything related to the structure of a system that makes it hard to understand or modify. Isolating complexity in a place where it will almost never be seen or touched is almost as good as removing it. There are many symptoms of complexity: Change amplification - when change requires modification in many places.  Cognitive load - how much a developer must know in order to make a change. Sometimes more code is simpler than less code because of cognitive load. Unknown unknowns - it is not obvious which places should be modified or what knowledge the developer must have to make a change. Complexity is caused by 2 things - dependencies and o
Read more