Forem: Daniil Kornilov

You’re Not Building Netflix: 9 Architecture Habits Small Teams Should Delete

Daniil Kornilov — Mon, 06 Apr 2026 15:47:51 +0000

Small teams love borrowing the aesthetics of big tech.

The problem is that architecture copied from a company with thousands of engineers usually becomes theater inside a team of four.

Complexity feels senior, but most of the time it only hides the product.

Here are nine habits I would delete first:

Splitting into microservices before the monolith hurts
Adding event-driven flows for simple request-response problems
Building abstractions before repeated pain exists
Reaching for CQRS where CRUD is enough
Choosing Kubernetes before a basic deployment pipeline is stable
Adding caches before measuring bottlenecks
Introducing multiple databases with no clear need
Organizing code by technical layers instead of product areas
Writing giant architecture docs nobody updates instead of short ADRs tied to real decisions

The replacement is not “be simple” in the abstract.

The replacement is to earn complexity with evidence.

Start with a modular monolith.
Duplicate a little until the pattern is real.
Use direct calls until coupling becomes a measurable problem.
Deploy the boring way until release pain justifies heavier tooling.
Measure before optimizing.
Keep the default path easy to understand.

A lot of engineering debt comes from solving future problems with present complexity.

Teams feel safe because the system looks “serious,” but they pay for it in slower onboarding, harder debugging, and endless coordination.

You are not building Netflix.

You are building a product with your current team, your current budget, and your current bottlenecks.

Architect for that reality.

Stop Building “Smart” Side Projects: 12 Portfolio Ideas That Actually Get Interviews

Daniil Kornilov — Mon, 06 Apr 2026 15:47:30 +0000

Most developer portfolios are full of projects that prove almost nothing:
a to-do app, a weather app, a notes app, then one “AI wrapper” with a chat box on top.

Hiring managers do not need another toy.
They need evidence that you can handle state, auth, business rules, bad input, tradeoffs, and boring product constraints.

If I had to build a portfolio from scratch today, I would choose projects that look like real internal or product work:

An admin panel with role-based permissions
A billing and usage dashboard
A document search tool with relevance feedback
An approval workflow for requests
A scheduler with conflict handling
A CSV import and validation pipeline
A feature-flag control panel
A support inbox with SLA rules
An analytics funnel explorer
An audit log viewer
An incident timeline dashboard
A migration assistant CLI

None of these sound sexy.
That is exactly the point.

They look like work teams actually pay for.

What makes a project interview-worthy is not the UI polish alone.
It is the evidence of decisions.

Show seeded demo data.
Show error states.
Show a clear README with tradeoffs.
Show tests for business logic.
Show what you would improve with more time.
Show that you know software is more than a screenshot.

The biggest portfolio mistake is trying to look impressive instead of trying to look useful.

Useful wins.
Real constraints win.
Boring but believable wins.

If your project makes a hiring manager think,
“yes, this person could own a messy feature on a real team,”
it is already better than 90% of portfolio work online.

How I Use Codex, Claude Code, and Cursor Together Without Burning Money

Daniil Kornilov — Mon, 06 Apr 2026 15:47:08 +0000

The fastest way to waste money on AI coding tools is to treat all of them like interchangeable magic IDEs.

I did that at first, and the result was predictable: vague prompts, duplicated work, too many open sessions, and a bill that grew faster than the product.

The fix was simple. I stopped asking every tool to do everything.

Codex is my execution engine inside a real repository. I use it when the task is concrete: implement a feature, fix a bug, update tests, review a diff.

Claude Code is my heavy researcher. I use it for repo-wide reasoning, architecture tradeoffs, and “what is the cleanest path through this mess?” questions.

Cursor is my fast local loop for edits, inspection, and short iteration when I already know what I want.

The rule that saved me money is this: never spend expensive context on a fuzzy problem.

First I write the task in plain English:
What changed?
What is broken?
What constraints matter?
What does “done” mean?

Only then do I pick the tool.

If the task still sounds vague, I reduce the ambiguity before I open the expensive agent.

A typical workflow looks like this:
I sketch the feature in 5-7 bullets, ask Claude Code to challenge the plan and point out risks, hand the narrowed task to Codex to implement in the repo, and use Cursor for the last 10%: renaming, docs, and small manual checks.

That single change stopped me from paying multiple tools to rediscover the same context.

The biggest mistake teams make is asking AI tools to think and execute and validate and design all at once.

That sounds efficient, but it usually means you are paying for wandering.

Good AI workflows are not about using more tools.
They are about creating cleaner handoffs.

Once I treated my AI stack like a small team instead of a slot machine, quality went up and cost went down.__

The Real Skill in 2026 Isn’t Writing Code Faster. It’s Debugging AI Systems

Daniil Kornilov — Mon, 06 Apr 2026 15:34:29 +0000

AI made the first draft cheap.

That changed the economics of software work fast.

But it did not remove the hard part.

In many teams, the scarce skill is no longer generating code.
It is diagnosing why a generated solution is wrong, fragile, incomplete, or impossible to maintain.

Debugging AI systems is bigger than debugging code.

You are debugging assumptions, context, prompts, missing constraints, tool calls, silent hallucinations, and code that looks plausible long before it becomes trustworthy.

The output can be fast and polished and still be wrong in the exact place that matters.

The workflow I trust is boring:

Isolate the failing behavior.
Reproduce it with the smallest possible case.
Inspect logs and diffs before asking for more code.
Verify every confident claim the model makes.
Shrink the context if the agent starts wandering.
Add tests for the edge case that escaped.

