Category: book reviews

97 Things every Developer should Know – Summarised Notes

I came across this book due to it being popular on a top 10 list somewhere.
Usually I take these "xxx you should know" or "Top 100 essential things" with a pinch of salt.
Everyone is different and everyone has an opinion. Nonetheless I wanted to read this book and see what it is about.

I'll put the 97 things in headings and have a short summary of each.

Don’t Put Your Resume Ahead of the Requirements

Also known as Solve the problem you have, not the problem you want to have

It is suggesting a tool because it is cool and hyped instead of it being the bet for the job.

Customers being happy with your work is much more important than a new, shiny tool or paradigm.

Also you need to spend a significant amount of time finding out what the tool does and if it is suited to a job - that is always a good idea. More knowledge will let you choose the appropriate tech from a more informed standpoint.

The right solution allows for a happier team, happier customer and far less stress - allowing you more time to do more research.

Always put the customer's long term needs first.

Simplify Essential Complexity, Diminish Accidental Complexity

Essential complexity - the difficulty of each problem.
Accidental complexity - complexity arising out of existing systems or ways of doing things, things that are suppposed to decrease essential complexity but rarely do...

Overenginnered frameworks add more complexity than they relieve

Developers are drawn to complexity like moths to a flame...

People are your biggest problem

Most projects are built by people, and those people are the foundation for success and failure

You need conversation - treat people with respect and give them the benefit of the doubt. It should work both ways.

Remember conversations, not confrontations.

Communication is king, clarity and leadership - it's humble servants

Clarity - how you communicate. No one on your team is going to read a 100-page architecture decisions document.
Being clear and concise in the way you communicate your ideas is vital to the success of any software project.

Being unclear and verbose is a huge smell.

Keep things as simple as possible - starting with a long word document is another huge smell.

Application architecture, determines application performance

Switching software vendors rarely solves applicatoin performance issues

Seek the value in Requested Capabilities

The customer or end user shouldn't think up the solution. They should tell you the problem.

Ask for the intended value.
Collaboration - ask why?

Stand Up

You need to sell your ideas and communicate effectively to do that.
When more than one person is coming for advice - stand up - it communicates authority and self-confidence.
Slow down when making important points.

Everything will Ultimately Fail

No automated system can respond to the same range of situations that a human can

One line of code is worth 500 of specification

Unfortunately it’s far too easy to get wrapped up in the process of design.

The ultimate goal of a software project is a production system

There is no One size fits all solution

Developers should exercise contextual sense to each problem

Make Tests Run Fast

There can be more than one

In technical domains we can force uniqueness. Very convenient for us. In business domains the inconsistent, multifaceted, fuzzy, messy world intrudes.

Why not face up to the reality of a messy world and allow multiple, incon- sistent, overlapping representations, services, solutions?

But let’s take a hint from the world of data warehousing. The schemata data marts are often (relationally) denormalized, mix imported and calculated val- ues arbitrarily, and present a very different view of the data than the underlying databases. And the sky does not fall because of the nonfunctional properties of a mart.

The ETL process sits at the boundary of two very different worlds, typically transaction versus analytical processing.

These have very different rates of update and query, very different throughput, different rates of change of design, perhaps very different volumes.

Simplicity before Generality, Use before Reuse

Most libraries, frameworks and infrastructure code is general purpose without reference to concrete applications.

This leads to a dizzying array of options and possibilities that are often unused, misused, or just not useful.

The best route to gen- erality is through understanding known, specific examples and focusing on their essence to find an essential common solution. Simplicity through experi- ence rather than generality through guesswork.

When there are two possible solutions, favor the one that is simpler and based on concrete need rather than the more intri- cate one that boasts of generality

Although well meant, many things that are designed just to be general pur- pose often end up satisfying no purpose

People do not on the whole pay for (or need) generality: they tend to have a specific situation, and it is a solution to that specific situation that has value

We can find generality and flexibility in trying to deliver specific solutions, but if we weigh anchor and forget the specifics too soon, we end up adrift in a sea of nebulous possibilities, a world of tricky configuration options, overbur- dened (not just overloaded) parameter lists, long-winded interfaces, and not- quite-right abstractions. In pursuit of arbitrary flexibility, you can often lose valuable properties—accidental or intended—of alternative, simpler designs

Don't Ever Rush, Don't ever panic

Rushing is cutting corners

Panicing is lack of clear though

