Bringing up Omarchy (omarchy.org/) today on a laptop. I hadn't used tiling on Hyprland before - it took a few minutes to get the hang of the keys. Seriously fast, crisp screen updates. Techies, give it a try!

For developers out there, would like to recognize the @windsurf_ai team for great work over the last few releases. I've been using v1.3.4 in agentic mode to work on a small-ish Bun/Typescript project we are releasing at end of month. The interface is getting much better every week! Finding the diagnostic loops to work better with Claude. Have had to nudge a few times on unit tests and some syntax issues. Overall, though, this is great!

New threads, broader mission: helping transactional businesses and their partners wrangle their scaling problems into submission. We've leveled up our game to turn your business challenges into solutions. Want to see what we're cooking? Hop over to our new website at 3leaps.net. Call or message us - we would love to explore how we can help you! #3LEAPS #ScaleUp

Smooth Development Maxims - Build In Observability Part 2 Practical tips for improving scalability and resiliency with observability Here are some tips we've accumulated from work with clients across a wide range of projects. DM me @3leapsdave or seek help from an experienced architect if you aren't sure how to get started. 1.) Log to STDOUT as a general pattern, using a well-supported library to format and direct traffic where needed. Use STDERR as well if you have a consistent pattern and a good reason for separating. Code is cleaner if you always write the same way. It is hard in large systems to keep up with file pointers. 2.) Implement centralized logging with an agent - being careful to avoid blocking You'd be amazed how many times we have found applications that will literally stop running if the log queue backs up. 3.) Write logs in a structured form using JSON or other notation Yes, it is harder to read on a console. However, having real "key value" patterns and consistent sets of data from each message means your analysis tools on the collection side will work much better. Remember, logs MOSTLY exist to sort out an issue AFTER it happens. The easier you make the forensics process, the faster you will find your problems. 4.) Instrument your code with event and place marking telemetry Libraries like OpenTelemetry provide a simple pattern to enable the code to say "I'm here" . For larger applications, it often makes sense to have some telemetry streams that are separate from the main activity log. We prefer this pattern for marking state in complex back-end operations, as an example. 5.) Select and use an analysis and visualization system for your logs and event data Some like the ELK stack (Kibana being the visualization part). Some like Grafana Prometheus. There are many excellent open source commercial solutions that integrate analytics and alerting for logs and events. If your solution has large data pipelines, think in terms of a "Data Operations Console" that provides real-time information on data flows and issues. As with all refactoring exercises, a key to success is choosing a balanced mix of "small quick wins" and "big winners". As we wrote in Part 1, find the blind spots first and fix them. Start small on your alerting and analysis with one key area - get that right and then add more. Dedicate a few stories each sprint to improving telemetry. Measure, Monitor, Manage! #smoothingsolutiondelivery #measuremonitormanage #3leaps

Development Maxims - Build In Observability Measure, Monitor, Manage While I am not certain that everything about software development is improving over time, it has never been easier to monitor the performance of applications. I started working in a time when we flashed LEDs or seven segment displays for most observability tasks. STDOUT (logging) usually went to a terminal via a serial port (creating all sorts of issues with blocking that at least did teach me a lot about asynchronous i/o). Today there are a number of patterns for centralized log delivery that work in virtually any language and operating environment. Entire libraries exist for event telemetry - really just a way of sending specialized log messages that provide specialized information about what is happening or what part of the code happens to be running. Unfortunately, I see all too many systems and applications that do not implement observability. As mentioned in a recent post( 3lps.co/wc8 ), I grew up on the principle of Measure, Monitor, Manage. Paraphrasing a former mentor and boss from many years ago, "You have to measure something in order to monitor it. You have to monitor something in order to manage it. You have to manage something if you want it to work all the time." Scalability requires observability. If you cannot see what is happening and understand the traffic your applications are getting, you cannot identify and fix bottlenecks. If you don't know how long it takes to process requests across a wide range of traffic scenarios, you won't know how your application will perform under stress. Ask your team members responsible for level 3 support, provisioning and performance tuning where their blind spots are. Chances are you will identify some quick wins - areas where you can add event telemetry feeds (simpler as first step than refactoring logging) or implement automated pattern searching on centralized logs you already have. In terms of tech debt resolution, this effort is one of the highest value, quickest return areas out there!

