DEV Community: Mykhailo

Certified Backstage Associate: I Passed by Five Points

Mykhailo — Wed, 14 Oct 2026 21:57:53 +0000

I wrote the longer version, with every config detail I studied and the full prep timeline, on my blog.

I scored 80 on the Certified Backstage Associate exam. Passing is 75.

No single domain sank me. I gave two or three soft answers in each of the four domains, and they stacked up until I was a couple of bad guesses away from a retake. CBA takes a point here and a point there, wherever you were pretty sure instead of certain.

Why CNCF exam habits don't help

CBA was one of my last exams on the Golden Kubestronaut track. Other CNCF certs test you on operating something. CBA is 60 multiple choice questions in 90 minutes about how a framework works. No kubectl, no cluster to fix.

The wrong answers are written to catch people who learned Backstage by osmosis. I felt confident going in.

What made it click: Backstage is a TypeScript framework you build on and own. Once I stopped thinking of it as a wiki with plugins and treated it as a platform for building platforms, the plugin and architecture questions started to make sense.

Domain	Weight
Customizing Backstage	32%
Backstage Development Workflow	24%
Backstage Infrastructure	22%
Backstage Catalog	22%

Customizing Backstage (32%)

Mostly: what's a frontend plugin and what's a backend plugin.

Frontend plugins are React components. They run in the browser, register routes, show up in the sidebar, and talk to backend plugins over HTTP. Backend plugins are server-side, independent services with their own database connections, exposing REST or GraphQL APIs. Expect questions on where code runs, plugin registration and what App.tsx does (it wires plugins together).

Smaller items: Material UI is the UI library (not Tailwind, not shadcn), and extension points let modules hook into existing plugins without forking them.

Development Workflow (24%)

Three commands matter:

npx @backstage/create-app@latest
yarn dev
yarn build && yarn build-image

The first scaffolds a monorepo with the frontend app and backend together. yarn dev runs both in watch mode. yarn tsc is a separate step from building the Docker image, and the exam asks where each step fits, including where yarn install sits relative to yarn tsc.

Infrastructure (22%)

PostgreSQL is for production, SQLite for development only. The exam will offer answers that present SQLite as production-ready.

The backend uses Knex, and each plugin gets its own logical database. Cache backends (memory, Redis, Memcached) are in scope too.

The rest is mostly app-config.yaml, which is layered. app-config.yaml is the base, app-config.local.yaml and app-config.production.yaml sit on top, and later files override earlier ones. Secrets come from environment variables via ${...} substitution. Know the integrations, backend.database and catalog.locations blocks.

Catalog (22%)

Small weight, subtle distinctions. The entity descriptor format is tested directly:

apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: my-service
  annotations:
    backstage.io/techdocs-ref: dir:.
spec:
  type: service
  lifecycle: production
  owner: team-a
  system: my-system

Know every kind: Component, API, System, Domain, Resource, Group, User, Location. Confusing Component with API is the most common way to drop catalog points. Well-known annotations carry meaning and point at external systems (backstage.io/techdocs-ref, github.com/project-slug), while labels are plain key-value pairs for filtering. Entities arrive through a static catalog.locations entry or through discovery providers.

I underestimated ingestion troubleshooting most. You register an entity and it doesn't show up: invalid YAML, wrong apiVersion, missing required fields, a processing error in catalog-backend. All in scope, and "I think I know" won't get you through it.

How I prepared, and what I'd change

About 6 hours on the official docs first, starting with the architecture overview and then the catalog and plugin pages linked above. Then LFS142 from the Linux Foundation, which is free and covers the material at the right depth. I did it in one sitting, maybe 3 hours. I think it beats most third-party courses because people who work on Backstage wrote it.

My Kubernetes knowledge didn't carry over; I caught myself applying k8s mental models to catalog questions.

The bigger mistake was quieter. I read each domain until it felt familiar, then moved on. On exam day "I've seen this" wasn't enough, and that gap is where my soft answers came from. Next time I'd drill each domain until I could answer from memory.

That's why I built a free CBA practice test. It's catalog-heavy on purpose and shows you the difference between "familiar" and "certain" before the exam does. The other CNCF practice tests use the same approach, and the rest of my resources live in awesome-kubestronaut.

If I sat it again, I'd bank the easy points fast (entity kinds and spec fields, the three commands, frontend vs backend scope) and spend the remaining prep on ingestion troubleshooting and annotations vs labels.

I still can't settle the dev workflow question. Backstage ships so often that I'm not certain what I studied matches what you'll get. If something in that domain surprised you recently, I'd like to hear about it.

Originally published on yetmike.com.

Three cargo errors that don't happen any more

Mykhailo — Tue, 13 Oct 2026 23:29:07 +0000

Three of the cargo errors I sat down to document don't happen any more. I only found out because the build refused to publish the pages.

The setup: I'm generating one page per diagnostic for a Rust learning site, and every page has to be confirmed by a real toolchain before it ships. For the cargo corpus that means an entry is a whole project, not a snippet. A build script writes the file map into a temp dir, runs actual cargo in it, and compares what came back against what the page claims. If the two disagree, the entry doesn't exist.

31 cargo entries survived. Here are the three that didn't, on cargo 1.96.0.

A manifest with no version

[package]
name = "probe"
edition = "2021"

I wrote this expecting a parse failure naming the missing package.version. What I got:

   Compiling probe v0.0.0 (/tmp/probe)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 3.25s

It builds. version is optional now and defaults to 0.0.0, which cargo prints right there in the compile line if you're reading it. The error still fires for a missing name, so the neighbouring entry in my corpus is fine:

error: failed to parse manifest at `/home/you/project/Cargo.toml`

Caused by:
  missing field `package.name`

Name and version used to fail the same way. They don't now, and I'd have written that they do.

A misspelled key in [profile.release]

