Pareto's law states that 80% of the results come from 20% of features (effort) of your application. Bear this in mind when planning the next scrum/delivery.

The best engineers are those who can estimate the effort of new requirements and they are the only with enough information to refuse the 80% that is not in the optimal next scope.

Own it! This is not the army, they pay you to think and take decisions and responsibility so speak up if you consider the requirements proposed are superfluous.

The worst code you've ever written is the code that is no longer used. Is called YAGNI (You Are Not Gonna Need It).

The best code you've ever written is the code you didn't write, simply because it's the only that never fails.

There's something I call fixing a bug by sedimentation (fixing it by accumulation of other bugs) or by erosion (client changed his mind). These are good examples where prioritization and waiting saved you from doing a worthless job.

Minimalism is not about not doing things but about focusing first in the most important.

Look for perfection, but not yet. Iteration is that friend that gives you the right advises at the right time.

First do it, then do it right, then do it better.

Engineers like to think that the world could be designed, however Nature shows the opposite. Any sufficiently complex system cannot be built out of design, it has to be evolved.

Consider everything as a work in progress and don't panic if it doesn't work right yet, remember Mosher's law, if everything worked right, you'd be out of a job.

Kill it. The sooner the better. Don't be afraid of throwing to the rubbish a project you've working on last months.

When you start from scratch, innovation comes organically inspired by previous experiences.

Evaluate your work constantly. This is what the book Lean Startup is all about, make your MVP (Minimum Viable Prototype) and validate it, if it doesn't fit, kill it, you will already learned from it.

Fail fast, learn soon.

Nobody can know much of everything.

Try to ask yourself how can you add value to your team. What do they need the most? Somebody who is an expert with scalability?, Somebody who knows every detail of the programming language? Somebody more focused in the product? A coordinator?

Every team is different so you have to adapt and choose, try to analyse the strengths and weakness of both you and your team.

Learn to love a particular thing and master it. Try to position yourself, it's like a brand, you like products that fulfill your needs not those who do a lot of things you already do by yourself.

Of course it's easier to get along well with people with whom you share common language but the real power is on complementary people, remember the A-team!

In some late point of our life we realise about the importance of basics. It's normally old people who claim they have gone back to basics. Don't be a fool and don't wait to realise about that so late, bet for basics, first.

There are very valuable concepts in CS (Computer Science) and the good thing is that you can apply them to every new design. You should try always a top-down thinking starting from them.

Borrowing an old saying, the three most important things in software development are: architecture, architecture and architecture, in that order.

Some examples of basics are: Separation of concerns, Systems engineering theory, GOF design patterns, GRASP responsability patterns, SOLID principles, Cleancode smells & heuristics, Agile guidelines, Algorithmia, Data structures, HTTP specification...

For example before you start digging into the details of how to use an specific unit test framework Jasmine, JUnit, Mocha... start learning in how to write testable code (for example isolating stateless code of your application and reducing the coupling between components).

Simple is harder than complex, minimalism requires a lot of creativity in order to find new ways of doing more with less.

Technical Skill is the mastery of complexity, while Creativity is the master of simplicity.

Creativity is intelligence having fun! so enjoy the opportunity.

So don't focus on working more, but in working less but smartly, Think! about your work, turn off the autopilot, leave the comfort zone and take control.

And hey! Don't be shy, it takes guts to change the status quo. But remember, the world you are living in is made by people no smarter than you are, they just believed it was possible.

Of course people will think you are a weirdo sometimes because the things you try are different, but you can't be a leader if you are not an innovator.

For example I'm sure every one of us has thought in some point that his company is losing too much time in meetings where you discuss about nothing. So Jeff Bezos, Founder and CEO of Amazon, has a particular and apparently a weird way to conduct meetings in his company. When all the attendants arrive to the meeting room they have 30 minutes to read the report of the meeting IN STRICT SILENCE. After that the meeting can start.

We have to write code for humans, not machines, and synthesis is the key of communication.

A good example is the Pascal's quotation "If I Had More Time, I Would Have Written a Shorter Letter".

Try to keep methods as short as possible, classes with a single responsibility, few parameters, avoid redundant comments… The work is finished when you have nothing to take away.

In software programming you can solve any problem by adding another layer of indirection, except the problem of too much indirection. This is true, and it means that we have to find balance in the complexity of our designs.

Abstraction is good, it allows us to create a new semantic level in which one can be absolutely precise. However, in some cases like refactoring we have to understand the big picture and it makes everything harder.

This is why we have to look for the natural points where we can make the division and try to understand the different possible trade-offs.

Examples of that are: Root-Leaf paradigm in Domain Model. Controller/Tools paradigm, High Cohesion/Low Coupling principle, plain RESTful APIs...

There's a concept named kipple that refers to all those things we keep but we never use. Our homes are full of it, so are our codebases. For example, legacy methods we are afraid to delete, just-in-case libraries we will never need, out of date comments…

It's only human nature to complicate so we have to enforce ourselves to simplify. This is a process we have to follow periodically, identify the kipple and destroy it.

Minimalism: it's all about avoiding distractions so that we can focus in the important things.