Software Engineering ==================== Development ----------- * https://conventionalcomments.org/ * https://www.conventionalcommits.org/ Infrastructure -------------- * `Artificial Intelligence Infrastructure-as-Code Generator `_ * `7 Core Elements of an Internal Developer Platform `_ * `How to make an Impact as a Platform Product Manager `_ * `Automating safe, hands-off deployments `_ * `Awesome Load Management `_ * `The Service Mesh Landscape `_ DevOps ------ * `DevOps uses a capability model, not a maturity model `_ Metrics / Observability ----------------------- * `You Only Get 3 Metrics - Which Ones Would You Pick? `_ * `OpenTelemetry Tracing in 200 lines of code | Jeremy Morrell `_ Misc ---- * `Read Every Single Error `_ * `Explaining `_ * `Amir’s 10 Laws of Tech `_ * `How To Get Buy-in for DevEx Initiatives: Strategies From GitHub, Notion, and More `_ * `My Approach to Building Large Technical Projects `_ * `Page Weight Matters `_ * `All the Hard Stuff Nobody Talks About when Building Products with LLMs `_ * `Introducing "Implement DNS in a Weekend" `_ * `A beginner-friendly introduction to Kubernetes `_ * `Lullaby Language `_ * `Talk Like A Systems Engineer: Yaks All The Way Down `_ * `Ditherpunk — The article I wish I had about monochrome image dithering `_ * `Whose Cert Is It Anyway? `_ * `Netreap: A Practical Guide to Running Cilium in Nomad `_ * `Building Customer-Facing Real-Time Dashboards with Postgres `_ * `llm, ttok and strip-tags—CLI tools for working with ChatGPT and other LLMs `_ * `Task `_ * `DevEx: What Actually Drives Productivity `_ * `Language Tooling Antipatterns `_ * `Technology Decision Making (and Boring Technology) `_ * `What is Technical Debt? `_ * `Refactoring CI/CD for a Moderately Large C++ Code Base `_ * `Levelling up Pull Requests `_ * `Agility and Architecture: Balancing Minimum Viable Product and Minimum Viable Architecture `_ * `User Story Template: What It Is and Why It Works So Well `_ * `Avoiding the Rewrite Trap `_ * `Should You Use Upper Bound Version Constraints? - `_ * "Capping dependencies has long term negative effects, especially for libraries, and should never be taken lightly. A library is not installed in isolation; it has to live with other libraries in a shared environment. Only add a cap if a dependency is known to be incompatible or there is a high (>75%) chance of it being incompatible in its next release. Do not cap by default - capping dependencies makes your software incompatible with other libraries that also have strict lower limits on dependencies, and limits future fixes. Anyone can fix a missing cap, but users cannot fix an over restrictive cap causing solver errors. It also encourages hiding issues until they become harder to fix, it does not scale to larger systems, it limits your ability to access security and bugfix updates" * `Tech debt metaphor maximalism - apenwarr `_ * `DevOps Notebooks Built with Markdown `_ * `googleapis/release-please: generate release PRs based on the conventionalcommits.org spec `_