Both do not achieve anything in the short or long term

Database as a Fortress

User interfaces, business and application logic, and even employees will come and go, but your data lasts forever

Consequently, enough cannot be said about the importance of building a solid data model from Day One.

While business rules and user interfaces do evolve rapidly, the structures and relationships within the data you collect often do not

It is critical to have your data model defined right from the start

Normalising your data

The database is the final gatekeeper of your precious data

Warning: Problems in Mirror May Be Larger Than They Appear

  • Individuals often face resistance when the rest of the team does not share their experience or knowledge. Overcoming this resistance requires unusual courage, confidence, and persuasiveness. It rarely happens, even with highly paid, experienced consultants specifically hired to help avoid such problems.
  • Most software developers are optimists. Painful experience teaches us to temper our optimism, but without specific experience we tend toward optimism. Natural pessimists on development teams are often unpopular, even if they are consistently right.
  • Every team member has a different view of what is more or less important. Their concerns are often focused on their personal responsibilities, not the project’s goals.

Reuse Is About People and Education, Not Just Architecture

The truth is that even the most beautiful, elegant, and reusable architecture, framework, or system will only be reused by people who:

  • Know it’s There
  • Know How to use it
  • Are Convinced That it’s Better Than doing it Themselves

There Is No ‘I’ in Architecture

Our egos can be our own worst enemy

people who:

  • think they understand the requirements better than the customers
  • view developers as resources hired to implement their ideas
  • get defensive when their ideas are challenged or ignore the ideas of others?

How to avoid it:

  • requirements don't lie
  • focus on the team
  • check your work, understand others opinions and ideas

Try before Choosing

Creating an application involved making decisions.
Decisions shouldn't be made from an ivory tower

Delay commitment until the last responsible moment; that is, the moment at which, if the team does not make a decision, it is made for them

I like this...

the later a deci- sion is made, the more information is available on which to base the decision

Understand the Business Domain

Know why a system is needed and how money is made from it.

Insurance lends more to a service oriented approach. FInancial markets are more workflow based.

Programming is an act of Design

software development—is a processes of discovery and learning, not a process of engineering and construction

Give Developers Autonomy

As a developer you rarely get the time to sit back and really look at how the whole system fits together

As an architect, this is your main focus. While developers are furiously building classes, methods, tests, user interfaces, and databases, you should be making sure that all those pieces work well together.

If you’re doing a great job of being an architect, you really shouldn’t have enough time to interfere with developers

Time Changes Everything

  • Pick a Worthy Challenge
  • Keep it Simple
  • Be Happy with Old Stuff

Software Architect isn't an Architect

We are not building buildings.

Software architecture is a craft, and it certainly takes practice and discipline to achieve success in the field

Practitioners of software development enjoy considerable compensation for work that is highly creative and exploratory

Scope is the Enemy of Success

Expanding scope is the enemy of success because the probability of failure grows faster than expected

What to do:

  • Understand the real need
  • Divide and conquer
  • Prioritize
  • Deliver results as soon as possible

Value Stewardship over Showmanship

There is a desire to prove one's worth - so you debazzle and baffle the team with your technical brilliance.

This showmanship is counter productive to leading a software development project - architects must win over their team with solid architectural decisions and understanding the environment.

Stewardship is taking responsibility and ownership of a project.

Heterogeniety Wins

Heterogeneous develop- ment affords using the right tool for the job, and text-based interop has blown the doors off what was previously possible

Context is king, and simplicity its humble servant.

For example they needed to choose a database for a tank - all databases achieved more than enough throughput for the systems on the tank.
However the firing of the gun cause an electromagnetic pulse that crashed the DB - so recovery time became the important criteria to base the choice on.

Dwarves, Elves, Wizards and Kings

  • Dwarves - hard workers - steadily producing artifacts in their cave
  • Elves - elegant, cultured creating beautiful and magical things
  • Wizards - immensely powerful and know magic

The architect is the king - must be familiar with the characters and architectures.
A good king will lead through many types of quests.

Architects’ Focus Is on the Boundaries and Interfaces

Divide and conquer - seperation of concerns...

The hard part is finding the natural place to locate boundaries.

With a bondary context map we can see what belongs together and what belongs apart.

Empower Developers

As an architect you should enable developers.
Make sure developers have the tools they need - tools should not be imposed on developers.
Repetitive and mindless tasks should be automated.
Developers should have top notch machines, access and speed to get things done.
If training is required - books etc. make sure they get it.