If the model is still fighting you, stop prompting and read the source of truth.

Many AI mistakes survive only because humans keep negotiating with them instead of verifying them.

This is why “AI makes developers obsolete” is such a shallow take.

AI lowers the cost of drafting.
It does not lower the cost of responsibility.

The person who can recover from bad generations, trace failures across tools, and turn vague output into reliable systems is becoming more valuable, not less.

In 2026, speed still matters.
But diagnosis is what protects the product.

How to Build a Personal Brand as a Developer (Without Being Cringe)

Daniil Kornilov — Mon, 30 Mar 2026 14:40:53 +0000

Let me guess. You just read "personal brand" and your eyes started to glaze over. You pictured some guy on LinkedIn posting selfies with captions like "I am humbled to announce..." or someone on Twitter farming engagement with "Day 47 of #100DaysOfCode" while their actual GitHub is a graveyard.

I get it. "Personal brand" sounds like marketing BS.

But here is what it actually means when you strip away the cringe: being findable and credible. That is it. When someone Googles your name, do they find a developer who clearly knows their stuff? Or do they find... nothing?

The uncomfortable truth: the developer who gets the job, the freelance contract, or the open source collaboration is not always the best coder. It is the one people can actually find. Your code skills matter. But if nobody knows you exist, those skills are a tree falling in an empty forest.

This is a no-BS guide to building your presence as a developer - without turning into a LinkedIn influencer and without making everyone you know want to mute you.

What Personal Brand Actually Means for Developers

Let me be clear about what we are NOT talking about: becoming a tech influencer, posting motivational content, building a "following," or any flavor of "hustle culture."

What we ARE talking about is simple. When a hiring manager or a potential collaborator encounters your name, they should quickly understand: what you do, what you know, and that you are legit.

Your personal brand is just the answer to one question: "What is this person known for?"

It does not have to be fancy. "The person who writes clear SwiftUI tutorials." "The person who contributes to that popular Python library." "The person who always shares useful debugging tips." That is a personal brand. No ring light required.

The "Be Findable" Framework

Here is your first homework: Google yourself. Right now. Open an incognito window and search your full name. What comes up?

If the answer is "nothing relevant to development" - you have a findability problem. And fixing it is easier than you think.

The 3 Platforms That Actually Matter

You do not need to be everywhere. You need to be in three places:

1. GitHub - This is your portfolio. Not your resume. Your portfolio. It is where other developers will actually judge your work. We will dig into this more later.

2. LinkedIn - Yes, I know. LinkedIn is cringe. But hiring managers and recruiters live there. You do not need to post. You just need a profile that does not look abandoned. Think of it as your professional landing page.

3. One Content Platform (Twitter, Blog, or Dev.to) - Pick ONE. This is where you show that you can think and communicate, not just code. More on choosing below.

Your Digital Presence Audit

Take 15 minutes right now: Google your name and note what shows up. Check your GitHub for a bio, photo, and pinned repos. Check your LinkedIn. Search your usernames. Blank slate? Good - you get to build from scratch. A mess? At least you know now.

Finding Your Niche

"But I don't have a niche! I just... code." I hear you. Let me reframe this.

You do not need to be the world expert on anything. You do not need to have invented a framework or have 10 years of specialized experience. You just need to be consistent about a topic.

The bar is shockingly low. If you write five blog posts about, say, testing React components, you are now "someone who writes about testing React components." That is a niche. People will find you when they search for that topic. People will remember you as "that person who writes about React testing."

How to Pick Your Topic

Find the intersection of three things:

What you know - Technologies you use daily, problems you have solved recently.

What you enjoy - What tech rabbit holes do you fall into at midnight voluntarily?

What people search for - Check Stack Overflow and Google Trends. If people are asking questions, there is demand for answers.

Two out of three is enough. Just do not pick something that only checks one box. "I help beginners learn TypeScript." "I share DevOps tips for small teams." "I write about Python automation for non-programmers." Specific, findable, sustainable.

The Content Strategy That Doesn't Suck

Most "personal brand" advice tells you to "create content" like you are supposed to become a media company. Here is a strategy that works for developers with actual jobs.

Learn in Public

Instead of waiting until you are an expert, share what you are learning as you learn it. You never run out of ideas, it is authentic, it helps people one step behind you, and it documents your growth over time.

TIL (Today I Learned) Posts

The lowest-effort, highest-value content format. Every time you learn something at work - a new API, a debugging trick, a configuration you struggled with - write it down in 3-5 sentences and post it.

Example: "TIL that in Python, dict.get(key, default) does not evaluate the default lazily. If your default is a function call, it runs every time. Use dict.setdefault() or a conditional instead."

That took 30 seconds to write. It is genuinely useful. It shows you know what you are talking about. And it is completely free of cringe.

Documenting Your Projects

Building a side project? Write about it. Not after it is perfect. During the process. Share the decisions you made, the tradeoffs, the bugs that took three hours to find, and the architecture choices you agonized over.

People love reading about the messy reality of building software. It is relatable and educational.

Sharing Opinions (Tactfully)

Have opinions backed by experience, not opinions designed to provoke. "I switched from Redux to Zustand and here is why" shares experience. "Redux is dead and anyone using it is wasting their time" starts fights. Big difference.

The 80/20 Rule

Eighty percent of what you share should be pure value - tips, tutorials, insights, helpful resources. Twenty percent can be about your work, your projects, your products.

If you flip that ratio, you become a spam account. If you go full 100/0, you build trust but miss opportunities. The 80/20 balance keeps you credible and connected to your goals.

