When it comes to choosing design patterns I usually lean towards KISS, and prefer less code.
Cyclomatic Complexity is the enemy of maintainable software and naturally arises when users request new features and grows exponentially with the number of users and/or developers. Because of that I do prefer Cowboy Coding - it handles one side of that count. Reflexively I'll argue with new requests and try and predict what else can go wrong or what unintended outcomes will be that will lead to more user requests or complexity. One pattern I often use in my head is to imagine software as biological systems, evolving ecosystems in tandem with users. There's a sort of evolutionary arms race between growing user stories, making the business money, and Conway's law. I try and stick to the 80/20 rule as often as I can when refactoring and making changes and often consider the biological paradigm Structure/Function when designing. I consider it a win when the system is either less technically complicated or the use case is simpler (less steps for a users workow) after I've touched it between releases.
For example that 80/20 rule you mention is actually a mental model called Pareto Principle, or Negative Space model when doing a binary search, etc.
Reduce Statefulness -> Explicit error handling -> Reduce Dependencies (sometimes even violating DRY if need be) -> Reduce complexity -> Everything else.
Designing systems or software usually has decoupling and complexity as a priority, with everything else in second place.
Iterate, iterate, iterate.
---
Get users unfamiliar with the program, have them try to do X, Y, Z... ask what they are looking for, if they get confused... work hard to get your mind into the space of someone unfamiliar with the system you've created.
---
Keep your databases as simple as possible. Don't ever have a way to put in N of something... it's either none, one, or infinitely many with a related table.
---
Always have a way to get help visible to the user.
---
In forms, don't enable the "Submit" or "OK" button until all the preconditions are set. Same with other fields. Make it impossible to submit invalid data, if at all possible.
---
Never make a user type something more than once... each time data is entered is another opportunity for error.
---
Old advice: Make sure the program can be used completely without a mouse, using only they keyboard.
New advice: Make sure the program can be used completely without a keyboard, using only the touchscreen.
---
If you're doing a data transfer to an external device, what happens if the connection fails in the middle of the transaction? Test it, and make it fail-safe.
---
Use GIT to keep history, and take the time to make your commit messages meaningful to yourself and others in the future. (It sure beats the heck out of a folder of versionNNN.ZIP files)
---
O(n) - If you don't know about O(n) notation, learn it and its importance. A program that works fine with a toy dataset will become unusable if there is an O(n^3) operation in there somewhere.
A few hours of optimization an testing can outperform decades of Moore's law.
---
Structured programming - Break down things into pieces as small as is reasonable to work with, but no smaller. Put related code into modules (units in Pascal)
---
Information Hiding - Keep your interfaces strict, don't work around them to get at the internal state of objects. Doing so will limit your future options, and is a huge source of technical debt.
---
Documentation: It should be possible to effectively use your program with only the manual, and some time and effort. If not, the program isn't done.
---
Hardware: Intermittent hardware should be treated as hazardous waste, and disposed of as quickly as possible. - Mike's law of intermittent hardware.
http://mikewarot.blogspot.com/2007/10/mikes-law-of-intermitt...
---
Hardware: SSD drives are a great way to speed up an older system, but don't let them get full, or they will slow down.
To the greatest extent possible, don't let users type anything. First, let them validate your suggested inputs (if you can discern it or there are sane defaults). Next, let them select options (with your control over invariants, no way to select invalid scenarios). And only after the previous, let them type something in. Ideally separated into multiple fields so that you don't have to parse (screw you office time system that requires me to type 'hh:mm am/pm' precisely, an extra space or missing am/pm throws it off, even though it uses 24h time, so damn stupid).