Forem: Erik Novikov

How I passed the AWS DVA-C02

Erik Novikov — Fri, 24 Apr 2026 11:14:39 +0000

What is the DVA-C02 and why does it matter?

The AWS Certified Developer – Associate (DVA-C02) is Amazon's certification for developers who build and maintain applications on AWS. It covers the full spectrum of what a backend/cloud developer needs to know in practice: serverless architectures, CI/CD pipelines, security and identity management, NoSQL at scale, event-driven systems, and more.

This isn't a "I clicked through a wizard" cert. Passing it means you can design, deploy, debug, and optimize cloud-native applications on one of the most widely adopted cloud platforms in the industry. The cert signals that you can own backend infrastructure on AWS — or work alongside DevOps and cloud engineers without hand-holding.

This is my journey on how I got there.

It wasn't a one-month sprint

I could have gone that route — watch a course, smash some practice exams, pass, forget everything. But that wasn't the point. I wanted to actually understand the AWS ecosystem, not just hold a certificate.

So I took my time. About 5 months in total — though I wasn't doing this full time. Most of my time went to regular software development work, and AWS prep happened in the gaps: evenings, weekends, whenever I had the mental bandwidth.

How I prepared

A few things worked well for me:

Hands-on labs on AWS Skill Builder — There's no substitute for actually doing things. Clicking through the console, breaking stuff, fixing it. Skill Builder has solid labs and I'd recommend going through them before anything else.

Building something real — I was already working on dotapro.org, an open-source Dota 2 analytics platform. Building and deploying a real application on AWS forced me to think about architecture decisions, IAM policies, deployment pipelines — things that actually show up on the exam because they actually matter in production.

Stephane Maarek's course on Udemy — The go-to for a reason. Clear, well-structured, covers a ton of the theory you need.

Tutorials Dojo practice exams — This is where things got real. The practice exams are harder than the actual exam, which is exactly what you want. They exposed the weak spots I didn't know I had and forced me to go back and fill them in properly.

Tutorials Dojo cheat sheets — A bit lengthy, but a community favorite — and for good reason. Free, comprehensive, and kept up to date. They cover each service in real detail, and if something doesn't click, they link directly to the relevant AWS docs.

What the exam is actually like

Mostly serverless and application-layer stuff. If you're expecting heavy networking or infrastructure questions, you won't find many. What you will find, a lot of:

