* 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.
* 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 presumption. 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 superfluous
* [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)
* As a developer you should strive to at least understand one level of abstraction deeper than you work on - [Scott Davis](https://twitter.com/danielbryantuk/status/919866216222724096)
* Keep your code absolutely simple. Keep looking at your functions and figure out how you simplify further - [John Romero](https://twitter.com/CodeWisdom/status/926568192729894912)
* Fix it immediately, but plan for the long-term resolution. Document the short-term fix. Automate the solution. [Adam Bertram](https://www.pluralsight.com/blog/it-ops/troubleshooting-tips)
* You can’t go fast when everyone is spending their time fighting with the poor decisions of yesterday - [Adam Chester](https://twitter.com/adamchester/status/925479016798109696)
* [Shirky Principle](https://twitter.com/OlafLewitz/statuses/560711454434025472) : Institutions will try to preserve the problem to which they are the solution.
* [David McRaney](https://youarenotsosmart.com/2010/06/23/confirmation-bias/) - Confirmation Bias : Your opinions are the result of years of paying attention to information which confirmed what you believed while ignoring information which challenged your preconceived notions.
* [David McRaney](https://youarenotsosmart.com/2013/05/23/survivorship-bias/) - Survivorship Bias : When failure becomes invisible, the difference between failure and success may also become invisible.
* [David McRaney](https://youarenotsosmart.com/2010/10/27/procrastination/) - Procrastination is fueled by weakness in the face of impulse and a failure to think about thinking.
* [David McRaney](https://youarenotsosmart.com/2010/05/19/fanboyism-and-brand-loyalty/) - Fanboyism and Brand Loyalty : You prefer the things you own because you rationalize your past choices to protect your sense of self. The Internet changed the way people argue.
* [Charity Majors](https://twitter.com/rynchantress/status/778702826578911233) - Don't make production decisions just because you want to learn Go. That's what your Saturdays are for.
* [Charity Majors](https://twitter.com/mipsytipsy/status/778970572835270656) - experiment on dev tools, or in your 20% time, or off hour, NOT IN THE CRITICAL PATH
* [Wikipedia](https://en.wikipedia.org/wiki/Wikipedia:Chesterton's_fence) - Chesterton's fence : the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood.
* [Dave Rupert](https://daverupert.com/2018/04/eponymous-laws-of-tech) - (2018) The Eponymous Laws of Tech | A compendium of tech-related laws, fallacies, and other wisdom
* [Thomas Nyambati](https://medium.com/rackbrains/https-medium-com-thomas-nyambati-how-to-avoid-handover-nightmares-aea38d9a3793) - (2017) How to Avoid Handover Nightmares | I totally adhere to those principles in my daily work... they are well known but still deserve a reminder :-) ...
* [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
* when times get tough, if people run away from the process instead of towards it, it's broken. And when people are freaking out, they run away from complexity and towards simplicity. [Source](https://critter.blog/2021/01/07/a-simple-process-beats-a-perfect-process/)
* No broken window. A repo should always be in a clean and working state, i.e the last commit should always build successfully.
* If you broke it, take ownership for the repair. If you break something, you are responsible of the situation, fix it (it's ok to ask for help).
* Avoid branching/batching your changes | Be careful what you batch. Changes and version bumps should be integrated continuously, not all at once.
* Don't hide your work, branch instead, and get it reviewed before creating a PR / merging it.
* If possible, don't branch, work on trunk/main. Branching/Feature flags can help.
* Use Peer code review, if possible pre-commit reviews. Peer code review is a key element in building a robust and egoless engineering culture of collaborative problem-solving ([source](https://semaphoreci.com/blog/cicd-pipeline))
* If you change the principles/systems/processess, do it incrementally. Developer productivity matters a lot. Minimize friction. e.g don't do a migration of all CI/CD Ecosystem in a way that breaks everything for a while. Do it step by step, phase the changes. Make it possible to rollback easily to previous working state.
* Quality first | Quality is always right. If you’re doing CI and for some reason the integration fails, that means the broken build becomes the highest priority to fix before continuing to add more features. System quality—not just velocity—is important. CI works in three simple stages: push, test, and fix. But despite this simplicity, CI might become challenging if only a few members of the team practice it. Consequently, CI also requires a change in culture and support from management. [source](https://stackify.com/what-is-cicd-whats-important-and-how-to-get-it-right/)
* Refactoring can only truly begin once you've actually learned what a piece of code or some data structure did, the unique properties for which they were written or chosen. Anything else is setting yourself up for failure. [source](https://ferd.ca/lessons-learned-while-working-on-large-scale-server-software.html)
* It also means that when building systems, you should not assume that operators will do things correctly. Expect failure from people. Try to think about tools you can give them to undo their mistakes, because they will happen sooner or later. Have some dread. Be understanding. Know things won't be perfect. [source](https://ferd.ca/lessons-learned-while-working-on-large-scale-server-software.html)
* Whether you’re getting a lot of satisfaction from being busy or just feeling exasperated, don’t forget to occasionally stop and ask yourself: Is this the best use of time?
* Improve systems : Improving systems helps remove busywork from an employee’s day, but it also makes things easier for the customer.
* **See also ** [Ref : How Being Busy Kills Productivity](https://www.hellosign.com/blog/busy-kills-productivity) on how doing less can help you be more productive
* Focus on results; not time : Time tracking is unavoidable in some instances, but rather than the rule by which companies operate, it should be used as a secondary metric to the results they achieve. Rather than give an employee a 2-hour window to do a job, have her do it right the first time (bonus points for documenting the process), then review and adjust your future plans based on time tracking data.
* Test the crap out of everything you do before telling anyone you are "finished". See also [Ref : Being a slow programmer](https://shansvex.wordpress.com/2013/12/03/being-a-slow-programmer/)
* Use right tools for the job (email != todo list, PR and commits != code documentation, Jenkins != long term storage for releases/versions/build info/state of quality of your code)
* Write less code, read more than you write. Read more tips, manuals, blogs, articles, watch presentations and listen to podcasts about your programming craft. Learn from others prior to writing bugs. As with culture and and knowledge, 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 with, and it's true with code as well. See also [Ref : Being a slow programmer](https://shansvex.wordpress.com/2013/12/03/being-a-slow-programmer/) and [Ref : Learn to Read the Source, Luke](https://blog.codinghorror.com/learn-to-read-the-source-luke/)
* Learn how to write clean code, and repeat. So when you will have to rush, you will not forget to do your work right, and you will naturally provide more quality work. Also you will tend to detect issues earlier before they hit production, i.e during reviews, and writing better code will lead the whole team in getting a better codebase you can all be proud of, which mean work will become more agreeable.
* Don't react yet. Take a little time before taking action / reacting to a task/request/message. It allows you to think more about your answer / action. Also, ask yourself if you really need to take action now for this task, or if it can wait later in the day/week. Check if you're not giving the task more focus/consideration than it deserves.
* Wait before jumping immediately on every opportunity/request/problem. Don’t touch it / don’t (re)act too soon
* Before you write any code, think first about what problem this is solving and for whom. **See also** [Ref : Think first about what problem this is solving and for whom](https://letterstoanewdeveloper.com/2021/01/18/think-first-about-what-problem-this-is-solving-and-for-whom/)
* The faster you react, the less you think. Not always, but often. [Ref : Give it five minutes](https://signalvnoise.com/posts/3124-give-it-five-minutes)
* **See also** [Ref : How Being Busy Kills Productivity](https://www.hellosign.com/blog/busy-kills-productivity) on how doing less can help you be more productive
* You don't want heroes, but you might benefit from experts / excellents colleagues / colleagues & managers that provide support and insights and who do not let you take everyting on your plate.
* Don't be overconfident | the fallacy of skipping the planning stage. Some tasks look simple at first glance, but it can hide some challenges. Take the time needed to run your analysis and estimate the effort after you have checked all possible impacts you could check. Overestimating is one thing, but underestimating the effort and challenge can really lead to getting cascade issues and mistakes that would add a lot of pressure on every team and lead then to rushing even more and causing even bigger mistakes. See also [Ref : Skipping the planning stage](https://www.caines.ca/blog/2009/12/13/code-slower/)
* Be helpful not harmful, fix things and care more about your impact. You have a big responsibility on your hands, and you should take it seriously. The world needs as much care and conscience as we can muster. Defend your users against anti-patterns and shady business practices. Raise your hand and object to harmful design ideas. Call out bad stuff when you see it. Thoughtfully reflect on what you’re sending out into the world every day. **See also** [Ref : Move Slowly and Fix Things](https://m.signalvnoise.com/move-slowly-and-fix-things/)
* More so than all other tools (issue tracker, code management system, etc.) comments in code have the greatest chance of still being around and easily searchable if they haven't been deleted. **See also** [Ref : The case for comments in code](https://notes.eatonphil.com/the-case-for-comments-in-code.html)
* Code can’t self-document if it isn’t there. If you decide to not write some code and don’t leave a comment explaining why, there will be nothing left to explain what you were thinking! Add comments that explain why the code is doing what it is doing, or is structured the way that it is structured. **See also** [Ref : How to write readable code](https://jeremymikkola.com/posts/2021_02_02_how_to_write_readable_code.html)
* When you're done with your commit and push, just double check what you have just done. Sometimes issues or possible improvements appear obvious only when the work is already pushed. Next time, slow down and double check before pushing ;-)
* Make your app fail fast in case of error. Ignoring errors will have side effects and can cause even more harm than if you just had the app crashing on first error.
* Focus on simplicity. The answer is always there. [source](https://blog.strategicedge.co.uk/2013/03/tidy-up-as-you-go-along-be-it-cooking-diy-or-selling-your-software-solution-remember-the-small-stuff-as-it-is-big-stuf.html)
* Drinking caffeine triggers the release of adrenaline. Adrenaline is the source of the “fight-or-flight” response, a survival mechanism that forces you to stand up and fight or run for the hills when faced with a threat. The fight-or-flight mechanism sidesteps rational thinking in favor of a faster response. This is great when a bear is chasing you, but not so great when you’re responding to a curt email. [source](https://www.linkedin.com/pulse/20140805002649-50578967-how-successful-people-stay-calm/)
* Less caffeine. More hot water and sliced ginger. [source](https://blog.strategicedge.co.uk/2013/03/tidy-up-as-you-go-along-be-it-cooking-diy-or-selling-your-software-solution-remember-the-small-stuff-as-it-is-big-stuf.html)
* When you sleep, your brain literally recharges, shuffling through the day’s memories and storing or discarding them (which causes dreams), so that you wake up alert and clear-headed. Your self-control, attention, and memory are all reduced when you don’t get enough—or the right kind—of sleep. Sleep deprivation raises stress hormone levels on its own, even without a stressor present. Stressful projects often make you feel as if you have no time to sleep, but taking the time to get a decent night’s sleep is often the one thing keeping you from getting things under control. [source](https://www.linkedin.com/pulse/20140805002649-50578967-how-successful-people-stay-calm/)
* The alarm clock is for back-up. Not wake up: get enough sleep. [source](https://blog.strategicedge.co.uk/2013/03/tidy-up-as-you-go-along-be-it-cooking-diy-or-selling-your-software-solution-remember-the-small-stuff-as-it-is-big-stuf.html)
* Look for help | Use your support system. It’s tempting, yet entirely ineffective, to attempt tackling everything by yourself. To be calm and productive, you need to recognize your weaknesses and ask for help when you need it. This means tapping into your support system when a situation is challenging enough for you to feel overwhelmed. Everyone has someone at work and/or outside work who is on their team, rooting for them, and ready to help them get the best from a difficult situation. Identify these individuals in your life and make an effort to seek their insight and assistance when you need it. Something as simple as talking about your worries will provide an outlet for your anxiety and stress and supply you with a new perspective on the situation. Most of the time, other people can see a solution that you can’t because they are not as emotionally invested in the situation. Asking for help will mitigate your stress and strengthen your relationships with those you rely upon. [source](https://www.linkedin.com/pulse/20140805002649-50578967-how-successful-people-stay-calm/)
* Breathe. The practice of being in the moment with your breathing will begin to train your brain to focus solely on the task at hand and get the stress monkey off your back. When you’re feeling stressed, take a couple of minutes to focus on your breathing. Close the door, put away all other distractions, and just sit in a chair and breathe. The goal is to spend the entire time focused only on your breathing, which will prevent your mind from wandering. Think about how it feels to breathe in and out. This sounds simple, but it’s hard to do for more than a minute or two. It’s all right if you get sidetracked by another thought; this is sure to happen at the beginning, and you just need to bring your focus back to your breathing. If staying focused on your breathing proves to be a real struggle, try counting each breath in and out until youget to 20, and then start again from 1. Don’t worry if you lose count; you can always just start over. [source](https://www.linkedin.com/pulse/20140805002649-50578967-how-successful-people-stay-calm/)
* Don’t forget to drink water, get sunlight, and that we are basically a house plant with complicated feelings. [source](https://twitter.com/TheWeirdWorld/status/930155807651528706)
* Often when we think we are hungry we are simply thirsty. Drink water first. [source](https://blog.strategicedge.co.uk/2013/03/tidy-up-as-you-go-along-be-it-cooking-diy-or-selling-your-software-solution-remember-the-small-stuff-as-it-is-big-stuf.html)
* Drink decent tea and coffee. Do the simple pleasures properly. [source](https://blog.strategicedge.co.uk/2013/03/tidy-up-as-you-go-along-be-it-cooking-diy-or-selling-your-software-solution-remember-the-small-stuff-as-it-is-big-stuf.html)
* Let things blow up from time to time, you're not your work, don't feel you are not responsible for everything within your employer's company, and your employer is more resilient than you think.
* Check your posture. It will reflect how you are treating your body. [source](https://blog.strategicedge.co.uk/2013/03/tidy-up-as-you-go-along-be-it-cooking-diy-or-selling-your-software-solution-remember-the-small-stuff-as-it-is-big-stuf.html)
> * Simplicity: The system should always be as simple and small as possible. When software projects grow, so do errors and bugs. Techniques such as line-by-line inspection of software, relevant unit testing, and physical examination of hardware that implements protection mechanisms are great. For such techniques to be successful a small and simple design is essential. This is sometimes described as the KISS principle and YAGNI.
> * Least privilege: Each user and program should operate using the fewest privileges possible.
> * Open design: In order for a system to be secure it must never depend on attacker ignorance. Instead the design should be based upon technology that depend upon public scrutiny - whenever possible.
> * Complete mediation: Every access attempt must be checked and validated.
> * Easy to use: The human interface must be as easy and intuitive to use as possible. Easy and simple is always better than smart and fancy. Simple user testing is a great way to get valuable feedback.
> * Usability: Well known usability standards should be met if required.
> * Discrimination: User discrimination is never good. User discrimination is when an application only works for a very limited amount of systems, like when a website only works with JavaScript enabled even though it doesn't provide any functionality that really requires JavaScript.
> * Documentation: Lacking or inadequate documentation is a bug. Everything needs to be adequately documented from the very beginning, it is an integrate part of software development. I strongly abhor poor or lacking documentation.
* [Nicholas Bate](https://blog.strategicedge.co.uk/2021/02/seven-productivity-boosters-in-a-covid-19-world.html) - (2021) Seven Productivity Boosters in a Covid-19 World
> * Every 45 minutes, take 5 minutes. Stand, stretch, sip water, look out of a window at the horizon and ask what's really important at this moment?
> * Control what you can: your mood, where you place your attention (see 1) and the accessibility of distractions.
> * Sort out and invest in the home office. It’s permanent.
> * Have a flight-deck: one place, one view, one perspective of what you need to focus on. This is not your in-box. Unsure? Read You, Only Better.
> * Slow down enough that you can recognise the tantalisingly seductive but perspective destroying, energy depleting and soul withering nature of the blisteringly urgent, but actually not at all important.
> * Say 'no'. Say it constructively. Say it nicely. Say it helpfully. But say 'no'.
> * Do a few things totally brilliantly every day. And feel very productive.