GitHub as Your Portfolio

For developers, GitHub is worth more than a resume. A well-organized profile tells me more about you in 30 seconds than a two-page PDF ever could.

README Optimization

Your profile README (the repo named after your username) is free real estate. Keep it short: who you are, 2-3 technologies you work with, a link to your blog, and what you are currently building. Do NOT include a wall of badges, animated GIFs of every technology ever, or inspirational quotes.

Pinned Repos Strategy

You get six pinned repositories. Choose them deliberately: 1-2 substantial projects, 1 open source contribution or utility, 1 repo with a great README, and 1-2 that demonstrate your niche. Every pinned repo needs a clear description and at least a basic README. A repo with no README is like a book with no cover.

Contributing to Open Source

You do not need to rewrite the Linux kernel. Fix typos in docs, answer issues, add tests, improve error messages. Start small.

One merged PR to a popular project is worth more than ten personal repos nobody uses. It shows you can work with existing codebases and collaborate with others.

Green Squares: Do They Matter?

Yes and no. A completely empty graph for six months raises questions if you are job hunting. But a perfectly green grid impresses nobody who actually hires - we know people game it with auto-commits and that the best work often lives in private repos.

Keep it reasonably active, but do not obsess. A few commits per week from genuine work beats daily "updated README" commits to keep a streak alive.

Writing Technical Content

Okay, you have decided to write. But where?

Blog vs Twitter vs LinkedIn - Which One?

Twitter (X): Short-form, networking, quick tips. Low effort, good visibility, unpredictable algorithm.

A blog (Dev.to, Hashnode, personal site): In-depth content that ranks on Google. Higher effort, but a well-written article brings traffic for years. Dev.to has a built-in community.

LinkedIn: Career-focused content, reaching recruiters. Lower competition than Twitter.

My recommendation: Start with Dev.to and one short-form platform (Twitter or LinkedIn). One article per week, a few short posts in between.

The "Teach What You Just Learned" Approach

The best time to write a tutorial is right after you figured it out. You remember exactly what was confusing and what the "aha moment" felt like. Experts often write terrible beginner content because they forgot what not understanding feels like. You, the recent learner, remember every stumbling block. That is your superpower.

How to Write Your First Technical Article in 1 Hour

Minutes 0-10: Pick your topic. What did you learn or build recently?
Minutes 10-20: Write the outline. Problem, approach, solution, result.
Minutes 20-50: Write the body. Do not edit as you go. Include code snippets.
Minutes 50-60: Edit and publish. Fix obvious errors. Hit publish.

The biggest mistake is waiting until it is perfect. Your first article will not be great. Your tenth will be much better. But you cannot get to ten without publishing the first.

The 30-Day Kickstart Plan

If you want a concrete roadmap, here is one that works without consuming your life:

Week 1: Set Up Your Profiles

Days 1-2: Update GitHub profile README, choose 6 pinned repos, update LinkedIn.
Days 3-4: Create a Dev.to account. Choose your niche topic. Write it down.
Days 5-6: Draft and publish your first TIL post.
Day 7: Rest. Do not burn out on day 7.

Week 2: Start Posting Daily

Share one TIL or tip every day (short form, 2-5 sentences)
Write your first full article (use the 1-hour framework)
Follow 20 developers in your niche

Week 3: Engage With the Community

Comment on 3 posts per day (genuine, thoughtful comments - not "Great post!")
Answer 2 questions on Stack Overflow or in GitHub issues
Share someone else's work with your own take added
Publish your second article

Week 4: Create Something Substantial

Write a comprehensive guide or tutorial (1000+ words)
Make your first open source contribution
Share a project you have been working on with a write-up
Review your analytics: what got engagement? Do more of that.

By day 30: an optimized GitHub, a professional LinkedIn, 4+ published posts, a network in your niche, and at least one open source contribution. Not bad for four weeks.

What NOT to Do (The Cringe List)

You wanted "without being cringe" so here is the definitive list of what to avoid:

Do not fake expertise you do not have. Posting "10 Advanced Kubernetes Tips" when you finished your first Kubernetes tutorial yesterday is transparent. It is okay to be a beginner - just be honest about your level.

Do not spam "I'm open to work." One post is fine. Reposting it every three days with increasingly desperate wording is a red flag, not a strategy.

Do not copy-paste motivational quotes. "The only way to do great work is to love what you do." We have all read it. It adds nothing. Share a specific story from your own experience instead.

Do not argue in comments. Someone says your favorite framework is bad? Let it go. Public technical arguments make both sides look petty.

Do not buy followers. 10,000 followers with 2 likes per post fools exactly nobody. It looks worse than 200 genuine followers.

Do not post just to post. One genuinely helpful post per week beats seven forgettable ones. Quality always wins.

The Long Game

Building a presence as a developer compounds. Your first article might get 12 views. Your fifth might get 50. But somewhere around article 15 or 20, things click. People recognize your name. Search engines rank your content. Someone mentions you in a conversation you were not part of.

That is when "personal brand" stops feeling like a marketing exercise and becomes your reputation. Something earned through consistently showing up and being helpful.

You do not need to be famous. You just need to be the person that comes to mind when someone in your network thinks about your topic.

Be findable. Be credible. Be helpful. The rest takes care of itself.

Now close this article and go update your GitHub README. Ten minutes. The single highest-ROI thing you can do for your career today.

Want the complete personal brand building system? The Personal Brand Builder Kit includes a brand assessment worksheet, 10 bio formulas for every platform, a 30-day content plan, 50 content ideas, a GitHub README template, a portfolio HTML template, and 30 ready-to-use post templates. Build your brand without the cringe. Get it on Boosty.