[profile.release]
opt-levle = 3

warning: unused manifest key: profile.release.opt-levle
   Compiling probe v0.1.0 (/tmp/probe)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.09s

A warning, and a build that succeeds with the default opt-level. This is the one I'm least happy about losing, because the failure mode is worse than an error would be. Your release build is not optimised the way you asked and the only evidence is one line that scrolls past. An error would at least stop you.

The typo case that does still error is a required key, and the message is worth looking at:

[package]
naem = "probe"
version = "0.1.0"

error: failed to parse manifest at `/home/you/project/Cargo.toml`

Caused by:
  missing field `package.name`

Cargo tells you what's absent, not what you misspelled. naem is sitting right there on line 2 and never gets mentioned.

A virtual manifest with one member

[workspace]
resolver = "2"
members = ["app"]

cargo run in that root, I was told, refuses because the root defines no package. It doesn't:

   Compiling app v0.1.0 (/tmp/probe/app)
    Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.09s
     Running `target/debug/app`
hello from app

One member with a binary means one answer, so cargo picks it. Add a second member and the old error comes back, which is the version I kept:

error: `cargo run` could not determine which binary to run. Use the `--bin` option to specify a binary, or the `default-run` manifest key.
available binaries: app, tool

So the entry isn't wrong so much as it needed a workspace big enough to be ambiguous. That's a different page from the one I'd planned to write.

Why I'd have got all three wrong

I didn't reason my way to these. I lifted them from what I'd read, and what I'd read was written when they were true. I haven't gone back to count how many of those write-ups are still near the top of a search for the error text, so I'm not going to give you a number, but the phrasing is still out there in blog posts and answers and nothing about a stale answer looks stale.

Documentation of an error is a claim about behaviour at a point in time, and cargo keeps relaxing things. Each relaxation turns a correct old page into a confident wrong one. Nobody edits the old page, because nothing tells them to.

The gate is the whole value here. It's about 200 lines that shell out to cargo and diff two strings, and its only real job is telling me to delete something. Three pages I'd have sworn were correct, deleted before anyone read them, by a script with no opinions.

What I'm less sure about: I now have three documented non-errors and nowhere to put them. The page that says "this used to fail and doesn't" is probably more useful than the page that says "this fails", because it's the one that contradicts what you already read. But it isn't a diagnostic, and the site is organised entirely around diagnostics. I haven't worked out where it goes: https://codecrab.app/?r=devto-cargo-stale

CAPA Exam Guide: Argo CD Is Only a Third of It. I Scored 93

Mykhailo — Tue, 13 Oct 2026 23:20:24 +0000

I wrote the longer version, with more on each Argo project and my prep timeline, on my blog.

Daily Argo CD use covers about a third of the CAPA exam. You blast through the CD questions, and then Argo Events shows up.

I passed the Certified Argo Project Associate on the first attempt with 93 out of 100 (passing is 75). I don't run Rollouts or Events at work, so that score came from noticing early that I was preparing for the wrong exam.

Format and weights

60 questions, 90 minutes, all multiple choice. No terminal. If you've done CKA or CKAD, muscle memory won't help here.

Argo is four projects, each with its own object model, and you can't reason from one to another. The weights when I took it:

Domain	Weight
Argo Workflows	36%
Argo CD	34%
Argo Rollouts	18%
Argo Events	12%

Workflows is the biggest domain and the one most people underprepare. Check the official CNCF curriculum before you plan, in case the weights have moved.

Workflows (36%)

Argo Workflows runs DAGs in pods. Know dag templates versus steps templates cold. In a DAG template you declare dependencies explicitly: task B waits on task A because you wrote dependencies: [build], not because it's listed second. Steps run top to bottom with no dependency graph. The exam gives you a manifest and asks which style it is.

Parameters pass values between tasks, artifacts pass files. Run one real workflow and most of this domain comes for free.

Argo CD (34%)

The one people think they already know.

prune: true deletes cluster resources that were removed from Git. selfHeal: true reverts manual changes made directly in the cluster. The exam asks about each separately, and if you've only ever turned on automated sync with both set to true, you've never had to think about which does what.

Sync status and health status are separate axes. Synced vs OutOfSync says whether the cluster matches Git. Healthy, Progressing, Degraded or Missing says whether the thing works. An app can be Synced and Degraded at once, and that combination gets tested.

Also recognize sync waves and hooks (PreSync, Sync, PostSync; the lowest wave applies first), ApplicationSet (one template plus generators makes many Applications), app-of-apps, and AppProject as the RBAC boundary. Know what each is for. You don't need to write them from memory.

Rollouts (18%)

Argo Rollouts replaces a Deployment when you need canary or blue/green.

Canary splits live traffic by percentage. Both versions serve users at the same time, and an AnalysisRun gates whether traffic keeps increasing.
Blue/green stands up a full second environment and swaps all traffic at once via activeService and previewService. Rollback is switching the Service back, because the old version is still running.

The wrong answer usually blurs "both versions live" with "instant full cutover".

Events (12%)

Only 12%, but it's where I burned the most prep time, and most of us have never touched anything like it at work.

In Argo Events, the EventSource listens to the outside world: a webhook, a file landing in S3, a Kafka message, a schedule. The Sensor subscribes to it and decides what to do. The Trigger is the action, like submitting a Workflow, creating a resource or calling an endpoint. Underneath, the EventBus (backed by NATS) carries events between EventSource and Sensor.

EventSource listens, Sensor decides, Trigger acts. I said that chain out loud probably 20 times before it stuck, because under pressure the instinct is to assume the listener is also the decider.

Even with the model down, Sensor dependencies and trigger conditions took me longest per question.

How I prepared

Two weeks: one of study, one of practice tests.

For each project, before opening docs, I wrote down the problem it solves and its three main objects. That exposes the gaps that reading lets you nod past.

