This is the list of the rules. As articles are added, I’ll add links to the rules and the tag “Article published yyyy-mm-dd” to the list item. Some articles will discuss multiple rules and a rule may be discussed in multiple articles. 9/11/2022

For more on the background of the rules, see here.

The General Rules

  • Rule 1 - Know who your customer is and what your product is. 8/20/2022
  • Rule 2 - Great collaboration solves all kinds of problems.
  • Rule 3 - Perception usually is reality.
  • Rule 4 - Make it easy to do the right thing.
  • Rule 5 - People are why we are here.
  • Rule 6 - Cooperation is a powerful force. 2/23/2024
  • Rule 7 - Be polite. Don’t be bashful.
  • Rule 8 - Sending teams to investigate different options is good. Fostering competition is usually the wrong choice.
  • Rule 9 - Everyone does something boneheaded at least once a week. 3/15/2023
  • Rule 10 - Every software project needs a strong product owner who has the vision, the authority, and ability to define the product. This goes for most forms of team effort, we just don’t call the role product owner. Sometimes this role can be a team, but it can’t turn into a committee.
  • Rule 11 - Continuously improve.
  • Rule 12 - Change for the sake of change isn’t good. Status quo because that’s the way it is isn’t good either.
  • Rule 13 - Don’t pursue perfection.
  • Rule 14 - If it isn’t tested, it’s broken.
  • Rule 15 - Slipping a date will be forgotten. Bad quality will not.
  • Rule 16 - Don’t overspecialize. It hurts your organization and your career.
  • Rule 17 - Understand your span of influence, not just your span of control.
  • Rule 18 - You can build processes to help good people do great things, or processes to help limit the harm of others. It’s really hard to do both.
  • Rule 19 - Agile Software Development rocks because it’s all about collaboration and feedback.
  • Rule 20 - Working iteratively does not absolve you of the need to be thoughtful and perform design.
  • Rule 21 - As team size grows, so does the need for formality.
  • Rule 22 - Use the highest level of abstraction you can get away with.
  • Rule 23 - Security is hard. The bad guys only have to be right once. The good guys have to be right all the time.
  • Rule 24 - Security needs people.
  • Rule 25 - People who think they are talented jerks are usually just jerks.
  • Rule 26 - Know who your backup is.
  • Rule 27 - Do the smart thing today so you can be lazy tomorrow.
  • Rule 28 - Don’t underestimate the time it takes to create content (part 1 - system content)
  • Rule 29 - Don’t underestimate the time it takes to create content (part 2 - knowledge)
  • Rule 30 - Most requirements we are given are actually someone’s idea of a solution. Understand the underlying need.
  • Rule 31 - Innovation happens when the people with the need meet the people with the how and can speak the same language. 2/23/2024
  • Rule 32 - As technologists, we need to be the ones to bridge the communication gap. Don’t expect the users of your system to do that.
  • Rule 33 - Fail Fast in your code and your organization. 3/23/2024
  • Rule 34 - Emphasize skill and highlight the “do-ers” in your organization.
  • Rule 35 - Don’t miss the glue in your team.
  • Rule 36 - “Don’t repeat yourself” : apply that to the computer too.
  • Rule 37 - Automated tests are my pillow.
  • Rule 38 - The compiler is your best test tool.
  • Rule 39 - People who make good leaders tend to think their own leaders are good by default. 9/11/2022 3/23/2024
  • Rule 40 - Creativity often is improved with some constraints.
  • Rule 41 - Treat incentives, especially monetary ones, very carefully. They often backfire and always limit people to operating inside the box. 8/27/2022
  • Rule 42 - Things that happen 10% of the time actually happen quite a lot.
  • Rule 43 - Thinking through what could happen is of greater value than trying to plan what will happen. (“Plans are worthless, planning is everything.”)
  • Rule 44 - Treat every proof of concept like it will go to production because often will — POC often means “Production On Completion”.
  • Rule 45 - The Quality Assurance team’s job is to validate the solution fits the need, not to find bugs.
  • Rule 46 - Every interaction between a senior person and a more junior person is inherently coercive. Every leader needs to actively create a culture where “no” is ok.
  • Rule 47 - If you are ready to fix it, you are not complaining.
  • Rule 48 - A lack of complaints doesn’t mean it’s good. It could be it’s seen as not changeable.
  • Rule 49 - Give your team options for technology, but not unlimited options for every type of technology. Give flexibility but don’t create sprawl.
  • Rule 50 - It’s good that your organization leans on public standards for technology as much as possible.
  • Rule 51 - You are always locked into something. You can’t avoid it and it’s not necessarily bad. Be intentional on the choice.
  • Rule 52 - Your primary job is to make the next person’s job easier. Sometimes that person is you. (paraphrase of Bob Martin)
  • Rule 53 - If you want to understand why someone is acting the way that they are, seek to understand their motivation. 8/27/2022
  • Rule 54 - Avoid creating multiple-boss situations for team members.
  • Rule 55 - It’s more important to follow the chain of command when you’re going down the chain than when you’re going up.
  • Rule 56 - Conway’s Law: Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization’s communication structure.
  • Rule 57 - Coplien & Harrison’s Corollary to Conway’s Law: Make sure your organization is compatible with your desired product architecture.
  • Rule 58 - Jim’s Corollary to Conway’s Law: Organizations are systems too. You can’t expect to affect significant change in an organization’s behavior without changing something else about the organization too.
  • Rule 59 - A leader’s job is to support the team. Most org charts are upside down! 1/21/2024
  • Rule 60 - If you think failure isn’t an option, it’s usually the result you’ll get.
  • Rule 61 - It’s not enough to have an open door. You need an open mind.
  • Rule 62 - Skip the psychology when interviewing unless you’re a psychologist.
  • Rule 63 - Work on the riskiest parts of an activity/project/product early.
  • Rule 64 - Always minimize work-in-progress.
  • Rule 65 - Once you start taking responsibility away from someone, they tend to shed other responsibility quickly.
  • Rule 66 - Know when data becomes code. This is particularly common in content management systems.
  • Rule 67 - Performance reviews are bad when they focus on the past. Don’t score what has happened, plan the future.
  • Rule 68 - No one is a zero. They either add to the team or take away from it. The question is whether those who are taking away are growing towards positive contribution.
  • Rule 69 - Err on the side of more granular and abstract in your system design, but still aim to only be as granular and abstract as you need to be.
  • Rule 70 - Be intentional.
  • Rule 71 - Never ask me my opinion unless you want it.
  • Rule 72 - Code reviews primarily are knowledge sharing activities, not quality activities.
  • Rule 73 - How we interpret a statement often has as much to do with who says it as the actual words used.
  • Rule 74 - Keeping standards high ultimately creates a better work environment.
  • Rule 75 - When you prepare to teach something, you usually learn more than your potential students.
  • Rule 76 - It takes a lot of preparation to be able to wing it well.
  • Rule 77 - Minimum Viable Products (MVP) are the start, not the end of a program.
  • Rule 78 - You need to identify the work, organize the work, do the work, and sell the work. Knowing the right order and right amount of each will define success.
  • Rule 79 - Selling happens internally too.
  • Rule 80 - Know where you are in your corporate lifecycle. Are you a startup? Are you an established enterprise? Are you owned by a sole owner, owned by private equity, have venture capital, publicly held, a partnership, or some other structure?
  • Rule 81 - If you don’t understand it until you can explain it to your grandmother/an eighth grader/a fifth grader then you don’t understand it until you can explain it without jargon, acronyms, and initialisms. 9/17/2022
  • Rule 82 - A fundamental rule of writing: Don’t use an acronym without first spelling it out (DUAAWFSPIO). This goes double for your marketing website9/17/2022
  • Rule 83 - No matter how much experience you have, there is something you can learn from someone with less experience.
  • Rule 84 - Interviews go both ways. The candidate is interviewing the organization just as much as the organization is interviewing the candidate. Keep this in mind both when you are hiring and being hired.