I Let AI Run My Workday for 7 Days. Here's What Actually Happened.

Daniil Kornilov — Mon, 30 Mar 2026 14:38:12 +0000

Everyone says AI makes developers "10x faster." That sounded impressive, but also vague.

So I ran a simple experiment: for 7 days, I let AI touch almost every part of my workday.

Not just code.

Planning. Prioritization. writing pull request summaries. debugging checklists. article outlines. even awkward emails I did not want to write.

I wanted a real answer to one question:

Does AI actually make a developer more effective, or does it just make you feel productive?

The Rules

For one week, before doing any non-trivial task, I had to ask AI for help first.

That included:

turning a messy task list into a schedule
summarizing bugs before I started fixing them
drafting code review comments
turning rough notes into content
generating first-pass documentation
rewriting vague ideas into something publishable

What I did not allow:

blindly pasting code into production
asking AI to make final decisions for me
using it as a substitute for understanding the system

The goal was leverage, not outsourcing my brain.

What AI Was Surprisingly Good At

1. Turning Chaos Into a Plan

This was the biggest win.

I would dump my entire backlog into a prompt and ask AI to:

group related tasks
identify blockers
suggest the highest-leverage sequence
cut anything that did not matter today

That last part was gold.

I realized I was not struggling because I had too much work. I was struggling because I kept treating every task like it had equal urgency.

AI was very good at saying, "These three things move the project. The other seven are emotional support tasks."

Painful. Accurate.

2. Writing the First Draft of Boring Things

Developers underestimate how much energy gets wasted on low-drama writing:

PR descriptions
release notes
setup docs
issue summaries
follow-up messages

AI handled first drafts well enough that I could spend my time editing instead of staring at a blinking cursor.

That shift matters. Editing is easier than inventing from zero.

3. Forcing Me to Clarify My Thinking

A lot of the value was not in the answer. It was in the act of asking a better question.

If I wanted a useful response, I had to explain:

what I was trying to do
what was failing
what constraints mattered
what outcome I wanted

That alone made me sharper.

Sometimes I solved the problem while writing the prompt.

That is not magic. That is structured thinking.

What AI Was Bad At

1. Understanding System Context

AI can explain patterns. It cannot magically know why your weird legacy payment service behaves like a haunted refrigerator.

When I gave it a bug with hidden business context, the suggestions got generic fast.

It would say:

"check for null values"
"verify the API response"
"add logging"

Not wrong. Also not enough.

The deeper the problem depended on local context, hidden assumptions, or product history, the less useful AI became.

2. Making Tradeoffs

AI loves sounding confident even when there are real tradeoffs.

Should this be refactored now or left alone?
Is the elegant solution worth the delay?
Should I optimize readability or short-term speed?

These are judgment calls.

AI can help frame them. It should not own them.

3. Reducing Overwork

This one surprised me.

AI helped me produce more. But without discipline, "more" turns into "more stuff to review, refine, and ship."

It did not automatically give me free time.

It gave me throughput.

Those are not the same thing.

If your system is already overloaded, AI can become an accelerator for chaos.

The Real Lesson

AI did not replace the hard parts of my job.

It replaced the friction around the hard parts.

That is a big difference.

The best use case was not "write everything for me."

It was:

help me start faster
help me think cleaner
help me package work better
help me move through low-value overhead

In other words: AI was not my replacement.

It was my most tireless assistant.

My New Rule

After this experiment, I kept one habit:

Before I do any task that feels fuzzy, repetitive, or annoying, I ask:

"Can AI give me a better first pass?"

If yes, I use it.
If not, I do the thinking myself.

That simple filter saved me more time than any "ultimate prompt framework" ever did.

Final Take

AI will not save a weak workflow.

It will expose it.

If your priorities are unclear, your systems are messy, and your writing is vague, AI will just help you produce confusion faster.

But if you already know how to think, decide, and edit, it becomes a serious force multiplier.

That is the real edge in 2026.

Not using AI.

Using it without becoming dependent on it.

I write about developer systems, AI workflows, and career leverage.

If you want more of that, follow me here and check my other posts.

Stop Treating Side Projects Like Startups. Do This Instead.

Daniil Kornilov — Mon, 30 Mar 2026 14:37:07 +0000

Most side projects do not fail because the idea is bad.

They fail because the developer secretly turned a tiny experiment into a fake startup on day one.

I have done this too many times.

You open a blank repo and suddenly you are thinking about:

the brand name
the landing page
the logo
the perfect database schema
the content strategy
the monetization plan
the roadmap

All before the project has earned the right to exist.

That is not momentum.
That is procrastination dressed up as ambition.

The Real Job of a Side Project

A side project has one job:

Teach you something valuable or prove that someone cares.

That is it.

Not become a company.
Not make you rich immediately.
Not justify a Notion board with 14 columns.

The earlier you accept that, the faster you start shipping things that actually matter.

Why Developers Overbuild So Fast

Because building systems feels productive.

And because uncertainty is uncomfortable.

If you admit your project is only an experiment, you also admit it might go nowhere.

That hurts the ego.

So instead, many people create complexity to feel serious.

They build authentication for a product with zero users.
They plan premium tiers for a tool nobody has opened.
They optimize architecture for scale that does not exist.

It feels safe because you are busy.
But busyness is not proof.

The Better Model: Tiny, Useful, Shippable

Now I try to make side projects pass three tests:

1. Can I ship a first version in under 7 days?

If not, it is too big.