Record your Rationale

One type of documentation that ages well, doesn’t require much effort, and almost always pays off is a record of the rationale behind decisions that are made regarding the software architecture

Why? Why are you using this tech - what is the reason for this project?
What Assumptions are made?

Quality, time, cost and feature tradeoff.

For example you might choose grafana instead of kibana as it is not locked down to a single datasource (elastic) and has users and orgs in the open source version unlike kibana that you have to pay.

Challenge your assumptions

How often is it that assumptions are made up in your own mind - not backed by any evidence.
Just historical reasons cited.

Quesiton these assumptions...they may not be true.

Share your Knowledge and Experiences

We learn a great deal from success and failure.
Disseminating this experience and knowledge is vital in helping sustain progress.

Pattern Pathology

Design patterns are excellent tools for mitigating necessary complexity, but like all tools, they can be misused

Don't become imfatuated by them - stamping patterns all over a project usually means overengineering.

Don’t let your desire to exhibit design pattern knowledge cloud your pragmatic vision

It’s our job to identify problems solved by these solutions when they arise and apply design patterns appropriately

As pragmatic.

I don't think I can name a signle design pattern...they might even be a smell when someone mentions them...

Focus on Application Support and Maintenance

  • There is no debugging in production
  • Log levels are lower in production
  • The CEO is now aware of the bug - mroe pressure

The relationship between developers and support should be good - most problems require a developer.

Make the support lead a core part of the dev team

Prefer prinicples, axioms and analogies over opinion and taste

Start with a walking skeleton

A minimal end-to-end implementation of the system that links together the main architectural components

Its all about the Data

If you stand back a little, a computer is nothing more than a fancy tool to help you access and manipulate piles of data

Data cuts through the crap

Make Sure the Simple Stuff is Simple

Thinking you are smart - and being clever.

Very bad smells.

Before Anything, an Architect Is a Developer

Perfect is the Enemy of Good Enough

My advice: don’t give in to the temptation to make your design, or your imple- mentation, perfect! Aim for “good enough” and stop when you’ve achieved it.

Avoid "Good Ideas"

The really insidious thing about “good ideas” is that they are “good.” Every- one can recognize and reject “bad” ideas out of hand—it’s the good ones that slip through and cause trouble with scope, complexity, and sheer wasted effort incorporating something into the application that isn’t necessary to meet the business need.

The Business vs the Angry Architect

At this point we can draw on our experience to provide many solutions quickly, leaving more time to enjoy the challenging issues. We’re confident in our solutions and we deliver as adver- tised. We have reached homeostasis. This is the perfect time to make a colossal mistake—like deciding you know so much that it’s time for you to start talking more than you listen

You aren't bigger thant he business - the business is our reason for existence

We live to serve the business.

Remember, when you’re talking you can only hear something you already know. Don’t ever start thinking you’re so smart that no one else has something valuable to say.

Don’t allow yourself to become a disgruntled genius who spends all of his time try- ing to impress others by making witty, condescending statements about how poorly the company is run. They won’t be impressed.

Stable Problems get Higher-quality Solutions

Real world programming is not solving the problem someone gives you, in the real world the best architects work around the hard problem - and find simpler solutions.

The skill is drawing boundaries so that problems are stable and self contained

Seperating into smaller chunks

What is interesting is that if the problem is stable, then when it is solved, it is solved permanently

It takes Diligence

An architect's job is usually charactierised by ingenuity and problem solving

However an equally important characteristic is Diligence

Take Responsibility for your Decisions

  • Decisions should be substantiated and traceable
  • Decision has been communicated to people who are affected by it

Don't be Clever

general intelligence, resourcefulness, thoughtfulness, a breadth and depth of knowledge, and an affinity for precision are laudable qualities in anyone, and particularly prized in architects

"cleverness " implies the ability to quickly get out of a jam but ultimately rests on a gimmick, a shell game or a switcheroo.

Clever software is expensive to maintain and brittle.

Cleverness should never be required, if it is then you haven't sovled the problem simply.

Cleverness is tricking software into working.

In simple solutions - one component does one thing.

Your customer is not your customer

In a software requirements meeting the customer you are serving momentarily is not your customer.
Your real customer is you customer's customer.

If you customer's customer win, your customer wins

It will never look like that

A detailed design can fool you into thinking you have everything covered.
Planning is guessing.

