• Philosophies

  • Usable is better than done, done is better than good, and good is better than perfect.

• Design Philosophy

  • An item must be useable in standalone execution as well as be usable as a module / API.
  • Like what Microsoft appears to do. Anything done today will be wrong tomorrow.
    • We run every interaction via interfaces, traits, and generics, and pad those interfaces with 2 or 3 degrees of indirection. a -> b -> c -> d. Think: cat, grep, less, strings, USB, Wall outlets, HTTP, iprogramming language designs (and how keywords are defined and how you use them in the language), etc...
    • Interfaces do not all need to be tightly defined from the outset. Reserved bytes and namespaces are created so we have plenty of options for filling in extra functions and endpoints later. This is how governments have handled managing and designating the limited radio frequency ranges.
  • Don't over-specify. Conditions on their own should be absolute; no redundancy nor repetition should be needed. A properly written answer for the fizz-buzz test would be a good example of this.
  • An extremely telling sign of a well-defined module or function, is that it can be comfortably used in unforeseen ways, without changes, and still produce correct output and produce no errors, thereby deriving new functionality.
  • Functions should not require many parameters. If many parameters are needed, or desired, a struct type or class instance containing those parameters should be used instead.
  • Functions should tend towards being generically defined, rather than being too type-specific, unless the nature of the process requires that parameters match a specific type. But, regardless of implementation, a function's purpose and usage should still be clear from the function signature.
  • Functions should not try to correct incorrect input and bad usage.
  • Prefer interfaces and generics over strict types

• Setup guides and checklists
• Troubleshooting
• Computer Science topics, theory, and application
• Cheatsheets
• Design Patterns
• Challenges and solutions
• Style guides
• Coding paradigms
• List of tools and programming languages

Programming Languages

Frameworks

Cloud

Projects

Current Primary Focus

• Reactjs
• TypeScript
• DevOps
• Nodejs
• SQL
• AWS
• Golang

To Do, Because that's what the jobs are asking for

• Agile, SCRUM, extreme programming (XP), TDD, BDD, unit testing, and others. Somehow give them examples of that experience.
• AWS... for some reason, everybody uses AWS, and nothing else...
• eCommerce Store
• DevOps (Super important)
• CI/CD
• A/B testing
• User Analytics
• Memcached (caching)
• Monitoring system performance
• Designing for scale and massively scaling your applications
• Kubernetes, cloud, docker, etc... for scaling applications
• SDLC, from conception to architectually sound systems
• Saelor
• Android
• Java
• C# .NET
• TypeScript
• Software Architecting
• Integration and integration testing
• Node.js
• Ruby on Rails
• Golang
• Shopify
• Wordpress