2. Can I explain the value in one sentence?

If not, it is too vague.

3. Can one real person benefit from it immediately?

If not, it is probably just a toy for my own ego.

That filter kills a lot of bad ideas early.
Good.

What to Build Instead

The best side projects are often boring on purpose.

Examples:

a script that turns messy notes into publishable summaries
a template that saves freelancers time every week
a debugging checklist for junior developers
a resume system that helps one friend get interviews
a tiny internal tool you wish existed at work

None of these sound flashy.
That is exactly why they work.

They solve a real irritation.

Boring pain is still pain.
And boring solutions are often easier to finish.

My Favorite Side Project Rule

Build for evidence, not identity.

Do not build something because you want to be "the founder of X."

Build something that produces one of these forms of evidence:

one user says "this helped"
one person pays
one workflow becomes faster
one painful task disappears
one post about it gets strong response

Evidence is better than excitement.

Excitement fades.
Evidence gives direction.

A Better 30-Day Plan

If I were starting a new side project today, I would do this:

Week 1

Pick one painful problem.
Build the ugliest version that works.

Week 2

Show it to 5 people.
Watch where they get confused.
Fix only that.

Week 3

Write one useful post about the problem it solves.
See if anybody cares.

Week 4

Decide:

kill it
simplify it further
double down

That process is not glamorous.
It is effective.

Final Thought

Most side projects do not need more features.
They need less fantasy.

If you stop pretending every small idea is a future company, you free yourself to actually learn, ship, and iterate.

And ironically, that is exactly how some side projects become real businesses later.

Not because you forced them to look like startups.

Because you let them earn it.

I write about side projects, digital products, and practical systems for developers who want traction without pretending to be a 20-person company.

The Invisible Developer Problem: Why Good Coders Still Get Ignored

Daniil Kornilov — Mon, 30 Mar 2026 14:36:09 +0000

Some developers are genuinely good at their job and still get overlooked.

Not because they lack skill.
Not because they are lazy.
Not because they do bad work.

They get ignored because they are invisible.

I have seen this pattern over and over:

solid engineer
reliable output
few mistakes
no real career momentum

Meanwhile, someone slightly less technical keeps getting better projects, more trust, and more opportunities.

That feels unfair until you notice what is actually happening.

Good Work Does Not Automatically Become Visible

This is the painful part.

A lot of developers believe quality speaks for itself.

Sometimes it does.
Usually it does not.

If your contribution is buried inside commits, hidden inside meetings, and never explained in business terms, most people will not fully register its value.

Managers are busy.
Recruiters are skimming.
Founders think in outcomes.
Teammates only see fragments.

If you do important work but nobody can quickly understand what changed, why it mattered, and what result it created, your work stays local.

Useful. But invisible.

What Invisible Developers Usually Do

Here are the common patterns:

1. They only communicate when something breaks

No updates.
No written summaries.
No framing.

Then suddenly:

"Done."

That sounds efficient. It is not.

2. They describe tasks instead of outcomes

Bad:

"Refactored auth flow."

Better:

"Reduced onboarding drop-off by simplifying auth flow and cutting the number of steps from 5 to 3."

People remember outcomes.
They forget implementation details.

3. They avoid publishing what they know

No posts.
No internal docs.
No small demos.
No useful comments.
No public proof of thinking.

Then they wonder why louder people keep winning.

Visibility Is Not the Same as Self-Promotion

This is where many good developers get stuck.

They hear "be more visible" and imagine cringe personal branding.

You do not need fake hustle energy.
You do not need to post hot takes every day.
You do not need to turn your life into content.

You just need to make your value easy to see.

That can look like:

clear pull request descriptions
short weekly summaries
screenshots before and after a change
writing down lessons from bugs you fixed
posting one useful insight a week
documenting decisions others will benefit from

That is not performative. That is leverage.

The 4-Part Visibility System

This is the simple version.

1. Ship work people can understand quickly

When you finish something, explain:

what changed
why it mattered
what result it improved

Three lines is enough.

2. Create artifacts

If your work disappears after a meeting, it has weak leverage.

Artifacts last:

docs
demos
posts
issue writeups
before/after screenshots
public case studies

Artifacts compound.

3. Translate technical effort into business language

Do not just say:

"Optimized query performance."

Say:

"Reduced dashboard load time from 6.2s to 1.4s, which makes sales reporting usable without waiting."

That lands.

4. Repeat without being annoying

Visibility is not one big announcement.
It is consistent clarity.

The developer who explains useful work every week will beat the technically stronger developer who stays silent for six months.

That is just how humans work.

The Hard Truth

If you are useful but invisible, the market will often price you below your real value.

Not because the market is evil.
Because attention is part of value distribution.

People can only reward what they can clearly see.

Final Thought

The goal is not to become famous.

The goal is to stop hiding the value you already create.

You do not need to become louder.
You need to become easier to understand.

That one shift changes careers.

I write about career leverage, developer writing, and practical systems for building visible work.

I Applied to 200 Jobs and Got 0 Interviews. Then I Changed ONE Thing.

Daniil Kornilov — Mon, 30 Mar 2026 14:34:55 +0000

I'm going to tell you something embarrassing.

Last year, I spent two straight months applying to every junior developer job I could find. LinkedIn, Indeed, Glassdoor, HH, random company career pages, sketchy job boards I found through Google on page 3. I didn't care. If the posting said "developer" and didn't require 10 years of experience, I hit apply.

200+ applications. I was keeping count in a spreadsheet because I thought tracking the numbers would make me feel productive. Spoiler: it just made me feel worse. 200 applications. Zero interviews. Not even a rejection email from most of them. Just... silence.