The truth is no matter how in depth the design is - it will never come out how it is imagined in your head.

Minor changes and external factors add up and it never turns out the way it was designed

Choose Frameworks that play well with others

Think about how easily a framework can adapt, change and update as the system evolves.

A system should be designed with mutually exclusive frameworks.

Make a Strong Business Case

  • Establish the value proposition - executive summary - how it improves the business
  • Build metrics to quantify
  • Link back to traditional business measures
  • Know where to stop
  • FInd the right timing

Control the data not just the code

You need to be able to build the entire application, including the data- base, as one unit

Pay Down your Technical Debt

Do it right or take shortcuts.

Generally business people (sales, marketing and customers) will want the change made as quickly as possible.
Where developers and tested are more concerned with doing things properly.

Technical debt is in the form of system instability and increased maintenance due to no tests or documentation and shortcuts being taken.

Don't be a Problem Solver

Developers get rewarded for solving programming problems, which are more local in scope than architectural problems

Finding problems and solving them architeturally is what gets you the big bucks and provides the most value

Sometimes the best solution is no solution - it is too easy to jump into problem solving mode - it is how we are conditioned.

Most problems don't need to be solved at all - they just appear as problems when looking at the symptoms.

We should interrogate the problem itself - not just jump into problem solving mode.

Understand the problem and the context and the value that will be added or removed by solving it.

The Ultimate Tool is the Invisible One

A tool that doesn't even feel like it is a tool - it is just part of the job

Find and Retain Passionate Problem Solvers

FInd problem-solving skills and passion - deep technical parts are not as relevant.

Asking someone about the process of diagnosing performance issues gives much better insight.

Keep developers motivated and keen.
Beware of negative reinforcement.

Learn a New Language

If you are a programmer - learn the business and testing languages.

It facilitates communication and helps the business do things more effectively

You can't future-proof solutions

Solve the problem you have, not the problme you want

No one can predict the future - planning is guessing.

Accpet the fact and release yourself from the burden of the future.

Too much analysis and design also has this problem

The User Acceptance Problem

  • People don't like change. There may be a negative reaction.
  • People have a fear of losing functionality, influence or power
  • People fear unproven tech
  • People have cost and budget concerns

Start early and engage with end users.

Consomme - Refine problems and thoughts

Software architecture requires a continual refinement of thought, a repeated straining of ideas until we have determined the essence of each requirement in the system

Many missed requirements and bugs in software can be traced to ambigu- ous, general language

Focus on what can be removed

For the End User, the Interface is the System

There are too many good products hidden behind bad user interfaces

Great Software is Built not Grown

Start small - the bigger the size at the start the more likely it is to fail.
Design small upfront.

More chance of being untestable and fragile.

Give the system a chance to grow - forget the massive spec ast the start.
Think minimal - think smaller.

Entrepreneur Wisdoms: Kevin O’Leary

Here are some excepts from Kevin O'leary's book: Cold hard truth on Business, Money and Life.

I was not built to be an employee but that does not mean I am better than the people I employ

...As long as my employees interests align with mine, we'll be fine. The minute they don't, they're gone, whether I like them or not

What are you willing to do, in order to be?

What level of rejection, fruitless meetings, disheartening developments and failed phone calls are you willing to make in order to get the 1 or 2 clients that will start or continue to grow your business.

You need to be ruthless and have heart and commitment to your ideas.

If you can't monetise a skill, it's a hobby

The key to growing wealth is not only having the skill but owning the place where that skill / skills are applied

The was no doubt in my mind that I would never be happy being an employee. But my goal at the time wasn't happiness - it was experience. En route to working for myself, I was fully aware I was going to have to work for other people from time to time.

There will come a time where you will need to leave the nest and make money on your own terms

Use your time working for others to figure out what team you need

How to Spot Winners

  • They have proof of money making and a plan to secure new ways of generating money
  • Money requires face time
  • Don't candy-coat screw-ups, demonstrate the lessons learned.
  • Winners lack defensiveness and have a relaxed humility

You need to solve a problem first

Distribution channels are key. Don't let great ideas die because you are too scared to face rejection. Pick up the phone. You will be rejected, Plenty of times. That is how entrepreneurial calluses are formed. The only people that mattered are those that accept the deal. If they don't, they are dead to you.


Don't do mundane shit, that other companies are experts at.  If they have perfected that part let them do that work and you focus on what you are good at.

