https://yanevskiv.com/ 2026-08-23T00:26:27+00:00 https://yanevskiv.com/ https://yanevskiv.com/lib/tpl/yanevskiv/images/favicon.ico text/html 2026-08-22T15:26:21+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/ab-testing?rev=1787412381&do=diff A/B testing A/B testing is comparing two variants of a feature by exposing each to different subsets of users simultaneously and measuring the effect on a metric. Variant A is the control (current behaviour); variant B is the treatment being evaluated. text/html 2026-08-22T15:26:16+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/agile?rev=1787412376&do=diff Agile Agile is a family of software development approaches emphasising iterative delivery, frequent customer collaboration, and adapting to changing requirements. Examples include Extreme programming, Scrum, and Kanban. Software projects fail when requirements are locked in upfront but users discover what they actually need only after seeing working software. Traditional waterfall divides projects into sequential phases (requirements, design, implementation, testing, deployment), which cannot … text/html 2026-08-22T15:25:52+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/artifact?rev=1787412352&do=diff Artifact Artifact is a file or package produced by a build process: a compiled binary, Docker image, firmware file, or compiled PDF. Source code is the input; artifacts are the outputs intended for use or distribution. Rebuilding from source before each deployment is slow and creates risk: you cannot guarantee the same bits were tested and deployed. Artifact registries store and serve versioned artifacts (Docker Hub, npm, PyPI, Artifactory), enabling rollback without rebuilding. text/html 2026-08-22T15:26:04+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/blue-green-deployment?rev=1787412364&do=diff Blue-green deployment Blue-green deployment maintains two identical production environments simultaneously. At any moment, one (blue) is live and the other (green) is idle. To deploy, run the new version on green, run smoke tests, then switch the load balancer to point to green. text/html 2026-08-22T15:22:28+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/brooks-law?rev=1787412148&do=diff Brooks's law Brooks's law states that adding people to a late software project makes it later. New team members are not immediately productive: they need time to understand the codebase, domain, and conventions, consuming the time of experienced members who train them. text/html 2026-08-22T15:26:09+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/canary-release?rev=1787412369&do=diff Canary release Canary release is rolling out a new version to a small subset of users before promoting it to everyone. Start at 5% traffic, monitor metrics for hours, then gradually increase to 50%, 100%. Staging deployments pass all tests but fail in production because real traffic has different volume, data patterns, and user behaviour. Deploying to 100% of users exposes those bugs to everyone simultaneously. text/html 2026-08-22T15:25:35+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/ci-cd?rev=1787412335&do=diff CI/CD CI/CD is the practice of automatically building, testing, and deploying software on every change. Continuous integration runs the test suite on each commit; continuous delivery extends this by automatically packaging and deploying the artifact to production. text/html 2026-08-22T15:26:48+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/devops?rev=1787412408&do=diff DevOps DevOps is a set of practices making developers responsible for the full lifecycle of their software: building, testing, deploying, monitoring, and operating it in production. This breaks the traditional wall between development and operations teams. text/html 2026-08-22T15:22:28+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/eat-your-own-dog-food?rev=1787412148&do=diff Eating your own dog food Dogfooding is using the product you are developing internally before releasing to external users. Developers discover bugs and interface friction immediately when they use it daily, rather than waiting for user reports. Internal users are not representative: developers are more tolerant of rough edges, more willing to work around bugs, and familiar with internals. The feedback loop is incomplete compared to external users. However, rough edges and crashes become imposs… text/html 2026-08-22T15:26:37+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/feature-branch?rev=1787412397&do=diff Feature branch Feature branch is a git branch created for developing a single feature separately from main. Work proceeds in isolation, code is reviewed in a pull request, then merged back once approved. Incomplete features on main force other developers to deal with broken or hidden code. Longer branches (weeks old) diverge further from main, accumulating conflicts and making review harder. Every day a branch exists increases integration risk. text/html 2026-08-22T15:25:40+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/feature-flag?rev=1787412340&do=diff Feature flag Feature flag is a conditional in code that enables or disables a feature at runtime without deploying new code. The feature is deployed but dark; it is activated by changing a configuration value. Releasing new features creates risk: if something breaks, rolling back the entire deployment is expensive and slow. Incomplete features merged to the main branch also cause delays while waiting for independent components to be ready before shipping. text/html 2026-08-22T15:22:28+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/goodharts-law?rev=1787412148&do=diff Goodhart's law Goodhart's law states that when a measure becomes a target, it ceases to be a good measure. Once a metric is used to evaluate performance, people optimise for the metric rather than for the underlying goal it was supposed to track, and the metric diverges from the thing it was measuring. text/html 2026-08-22T15:27:11+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/greenspuns-tenth-rule?rev=1787412431&do=diff Greenspun's tenth rule Greenspun's tenth rule (despite there being no rules one through nine) is an aphorism by Philip Greenspun: “Any sufficiently complicated C or Fortran program contains an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp. text/html 2026-08-22T15:26:13+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/hotfix?rev=1787412373&do=diff Hotfix Hotfix is an urgent patch applied directly to production without going through the normal development cycle. It bypasses QA and review because the system is broken and every minute matters. Critical bugs in production (security exploits, data loss, crashes) cannot wait for the next scheduled release. Waiting hours or days for a normal release cycle means more users affected and more revenue lost. text/html 2026-08-22T15:22:28+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/incremental-build-model?rev=1787412148&do=diff Incremental build model The incremental build model is a software development lifecycle model in which the system is built and delivered in a series of increments, each adding functional capability to the previous one. The first increment delivers a working core; subsequent increments add features until the full system is complete. text/html 2026-08-22T15:25:56+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/kanban?rev=1787412356&do=diff Kanban Kanban is a workflow management method using a board with columns representing work stages and cards representing individual items. Work flows continuously through columns with work-in-progress limits at each stage. Teams struggle with unpredictable incoming work, context switching overhead, and hidden bottlenecks when work piles up in certain stages. Sprint-based methods like text/html 2026-08-22T15:27:00+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/liskov-substitution-principle?rev=1787412420&do=diff Liskov substitution principle Liskov substitution principle states that if S is a subtype of T, you can substitute S for T without breaking the program. It is the L in SOLID. This is about behavioural contract, not just syntax: a subclass must honour the base class contract, not weaken postconditions or strengthen preconditions. text/html 2026-08-22T15:22:28+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/parkinsons-law?rev=1787412148&do=diff Parkinson's law Parkinson's law states that work expands to fill the time available. Three weeks to build a feature takes three weeks; three days takes three days. The result is often functionally equivalent because extra time was spent on marginal improvements, over-engineering, and second-guessing decisions. text/html 2026-08-22T15:26:33+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/production?rev=1787412393&do=diff Production Production is the live environment serving real users, distinguished from development (a developer's local machine), staging (a production-like test environment), and CI (automated build). Production has real user data, unpredictable load patterns, and consequences when something breaks. text/html 2026-08-22T15:26:00+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/prototype?rev=1787412360&do=diff Prototype Prototype is a preliminary version of a system built to explore design, validate an assumption, or demonstrate feasibility. It is intentionally incomplete and not intended for production. The goal is reducing uncertainty before committing to a full implementation. text/html 2026-08-22T15:26:25+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/regression?rev=1787412385&do=diff Regression Regression is a bug introduced by a change that fixed something else or violated a hidden assumption. The feature previously worked, so something broke it. Without protection, the same bug can be reintroduced months later by someone unaware of the original fix. The cost accumulates: each re-introduction requires re-diagnosis and re-fixing. text/html 2026-08-22T15:22:28+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/smart-and-vapid?rev=1787412148&do=diff Smart-and-gets-things-done Smart-and-gets-things-done is a hiring heuristic: the only two things that matter are reasoning ability (understanding complex systems, debugging novel problems, learning domains) and execution (actually shipping work). All other criteria are proxies for these or irrelevant. text/html 2026-08-22T15:22:28+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/solid?rev=1787412148&do=diff SOLID SOLID is five object-oriented design principles: Single Responsibility, Open/Closed, Liskov substitution principle, Interface Segregation, Dependency Inversion. They make code more understandable, maintainable, and extensible. A class with multiple reasons to change is harder to modify when each reason occurs independently. Adding new behaviour requires editing existing code, creating risk of regression. Interfaces and abstractions allow new behaviour without modifying old code. Clients … text/html 2026-08-22T15:22:28+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/spike-solution?rev=1787412148&do=diff Spike solution Spike solution is a short, throwaway experiment written to explore a technical question or reduce uncertainty. A spike answers a specific question: can we use this API fast enough, how hard is porting to Rust, which JSON library handles these edge cases. text/html 2026-08-22T15:26:29+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/test-automation?rev=1787412389&do=diff Test automation Test automation is running tests programmatically rather than manually. A program verifies that features work instead of a person clicking through an application. Tests run on every change and give pass/fail results within minutes. text/html 2026-08-22T15:25:44+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/test-driven-development?rev=1787412344&do=diff Test-driven development Test-driven development is a practice where you write the test before you write the code. The cycle is red-green-refactor: write a failing test, write minimum code to make it pass, then clean up the code while keeping tests green. text/html 2026-08-22T15:25:48+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/unit-test?rev=1787412348&do=diff Unit test Unit test is a test that verifies a single function or method in isolation from its dependencies. Dependencies are replaced with fakes (stubs, mocks) that return controlled values so the test is fast and deterministic. Integration tests and end-to-end tests verify the whole system but run slowly and are brittle. Unit tests alone cannot catch bugs that only appear when components interact, for example when one function passes data in a format the downstream component does not expect. text/html 2026-08-22T15:22:28+00:00 Anonymous (anonymous@undisclosed.example.com) https://yanevskiv.com/swe/xp-programming?rev=1787412148&do=diff Extreme programming Extreme programming is a software development methodology that takes proven practices and pushes them to their logical extreme. If testing is good, test everything via Test-driven development. If code review is good, review code continuously via pair programming.