I remember sitting in my room at 2 AM, eyes bloodshot, copy-pasting my resume into yet another application form, thinking "this is fine, it's a numbers game, eventually someone will say yes." I was wrong. So, so wrong.

What I was doing wrong

Let me walk you through my brilliant strategy. Maybe you'll recognize yourself in this, and if you do, please stop. I'm begging you.

My resume was a generic disaster. One resume. For every single job. Frontend position at a startup? Same resume. Backend role at a bank? Same resume. iOS developer at a health tech company? You guessed it. Same resume. I had this Frankenstein document that tried to be everything to everyone and ended up being nothing to anyone.

I also wasn't reading job descriptions. Like, at all. I'd look at the title, skim the requirements for about 4 seconds, and if I recognized at least two technologies from the list, I'd apply. "Oh, they mention Swift. I know Swift. Ship it." Never mind that the posting specifically asked for 5 years of CoreData experience and knowledge of Objective-C legacy codebases. Details, right?

Cover letters? Zero. None. I told myself "nobody reads those anyway" which is a really convenient excuse when you're too lazy to write one. When an application required a cover letter, I'd either skip that job entirely or write something like "Dear Hiring Manager, I am interested in this position. I have experience in software development. Please see my attached resume." Riveting stuff.

Then there's the schedule. My peak application hours were between midnight and 3 AM. You know, the time of day when you make your best decisions. I'd have 15 tabs open, half-eaten ramen on my desk, and I'd be speed-running through applications like I was trying to set a world record. Quality? Never heard of her.

Worst of all, I was treating the whole thing like a lottery. Buy enough tickets and eventually you win, right? That's literally how I thought about job applications. More applications = higher chance. It's simple math! Except it's not math. It's not a lottery. And I was an idiot.

The moment it clicked

I was complaining to a friend (also a developer, but one who actually had a job) about how "the market is broken" and "nobody is hiring" and all the other things you say when you don't want to look at your own process.

He asked me one question: "Show me the last application you sent."

So I showed him. He read my resume. He looked at the job posting. He looked back at my resume. He looked at me like I had just shown him a crayon drawing and called it a Picasso.

"Dude. This job asks for experience with CI/CD pipelines and you don't mention it anywhere. You have it on your GitHub. Why isn't it on your resume?"

"Well, I use the same resume for everything..."

"That's your problem."

Then he said the thing that actually got through to me: "You're sending 50 applications that say 'please hire me for something' instead of 5 applications that say 'I'm the exact person you described in that job posting.'"

That hurt. Because he was right.

The ONE thing I changed

I stopped applying to 50 jobs per week. Cold turkey. Instead, I committed to 5 applications per week. Maximum.

"Five? That's nothing! That'll take forever!" That's what I thought too. Here's what those 5 applications actually looked like, though.

Monday and Tuesday were just research. I'd spend two full days finding 5 companies I actually wanted to work for. Not "any company with a pulse," but companies where I could see myself. I'd read their blog, check their GitHub repos, look at their tech stack, read employee reviews, find the hiring manager on LinkedIn. By the time I was done, I could tell you what framework they use for their backend and what their last product update was about.

Wednesday was resume day. I had a master resume with everything on it. For each of the 5 jobs, I'd create a custom version. If they wanted CI/CD experience, that bullet point moved to the top with specific details. If they cared about UI/UX, I'd emphasize my design work. Every resume was basically a mirror of their job description, written in my own words with my actual experience.

Thursday, cover letters. Yes, actual cover letters. Not "Dear Sir/Madam, I am writing to express my interest..." Real ones. I'd mention a specific project the company shipped and what I found interesting about it. I'd explain why their tech stack excited me. I'd connect my experience to their specific needs. Each one took about 30-40 minutes to write. It felt painful. It was worth it.

Friday was LinkedIn day and submit day. Before hitting apply, I'd find someone at the company on LinkedIn (usually the hiring manager or a team lead) and send them a short, genuine message. Not "PLEASE HIRE ME" energy. More like "Hey, I saw you're hiring for X role. I just applied, and [specific thing about the company] caught my eye. Would love to chat if you have a few minutes." Then I'd submit the application.

Five applications. The whole week. That's it.

Going from 50 to 5 felt like giving up. Honestly, it felt wrong. Watching my weekly application count drop by 90% was physically uncomfortable. I had to keep reminding myself that 50 applications with a 0% response rate is worse than 5 applications with any response rate above zero.

The results

Here's what happened. I want to be specific because vague "and then everything changed!" stories are useless.

Week 1, 5 applications sent. I got two auto-acknowledgment emails, which was already more than I'd gotten from 200 generic ones. Then one actual response from a recruiter asking to schedule a screening call. I nearly fell out of my chair.

Week 2, another 5. The screening call from Week 1 went well and turned into a technical interview. Got one more response from Week 2's batch, a small startup that liked my cover letter and wanted to chat.

Week 3, last batch of 5. The technical interview from Week 1 went... okay. Not great, not terrible. The startup from Week 2 scheduled a call. Got a third response, this time from a mid-size company. Their recruiter specifically mentioned that my cover letter stood out because I'd referenced a blog post their CTO wrote.

The final score after 3 weeks: 15 total applications (down from 200+ over two months), 3 interview processes, 1 job offer.

Let me repeat that. Fifteen targeted applications got me further than two hundred generic ones. The ratio wasn't even close.

I took the offer from the startup. The founder later told me that what caught his attention was that I'd actually used their product before applying and mentioned specific features in my cover letter. He said most applicants clearly had no idea what the company even did.

