reference

Introduction | The Guide to SaaS Metrics The Software as a Service (SaaS) model is different since the initial sale rarely covers the cost of acquiring the customer. Instead, SaaS companies recoup their upfront investment over time, often in monthly or annual subscription fees. The critical question is: How quickly can despair turn into profitability? And how big is the prize outside the triangle? CATEGORY DESCRIPTION METRICS Unit Economics How profitable is each customer relationship over its lifetime? Can we scale customer acquisition sustainably? Average Revenue Per Account (ARPA) Lifetime Revenue (LTR) Lifetime Value (LTV) Customer Acquisition Cost (CAC) LTV:CAC Payback Period ARR How is our recurring revenue growing, and what are the key factors driving changes in this growth? ARR ARR Components (Gross New, Churn, Contraction, Expansion, and Restart ARR) Retention How effectively are we retaining our customer base, and what are the reasons for customer loss or reduction in spend? Gross Logo Churn Gross Dollar Churn Net Dollar Churn Gross Dollar Retention Net Dollar Retention Logo Retention Engagement How frequently and deeply are users interacting with our product, and what does this imply about its value? DAU, WAU, MAU DAU/WAU, DAU/MAU A3x7 Investor Benchmarks How efficiently is our company using its resources to generate growth, and how does it compare to market expectations? ARR Multiple Burn Multiple Magic Number SaaS business performance metrics covered in this guide. ...

Introduction | Engineering Ladders This framework allows software engineering managers to have meaningful conversations with their direct reports around the expectations of each position and how to plan for the next level in their career ladder. The framework relies heavily on radar charts to visually represent the different perspectives and expectations of a given position: The chart shown above has the following 5 axes: Technology: knowledge of the tech stack and tools System: level of ownership of the system(s) People: relationship with the team(s) Process: level of engagement with the development process Influence: scope of influence of the position The influence axis can be seen as a different dimension since it is orthogonal and applies to all the other axes. ...

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 Gergely Orosz, The Product-Minded Engineer ...

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. You are simply going to waste valuable time, performance and nerve you could have spent better otherwise. ...

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? How do we evaluate, select and adopt new technologies? How do we migrate away from our existing technologies? How do we respond to incidents? How do we identify and prioritize incident remediations? How do folks switch teams? How do you staff work on ‘unowned” areas and tools? How do folks move from individual contributor track to management track? How do they move back? How do you think about evaluating internal versus external candidates for scarce roles? How do you empower senior engineers to contribute to the engineering organization beyond day-to-day technical contributions?

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. The generic format is: ...

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.

Architecture Antipatterns Discover common architecture antipatterns, learn how to avoid them and overcome design pitfalls! Gain valuable insights, practical advice, and real-world examples to build better software architectures and improve existing ones. Cargo-Culting Domain Allergy Emotional Attachment Infrastructure Ignorance Malignant Growth Misapplied Genericity Never change a running system Over-Engineering Over-Modularization Under-Modularization

Media Types | IANA … Media Types (formerly known as MIME types) and Media Subtypes will be assigned and listed by the IANA.

Site Structure | Web Style Guide 3 The success of the organization of your web site will be determined largely by how well your site’s information architecture matches your users’ expectations. A logical, consistently named site organization allows users to make successful predictions about where to find things. Figure 3.2 — Examples of the “Goldilocks problem” in getting the site structure “just right.” Too shallow a structure (left) forces menus to become too long. Too deep a structure (right) and users get frustrated as they dig down through many layers of menus. ...

{width=“342” height=“268” srcset=“tumblr_nitzh5x70h1qz82meo1_400.jpg 342w, tumblr_nitzh5x70h1qz82meo1_400-300x235.jpg 300w” sizes="(max-width: 342px) 100vw, 342px"} PICOL stands for PIctorial COmmunication Language and is a project to find a standard and reduced sign system for electronic communication. PICOL is free to use and open to alter. [creative

playbook, by thoughtbot This is your playbook. It details how you and your teammates run our software consulting company and how we make web and mobile products together. We’ve made the playbook free and licensed it as Creative Commons Attribution-NonCommercial so others may learn from, or use, our tactics in their own companies. HELLO TIME Consulting Investment PRODUCT DESIGN SPRINT Prep Work Understand Diverge Converge Prototype Test and Learn CHOOSE PLATFORMS Web Apps Mobile Apps Programming Languages Frameworks Databases Licenses LAPTOP SETUP Laptop Dotfiles Text Editor PLANNING Daily Standups Tasks Weekly Retrospectives Planning Meeting Altering the Process DESIGNING Sketches Wireframes User Interface Interaction Design Visual Design Usability Testing DEVELOPING Version Control Style Guide Pair Programming Test-Driven Development Acceptance Tests Refactoring Code Reviews Continuous Integration PRODUCTION Checklist Domain Names SSL Certificates Hosting Performance Monitoring Error Tracking Transactional Email Payment Processing MEASURING AARRR Instrumentation Subscription Metrics A/B Testing Feature Flags SALES Leads Understanding Product Vision On Site Customer NDAs Roles No Fixed Bids Budget Rate Typical Projects Contract Invoices HIRING Recruiting Interviewing Offer and Onboarding OPERATIONS Expenses Email Calendar Documents Meetings Accounting Legal SHARING Blog Twitter Research Open Source GOODBYE

Mocks Aren’t Stubs Meszaros uses the term Test Double as the generic term for any kind of pretend object used in place of a real object for testing purposes. The name comes from the notion of a Stunt Double in movies. (…) Meszaros then defined four particular kinds of double: Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists. Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example). Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ‘sent’, or maybe only how many messages it ‘sent’. Mocks are what we are talking about here: objects pre-programmed with expectations which form a specification of the calls they are expected to receive. The classical TDD style is to use real objects if possible and a double if it’s awkward to use the real thing. So a classical TDDer would use a real warehouse and a double for the mail service. The kind of double doesn’t really matter that much. ...

**Dieter Rams: ten principles for good design ** (via Vitsœ | Good design ) Good design… … is innovative … makes a product useful … is aesthetic … makes a product understandable … is unobtrusive … is honest … is long-lasting … is thorough down to the last detail … is environmentally-friendly … is as little design as possible Born in 1932, Dieter Rams is one of the foremost industrial designers of the 20th century. ...

What Every Computer Scientist Should Know About Floating-Point Arithmetic Floating-point arithmetic is considered an esoteric subject by many people. This is rather surprising because floating-point is ubiquitous in computer systems. Almost every language has a floating-point datatype; computers from PCs to supercomputers have floating-point accelerators; most compilers will be called upon to compile floating-point algorithms from time to time; and virtually every operating system must respond to floating-point exceptions such as overflow. This paper presents a tutorial on those aspects of floating-point that have a direct impact on designers of computer systems. It begins with background on floating-point representation and rounding error, continues with a discussion of the IEEE floating-point standard, and concludes with numerous examples of how computer builders can better support floating-point. ...