To grow a company you have to live, breathe and sleep your business

Have multiple clients and investors, don't rely on one. It gives you options and leverage and ensures you are not on the short side of the equation.

Everyone is replaceable

I'm not making friends, I'm making money

Perfect Team

  • Have a business partner that compliments skills you don't have
  • A numbers expert

Code writers were a dime a dozen. It was like a game of Whack-a-Programmer

Rules for sucesssful Partnerships

  • Find someone whose strength are your weaknesses
  • Leave your ego at the door
  • Establish a common goal
  • Never undermine your partners in public, even when you think they're wrong
  • It's always about the company

Focus on the Best, Dump the Rest

If you want to buy a company don't talk to the president of CEO. He or she is often just an employee. Go straight to the shareholders.

People are infinitely greedier than they are competitive

Adapt or Die

Money is the motivator, plain and simple.

How to be a Star Employee

  • Pace Yourself
  • Take stock if offered - It is impossible to get rich without owning stock
  • Think more than your company, think what competitors are doing
  • Don't brown nose the boss




Summary of 97% Owned Financial Documentary

97% Owned

Seigniorage - a form of fund raising for the government by selling currency to commercial banks.

It created bank notes for 4 pence, and sells the note to bank for 10 pounds, the profit goes straight to treasury and reduces tax burden.

In 10 years the Bank of England raised 18 billion pounds

In 1948 notes and coins were 17% of total money supply

Now notes and coins make up less than 3%. The rest of the money is digital and imaginary...97% owned.

Most money is now digital so it is not the central bank that creates the money it is the commercial/private banks that create the vast majority and decide how and to whom it is loaned to.

Banks create money, they don't lend it. When you get a loan, the bank just pretends you have deposited the money. It has to invent the liability.

If everyone starts saving, the amount of money in the economy shrinks. We have a recession.

Whoever creates the electronic money gets the proceeds. It is much more profitable than creating cash in the form of notes and coins as with digital money there is zero expense.

Commercial banks have created 1.2 trillion pounds in same time it took the central bank to create 18 billion pounds with hard currency.

Banks create new money by extending credit, buying an existing asset or by making payments on their account.

When a bank buys a company's bond it adds the bond to it's assets and increases the company's deposits by the corresponding amount. In other words, the bank just types in the figure it just bought the bond for on the company's account and it has acquired the asset. So it has created new money to the value of the bond out of thin air.

People think their personal or household economy works the same way as the national economy.

That is incorrect.

The money is distributed based on the priorities of the banking sector.

If you let bankers control money supply, they will keep creating it. Why would you stop you are creating it from thin air? And it is their prerogative to acquire more loans.

Until there is so much debt that it can't be paid back.

Money in the current system is debt. So the only way we can have money is if we have borrowed it all from the banks.

We think money is created from hard work, from working in a job. But in reality you would never have got that job without a loan / credit in the first instance.

Then people get over-indebted and cannot repay their debt.

Banks go insolvent and stop lending which causes a recession. People lose jobs and become more indebted to the banks.

If we didn't bail out the banks it would be a total and complete killer of economic growth or the whole economy, but now there is more debt from bailout.

The only way to stop this is for banks to stop creating money. Private profit seeking banks creating 200 million pounds a year and pumping that into the economy. These private profit seeking banks are putting money into housing bubbles making houses more expensive, making their loans bigger and making more money out of thin air.

Central bank reserves is an electronic version of cash (not the imaginary numbers or bank money the general public use), it is how banks pay each other.

A High street bank will create a bond which is effectively government debt and give it to the central bank and then the central bank will type some numbers into the account for that bank at the bank of england.

So the central bank is creating these reserves out of nothing.

Before the credit crisis if a bank was short of central bank reserves, it could loan reserves from other banks with interest.

When transactions take place they use special money central bank reserves, so you buy a house from another bank they tell central bank to change values of reserves.

If they don't have enough central bank money, then they can't make payments and the whole system seized up. So bank must ensure this doesn't happen.

Banks were allowed to set their own reserve targets each month.

Quantitative easing, is the process of giving commercial banks the reserve currency for free.

So central reserve money is considered real money, but fact is banks can have as much of this as they want now. It is also FIAT money, backed by nothing.

History of money