Three weeks. 15 applications. 1 offer. That's all it took once I stopped playing the numbers game and started actually trying.

Your quality application checklist

If you're currently in spray-and-pray mode, here's how to make each application count. Steal this list.

Actually read the entire job description. The whole thing. Yes, even the "nice to have" section at the bottom. Understand what they're really looking for, not just the title.
Research the company for at least 20 minutes. Check their website, blog, product, LinkedIn page, recent news. If you can't explain their product to someone in two sentences, you haven't researched enough.
Customize your resume for THIS specific job. Rearrange your bullet points. Change your summary. If they want React experience and you have it buried in the fourth bullet of your second job, move it up.
Mirror the language from the job posting. If they say "cross-functional collaboration," use that phrase (if it actually applies to you). A lot of companies use ATS software that literally scans for keywords. Help the robots help you.
Write a real cover letter. Mention the company by name. Reference something specific about them. Explain why you want to work THERE, not just "somewhere." This alone puts you ahead of 80% of applicants.
Find a real person at the company on LinkedIn. The hiring manager, a team lead, someone on the team you'd be joining. Follow them. Engage with their content if they post any.
Send a short LinkedIn message. Don't be pushy. Don't write a novel. Introduce yourself, mention you applied, and say something specific about why that company interests you. Keep it under 5 sentences.
Check if you know anyone who works there. Second-degree connections, former classmates, people from meetups. A referral is still the single most effective way to get an interview. Ask for an introduction, not a favor.
Prepare before you even apply. If the job requires a skill you're rusty on, spend an hour brushing up. Do a small project, write a blog post about it, push it to GitHub. Now you have something to reference in your application.
Apply during business hours. I'm serious. Applications submitted at 2 AM on a Saturday hit different than ones submitted at 10 AM on a Tuesday. Some ATS systems timestamp applications, and hiring managers see that. Don't be the midnight applicant. I learned this one the hard way.

Quality beats quantity, every single time

Look, I know this advice isn't sexy. "Apply to fewer jobs" doesn't have the same ring as some growth-hack shortcut. There's no Chrome extension that'll do this for you. It's just work, done properly.

The job market IS competitive. I'm not denying that. There ARE more applicants per position than there used to be. All true.

What's also true: most of those applicants are sending the exact same generic resume to 50 companies a day without reading a single job description. When you actually put in the effort, you stand out. Not because you're a genius, but because the bar is on the floor and you're one of the few people bothering to step over it.

Stop mass applying. Start actually applying. Your future employer isn't going to find you in a pile of 500 identical resumes.

If you found this useful, I share more stuff like this on Telegram and sell developer toolkits on Boosty.

If I Had to Rebuild My Developer Career From Zero in 2026, I'd Do This

Daniil Kornilov — Mon, 30 Mar 2026 00:58:03 +0000

If I lost everything career-wise tomorrow and had to rebuild from zero, I would do it very differently than most advice on the internet suggests.

I would not start with a 9-month roadmap.
I would not buy five courses.
I would not obsess over the "perfect stack."
I would definitely not wait until I felt ready.

I would optimize for proof.

That is the whole framework.

Not confidence.
Not credentials.
Not endless preparation.

Proof.

Step 1: Pick One Marketable Direction

Not ten.
One.

Examples:

frontend for product teams
backend for SaaS tools
iOS apps with SwiftUI
internal automation for small businesses

Most people stay stuck because they try to keep every possible path open.

That feels flexible.
It is actually paralyzing.

Specificity creates momentum.

Step 2: Build One Useful Project, Not a Portfolio Graveyard

I would build a single project with a real use case and document it properly.

Not a clone.
Not another todo app.

Something with context:

who it is for
what pain it solves
what tradeoffs I made
what I learned

One real project with clear explanation is worth more than six shallow demos.

Step 3: Learn in Public Just Enough to Be Visible

I would not try to become an influencer.

But I would publish useful artifacts:

short lessons
bug writeups
architecture notes
project updates

Because visibility matters.

Not vanity visibility.
Proof visibility.

The market needs a way to discover that you exist and that you can think.

Writing gives it that.

Step 4: Get Good at Written Communication Early

This is the unfair advantage most beginners ignore.

If you can write:

a sharp README
a clean project case study
a clear bug report
a thoughtful outreach message

you will feel more hireable faster.

Because now your skill is easier to trust.

Step 5: Target Environments Where Proof Beats Pedigree

I would not spend all my energy chasing the most competitive, prestige-heavy path first.

I would target places where visible skill matters:

startups
freelance clients
small product teams
founder-led companies
communities where builders get noticed

Later, if I wanted brand-name companies, I could aim there with stronger proof in hand.

Step 6: Create a Weekly Output System

Not motivation.
Output.

Every week I would aim for:

one build improvement
one public artifact
one outreach action

That means I am always increasing:

skill
proof
surface area for luck

That last one matters more than people admit.

Luck finds active people faster.

Step 7: Stop Measuring Progress by Feeling

This is where many beginners lose months.

They keep asking:

"Do I feel ready?"

Wrong metric.

I would ask:

what did I ship?
what did I publish?
what feedback did I get?
what became easier this month?

Feelings fluctuate.
Evidence is calmer.

Final Thought

If I had to rebuild from zero in 2026, I would not try to look impressive early.

I would try to become undeniable in small, concrete ways.

One project.
One clear direction.
One useful public trail.
One repeatable system.

That is enough to create momentum.

And momentum is what most developer careers are really missing in the beginning.