I also deployed all four projects on one cluster. Not production grade, just enough to watch a workflow run and a rollout progress.

What didn't work: going deep on Argo CD because I use it daily and skimming Events. About five days in I caught it and moved my time over.

The easy points are the OpenGitOps principles, the Workflows template types (container, script, dag, steps), and knowing which Argo project solves which problem.

Beyond the official docs, the Linux Foundation has LFS256, DevOps and Workflow Management with Argo, and everything I used for all 15 CNCF certs is in awesome-kubestronaut.

Practice test

I built a free CAPA practice test around the traps that cost the most points (EventSource/Sensor, selfHeal vs prune, canary vs blue/green, DAG vs steps). Take it a week out and you'll see which domain needs your last few evenings. Other CNCF exams are at yetmike.com/tests.

Two weeks was enough. I'm not sure I'd pass the Events section again without a refresher, though. Sensor conditions only stick if you run them, and I don't run Events outside a practice cluster.

Originally published on yetmike.com.

Every rustc error has two spans, and they mean different things

Mykhailo — Sat, 03 Oct 2026 21:13:39 +0000

The line rustc points at is usually not the line you edit. The message is doing more work than most people read.

Here's the smallest example, E0384:

fn main() {
    let x = 5;
    x = 6;
    println!("{x}");
}

error[E0384]: cannot assign twice to immutable variable `x`
 --> src/main.rs:3:5
  |
2 |     let x = 5;
  |         - first assignment to `x`
3 |     x = 6;
  |     ^^^^^ cannot assign twice to immutable variable
  |
help: consider making this binding mutable
  |
2 |     let mut x = 5;
  |         +++

Two spans. Line 3 carries the carets, because that's where the rule broke. Line 2 carries a single dash, because that's where you made the decision that broke it. The header names the failure, the dash names the cause, and the help: block edits the cause, not the failure. Read in that order the error stops being a complaint and turns into a two line story: you decided here, it went wrong there.

Most people stop at the header, add mut, and keep going. That works for E0384 and it teaches you nothing that survives to the next error.

The same shape, one step harder

E0382, borrow of moved value:

fn main() {
    let name = String::from("crab");
    let other = name;
    println!("{name}");
}

error[E0382]: borrow of moved value: `name`
 --> src/main.rs:4:16
  |
2 |     let name = String::from("crab");
  |         ---- move occurs because `name` has type `String`, which does not implement the `Copy` trait
3 |     let other = name;
  |                 ---- value moved here
4 |     println!("{name}");
  |                ^^^^ value borrowed here after move
  |
help: consider cloning the value if the performance cost is acceptable
  |
3 |     let other = name.clone();
  |                     ++++++++

Carets at line 4. But nothing on line 4 is wrong in isolation, printing a String is fine. The dashes carry the actual content: line 2 says why the type behaves this way, line 3 says where the ownership left. The fix lands on line 3, one line above the report and two below the explanation.

That middle dash on line 2 is the whole ownership model in one sentence, and it's the part people skim because it's long and doesn't have carets under it.

And once more, with three

E0502:

error[E0502]: cannot borrow `numbers` as mutable because it is also borrowed as immutable
 --> src/main.rs:4:5
  |
3 |     let first = &numbers[0];
  |                  ------- immutable borrow occurs here
4 |     numbers.push(4);
  |     ^^^^^^^^^^^^^^^ mutable borrow occurs here
5 |     println!("{first}");
  |                ----- immutable borrow later used here

Here the second span split in two, one before the carets and one after. That's the borrow checker showing you a span of time, not a span of text: the borrow starts at line 3, is still alive at line 5, and line 4 sits inside it. Delete the println! and the error goes away, which is a strange thing to be true about code three lines up from the complaint.

So the rule generalises a little past "two spans". Carets are where the compiler stopped. Dashes are the evidence, and there can be one or several. The fix goes wherever the evidence points.

Why I think this matters more than the error codes

I've been writing one page per rustc error code and I'm about fifty in, out of roughly six hundred codes that exist. Somewhere around the twentieth it stopped feeling like fifty separate things to memorise. The codes differ, the span layout doesn't, and the layout is the part you can actually carry into an error you've never seen. A beginner who reads dashes before carets can handle E0499 the first time they meet it. A beginner who's memorised twelve codes still can't.

My unresolved doubt, and it's a real one: rustc --explain E0384 is already built into the toolchain, offline, with no site to visit. It explains the code in general. It does not explain your diagnostic, with your line numbers and your dashes in it, which is the thing I think people need. I'm not certain that gap is big enough to justify a page per code. I've got about fifty of them here if you want to tell me either way: https://codecrab.app/?r=devto-two-spans

What's the error you kept fixing at the wrong line before you noticed the dashes?

CGOA exam prep: why 50 clusters of Argo CD got me an 82

Mykhailo — Sat, 03 Oct 2026 20:47:34 +0000

I wrote the longer version, with the full domain breakdown and my prep timeline, on my blog.

I run Argo CD in production on 50 Kubernetes clusters across several public clouds. Before studying for the Certified GitOps Associate, I took a practice test cold and scored 82. Passing is 75, so fine on paper. The questions I missed were the ones I didn't expect to miss.

The CGOA does not grade how well you run Argo CD. It grades whether you can apply the OpenGitOps specification word for word.

Format

60 multiple-choice questions, 90 minutes, 75 to pass. No terminal, no kubectl, no YAML. Argo CD and Flux appear as examples, never as the thing being graded.

Domain	Weight
GitOps Principles	30%
GitOps Terminology	20%
GitOps Patterns	20%
Related Practices	16%
Tooling	14%

Tooling is roughly one question in seven. In my experience it gets most of people's prep time anyway, because sync options and CRDs are what we touch every day.

30% of the exam is four sentences

About 18 questions come from the four OpenGitOps principles:

Declarative. The system is described declaratively.
Versioned and Immutable. Desired state is stored in a way that enforces immutability and versioning, and retains a complete version history.
Pulled Automatically. Software agents automatically pull the desired state declarations from the source.
Continuously Reconciled. Software agents continuously observe actual system state and attempt to apply the desired state.

Memorize the exact wording. The options are written so a paraphrase lands you on the wrong one. "Pulled Automatically" is the usual slip: people read it as "applied automatically", but the agent pulls and the CI pipeline does not push.

Terminology cost me the most

Terminology is 20%, and the spec vocabulary sits in the question stem too, so a fuzzy term means you misread the question before you see the options.

Learn desired state, actual state, state drift, state store, reconciliation, feedback loop, rollback, and "continuous" (recurring, not instantaneous). The pair people mix up most: Git is the state store, the cluster holds the actual state.

My 82 came from here. I'd fixed plenty of state drift. I was sloppy about the exact definition.

Pull vs push, and related practices

In the pull model an agent inside the cluster watches Git and applies changes, so CI holds no cluster credentials. In the push model a runner calls kubectl apply or Helm. That deploys fine, and it isn't GitOps.

The wrong answer on a patterns question is usually a pipeline that deploys everything correctly. A couple caught me because I was thinking about implementation. Also know that a reconciler can run in-cluster or externally as long as it pulls, that the merge is the promotion, and that reverting the commit is the rollback.

Related Practices (16%) is mostly review with a DevOps background: Infrastructure as Code, Configuration as Code, DevSecOps, CI vs CD. In GitOps, CI builds and tests, the reconciler deploys. A few CI/CD split questions made me stop, and I'm not sure whether that section has shifted since I sat it. If you're preparing in late 2026, check the current curriculum first.

How I'd prepare

I spent about 8 hours over a weekend. Aimed right from the start, I think 5 or less.

Read the OpenGitOps principles and the GitOps glossary. About 20 minutes. Say the principles out loud without looking.
Take the free LFS169 Introduction to GitOps course. Around 4 hours, and it follows the exam domains in order.
Do practice questions until the wrong answers look obviously wrong. For this step I built a free CGOA practice test from the concepts I had to reason through after that 82, so you can see which domain is weak before exam day.

I wasted about 2 hours on Flux and Argo CD docs. Nobody cares about argocd app sync flags here. More study links are in awesome-kubestronaut.

The mental model

GitOps clicked when I saw it as a control loop rather than a deployment tool. Same pattern as a Kubernetes controller: watch desired state, compare to actual, reconcile. Desired state lives in Git instead of etcd.

The four principles then map onto the loop: how you express desired state, how you store it, how the agent gets it, what the agent does with it.

98 out of 100, first attempt. The concepts aren't hard; they need precision, which is probably why people with years of Argo CD keep landing around 80 first try.

I still don't know whether those Related Practices questions were bad luck or the curriculum drifting. If you sit it after me, tell me which.

Originally published on yetmike.com

The 22 Rust errors every beginner hits, in the order they hit them

Mykhailo — Sun, 16 Aug 2026 20:50:35 +0000

Rust's compiler is the best teacher in the language and almost nobody reads it properly. Below are the 22 errors you will actually hit, roughly in the order you'll hit them, with what each one is really telling you.

Every diagnostic here is real. It was captured from a real rustc 1.96.0 (ac68faa20 2026-05-25) compiling a real broken program. The explanations were drafted with an LLM and edited by me.

Two things to know before the list.

Most Rust errors underline two places. One is where the rule was broken. The other is where the decision that broke it was made. The error is reported at the first; the fix is almost always at the second.

The help: block is often a literal diff. When you see +++ under a span, rustc isn't describing the fix. It's writing it.

1. E0061: The function takes two arguments and you passed one.

error[E0061]: this function takes 2 arguments but 1 argument was supplied
 --> src/main.rs:6:20
  |
6 |     println!("{}", add(1));
  |                    ^^^--- argument #2 of type `i32` is missing
  |
note: function defined here
 --> src/main.rs:1:4
  |