Remembering that Excellence Wins Here's a plug for a book that reminds me that customer satisfaction and (fanatical) loyalty come from a firm's absolute devotion to operational excellence, empathy, kindness, and the incredible power of being nice. Ever have a book come to mind when writing? Only a fistful of business books stick with me. Today I was working on a Smooth Development Maxims post for our 3 LEAPS page and one came to mind. The subtitle for this post is "Measure, Monitor, Manage" - a core maxim taught to me by a gifted boss and mentor back in the late 80s and early 90s. Check out the book, Excellence Wins (horstschulze.com/) by @horstschulze . Mr. Schulze was a co-founder and longtime president of Ritz-Carlton and the architect of their legendary management systems. This book will remind you of how to build lasting customer loyalty. I offer that it might inspire you to be passionate about building a better organization, being a better leader, and being a better person. Without spoilers, I will simply say that his idea of "becoming the best in a world of compromise" is something I strive to follow. Ritz-Carlton was legendary for their service in the 90s. Their employees were (and may be still) famously empowered to spend - without management approval - a fairly large sum "per incident" in order to delight a guest. What brought me into researching them was their process discipline. As my mentor taught me, "You have to measure something in order to monitor it. You have to monitor something in order to manage it. You have to manage something if you want it to work all the time." Does it seem strange that I learned a core principle of enterprise-scale operations from the business processes of a hotelier? The funny thing about this (important-but-dry) topic is that I learned in the context of how a hotel chain became literally world-class in service delivery. Those of a certain age may remember that Ritz-Carlton was (and still is) the only hotel company to have won the Malcolm Baldridge National Quality Award - twice (in 1992 and 1999). Here's a link to a story about win #2: nist.gov/baldrige/ritz-carlt…. If you deliver solutions with software, I humbly note that "people buy solutions from people." Those feature charts we make help us stand out in the early sale. Winning and keeping clients comes from delivery excellence. In the end, I've come to appreciate the brilliance of my former boss and mentor, teaching me that software folks could learn quite a lot from the hospitality industry. I try now to seek out examples of firms delivering excellence in any area or walk of life. People reward firms that deliver good and reliable experiences with more business. People become lifelong fans of firms that deliver excellence and have genuine empathy and initiative for their needs and for those around them. Don't compromise on principles - deliver excellence! #opsuccess #smoothingsolutiondelivery #3leaps

Smooth Development Maxims - Keeping Things Dry One of our core maxims is to "follow the DRY principle." DRY means "Do not Repeat Yourself." It means that - among other things - system-of-record data should not be duplicated. Advanced data engineering and analytics staff will note that we DO repeat ourselves in certain cases, particularly with semantic data stores built from flattened data into "query friendly" layers. I stand by the DRY principle even here because of how these flat data stores are typically built. Whether through views ("simulated" data stores built on lower layers in a user-friendly way) or via automation, the DRY principle ensures we have only one system-of-record. The web developers among you may use pnpm, an alternative to npm for managing the (many) packages in a typical web application. One of the key innovations is the use of a content-addressable store. In straightforward terms, pnpm follows the DRY principle. Have 100 modules using the same package? You'll have one version shared across the 100 modules on your build machine rather than 100 copies. Staying DRY is not only about saving disk space by eliminating duplication. Being clear about where the "source of truth" lies leads to better design. When we make copies of the same thing over and over, it is highly likely that at some point we'll mess up an update and change only SOME of those copies. Devops professionals probably use Terraform or OpenTofu. These tools (used for efficient provisioning of infrastructure) use a language that can in some cases require lots of copies of the same text. On this front, 3 LEAPS supports Gruntwork's open source work on Github. In particular, we are fans of the package Terragrunt (please consider supporting if you are building IaC). We like this tool for many reasons, particularly as it helps us to avoid duplicating common code. What are some things we can do to stay DRY? 1.) Do input validation in exactly one place (using schemas - for a future post) 2.) Put configuration data in exactly one place 3.) Structure code as a series of transformations and extensions that derive additional measures from existing sources (vs. copying functions and altering) 4.) Build specifications referentially (don't repeat requirements or parameters - instead reference other sources) Despite the simplicity of this principle, we see a lot of (ill advised) duplication. Imagine a case where you have three slightly different paths in a pipeline using the same input. If you copy the code twice, now you must remember to make common updates multiple times. If you forget, some cases will work and some will fail. As obvious as this seems, I routinely coach development teams through bugs that arise from improperly duplicated "common code." DM me if you would like some references on this topic. Take a look at your work in-flight and ask yourself where you might be copying rather than referencing. Keep your systems DRY! #smoothdevelopment #staydry #3leaps

Smooth Development Maxims - Making Specifications Work Make specifications sparse, precise, and verifiable. In the TL;DR age, too much documentation is unfortunately nearly as much an issue as too little. Modularity is important - just as it is in software design. Specifications represent the most important part of any system's documentation tree. Good specifications provide developers, architects, test analysts and other product-related specialists with clear requirements and methods for verification in a minimalist structure. We describe this as "sparse, precise and verifiable. The most effective specifications are built from many single-topic items. While complex components or interfaces may benefit from an additional "theory of operation" in prose, focus first on quantitative requirements that map to success. Build a taxonomy of the important kinds of specifications. Then build small (Markdown-based) documents for components, interfaces and systems that cover a single topic. We can use auto-build systems to build a larger document by combining many small ones. Working in this manner makes it easy to get started and to focus on the areas your particular system needs most. In our @3LEAPS Flow Lanes syntax, we always include what we call Key Assurance Metrics: testable attributes tagged as functional, performance, availability, and security. These key inputs work to an overall verification plan, representing the KPIs that define success. At the component or interface level, start by deciding what needs a specification. Interfaces should be precise - JSON Schema, JSON Type Definition, OpenAPI, and AsyncAPI are tools you might consider. External interfaces in particular need formal specifications that are accessible by (external) users. Document algorithms and functional logic using simple flow diagrams or text and by storing the (Markdown) documents in the code as noted in another post ( 3lps.co/ny5 ). When reviewing what constitutes an adequate specification, think from three key perspectives. 1.) What does a developer need to know in order to address the full range of inputs and boundary conditions? Consider numeric precision as an often overlooked item. 2.) How are high-level system requirements (Key Assurance Metrics) particularly impacted by this component? 3.) How can a test analyst confirm operation in black box fashion? While the specification count might seem overwhelming, recognize that no system and no component requires every type of document for every use case. Start with new work, adding specs that cover the most important areas based on your own analysis of where gaps lie. Ensure the acceptance process for each development cycle includes specifications. As you build up an inventory of specifications, your devops team can add CICD operations to create a larger validation "suite." Don't let TL;DR attitudes create ambiguity or inconsistency in your system design! #smoothdevelopment #flowlanes #3leaps