After world war 2, the UK and USA came together to manage world economies with the IMF and the world bank. At that time there was still a gold standard - Dollars was pegged to gold. And all currencies pegged to the dollar so long as americans played the roll as oversight. Preventing countries not being able to pay their bills / currency collapses. Then Americans started inflating the value of their own currency (To pay for vietnam war).

The French got worried and sent a gun boat to ask for their gold back

FIAT currency - medium of exchange where issuer does not promise to redeem in a commodity and holds its value based on confidence alone.

We believe it is worth something.

Growth and Inflation

A growing economy required growing debt.

Politicians (and many finance and economic professionals) do not realise this.

Money supply can be used to drive growth but it can also be used to inflate asset prices and for market speculation.

Inflation is the general rise in prices of goods and services. It means that each unit of currency is worth less as time passes.

When money supply grows there is more money for investments and growth but there is also more money for market speculation and buying of goods.

Inflation is caused by too much money chasing too few goods and services. When money supply is growing at a faster rate than goods and services.

Recorded / Measured is flawed

CPI is a measure of the increase in price of  basket of goods and services over time. It is deemed to provide a consistently lower figure for inflation. This is because house prices, mortgage repayments and council tax are excluded from the calculation.

RPI retail price index is deemed a better representation of inflation.

The biggest expenditures one makes should be taken into account, like house or car / school fees.

The increase in mortgage/loan on a house does not increase the economic output of a naction. It just increases money supply and hence does not enhance GDP, causing inflation. Banks creating money leads to more speculative credit and higher valuations on safe assets.

You can give a loan to a small business, is more risky as there is less collateral. Giving a Loan to a house, on the other hand, there is collateral. Not productive investments.


High inflation on a specific good or service.

The Tulip mania. The money system is not abstract it has alot to do with nations, power, trade and how they interact.

The ideal attributes for bubble creation: Luxury and Necessity.

Inflation can be avoided if money supply or creation does not exceed the economic output

Argument for government to guide where money should be invested (war economy)

People are getting poorer all the time, money is distributed from the poor to rich.

Every pound of money, has a pound of debt.

Debts from the poor to the rich are set in stone and are now sacred.

The reason the poor are in debt is because the prices have gone out of control and when the system breaks the poors are the ones owing.

Bank Run

You can withdraw all your cash from bank, but this does not reduce digital money supply.

You can stop the monopoly by moving your money into local community banks, not these massive private banks.

International bank run - withdraw from one currency to another, reserve currency shifts from reserve currency to international bank. But not part of their local central bank.

Currency Wars

It will get a trade imbalance.

Spending more than they are earning = trade deficit. Ability to repay debts is questioned. You can devalue your currency so exports increase. Domestic industry demand has grown.

Central bank can sell reserve currency in the market to devalue currency (this reserve is created from nothing, typed into a computer).

Belief is the thing holding up a currency.

Third world debt is used as a form of colonialism, having power of the economy controlling what they do.

IMF tells 3rd world countries that they can pay back their debt by increasing exports so they are earning more dollars so you can pay off your debt. Which is all a lie.

In reality countries cut their government spending and hence they stop growing. So they paid their debts but their own economy was not being developed. So the country becomes poorer and then big corporations come to exploit its natural resources.

These rules imposed by IMF actually destroys local industry and makes more dependent on foreign loans.

Also tell countries to lower tax in multinational corporations.

Also means profits made in country go out and do not help locals.

To manage risk on this unbacked currency you needed derivatives, futures and new markets. Hedging = insuring against your risk.

Derivatives based not on real products were essentially gambling, which changed in the 1960.

Efficient market hypothesis, The theory is that a market regulates itself better than if a government interferes.

The 2008 credit crisis caused that belief to end. Anyone who still believes the market is self regulating is a pencil neck.

Credit default swaps - insurance against companies from going bust - inflated from 1 trillion to 60 trillion in 5 years. But it turns out they don't provide stability and the maths inside them is completely borked.

Cash is backed up by government debt and government debt is backed up by the ability of government to get money from the public through tax.

System is designed to make a few people very rich at the expense of taxpayers and citizens.

It Lowers standard of living of majority.

Currency Reform

So what can we do...

One hypothesis it to back a currency by renewable energy, which will increase investment in that space.

Banks should have to ask you what they do with your money. They shouldn't be able to gamble with it.

A safe account and an investment account so banks don't need to be bailed out by government.

Person to person banking.

We should not ask the banks for advice on how to improve the money system, they are the last people to ask.

You wouldn't ask a bad house builder advice on how to build a house.