* You are the books you read, the films you watch, the music you listen to, the people you spend time with, the conversations you engage in. Choose wisely what you feed your mind.
* [Lucas Medeiros Reis](https://dev.to/iamlucasmreis/the-single-most-important-driver-of-software-quality) - The Single Most Important Driver Of Software Quality
* don't change code you don't understand
* never merge a branch with known defects
* use checklists to make sure the whole problem is solved
* [Ozan Onay](https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb) - You Are Not Google
* Don’t even start considering solutions until you **Understand** the problem. Your goal should be to “solve” the problem mostly within the problem domain, not the solution domain.
* **eNumerate** multiple candidate solutions. Don’t just start prodding at your favorite!
* Consider a candidate solution, then read the **Paper** if there is one.
* Determine the **Historical context** in which the candidate solution was designed or developed.
* Weigh **Advantages** against disadvantages. Determine what was de-prioritized to achieve what was prioritized.
* **Think!** Soberly and humbly ponder how well this solution fits your problem. What fact would need to be different for you to change your mind? For instance, how much smaller would the data need to be before you’d elect not to use Hadoop?
* [O'reilly](http://programmer.97things.oreilly.com/wiki/index.php/Contributions_Appearing_in_the_Book) - contributions appearing in book 97 Things Every Programmer Should Know
* [Kent Beck](https://twitter.com/KentBeck/statuses/499584833929367552) - If you break a problem into sub-problems and the sub-problems aren't simpler than the original problem, git reset --hard and try again
* [Johannes Seitz](https://twitter.com/Ookami86/statuses/515483645663252480) - Software Engineering best practice: Actually understand what you’re doing. Unfortunately it’s rarely used in practice.
* [Stuart Halloway](https://twitter.com/stuarthalloway/statuses/502906568569286657) - the #1 source of software defects is easy presumtion. Presume nothing.
* "Worried that TDD will slow down your programmers? Don't. They probably need slowing down." [J. B. Rainsberger](https://twitter.com/jbrains/statuses/167297606698008576)
* [Tim Lister](https://twitter.com/abt_programming/statuses/538015028574945280) - If you don't get innate pleasure from writing code, it's time to move on
* [Paul Graham](https://twitter.com/ValaAfshar/statuses/538015468146393088) - Don't let other people tell you the problems you're working on don't matter. People are frequently mistaken about this.
* [Meir Lehman](https://twitter.com/CodeWisdom/status/921139649661284352) - An evolving system increases its complexity unless work is done to reduce it.
* [Vala Afshar](https://twitter.com/ValaAfshar/statuses/537441340842582017) - Tell people where you're going and why. Some may volunteer their time and effort to help you get there sooner.
* [Goethe](https://twitter.com/ValaAfshar/statuses/537084241268727808) - The way you see people is the way you treat them, and the way you treat them is what they become.
* [Vala Afshar](https://twitter.com/ValaAfshar/statuses/536662076924915712) - The best way to achieve mediocrity is by often choosing the path of least resistance.
* [Roy Osing](https://talentculture.com/11-ways-to-lose-yourself-in-the-crowd/) - Anti principles (Don't do this !) / 11 Ways To Lose Yourself In The Crowd
* [Martin Fowler](https://twitter.com/abt_programming/statuses/531036428948738048) - When you feel the need to write a comment, first try to refactor the code so that any comment becomes superflouus
* [Andy Hunt & Dave Thomas](https://twitter.com/nicolopigna/status/921280768697143296) - the original DRY principle : "Every piece of knowledge must have a single, unambiguous, authoritative representation, within a system"
* Business software implementation and development is unpredictable. There will always be things to alter timeline and priorities. [Tina Marie Parker](https://twitter.com/Nozeyparkers/status/922403525950353409)
* [MorganGeek](https://twitter.com/MorganGeek/statuses/420907517934178304) - Problem solving / Productivity : Good programmers write code after they found the solution. Un bon programmeur ne commence à coder qu'après avoir trouvé une solution.
* [MorganGeek](https://twitter.com/MorganGeek/statuses/450614047608934400) - Productivity : To find a solution, first eliminate the impossible ones. Astuce : Trouver la solution en éliminant d'abord les non solutions.
* [MorganGeek](https://twitter.com/MorganGeek/statuses/450218285129531392) - Readability / Reusability : If you wan write a 100 lines function, you can also replace it with a dozen more legible functions
* Market yourself. You're putting on the effort, make sure you show it
* Go right to the point
* Ask why
* Keep your ability to be amazed by things and people, they won't last forever
* Act to fight perfectionism
* Take advantage of any opportunities that present themselves
* Physical and visual contact rather than emails, sms, chat
* Accept people as they are
* Select your friends
* More slow, minder stress
* Remain calm and quiet about everything which you will experience
* Reinvent yourself, evolve
* Grow and progress in love, work, leisure
* Be yourself, know yourself
* Be curious, observe and play (mentally, physically) with what surrounds you
* Be positive
* Be realistic, concrete
* Understand your goals and others' goals
* Taking notes, writing things down is a way to free your mind and not forget or lose anything. It's also a way to train your senses of observation and reflection