Smooth Development Maxims - Keep Documentation Close Keep Documentation Close to Code The second of our Smooth Development Maxims focuses on the accuracy, timeliness and relevance of documentation. In the days of waterfall-style software development, we used to write requirements docs, high level design docs and then detailed design docs. Assuming all these were actually completed, then people would start writing code. Guess how relevant the documents were after a few months? Agile processes do not automatically solve the documentation problem. It takes discipline from all team members and leaders to keep the documentation accurate as designs and interfaces iterate. Noting the expression "out of sight, out of mind," the best place to keep technical documentation is in the same repository as the code (or one nearby.) Here are some success attributes that indicate a good documentation process: 1.) A README exists in each repo with accurate crosslinks to other docs - Is this a true "start here" with an accurate overview? Do the crosslinks to other docs work? 2.) Include comprehensive and accurate setup instructions - do they work? Can someone new to the project follow the (markdown) content and get the code built? 3.) Include links to styles and standards guides - since these generally apply to multiple projects, update centrally. Make sure links work. More to come on styles and standards in a future post. 4.) (Short) docs for component-specific topics such as context diagrams (i.e., C4 syntax), theory-of-operation summaries, or specialized integration notes are present and getting updated 5.) (Relevant) specifications included "in repo" - review and update as needed 6.) One or more auto-build scripts are running to build schema docs, interface specs and supporting materials for user guides - steady state one should never build docs for distribution manually Larger docs for the enterprise such as runbooks (devops), roadmaps and agile artifacts (prod mgmt), (external) integration guides (dev prod mktg) should generally be assembled from smaller pieces. Build managers and scrum leaders need to ensure the checkpoint processes at each milestone include review of the documentation elements relevant to the changes. Attention to detail matters. If your documentation is not working for you, start a process to add those small elements mentioned here in the next cycle. Once everyone gets comfortable with the incremental changes, you can retrofit the larger build and integration elements over a few cycles. With complex systems, both internal and external users benefit from accurate documentation. Boring though it may be, getting these small bits right is the best way to ensure everyone has a big picture that is visible and accurate. #smoothdevelopment #embracingcomplexity #flowlanes #3leaps

Use Plain Text for Documentation In the 3 LEAPS Flow Lanes development system ( 3lps.co/04d ) the statement, "Use Plain Text for Documentation" is our foundational maxim for development. Everyone says documentation is important but almost no one does a good job of maintaining it. Complex systems have different documentation types and audiences, ranging from interface specs and schemas to user-facing manuals. How you render and present such information varies. How you build and archive these types should be mostly the same. Here are the key attributes we have for a plain text documentation approach: 1.) Text-based file formats - don't use file types that you cannot view in a text editor 2.) Human-readable content - while SVGs are text-based, no one can "see" a diagram like in the Matrix 3.) Changes viewable using only simple "diff" tools - readers must be able to understand what changed by comparing the source files in raw form 4.) Markdown-based structure for text - pick a standard flavor (DM @3leapsdave ) if you need suggestions) and use it literally for everything (specialized extensions allow use of TeX and LaTex for rendering equations, as example) 5.) Auto-generated diagrams wherever possible - we recommend @MermaidChart for all but the largest "big picture" diagrams where manual layout matters 6.) Source-control stores actual source - PDF is not a source form unless it is the authoritative reference from a third party where no human-readable alternative exists 7.) Limits use of SVGs and avoids binary images as source - apply #5 and #6 except where an image is "the" source for a crucial part of a document 8.) Packaged content auto-built using scripts or CI/CD - use Pandoc, MkDocs or something similar to blend content and transform Markdown into the final published form such as HTML or PDF Applying this first maxim is a good way to lay a foundation for usable, relevant documentation. Just as we do not build code by hand in a real system, one should not be building or transforming documentation manually either. We'll explore some other documentation-related maxims in future posts. You cannot scale smoothly without good documentation. Commit to a process built on plain text and human readable content as an important step towards better documents and a better system! #smoothdevelopment #embracingcomplexity #flowlanes #3leaps