1 | fn add(a: i32, b: i32) -> i32 {
  |    ^^^         ------
help: provide the argument
  |
6 |     println!("{}", add(1, /* i32 */));
  |                         +++++++++++

The fix. Pass both: add(1, 2).

Rust has no default parameters and no overloading, so arity is exact. That sounds restrictive until you notice it means a function signature is a complete description of how to call it. There is never a hidden second way.

2. E0277: `Vec` has no single obvious way to print itself, so `{}` will not take it.

error[E0277]: `Vec<{integer}>` doesn't implement `std::fmt::Display`
 --> src/main.rs:3:20
  |
3 |     println!("{}", numbers);
  |               --   ^^^^^^^ `Vec<{integer}>` cannot be formatted with the default formatter
  |               |
  |               required by this formatting parameter
  |
  = help: the trait `std::fmt::Display` is not implemented for `Vec<{integer}>`
  = note: in format strings you may be able to use `{:?}` (or {:#?} for pretty-print) instead

The fix. Use the debug formatter: println!("{:?}", numbers);

This is the first trait error most people meet, and the message names the exact missing capability: Vec<i32> doesn't implement std::fmt::Display. Read trait errors as a sentence (this type cannot do that thing) rather than as a wall.

3. E0282: Rust cannot work out what type this collection holds, because nothing was ever put in it.

error[E0282]: type annotations needed for `Vec<_>`
 --> src/main.rs:2:9
  |
2 |     let items = Vec::new();
  |         ^^^^^   ---------- type must be known at this point
  |
help: consider giving `items` an explicit type, where the type for type parameter `T` is specified
  |
2 |     let items: Vec<T> = Vec::new();
  |              ++++++++

The fix. Say it: let items: Vec<i32> = Vec::new();

Rust infers types from use, not from declaration. Push one integer and the annotation becomes unnecessary, because the inference works forward from evidence, and here you gave it none.

4. E0308: You promised an `i32` and returned nothing.

error[E0308]: mismatched types
 --> src/main.rs:1:14
  |
1 | fn five() -> i32 {
  |    ----      ^^^ expected `i32`, found `()`
  |    |
  |    implicitly returns `()` as its body has no tail or `return` expression
2 |     5;
  |      - help: remove this semicolon to return this value

The fix. Delete the semicolon after 5.

() is Rust's word for "nothing". Whenever you see found (), look for a stray semicolon before you look at anything else. In Rust an expression without a semicolon is the value, and with one it becomes a statement that evaluates to nothing.

5. E0381: The variable was declared but never given a value, and you read it.

error[E0381]: used binding `count` isn't initialized
 --> src/main.rs:3:16
  |
2 |     let count: i32;
  |         ----- binding declared here but left uninitialized
3 |     println!("{count}");
  |                ^^^^^ `count` used here but it isn't initialized
  |
help: consider assigning a value
  |
2 |     let count: i32 = 42;
  |                    ++++

The fix. Give it a value: let count: i32 = 0;

Other languages hand you a zero or a null here. Rust refuses to guess, and that refusal is the point: there is no such thing as an uninitialised read in safe Rust, so a whole category of bug cannot reach runtime.

6. E0384: `let` bindings do not change unless you say `mut`.

error[E0384]: cannot assign twice to immutable variable `x`
 --> src/main.rs:3:5
  |
2 |     let x = 5;
  |         - first assignment to `x`
3 |     x = 6;
  |     ^^^^^ cannot assign twice to immutable variable
  |
help: consider making this binding mutable
  |
2 |     let mut x = 5;
  |         +++

The fix. Write let mut x = 5;

Two spans, not one: the ^^^^^ is where the rule broke, the - marks where the decision was made. The error is reported at the assignment, the thing you change is the declaration. That pattern holds across most Rust errors, and once you see it you cannot unsee it.

7. E0425: You used a name that was never declared in this scope.

error[E0425]: cannot find value `count` in this scope
 --> src/main.rs:2:20
  |
2 |     println!("{}", count);
  |                    ^^^^^ not found in this scope

The fix. Declare it first: let count = 0;

Ninety percent of the time this is a typo, and rustc will often guess the name you meant in a help: line. Read that before you go looking for a real bug, because the compiler has already done the search.

8. E0596: You called a method that needs to modify the value, on a binding that cannot be modified.

error[E0596]: cannot borrow `numbers` as mutable, as it is not declared as mutable
 --> src/main.rs:3:5
  |
3 |     numbers.push(4);
  |     ^^^^^^^ cannot borrow as mutable
  |
help: consider changing this to be mutable
  |
2 |     let mut numbers = vec![1, 2, 3];
  |         +++

The fix. let mut numbers = vec![1, 2, 3];

The interesting part is that push never says "mutable" in your code; you have to know its signature takes &mut self. The compiler is telling you a fact about a function you did not write, which is why the fix is on a different line from the error.

9. E0599: That type has no such method.

error[E0599]: no method named `push` found for type `{integer}` in the current scope
 --> src/main.rs:3:11
  |
3 |     count.push(1);
  |           ^^^^ method not found in `{integer}`

The fix. Use a type that has it, or the right method for this one.

When the type is right but the method is missing, rustc often lists candidates with similar names, and sometimes tells you a trait exists but is not in scope, which is a use statement away, not a redesign.

10. E0601: Every Rust program starts at a function called `main`, and there isn't one.

error[E0601]: `main` function not found in crate `snippet`
 --> src/main.rs:3:2
  |
3 | }
  |  ^ consider adding a `main` function to src/main.rs`

The fix. Rename the function to main.

The compiler is not looking for your code, it is looking for one specific name. Rust has no "top level" that runs. The entry point is a convention with no flexibility, and this is usually the first time a beginner learns the program has a designated front door.

11. E0618: You put call parentheses after something that is not a function.

error[E0618]: expected function, found `{integer}`
 --> src/main.rs:3:18
  |
2 |     let total = 5;
  |         ----- `total` has type `{integer}`
3 |     let result = total();
  |                  ^^^^^--
  |                  |
  |                  call expression requires function

The fix. Drop the parentheses, or call the function you meant.

Usually a shadowed name: a variable and a function with the same identifier, and the variable won. The help: line will tell you what the thing actually is, which is faster than re-reading your own code.

12. E0765: A string was opened with a quote and never closed.

error[E0765]: unterminated double quote string
 --> src/main.rs:3:25
  |
3 |       println!("{greeting}");
  |  _________________________^
4 | | }
  | |_^

The fix. Close the quote: let greeting = "hello";

Notice the error points at where the string started, not where the compiler gave up. That is the general pattern for unclosed things: the reported line is the opening, because the compiler cannot know which of the following lines you meant to close it on.

13. E0004: A `match` has to cover every possible case and yours misses one.

error[E0004]: non-exhaustive patterns: `Direction::South` not covered
  --> src/main.rs:8:11
   |
 8 |     match d {
   |           ^ pattern `Direction::South` not covered
   |
note: `Direction` defined here
  --> src/main.rs:1:6
   |
 1 | enum Direction {
   |      ^^^^^^^^^
 2 |     North,
 3 |     South,
   |     ----- not covered
   = note: the matched value is of type `Direction`
help: ensure that all possible cases are being handled by adding a match arm with a wildcard pattern or an explicit pattern as shown
   |
 9 ~         Direction::North => println!("up"),
10 ~         Direction::South => todo!(),
   |

The fix. Add the missing arm, or a _ => {} catch-all.

This is the feature you will miss most in other languages. Add a variant to the enum a year later and every match that forgot to handle it fails to compile. The compiler maintains your switch statements for you.

14. E0005: That pattern can fail, and `let` has nowhere to go when it does.

error[E0005]: refutable pattern in local binding
 --> src/main.rs:3:9
  |
3 |     let Some(value) = maybe;
  |         ^^^^^^^^^^^ pattern `None` not covered
  |
  = note: `let` bindings require an "irrefutable pattern", like a `struct` or an `enum` with only one variant
  = note: for more information, visit https://doc.rust-lang.org/book/ch19-02-refutability.html
  = note: the matched value is of type `Option<i32>`
help: you might want to use `let...else` to handle the variant that isn't matched
  |
3 |     let Some(value) = maybe else { todo!() };
  |                             ++++++++++++++++

The fix. Use if let Some(value) = maybe { … } or let Some(value) = maybe else { … };

let must always succeed, so it only accepts patterns that cannot fail. This is where if let and let … else come from: they are the versions with somewhere to put the failure.

15. E0063: You built a struct without all of its fields.

error[E0063]: missing field `y` in initializer of `Point`
 --> src/main.rs:7:13
  |
7 |     let p = Point { x: 1 };
  |             ^^^^^ missing `y`

The fix. Supply y too.

There is no partially-built struct in Rust. Every field is set at construction or the value does not exist, which is why you never have to check whether a field was initialised.

16. E0070: The left side of `=` has to be something that can be assigned to.

error[E0070]: invalid left-hand side of assignment
 --> src/main.rs:2:7
  |
2 |     5 = 6;
  |     - ^
  |     |
  |     cannot assign to this expression

The fix. Assign to a variable, or use == if you meant to compare.

Almost always a == typed as =. In C this class of typo silently compiles inside an if; Rust rejects it because a condition must be a bool and an assignment is not one.

17. E0382: The value moved to a new owner, and you used the old name afterwards.

error[E0382]: borrow of moved value: `name`
 --> src/main.rs:4:16
  |
2 |     let name = String::from("crab");
  |         ---- move occurs because `name` has type `String`, which does not implement the `Copy` trait
3 |     let other = name;
  |                 ---- value moved here
4 |     println!("{name}");
  |                ^^^^ value borrowed here after move
  |
help: consider cloning the value if the performance cost is acceptable
  |
3 |     let other = name.clone();
  |                     ++++++++

The fix. Clone it, or borrow with &name, or use other.

Read the note: rather than the error: move occurs because String does not implement the Copy trait. That single line is the whole ownership model. An i32 in the same code would have been fine, because copying eight bytes is free and copying a heap allocation is not.

18. E0423: You used a struct's name where a value was expected.

error[E0423]: expected value, found struct `Config`
 --> src/main.rs:6:13
  |
1 | / struct Config {
2 | |     debug: bool,
3 | | }
  | |_- `Config` defined here
...
6 |       let c = Config;
  |               ^^^^^^ help: use struct literal syntax instead: `Config { debug: val }`

The fix. Construct it: Config { debug: true }.

A struct name is a type, not a value, unless it is a unit struct, in which case the name is the value. That inconsistency is real and worth knowing, and the error message tells you which case you are in.

19. E0428: Two things with the same name in the same scope.

error[E0428]: the name `total` is defined multiple times
 --> src/main.rs:5:1
  |
1 | fn total() -> i32 {
  | ----------------- previous definition of the value `total` here
...
5 | fn total() -> i32 {
  | ^^^^^^^^^^^^^^^^^ `total` redefined here
  |
  = note: `total` must be defined only once in the value namespace of this module

The fix. Rename one of them.

No overloading in Rust: one name, one item, per scope. This is the language deciding that "which one did I call?" should never be a question you have to answer.

20. E0432: The path in your `use` statement does not exist.

error[E0432]: unresolved import `std::collections::HashMapp`
 --> src/main.rs:1:5
  |
1 | use std::collections::HashMapp;
  |     ^^^^^^^^^^^^^^^^^^^^^^^^^^ no `HashMapp` in `collections`
  |
help: a similar name exists in the module
  |
1 - use std::collections::HashMapp;
1 + use std::collections::HashMap;
  |

The fix. Fix the spelling: HashMap.

Import errors surface before type errors, so a single typo in a use line can produce a cascade of unrelated-looking failures below it. Always fix the topmost error first and recompile. Most of the rest often vanish.

21. E0433: The type exists in the standard library but has not been brought into scope.

error[E0433]: cannot find type `HashMap` in this scope
 --> src/main.rs:2:18
  |
2 |     let scores = HashMap::new();
  |                  ^^^^^^^ use of undeclared type `HashMap`
  |
help: consider importing this struct
  |
1 + use std::collections::HashMap;
  |

The fix. use std::collections::HashMap;

Rust's prelude is deliberately tiny: only the handful of items nearly every program needs. Everything else you import by hand, and rustc will usually print the exact use line, which you can paste.

22. E0609: That struct has no field by that name.

error[E0609]: no field `z` on type `Point`
 --> src/main.rs:8:22
  |
8 |     println!("{}", p.z);
  |                      ^ unknown field
  |
help: a field with a similar name exists
  |
8 -     println!("{}", p.z);
8 +     println!("{}", p.x);
  |

The fix. Use a field that exists, or add it to the struct.

rustc lists the fields that do exist, which makes this one of the errors you can fix without leaving the terminal. Worth noticing: the available-fields list is the compiler volunteering information you did not ask for.

The pattern behind all of them

Once you've read a few hundred of these, they stop being 22 separate errors and become four questions:

Who owns this value, and did I give it away? Ownership errors.
How long does this reference need to live? Lifetime errors.
Does this type do the thing I'm asking of it? Trait errors.
Did I say what I meant? Type, scope and mutability errors.

That's the language's whole difficulty curve, and the compiler tells you which of the four you're in every single time.

If you want to practise these against a real compiler without installing anything, that's what I built codecrab for: actual rustc output, the failing span underlined in your own source, one hint at a time. 94 exercises. Exercises derive from rustlings (MIT).

Compiling costs real money and I'd like this to still exist in 2028. The 94 exercises above stay free - the Pro subscription Pass raises the daily compile limit and opens the courses built from the error corpus.

https://codecrab.app/

Forward Deployed Engineer is outsourcing with a better logo

Mykhailo — Fri, 14 Aug 2026 00:26:41 +0000

I spent more than five years in outsourcing companies. That is where I started my career.

The job looked like this: get assigned to a client, learn their infrastructure, fight their legacy systems, sit in calls with people who could not describe what they wanted, ship something that worked, move to the next client. Sometimes I was on their VPN more than my own employer's. Sometimes I knew their systems better than their own staff did.

Now the same job has a new name and a salary that can be twice as high. It is called Forward Deployed Engineer.

Where the name came from

The term belongs to Palantir. The earliest published use I could find is a TechCrunch piece from June 2010 about a funding round, which identifies one of their employees by the title forward deployed engineer.

The name is borrowed from the military, where a forward deployed unit sits in the field instead of at home base. That is the whole idea. Palantir was selling data integration software to intelligence and defense customers who could not describe what they needed, partly because the requirements were classified and partly because nobody had written them down. Shipping the software did not work. So they shipped engineers, cleared and embedded on site, writing production code inside the customer's environment for months at a time.

Internally Palantir called them Deltas, a name they explain in their own post on Dev versus Delta. According to The Pragmatic Engineer, the company had more FDEs than regular software engineers until roughly 2016. That is a striking ratio for a company that sells a product. There is also a day in the life of an FDE from 2022 if you want their version of the job.

So the name is about fifteen years old, and the current wave of AI companies hiring FDEs did not invent anything. They picked up a label that already had a decade of history and a good story attached to it.

The job description is identical

Read what an FDE is supposed to do. Integrate a vendor's product with the client's messy data. Build custom pipelines and workflows on top of it. Sit with non-technical stakeholders and translate business pain into technical requirements. Feed real-world edge cases back to the product team.

Now read what I did in outsourcing. Integrate whatever the client bought with whatever the client already had. Build custom pipelines on top of it. Sit with non-technical stakeholders and translate business pain into technical requirements. File bugs and feature requests upstream when the vendor's product could not do the thing the client paid for.

I cannot find the daily difference. Same messy enterprise APIs. Same undocumented internal system that one person understands and that person is on vacation. Same client stakeholder who changes the requirement after the sprint started. Same travel, same context switching, same burnout curve.

What actually differs

Two business models, one job description.

An outsourcing agency sells hours. The unit of revenue is a person occupying a seat for a month. If a client cuts ten engineers, the agency loses ten engineers of revenue. Every engineer is a line item, and line items get negotiated down. That is why the rate is what it is, and it is why the agency's incentive is to keep bodies billable rather than to make any single engineer irreplaceable.

A product vendor sells licenses. The unit of revenue is an annual contract with a margin an agency will never see. The engineer they send into the client is not the product. The engineer is what makes the contract renew. One person who unblocks a stuck rollout can be the reason a seven-figure renewal happens instead of a churn. That is a very different number to justify a salary against.

If you want the numbers, levels.fyi has them. Palantir's forward deployed software engineer sits around $211K median. An EPAM engineer in the US is $165K. Accenture is closer to $109K. The frontier labs pay far more than any of them, but they pay everyone far more, so that gap is the company and not the title.

The lock-in argument does not hold up

The usual defense is that outsourcing and FDE work create different kinds of dependency. Outsourcing locks the client into people who understand the custom code. FDE work locks the client into the vendor's platform.

Both are lock-in. I have watched both happen. I have written the pipeline that nobody else could maintain, and I have also been the one who inherited someone else's version of it three years later and needed two weeks just to draw the diagram.

The distinction people draw is real but small. It describes who captures the value, not what the engineer does with their day. An engineer wiring a client's legacy database into a vendor's domain model is doing the same work whether the invoice says time and materials or annual license.

What I would actually tell someone trying to make the jump

If you are in outsourcing and you want the FDE title and the FDE compensation, the honest advice is to stop optimizing your engineering and start optimizing three other things.

Learn one product deeply instead of ten stacks shallowly. Outsourcing rewards breadth. You get thrown at whatever the next contract needs, and after five years you have touched a dozen stacks and mastered none of them. Product companies hire for the opposite. They want someone who knows their platform's data model well enough to argue with the core team about it. Pick a platform, go deep, get certified if the vendor offers it, build something real on it in public.

Get comfortable being wrong in front of executives. In outsourcing my escalation path was almost always internal. There was an account manager and a delivery lead between me and anyone who owned a budget. FDE work removes those layers. You are in the room where the customer decides whether to keep paying, and you have to say "that integration will take three weeks and here is why" to someone who wanted to hear one week.

Go find out what they are actually hiring for. Change your LinkedIn title to Forward Deployed Engineer and start reading the job posts. Scrape them if you want, there is nothing hidden here. A few dozen descriptions will tell you what the requirements really are, and once you line them up against your own CV the gaps are obvious. Then build a plan to close them.

What you will notice is that almost every one of these roles is at a product company. So you need a product mindset. Not just "solve the client's problem", but understand why the company put you at this particular client, what that account means to them, and what happens if it goes badly.

None of this is about writing better code. If you are already the person the client asks for by name, you have the engineering part.

The part I am not sure about

I do not know how durable the FDE label is. Roles that exist to make a specific product land tend to get squeezed when the product gets easier to deploy, or when the vendor decides the work belongs to a partner network. That is more or less what happened to a lot of specialist consulting niches over the last decade.

I also do not know whether the pay gap survives the title becoming common. Right now it is scarce enough that the compensation reflects the revenue it protects. In five years there may be a lot of people with FDE on their profile, and the salary may look a lot more like a senior engineer's, and the same people who chased the title will be looking for the next one.

I did this job for five years before it had the good name. Nobody called it strategic then, and I still cannot tell whether they were wrong about the work or just early on the pricing.

Originally published on yetmike.com.

Podman Lost to Docker. I Stopped Fighting It.

Mykhailo — Mon, 27 Apr 2026 20:18:32 +0000

Most "Podman vs Docker" articles treat it as a technical comparison. It isn't. It's a migration cost problem.

The technical case for Podman is real: rootless by default (not opt-in like Docker's 20.10 mode), no dockerd running as root, no $9–15/user/month for Docker Desktop, and Quadlet (5.0, 2025) for native systemd integration. These are genuine architectural wins.

But Stack Overflow's 2025 survey shows Docker at 71.1% adoption — the largest single-year jump of any technology. Podman at 11.1%. Docker Hub: 318 billion pulls. Podman Desktop: 3 million total downloads since launch.

That's not a competitor. That's a niche.

The question that actually matters

Not "which is better?" but "what context are you in?"

Starting fresh — use Podman if it fits. On RHEL, it's the obvious choice: Red Hat ships it by default, Quadlet integrates directly with systemd, rootless-by-default matters when someone audits your runtime. The CNCF accepted it into sandbox in January 2025. Greenfield project, no legacy tooling — go for it.

Migrating an existing Docker setup — think twice. This is where the calculation breaks down. The spreadsheet shows Docker Desktop at $9–15/user/month. It doesn't show:

Migration day
Debugging socket path differences (Podman uses a different socket location than Docker)
Updating CI pipelines built around Docker socket compatibility
Fixing Dev Containers when VS Code stops finding the right runtime
The 30-minute Podman explanation for every new hire who's never heard of it

These are real hours from real people. None of them ship anything a user will ever see.

Why Docker won anyway

Not on merit. On surface area.

GitHub Actions assumes Docker. Rancher Desktop defaults to Docker. MCP server configs reference Docker. Every Stack Overflow answer assumes Docker. Every internal platform template your company has written assumes Docker.

When you switch, you're not just swapping a binary. You're swimming against the accumulated inertia of every tool your team uses daily. Podman's remaining real advantages — daemonless architecture, rootless-by-default, Quadlet — are genuinely better. They're also genuinely invisible to 90% of the people making the decision.

I wrote about the full trade-off breakdown, including where each argument actually landed and what Docker did and didn't fix, in the original post on yetmike.com.

The short version: run the numbers with migration costs included. Then decide.

Originally published on yetmike.com

DEV Community: Mykhailo

Certified Backstage Associate: I Passed by Five Points

Why CNCF exam habits don't help

Customizing Backstage (32%)

Development Workflow (24%)

Infrastructure (22%)

Catalog (22%)

How I prepared, and what I'd change

Three cargo errors that don't happen any more

A manifest with no version

A misspelled key in [profile.release]

A virtual manifest with one member

Why I'd have got all three wrong

CAPA Exam Guide: Argo CD Is Only a Third of It. I Scored 93

Format and weights

Workflows (36%)

Argo CD (34%)

Rollouts (18%)

Events (12%)

How I prepared

Practice test

Every rustc error has two spans, and they mean different things

The same shape, one step harder

And once more, with three

Why I think this matters more than the error codes

CGOA exam prep: why 50 clusters of Argo CD got me an 82

Format

30% of the exam is four sentences

Terminology cost me the most

Pull vs push, and related practices

How I'd prepare

The mental model

The 22 Rust errors every beginner hits, in the order they hit them

1. E0061: The function takes two arguments and you passed one.

2. E0277: Vec has no single obvious way to print itself, so {} will not take it.

3. E0282: Rust cannot work out what type this collection holds, because nothing was ever put in it.

4. E0308: You promised an i32 and returned nothing.

5. E0381: The variable was declared but never given a value, and you read it.

6. E0384: let bindings do not change unless you say mut.

7. E0425: You used a name that was never declared in this scope.

8. E0596: You called a method that needs to modify the value, on a binding that cannot be modified.

9. E0599: That type has no such method.

10. E0601: Every Rust program starts at a function called main, and there isn't one.

11. E0618: You put call parentheses after something that is not a function.

12. E0765: A string was opened with a quote and never closed.

13. E0004: A match has to cover every possible case and yours misses one.

14. E0005: That pattern can fail, and let has nowhere to go when it does.

15. E0063: You built a struct without all of its fields.

16. E0070: The left side of = has to be something that can be assigned to.

17. E0382: The value moved to a new owner, and you used the old name afterwards.

18. E0423: You used a struct's name where a value was expected.

19. E0428: Two things with the same name in the same scope.

20. E0432: The path in your use statement does not exist.

21. E0433: The type exists in the standard library but has not been brought into scope.

22. E0609: That struct has no field by that name.

The pattern behind all of them

Forward Deployed Engineer is outsourcing with a better logo

Where the name came from

The job description is identical

What actually differs

The lock-in argument does not hold up

What I would actually tell someone trying to make the jump

The part I am not sure about

Podman Lost to Docker. I Stopped Fighting It.

The question that actually matters

Why Docker won anyway

2. E0277: `Vec` has no single obvious way to print itself, so `{}` will not take it.

4. E0308: You promised an `i32` and returned nothing.

6. E0384: `let` bindings do not change unless you say `mut`.

10. E0601: Every Rust program starts at a function called `main`, and there isn't one.

13. E0004: A `match` has to cover every possible case and yours misses one.

14. E0005: That pattern can fail, and `let` has nowhere to go when it does.

16. E0070: The left side of `=` has to be something that can be assigned to.

20. E0432: The path in your `use` statement does not exist.