Lambda (a lot)
DynamoDB (seriously, a lot — know it well)
API Gateway
Cognito
Kinesis
CodeDeploy and CI/CD pipelines
IAM
S3
RDS
EC2 (less than you'd think)

The questions are scenario-based. They'll describe a situation and ask what the best solution is — which means you need to understand the why behind each service, not just what it is. Memorizing won't cut it. Understanding will.

The takeaway

The DVA-C02 isn't brutal, but it's not a gimme either. What made the difference for me wasn't the number of hours I put in — it was the quality of them. Hands-on work, real projects, and practice exams that exposed my gaps.

If you're planning to sit it, don't shortcut the fundamentals. Cloud computing isn't magic — it's just distributed systems with good marketing. Once you internalize the core principles of software development and system design, the AWS-specific stuff starts making a lot more sense.

My Arch Linux Story

Erik Novikov — Tue, 21 Apr 2026 09:54:57 +0000

Intro

This is my journey of how I transitioned from Windows to Arch Linux, the reasons behind it, and whether it's really worth it. I'm a quite practical and no-fluff writer, so I'm sure you will find something useful or interesting. Stay tuned!

The very beginning

Like everyone, I started on Windows. It's what everyone uses, it's what comes pre-installed, and it comes with most of what a normal person would need from a computer. Then at some point, I met Linux: open source, super fast and resource efficient, without the Windows bloat and with free licensing. Also, the server world runs on Linux, because it's faster and cheaper. So it was evident that if I wanted to take it seriously as a software dev, I had to become comfortable around Linux.

First stop: WSL

The obvious first step was WSL — Windows Subsystem for Linux. You get a Linux terminal without leaving Windows, it's easy to set up, and for small scripts and simple projects it works fine.

The problem showed up as soon as I tried to use it for real work. On an 8GB RAM machine running VSCode with a fullstack project open — LSPs, syntax extensions, the works — the whole thing would hang. Not a little lag, but full 30-second freezes from just opening a moderately sized codebase. WSL adds a virtualization layer on top of Windows, and Windows itself is already eating a significant chunk of your memory. On constrained hardware, it simply doesn't hold up. And even on more powerful machines, I'd rather save that compute for actual development — not for system bloat or telemetry quietly reporting back to Microsoft.

So I decided to switch for real.

Fedora — the right call for the wrong hardware

It had a very good reputation among the dev community, since it is the most developer-friendly distro. Faster and less bloated than Ubuntu, with good stability and smooth updates with 6-month release cycles, and it handles a ton for you out of the box.

The difference from day one was noticeable. Memory usage at idle dropped substantially, everything felt snappier, and I could finally run my full dev setup — VSCode, Chrome with multiple tabs open, Docker, DBeaver — without the machine gasping.

But I had a small problem — my laptop's WiFi chipset. It's a MediaTek MT7902, and MediaTek simply doesn't ship Linux-compatible drivers. My fix at the time was a USB WiFi dongle, which got the job done until it broke. So I started searching for alternatives, and the most promising solution was to compile and install third-party community drivers for my chipset. The community driver didn't work on Fedora, so I tried a few other distros. None allowed for the community driver installation, except Arch Linux.

Installing Arch (it was awesome)

Arch has a reputation. The community talks about it like a rite of passage, and for years the installation process genuinely was manual enough to intimidate most people. I went in expecting the worst.

The reality in 2026: archinstall exists. It's a guided installer that walks you through partitioning, locale, desktop environment, bootloader — the whole thing. The whole installation took maybe 45 minutes. I was expecting a weekend project.

Once it was up, I compiled the MediaTek driver. It worked. That alone made the whole detour worth it. I ended up automating the entire driver setup and publishing it here for anyone else stuck in the same situation.

What Arch actually feels like

The performance difference is real, and it's immediately obvious. My system boots in about 5 seconds max — a few seconds faster than Fedora, which is a nice touch.

Part of that is Arch's philosophy: you install exactly what you need, nothing else. No background updater for software you never asked for, no telemetry running quietly, no bundled apps eating RAM. The base system is minimal by design, and everything on top of it you put there deliberately.

The other relevant thing about Arch is that it's a rolling release. There are no versions — no "Arch 2026" to upgrade to each year. You just run pacman -Syu and you're always on the latest everything. For a dev machine that's genuinely convenient, but still isn't something that makes it 10x better than any other distro.

And the most important thing — you get to flex "I use Arch btw 💪". The greatest meme in the Linux community.

The tradeoff — some things don't configure themselves. Connecting an external monitor required manual setup. Default system audio meant installing pavucontrol and configuring things from there. These aren't hard problems, but they're yours to solve — which is a different experience from what most people and devs are used to. If something doesn't work, you look it up, find the answer on the Arch Wiki or with a quick Google or AI search, install and set up what you need, and move on.

Bottom line

Honest answer — IT DOESN'T MATTER. The real-world performance difference between Arch, Fedora, Ubuntu, and other distros is smaller than the internet would have you believe.

I still recommend Arch to devs who take their craft seriously. You will gain a deeper understanding of your system. The installation teaches you things. Running, breaking, and fixing it teaches you even more. But it's not the right tool for everyone, and pretending otherwise is a kind of gatekeeping that doesn't help anyone. I also derive great satisfaction from having my OS as clean and minimal as possible, in the same way I do for my physical workspace — knowing exactly what the system has and for what purpose.

Always remember — Pragmatism over dogma. The most important thing is developer experience and productivity. Having your tools work, your workflow be uninterrupted, and your system stay out of your way — that's what matters. Which distro gets you there is secondary. A 5-second extra boot time or downloading some package 200 milliseconds faster is negligible when you work for hours a day.

Try the best-known distros for a while (no more than a day in total), and pick the one that resonates the most with you. Don't fall into the OS optimization hell — focus instead on the big picture (developer experience and productivity), and remember that distro hopping is itself a form of procrastination. Use that time instead to do real work or to work on something you enjoy.

The tech market is tough. Here's what actually matters.

Erik Novikov — Tue, 07 Apr 2026 19:35:39 +0000

The situation

Layoffs, an influx of new devs, and AI getting more capable every month. The market is genuinely harder than it was a few years ago — both at entry level and senior. Supply is up, so the average developer's value is down. That's just supply and demand.

But the average developer is not you. Here's why it's not as grim as it looks.

Competence still wins

The market isn't homogeneous. Two developers with the same title and years of experience can be worlds apart in actual ability. What separates them:

1. Problem-solving over knowledge accumulation

The developer who knows three frameworks but can't think through an unfamiliar problem is less valuable than the one with strong fundamentals who can adapt fast. Protocols, concurrency, system design, debugging, fixing and shipping under pressure — these transfer across stacks. Knowing by heart a specific library or framework doesn't.

A concrete example: migrating a microservice from Java to Go. A developer who's never touched Java might freeze. A developer with solid fundamentals in how languages handle concurrency and how services communicate will figure it out. Be the second developer.

2. AI leverage

Use AI to plan, brainstorm, review, and code — but stay in the driver's seat. Vibe-coding your way to a shipped feature might look fast until you spend hours debugging a system you never actually understood. AI is a force multiplier, not a replacement for understanding what you're building.

3. Learning rate

In tech, what you know today matters less than how fast you can learn something new and apply it. The half-life of any specific skill is shrinking. Your ability to pick things up quickly is the most durable asset you have.

Final word

Don't stress over the market. Get extremely good instead. Strong fundamentals, smart use of AI, and a fast learning rate will put you ahead of most. Focus on those and the rest takes care of itself.

How I built voice-type

Erik Novikov — Tue, 07 Apr 2026 19:17:00 +0000

Intro

This post breaks down Voice Type — a system-wide speech-to-text tool for Linux I built and use daily. I'll cover why I built it, how it works under the hood, and what I learned along the way.

Why I built it

Two reasons: wrist pain and productivity.

Modern dev workflows involve a ton of prompting — LLMs, search, documentation. If you're doing that all day with a keyboard, your wrists notice. And beyond the ergonomics, you simply speak faster than you type. Offloading even part of that to voice has a real impact.

The obvious solution was a local STT model. I tried SpeechNote on Linux with a Whisper.cpp small model — it wasn't accurate enough and had noticeable latency. Running a larger model wasn't an option either: I'm on an 8GB RAM laptop, and my dev setup (VSCode, Chrome, Docker, DBeaver, etc.) already pushes that. A 3–4GB model sitting in RAM wasn't viable.

I eventually found that Chrome's built-in Web Speech API — which routes audio to Google's servers under the hood — matches the accuracy and speed of much larger models like Whisper large, with virtually zero local resource usage. That was the unlock.

How it works

Voice Type launches a headless Chrome instance via Puppeteer and uses the Web Speech API to do real-time transcription. Here's the flow:

Browser — Chrome runs the Web Speech API with interimResults: true, which streams partial transcripts as you speak in real time. These flow in via Google's WebSocket infrastructure.
IPC — When a new interim result arrives in the browser, it triggers a callback into the main Node.js daemon. This is done via Puppeteer's exposeFunction, which leverages the Chrome DevTools Protocol WebSocket connection to invoke a function in the main process in real time.
Diffing — The daemon keeps track of currentText. On every update, it runs a diff: if nothing changed, do nothing. If it changed, find the longest common prefix between the old and new text, send the right number of backspaces, and type the new characters.
Typing — Text is typed system-wide via dotool. Standard ASCII goes through directly. Accented characters, emojis, and CJK are handled via GNOME's Unicode Hex Input sequence (Ctrl+Shift+U → hex code → Enter), which makes it work across languages without needing to match the user's keyboard layout.

This is why Voice Type can correct itself mid-sentence without retyping everything from scratch — it only fixes what changed.

Privacy note

Since the Web Speech API is powered by Google's servers, your audio does leave your machine. Worth knowing before you use it for anything sensitive.

How I actually use it

Mostly for prompting and writing blog posts like this one. Once it's bound to a key, it gets out of the way completely — press, speak, done. It supports text and sound notifications, though I prefer them disabled — GNOME already shows a mic icon in the system tray when the mic is active.

Conclusion

STT is underrated as a dev tool. If you're on Linux, give Voice Type a try — it's free, open source, and uses almost no resources. If it's useful to you, a star on GitHub goes a long way. Happy coding!

How I built dotapro.org

Erik Novikov — Wed, 01 Apr 2026 15:13:59 +0000

Intro

This post breaks down dotapro.org — an open-source Dota 2 analytics platform for professional matches. I'll cover why I built it and the technical decisions behind it.

Why I built it

Dota 2 is one of the few games I actually enjoy. I couldn't find a good tool for browsing professional match data with proper filtering, so I built one.

What it does

Advanced filtering by league, team, player, and hero
Real-time ETL pipeline keeping match data up to date
Fast pg_trgm similarity search for names

Architecture

The React frontend talks to an API Lambda. A separate scraper Lambda runs on a schedule, pulls data from the OpenDota API, and inserts it into PostgreSQL on RDS.

Storage

PostgreSQL on AWS RDS. I briefly ran Postgres manually on an EC2 instance just to understand what managed services actually abstract away — OS patching, backups, vertical scaling. The time cost isn't worth the savings unless you're optimizing hard on infrastructure spend.

Compute

Two Lambdas: one scraper on an EventBridge schedule, one monolithic API Lambda handling all routes via go-chi.

The monolith was a deliberate choice. One codebase, one deployment, and warm starts benefit all endpoints regardless of which one was hit first. I initially over-engineered it — scraper → SQS → ingestor Lambda — then collapsed it into a single Lambda when I realized nothing actually required that complexity.

Split a Lambda monolith when you have separate teams needing independent deployments, or a specific hot path that needs provisioned concurrency. Otherwise, keep it simple.

Frontend

React + TypeScript + Tailwind + Vite + TanStack Router/Query, deployed to S3 behind CloudFront. Standard setup, nothing unusual.

CI/CD

GitHub Actions on push to main, with OIDC auth to AWS. Selectively redeploys only what changed — UI gets built and synced to S3 with a CloudFront invalidation, Lambdas get compiled and pushed via update-function-code.

Conclusion

Feel free to check it out at dotapro.org. The code is also on GitHub — drop a star if you find it useful. Happy coding!

Welcome to my blog

Erik Novikov — Thu, 08 Jan 2026 13:56:36 +0000

What is this blog about?

Throughout this blog I intend to write about tech - full-stack web dev, programming, career advice, Linux, cloud computing, AI, and software development in general. Occasionally I may write about other topics I find interesting, only if I'm absolutely sure it would be of help to you somehow.

A bit about me

Hey there! I'm Erik, a software dev. I started programming at 17, went to university (Software Engineering), and after that I have been professionally in the industry for a while. It's been an exciting ride, where I've had to learn A LOT, and will continue to do so. IMO, that's the best thing about tech - it evolves all the time. Other than doing "normal dev stuff", I'm currently sharpening my cloud computing (mostly AWS), 3D development, and AI skills. In my free time, you will find me building something cool like dotapro.org (an open-source Dota 2 analytics platform), or voice-type (a free Linux dictation tool with unmatched speed and accuracy).

Why this blog?

You'll definitely find something helpful here.
I genuinely enjoy writing.

About my writing style

I don't like fluff.
I keep it casual, concise, and to the point.

I intend to be as value-driven as possible, so I'll only blog about something if I really believe it can be helpful to you. So no, GPT-stenchy blogs with a lot of bs and zero real world utility is something I won't ever do.

Forem: Erik Novikov

How I passed the AWS DVA-C02

What is the DVA-C02 and why does it matter?

It wasn't a one-month sprint

How I prepared

What the exam is actually like

The takeaway

My Arch Linux Story

Intro

The very beginning

First stop: WSL

Fedora — the right call for the wrong hardware

Installing Arch (it was awesome)

What Arch actually feels like

Bottom line

The tech market is tough. Here's what actually matters.

The situation

Competence still wins

Final word

How I built voice-type

Intro

Why I built it

How it works

Privacy note

How I actually use it

Conclusion

How I built dotapro.org

Intro

Why I built it

What it does

Architecture

Storage

Compute

Frontend

CI/CD

Conclusion

Welcome to my blog

What is this blog about?

A bit about me

Why this blog?

About my writing style

My socials