reference

Home | Laws of UX Laws of UX is a collection of best practices that designers can consider when building user interfaces. Aesthetic-Usability Effect Chunking Cognitive Bias Cognitive Load Doherty Threshold Fitts’s Law Flow Goal-Gradient Effect Hick’s Law Jakob’s Law Law of Common Region Law of Proximity Law of Prägnanz Law of Similarity Law of Uniform Connectedness Mental Model Miller’s Law Occam’s Razor Paradox of the Active User Pareto Principle Parkinson’s Law Peak-End Rule Postel’s Law Selective Attention Serial Position Effect Tesler’s Law Von Restorff Effect Working Memory Zeigarnik Effect

Essays on programming I think about a lot | benkuhn.net Every so often I read an essay that I end up thinking about, and citing in conversation, over and over again. Here’s my index of all the ones of those I can remember! Nelson Elhage, Computers can be understood Dan McKinley, Choose Boring Technology Sandy Metz, The Wrong Abstraction Patrick McKenzie, Falsehoods Programmers Believe About Names Thomas Ptacek, The Hiring Post...

GitHub - azet/community_bash_style_guide: Community Bash Style Guide: writing useful and modern bash scripts, seriously. When to use bash and when to avoid bash it’s rather simple: does it need to glue userland utilities together? use bash. does it need to do complex tasks (e.g. database queries)? use something else. Why? … It consumes a lot of time and is often very difficult to debug in comparison to dynamic programming languages such as python, ruby or even perl....

Catalog of Refactoring Refactoring.Guru makes it easy for you to discover everything you need to know about refactoring, design patterns, SOLID principles, and other smart programming topics. See also: The Catalog of Refactoring The Catalog of Design Patterns

GitHub - ivbeg/awesome-status-pages: Awesome list of status pages Awesome list of status pages opensource software, online services, and public status pages of major internet companies.

Engineering strategy every org should write. | Irrational Exuberance An unordered list of strategies I would recommend every engineering organization document as they grow are: How do we review, merge, deploy, and release code? What are our approved technologies for new projects? When and how do we deprecate user-facing functionality? When and how do we deprecate internal tools? How do we document our software and process? Because this is a surprisingly controversial topic, explicitly which tools do we and don’t we use for documentation?...

Risk Based Prioritization This guide serves as a crucial companion for cybersecurity professionals, offering an in-depth understanding of how to effectively prioritize vulnerabilities in the digital landscape.

💼 An Engineering Leader’s Job Search Algorithm If you do nothing else from this guide, please: Use employee referrals to get your application noticed. Participate in practice interviews to level up your interviewing skills. Always negotiate your offer. Remember that job searching is hard, but your new team is excited to have you join–they just don’t know it yet! Communicating Impact For each job on your resume, you’ll want one or more bullet points that outline what action you took, what you achieved, the impact it had, and perhaps the tech that was used....

DevDocs API Documentation DevDocs combines multiple API documentations in a fast, organized, and searchable interface. Fast, offline, and free documentation browser for developers. Search 100+ docs in one web app including HTML, CSS, JavaScript, PHP, Ruby, Python, Go, C, C++, and many more. See also native apps: Dash (paid) for macOs Zeal (free) for Linux and Windows

Messaging Patterns Overview - Enterprise Integration Patterns This pattern catalog describes 65 integration patterns, collected from many integration projects since 2002. The patterns provide technology-independent design guidance for developers and architects to describe and develop robust integration solutions. The inspiration to document these patterns came when we struggled through multiple integration vendors’ product documentation just to realize later that many of the underlying concepts were quite similar.