I write about developer careers, proof-first growth, and building enough visible leverage to stop feeling invisible.

What 'Senior' Actually Looks Like in 2026 (It's Not LeetCode)

Daniil Kornilov — Mon, 30 Mar 2026 00:57:31 +0000

A lot of developers still have a distorted picture of what "senior" means.

They imagine:

perfect system design answers
obscure algorithm knowledge
instant solutions to every technical problem
a brain full of syntax and architecture patterns

Some of that helps.
Very little of it is the core.

If you spend enough time around strong engineers, you notice something else:

Senior developers are not defined by how much they know.

They are defined by how they reduce risk, ambiguity, and waste.

That is a very different skill set.

What Looks Senior in Real Life

Here is what I keep seeing.

1. They do not panic in unclear situations

A junior sees uncertainty and starts guessing.
A senior slows the room down.

They ask:

what do we know?
what changed?
what is the real failure mode?
what is the cheapest safe next step?

That calm structure is worth more than sounding brilliant.

2. They make tradeoffs explicit

Less experienced developers often argue for "the best" solution as if context does not matter.

Senior developers usually sound more like this:

"This is the quickest stable version. This is what we are sacrificing. This is when it becomes worth revisiting."

That is maturity.

3. They protect the team from unnecessary complexity

Juniors often want to prove they can build advanced things.
Seniors often want to avoid advanced things unless the problem demands them.

That is not lack of ambition.
That is taste.

4. They communicate before confusion spreads

They do not wait until a problem becomes political.

They write the summary.
Raise the risk.
Clarify the scope.
Document the decision.

That looks boring.
It is actually leadership.

What Does Not Automatically Make You Senior

This part matters too.

These things can be useful, but they do not equal seniority by themselves:

solving LeetCode hards
memorizing design patterns
knowing more frameworks
talking confidently in meetings
using advanced architecture vocabulary

You can have all of that and still create confusion everywhere you go.

The Fastest Way to Grow Toward Senior

If I had to boil it down, I would focus on five things:

Write smaller, clearer pull requests
Explain tradeoffs in plain language
Get good at debugging without panic
Learn to say "this is enough for now"
Leave systems easier to change than you found them

That is already more senior than a lot of people with the title.

The Hidden Shift

At some point, growth stops being mostly about your own output.

It becomes about what happens around your output.

Do people understand your decisions?
Can they build on your work?
Do you reduce chaos for others?
Do you make the system safer, clearer, calmer?

That is the shift.

From individual contributor energy to system-level responsibility.

Final Thought

Senior is not a vibe.
It is not a salary.
It is not a LinkedIn headline.

It is a pattern:

You make progress clearer.
You make risks more visible.
You make decisions easier.
You make systems less painful to live with.

That is what senior actually looks like.

And no, LeetCode is not the main point.

I write about developer growth, senior-level habits, and practical career moves that matter more than internet mythology.

The Best Engineers I Know Are Not the Fastest. They're the Clearest.

Daniil Kornilov — Mon, 30 Mar 2026 00:56:01 +0000

There is a type of developer everyone quietly trusts.

They are not always the flashiest person on the team.
They are not the fastest typist.
They are not the person posting screenshots of 14-hour coding sessions.

But when something matters, people want them involved.

Why?

Because they are clear.

Clear in how they think.
Clear in how they code.
Clear in how they explain tradeoffs.
Clear in how they reduce chaos around everyone else.

That is a bigger advantage than raw speed.

Speed Is Overrated Without Clarity

Fast developers can create a lot of movement.

But movement is not always progress.

I have seen extremely fast developers:

ship unreadable code
make unclear decisions
leave weak documentation
create fixes nobody understands later

For a while, they look impressive.

Then the maintenance bill arrives.

That is when clarity starts to matter more than velocity.

What Clear Engineers Actually Do

They tend to do a few things consistently:

1. They name things well

Variables. functions. modules. tickets. decisions.

They reduce ambiguity instead of spreading it.

2. They separate signal from noise

They can look at a messy problem and say:

"This is the real issue. The rest is downstream."

That is an elite skill.

3. They explain tradeoffs honestly

Not:

"This is the best solution."

But:

"This is the simplest solution under current constraints. We can revisit if scale changes."

That makes teams trust them.

4. They leave clean traces

Good PR descriptions.
Useful comments.
Readable commits.
Thoughtful postmortems.

They do not just solve problems.
They make future work easier.

Why Teams Reward This So Much

Because unclear engineers are expensive.

Even if they are smart.

Unclear work creates:

slower reviews
weaker onboarding
harder debugging
duplicated effort
fragile systems

Clear work does the opposite.

It lowers the cognitive cost of collaboration.

And in real teams, that is worth a lot.

The Mistake Many Juniors Make

They assume seniority looks like knowing more.

Sometimes it does.

But what often looks senior in practice is this:

asking sharper questions
making simpler decisions
reducing complexity
communicating intent clearly

That is why some people feel senior in a room long before they have the title.

They create clarity under pressure.

How to Build More Clarity

You do not need a personality transplant.

Start with small habits:

write the problem before you solve it
make PRs smaller
explain why, not just what
rename things until they feel obvious
choose simple solutions more often

Clarity is rarely a talent.
It is usually a discipline.

Final Thought

The best engineers I know make hard things feel understandable.

That is their magic.

Not speed.
Not complexity.
Not brilliance that nobody else can follow.

Clarity.

And clarity scales better than hype ever will.

I write about engineering judgment, readable systems, and the quiet habits that make developers easier to trust and harder to ignore.