Specific Rules

  • Special Rule 1 - C and C++ are no longer general purpose programming languages. That doesn’t mean they are obsolete.
  • Special Rule 2 - It’s hard to replace direct database access because SQL just plain makes sense as a language.
  • Special Rule 3 - Know the difference between Base-10 and Base-2 numbers and how your technologies treat them.
  • Special Rule 4 - Most organizations will find hybrid approaches between traditional and cloud technologies work best.
  • Special Rule 5 - Whether something is IaaS, PaaS, or SaaS is often a matter of what you’re doing with it. The definitions make up a useful mental model, not a technology.
  • Special Rule 6 - Well-defined structure in your code is necessary to avoid bugs and get to the ideal of “it looks like one person wrote this, not a bunch.”
  • Special Rule 7 - Most teams adopting microservices make their services (as the unit of deployment) far too small. Remember Conway’s Law and think of its implications on your architecture.
  • Special Rule 8 - Microservices are more of a team organization architecture than a system architecture.
  • Special Rule 9 - Microservices should be built around the function (domain), not data(entity).
  • Special Rule 10 - You should only store as much data on a server as you can reliably restore in your Recovery Time Objective window. Thanks Brent Ozar

Pending Rules - things that need elaboration

  1. If you’re helping someone grow their skills and they still are not independent, it’s better to structure the work so they are helping you rather than you helping them.