bookmarks/PRINCIPLES.md

• Shared problems are solved faster
• Transparency forces authenticity and honesty
• Participative communities are more open to change
• Open standards provide business agility
• With more eyes, all typos are shallow
• Jon Prall - (2007) 85 Operations Rules to Live By
• Make decisions using the path of least regret
• The simplest explanation is always the most likely.
• Christopher Diggins - The Principles of Good Programming
• 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.
• Lars Kappert - Categorized Overview of Programming Principles
• Lucas Medeiros Reis - 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
  • static analysis tools for everything
  • code review for everything
  • test (automated and manual)
  • make small changes and iterate
• Ozan Onay - 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?
• Viktor Farcic - Jenkins World 2017: The Ten Commandments Of Continuous Delivery
• do pull requests
• prioritize
• finish what you're doing, focus on a small number of tasks in parallel.
• delegate some work to others if you already have lot of work to achieve, so you have more time to work on what matters for you
• O'reilly - contributions appearing in book 97 Things Every Programmer Should Know
• Daniel Miessler - Lot of concepts summarized by Daniel Miessler
• Kent Beck - 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
• Stuart Sierra - There's always a reason, no matter how strange the bug
• Johannes Seitz - Software Engineering best practice: Actually understand what you’re doing. Unfortunately it’s rarely used in practice.
• Stuart Sierra - "Bugs are dependency-transitive"
• Stuart Halloway - the #1 source of software defects is easy presumption. Presume nothing.
• "The Principle of Least Astonishment: Make a user interface as consistent and as predictable as possible"
• "Worried that TDD will slow down your programmers? Don't. They probably need slowing down." J. B. Rainsberger
• encourage others when they need it. relevant reference
• Tim Lister - If you don't get innate pleasure from writing code, it's time to move on
• Raphaël Yharrassarry - Il faut s'attaquer aux comportements et non aux idées
• Natanael Copa - don't install / start things unless explicitly asked for or needed (to improve security)
• Paul Graham - Don't let other people tell you the problems you're working on don't matter. People are frequently mistaken about this.
• Meir Lehman - An evolving system increases its complexity unless work is done to reduce it.
• Vala Afshar - Tell people where you're going and why. Some may volunteer their time and effort to help you get there sooner.
• Goethe - The way you see people is the way you treat them, and the way you treat them is what they become.
• Amelia Earhart - The most effective way to do it, is to do it. ~ Amelia Earhart RT
• Vala Afshar - The best way to achieve mediocrity is by often choosing the path of least resistance.
• Roy Osing - Anti principles (Don't do this !) / 11 Ways To Lose Yourself In The Crowd
• Martin Fowler - When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous
• Craig Zerouni - "If you have too many special cases, you are doing it wrong"
• You learn nothing from life if you think you're right all the time
• Mark Twain : If you tell the truth, you don't have to remember anything.
• One day, you will be at the place you always wanted to be. Don't stop believing.
• There is no elevator to success. You have to take the stairs.
• Andy Hunt & Dave Thomas - the original DRY principle : "Every piece of knowledge must have a single, unambiguous, authoritative representation, within a system"
• A prototype is worth a thousand meetings
• Business software implementation and development is unpredictable. There will always be things to alter timeline and priorities. Tina Marie Parker
• As a developer you should strive to at least understand one level of abstraction deeper than you work on - Scott Davis
• DhilipSiva Bijju - (2013) some Best Practices. Bonus : Related GitHub repo
• Keep your code absolutely simple. Keep looking at your functions and figure out how you simplify further - John Romero
• Fix it immediately, but plan for the future fix. Document the fix. Automate the solution. Adam Bertram
• Finding errors in your past decisions and ideas means you’re progressing. - Greg Kogan
• You can’t go fast when everyone is spending their time fighting with the poor decisions of yesterday - Adam Chester
• Better to Say "Oops" Than "What If…" (= avoid analysis-paralysis, or paralysis by analysis, aka the state of over-analyzing / over-thinking)
• The Art Of Clean Code by Victor Rentea
  • Make it more readable even if it makes writing harder : We read 10x more times than we write
  • Boy scout rule : always check in code cleaner than you found it
  • Functions are verbs
  • Boolean names should always answer yes/no
  • Classes are nouns. Avoid meaningless names (OrderInfo, OrderData vs Order)
  • Delete the interfaces : except for Remoting/API client jars and strategy pattern implementation.
  • Names : Make the name speak for itself. Apply Continuous renaming as your learn the application
  • Names : Names should be at least pronounceable. Don't abbreviate ! Unless it's a basic business concept, like VAT
  • Names : should be consistent and unique (synonyms confuse).
  • Names should have meaningful context. eg: order.customerFirstName. But don't repeat yourself (DRY) : Order.orderCreationDate
  • Functions should be small : 5-10 lines, ... or at least should be understandable in 5 sec no more.
  • Functions do one thing
  • Functions have max 2-3 parameters
• Shirky Principle : Institutions will try to preserve the problem to which they are the solution.
• Shower Thoughts - Don’t forget to drink water, get sunlight, and that we are basically a house plant with complicated feelings.
• David McRaney - 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 - Survivorship Bias : When failure becomes invisible, the difference between failure and success may also become invisible.
• David McRaney - Procrastination is fueled by weakness in the face of impulse and a failure to think about thinking.
• David McRaney - 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.
• Backend Engineer Principles by Kim Hirokuni
  • Security First : Risks have to be measured by the impact when that happens, not how likely it happens
  • Don’t break stuff : Backward compatibility for the win
  • Don’t merge PRs at late night : Merging PRs at Friday night is a terrible thing to do
• Charity Majors - Don't make production decisions just because you want to learn Go. That's what your Saturdays are for.
• Charity Majors - experiment on dev tools, or in your 20% time, or off hour, NOT IN THE CRITICAL PATH
• Wikipedia - Chesterton's fence : the principle that reforms should not be made until the reasoning behind the existing state of affairs is understood.
• Wikipedia - The No Asshole Rule

1. After encountering the person, do people feel oppressed, humiliated or otherwise worse about themselves?
2. Does the person target people who are less powerful than him/her?

• Act. No matter what. Planned Parenthood
• Dave Rupert - (2018) The Eponymous Laws of Tech | A compendium of tech-related laws, fallacies, and other wisdom
• No code is faster than no code. - Merb Motto
• If you can't see yourself working with someone else for life, don't work with them for a day. - Naval Ravikant. Tools of Titans by Tim Ferriss.
• Earn with your mind, not with your time. - Naval Ravikant. Tools of Titans by Tim Ferriss.
• 99% of all effort is wasted. - Naval Ravikant. Tools of Titans by Tim Ferriss.
• Total honesty at all times. It's almost always possible to be honest & positive. - Naval Ravikant. Tools of Titans by Tim Ferriss.
• Praise specifically, criticize generally (Warren Buffett). - Naval Ravikant. Tools of Titans by Tim Ferriss.
• All greatness comes from suffering. - Naval Ravikant. Tools of Titans by Tim Ferriss.
• Enlightenment is the space between your thoughts. - Naval Ravikant. Tools of Titans by Tim Ferriss.
• Love is given, not received. - Naval Ravikant. Tools of Titans by Tim Ferriss.
• Jan Stette - (2020) Things I believe
• dwmkerr/hacker-laws - Laws, Theories, Principles and Patterns that developers will find useful.
• Thomas Nyambati - (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 :-) ...

• Keep things simple.
• Document everything.
• Adopt workflow and best practices.
• Employ separation of concerns.
• Avoid using personal accounts or credentials.
• Automate as much as you can.
• Write good code.

personal thoughts

• MorganGeek - 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 - Productivity : To find a solution, first eliminate the impossible ones. Astuce : Trouver la solution en éliminant d'abord les non solutions.
• MorganGeek - Readability / Reusability : If you wan write a 100 lines function, you can also replace it with a dozen more legible functions

Values I adhere to

• Learn the basics of a language before learning frameworks
• DRY (Don't Repeat Yourself) is not about code, but about knowledge
• Refactoring is a development technique, not a project
• Break rules, take risks.
• True leaders want everybody to be great.
• True leaders don't respect discipline.
• Build and grown trust otherwise it can't work
• Best way to convince is by giving an example / by showing it exists
• Everything we do expresses a need
• We often eat only what we already like / know
• We all criticize, we need to be aware of it
• Violence is an answer to unsatisfied needs
• Take pleasure in simple things
• Ban negative thoughts
• Take the time you need, don't go too fast
• Take risks
• Ask for help when struggling
• Don't do to others what you don't want done to you
• Write down your ideas and your Aha moments
• Share your feelings, don't hide your humanity
• Don't let other people decide your future for you
• Give your word.
• Say no rather than "I don't know" or "whatever you wish"
• Doing / saying nothing is already telling something
• Let go of control / release the need to control
• The faster you do a task the more you learn and the sooner you become satisfied
• The slower you do a task the more painful it will be
• Say thanks
• Smile
• Give, share
• Take time for you, for important things and people
• Keep in touch, maintain friendship
• 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
• Observe without judging, relate facts
• Choose the right tool for the job
• Don't multitask
• Achieve what you're doing before you move to something else
• Life doesn't get easier you just get stronger
• living isn't fucking easy but at least you can make your life more fun
• when you pause what you're doing, you find more interesting ways to do it. So pause often
• Be you ! the world will adjust
• Write simple code that does not need to be refactored immediately : build solutions that can still be used or adapted to tomorrow needs
• Build solutions for today but anticipate future changes and always be at least one step ahead
• Teamwork starts with trust
• Il n'y a pas de forteresses imprenables, il n'y a que des mauvaises stratégies
• Think twice
• 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
• Perfection is not attainable, but if we chase perfection, we can catch excellence.

Art of Questions

• Just ask
• Explain your misunderstanding
• Explain / state what you know / don't know
• Sound confident
• Have a come back
• Know first which answer type you're expecting : Opinion ? Factually correct answer ? Well reasoned judgment ?
• Avoid "yes" or "no" questions
• Dig deeper (5 Why...)
• Use the power of silence
• Don't interrupt
• Prepare the topic (know a bit what you are talking about)
• Check your assumptions (are you sure about what you think you know ?)
• Find the right person to ask
• Use correct grammar
• Keep the question simple
• Differentiate between open (Why ?) vs closed (when ? who ?) question types
• Explain why you are asking

Art of Communication

• Never use "never", always avoid "always"
• Suggest, don't criticize
• Don't make important decisions alone
• Don't cut communication, don't go away, don't flee
• Share your needs, your wills, your tastes / opinions
• Mutually listen to each other. Know how to listen. Use your right ear for listening (right ear = left brain)
• Feedback is important : Show interest (nod, smile, ...)
• Talk about the connection you have with the other person
• When you communicate a hard decision, don't hide behind emails, talk directly to your audience
• Use the SBI tool (Situation - Behavior - Impact)
• Assertiveness is ability to say yes to the person, no to the task
• Respond rather than react
• Prepare, verify carefully what you will communicate
• Check if your message has been heard and understood
• Expect / Give feedback
• Know the 7 C's : Clear Concise Concrete Correct Coherent Complete Courteous
• Set the main idea first
• Focus on your audience
• Avoid passive constructions
• Be open minded, don't think you know everything about your audience
• Use the body language (physical and visual contact, ...)
• Stay calm : Wrap up then stop talking. Pause. Repeat. Ask clarification of a statement. Be clear.
• Look for humor.
• Look for compromise if the other cares about something not important for you
• Agree to disagree : take beak so everyone calms down
• Assert yourself : express (negative) opinions and needs positively. Ask for help. Learn from errors. Accept feedback. Say no
• Observe rather than interpret. Communicate facts not interpretations
• Understand people's needs/feelings
• Use non violent communication

Slow programming principles

See also Calm programming / Slow programming

• 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)
• 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
• 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
• 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
• Study your tools, see how you work, understand how you can improve it. Don't rush. Before you run, you have to learn to walk.
• Wait before jumping on every opportunity/request/problem. Don’t touch it / don’t act too soon
• 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)
• Love what you have. Using boring technology. Don't get distracted too often with shiny tools that reinvent the wheel.
• Write lesss code, read more. Read more code, tips, manuals, blogs, articles, watch presentations and listen to podcasts about your programming craft. Learn from others prior to writing bugs.
• Disconnect & Focus. Value your time, use it to focus. Put lot of non-meeting blocks in your agenda.
• 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.
• Do your research, don't always rush in coding or in reinventing the wheel. You will learn a lot through research.
• Reuse existing code. GitHub is your friend.
• Discipline / Consistency beat motivation and quality.
• You don't want heroes, but you might benefit from experts / excellents colleagues.
• Simplify. Become a minimalist.
• Do one thing at a time. Only one item under your name in the WIP. The rest will wait.
• Stay positive. Focus on what is doing ok, what you have accomplished. Focus your brain attention more often on something that is stress free.
• Limit your coffee intake. 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
• Sleep. 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
• 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