Forem: Daniel Rusnok

I Thought I Understood Git. Then I Actually Learned the Difference Between Rebase and Merge.

Daniel Rusnok — Wed, 25 Mar 2026 13:27:36 +0000

I used git rebase long before I actually understood what it does.

I picked it up from a senior developer on my first team. The rule was simple: always rebase before you merge, keep the history clean.

I followed it. I typed the commands. I never questioned it.

Then one day I rebased the wrong branch and rewrote a week of shared history. That was the day I finally sat down and learned what I had been doing.

What merge actually does

git merge takes two branches and joins them. It creates a new commit — a merge commit — that has two parents: the tip of your branch and the tip of the branch you're merging into.

# You're on feature/my-feature
git merge main

The result is a non-destructive operation. Nothing is rewritten. Your history grows a new node with two parents, and both lines of development are preserved exactly as they happened.

      A---B---C  feature
     /         \
D---E---F---G---H  main (merge commit)

The upside — it's safe.

The downside — if you merge large feature branches frequently, the commit history can become harder to read.

What rebase actually does

git rebase moves your commits. It takes the commits on your branch and replays them on top of another branch, one by one, as if you had started your work from there.

# You're on feature/my-feature
git rebase main

# Before
      A---B---C  feature
     /
D---E---F---G  main

# After
              A'--B'--C'  feature
             /
D---E---F---G  main

Notice the prime marks — A', B', C' are new commits. Same changes, new hashes. Rebase rewrites history.

The upside — your history looks linear and clean.

The downside — if anyone else has those original commits (A, B, C), their history now diverges from yours. This is what I did wrong.

The golden rule of rebase

Never rebase commits that exist outside your local repository.

If you've pushed a branch and someone else has pulled it, rebasing rewrites commits they already have. Their history diverges. Pulling becomes painful. You'll see duplicate commits, conflicts that make no sense, and a very confused colleague.

The safe version — rebase only your local, unpushed work. Once commits are shared, merge.

# ✅ Safe — rebasing local work before pushing
git rebase main
git push origin feature/my-feature

# ❌ Dangerous — rebasing already-pushed commits
git push origin feature/my-feature  # already done
git rebase main                      # rewrites shared history
git push --force                     # now you've broken everyone else

Interactive rebase

Once you understand what rebase does, git rebase -i becomes one of the most useful tools in Git.

It lets you rewrite your local commit history before you share it — squash messy WIP commits into clean ones, reorder commits, edit commit messages, or split a large commit into smaller ones.

# Rewrite the last 3 commits interactively
git rebase -i HEAD~3

This opens an editor where you choose what to do with each commit:

pick a1b2c3 Add order validation
pick d4e5f6 fix typo
pick g7h8i9 WIP: still debugging

# Change to:
pick a1b2c3 Add order validation
squash d4e5f6 fix typo
drop g7h8i9 WIP: still debugging

The result — one clean commit instead of three messy ones.

This is what "clean history" actually means in practice — not avoiding merge commits, but being intentional about what you leave behind.

When to use which

Use merge when:

Integrating a completed feature branch into main or develop
Working on a shared branch where others have the same commits
You want to preserve the full context of when and how branches diverged
Merging release branches or hotfixes where an audit trail matters

Use rebase when:

Updating your local feature branch with changes from main before pushing
Cleaning up local commit history before opening a PR (with -i)
Keeping a long-lived feature branch up to date with the base branch
Working solo on a branch nobody else has touched

Never rebase:

Commits that have already been pushed and shared
main, develop, or any branch others are working from

The workflow that actually works

In practice, most teams land somewhere between "always merge" and "always rebase." Here's a workflow that's served me well:

Work locally on a feature branch
Before opening a PR, git rebase -i to clean up commits
git rebase main to update your branch with latest changes
Push and open the PR
Merge the PR into main (with a merge commit or squash merge — team's call)

This gives you a clean PR history while preserving the merge commit that marks when a feature landed in main. Best of both approaches.

What I wish I had understood earlier

Rebase and merge aren't competing philosophies. They're different tools for different moments in a workflow.

Merge preserves history. Rebase rewrites it. Both are useful — but rewriting shared history is always a mistake.

I learned that the hard way. The senior developer who taught me to "always rebase" wasn't wrong — he just assumed I understood what rebase does. I didn't. I copied the command without understanding the consequence.

Now I understand both. And I still rebase — just never the wrong branch.

How does your team handle this? Do you have a strict rebase-only policy, or do you let developers decide? I'm curious whether the "clean history" argument is still winning in 2026. 👇

I Spent 3 Months Building a Game Nobody Understood. Here's What I Learned.

Daniel Rusnok — Wed, 18 Mar 2026 16:08:45 +0000

98 views. 40 plays. 1 comment — and that one was mine.

That was the result of three months of work. Evenings, weekends, and a few sleepless nights. And the hardest part wasn't the numbers. It was the feedback that came with them: "Interesting, but I'm not sure what it is."

What I Actually Built

Sappy was an emotional survival game — at least, that's what I told myself it was. The player controlled a small jester-like character moving through an open world, collecting orbs, and surviving.

But Sappy wasn't just a jester. He had emotions. Real ones. When he was angry, his head turned red. Fear made him purple. Joy lit him up yellow. Sadness washed him in blue.

Every single one of those states had its own hand-drawn sprites. I drew everything in Procreate — 4 animations, 4 directions each, across 4 emotional variants. That's a lot of sprites for one character. And I wasn't done.

The environment had emotions too. Every tile, every tree, every background element existed in two versions: a Sad version and a Happy version. The world itself was supposed to breathe with Sappy's emotional state.

I wanted to give the game a story. But it was an open-world map with survival mechanics. How do you give a narrative to something deliberately open? And if I added a story, did the survival mechanics still make sense? The more I thought about it, the less I knew what Sappy actually was.

I kept building anyway.

If you're a developer navigating that strange intersection of code and creativity, I write a newsletter on Substack about exactly that — the solo dev journey, the mistakes, and what I'm figuring out along the way. You can find it at danielrusnok.substack.com.

The Feedback That Broke the Illusion

I shipped Sappy to itch.io. I reached out to gamedev communities and asked people to try it.

The numbers were brutal. But numbers I could have accepted. What I couldn't shake was what people actually said.

Nobody said the game was bad. They said they didn't know what it was.

"Interesting, but I don't understand the goal." "Cool character, but where's the onboarding?" "What kind of game is this supposed to be?"

These aren't the same as "this needs work." They're something worse. They mean the game had no identity — and no amount of polishing would fix that.

The Problem Wasn't the Work. It Was the Foundation.

I'd been asking the wrong question the whole time.

Instead of "How do I build this better?" I should have been asking "What is this, exactly?"

Was Sappy an emotional survival game for adults? Then why was there a cheerful jester collecting orbs? Was it a children's game? Then why the abstract open-world mechanic with no clear goal? Was it a narrative game? Then the entire structure — open world, survival loop — was fighting the story rather than carrying it.

I'd built hundreds of hand-drawn sprites. I'd coded the emotional state system. I'd designed a whole world with dual versions of every asset. And underneath all of it was a question I'd never answered: What is this game for? Who is it for?

Three months of evenings and sleepless nights — and I'd built something technically impressive that nobody, including me, could explain.

The Five-Minute Scene That Changed Everything

A few weeks after Sappy's launch, I wanted to play something that would actually move me. I asked ChatGPT to recommend a game — something emotionally driven, something I hadn't heard of.

It suggested Planet of Lana.

I didn't know it. I loaded it up.

Within five minutes, two sisters are screaming at each other. No tutorial. No exposition dump. Just two characters, a relationship, and immediate emotional stakes.

I paused the game and sat with that for a moment.

This. This is what I want to make.

Not survival loops. Not open worlds. A story you feel before you understand it. Two characters whose relationship is the mechanic.

Starting Over (But Not From Zero)

I didn't throw away Sappy. I finally understood what he was missing.

The emotional state system — the red anger, the purple fear, the yellow joy, the blue sadness — that was real. That was worth keeping. But Sappy needed a world that made those emotions matter. He needed someone to have those emotions with.

I started thinking about companionship. About what it means to navigate emotions not alone, but in relationship. I'd wanted to add a companion to Sappy from the beginning — I just hadn't known why. Now I did.

I thought about who those two characters could be. And I found them in my own life: the person I was before I became a father, and the small person who changed me. A solo dev dad and the little girl who taught him to feel things he'd spent years ignoring.

That's where Eli and Uri came from. You can follow the journey at echoeswithingames.com.

A side-scrolling 2D game. Two characters. One emotional journey. A story that only I can tell — because it's mine.

What Three Months of "Wasted" Work Actually Taught Me

I didn't waste those three months. I just didn't know what I was learning yet.

I learned that technical execution without creative clarity is a trap. You can draw hundreds of sprites and still not have a game. I learned that feedback saying "I don't know what this is" is the most important feedback you'll ever get — and the most painful to hear. And I learned that the question "What is this game, exactly?" has to be answered before anything else.

Sappy taught me what I wanted to make. Sometimes that's worth three months and a hundred sleepless hours.

If you're in the middle of a project that feels unclear — not broken, just undefined — stop building for a moment. Ask yourself the question I avoided for too long: What is this, exactly? And who is it for?

You might not like the answer. But you'll build something better because of it.

Are you a solo dev navigating the same questions? I'd love to hear about it in the comments.

I've Been Slowing Down React for 3 Years. Here's What My Code Review Revealed.

Daniel Rusnok — Tue, 17 Mar 2026 07:32:56 +0000

I've been writing React for three years. I thought I understood memoization. Then a colleague reviewed my PR and pointed something out: I was wrapping almost every computed variable in useMemo.

Not because I had profiled anything. Not because there was a performance problem. Just because — why not? It felt responsible. He was polite about it. But the message was clear: I was making React do more work, not less.

That conversation sent me down a rabbit hole I should have gone down years ago. Here's what I found.

The cost of memoization

The idea behind useMemo is simple: cache the result of an expensive computation so React doesn't have to redo it on every render.

const sortedList = useMemo(() => {
  return items.sort((a, b) => a.name.localeCompare(b.name));
}, [items]);

Instead of sorting on every render, React stores the result and only recalculates when items changes. Sounds like a no-brainer, right?

Here's the part I was ignoring: useMemo itself has a cost. React stores the cached value, compares dependencies on every render, and manages the cache lifecycle.

For simple computations — overkill.

// This is almost certainly not worth memoizing
const fullName = useMemo(() => {
  return `${user.firstName} ${user.lastName}`;
}, [user.firstName, user.lastName]);

// Just do this
const fullName = `${user.firstName} ${user.lastName}`;

String concatenation is done in microseconds. The memoization wrapper costs more than the computation. I had dozens of these in my codebase. And the worst part? I was proud of them. I thought I was being thorough.

Have a reason for useMemo

Don't reach for useMemo until you have a reason. A reason is either a measurable performance problem, or a referential stability requirement.

Case 1: Expensive computation

If the calculation is genuinely costly — filtering a large dataset, running a complex algorithm, processing a lot of data — memoization makes sense. The key word is measurable. If you haven't profiled it, you don't know it's expensive.

const filteredProducts = useMemo(() => {
  return products
    .filter(p => p.category === selectedCategory)
    .filter(p => p.price >= minPrice && p.price <= maxPrice)
    .sort((a, b) => b.rating - a.rating);
}, [products, selectedCategory, minPrice, maxPrice]);

Case 2: Referential stability

This is the one most developers miss — and it's where useMemo is actually most valuable.

In JavaScript, [] !== [] and {} !== {}. Two arrays or objects with identical contents are not the same reference. This matters because React's dependency comparison is based on reference equality.

// Without useMemo - new object reference on every render
// This will cause child components and useEffect to fire even if nothing changed
const config = { threshold: 0.5, maxItems: 100 };

// With useMemo - stable reference, child only re-renders when values actually change
const config = useMemo(() => ({
  threshold: 0.5,
  maxItems: 100
}), []);

If you're passing an object or array as a prop to a memoized child component, or as a dependency to useEffect, you almost certainly need useMemo to maintain referential stability — not to save computation time.

This was the one I genuinely didn't know. I'd been using useMemo for the wrong reason — saving computation — and accidentally getting the right result sometimes. When I understood referential stability, a lot of confusing bugs from the past suddenly made sense.

Don't interchange it with React.memo

React.memo wraps a component, not a value. It tells React: only re-render this component if its props have changed.

const UserCard = React.memo(({ user, onSelect }) => {
  return (
    <div onClick={() => onSelect(user.id)}>
      {user.name}
    </div>
  );
});

Without React.memo, UserCard re-renders every time its parent re-renders — even if user and onSelect haven't changed. With it, React compares props before deciding whether to re-render.

But here's the catch: React.memo uses shallow comparison. If you pass a new object or function reference on every render — which happens by default — the memoization is useless.

// This breaks React.memo - new function reference on every parent render
<UserCard
  user={user}
  onSelect={(id) => handleSelect(id)}
/>

// This works - stable reference via useCallback
const handleSelectUser = useCallback((id) => handleSelect(id), []);
<UserCard
  user={user}
  onSelect={handleSelectUser}
/>

This is why useMemo, React.memo, and useCallback tend to appear together. They're solving the same underlying problem: preventing unnecessary work caused by reference instability.

useCallback is useMemo for functions

useCallback is essentially useMemo for functions. It memoizes a function reference so it stays stable across renders.

// Without useCallback - new function on every render
const handleSubmit = (values) => {
  submitForm(values);
};

// With useCallback - same reference unless dependencies change
const handleSubmit = useCallback((values) => {
  submitForm(values);
}, [submitForm]);

The main use case: passing callbacks to memoized child components or including them as useEffect dependencies. Without useCallback, you'll break React.memo optimization or trigger infinite useEffect loops.

// Classic infinite loop - handleFetch is a new reference on every render
useEffect(() => {
  handleFetch();
}, [handleFetch]);

// Fixed with useCallback
const handleFetch = useCallback(() => {
  fetchData(userId);
}, [userId]);

useEffect(() => {
  handleFetch();
}, [handleFetch]);

One rule of thumb: if you're writing useCallback on a function that never gets passed anywhere as a prop or dependency, you probably don't need it.

Profile before you optimize

Before reaching for any of these tools, you need to know whether you have a problem. Guessing is how I ended up with memoization everywhere and performance that wasn't actually better.

React DevTools Profiler is the right starting point. Record a user interaction, and it shows you exactly which components re-rendered, why, and how long they took. Look for components that render frequently with no visible reason.

A few patterns that indicate real problems:

A component re-renders on every keystroke in a parent input, even though it doesn't use the input value
A list re-renders all items when only one changes
useEffect fires more often than expected

If you don't see these patterns — or if the render time is under a few milliseconds — memoization probably won't help. The cost of the abstraction outweighs the benefit.

Common mistakes that break memoization silently

Even when you reach for these tools correctly, it's easy to misconfigure them and get none of the benefit.

Inline objects in JSX

// Breaks memoization - new object every render
<Chart options={{ color: 'blue', width: 300 }} />

// Fixed
const chartOptions = useMemo(() => ({ color: 'blue', width: 300 }), []);
<Chart options={chartOptions} />

Missing or incorrect dependencies

// Stale closure bug - reads outdated userId
const fetchUser = useCallback(() => {
  api.get(`/users/${userId}`);
}, []); // userId missing from deps

// Correct
const fetchUser = useCallback(() => {
  api.get(`/users/${userId}`);
}, [userId]);

Memoizing too high up

Wrapping an entire page component in React.memo rarely helps — its props almost always change. Memoization is most effective on leaf components that receive stable props and render often.

Decision framework

For useMemo — Is this computation expensive, or does reference stability matter? If neither — skip it.

For React.memo — Does this component render often? Are its props actually stable? If props change frequently anyway, it adds cost without benefit.

For useCallback — Is this function passed as a prop to a memoized component? Is it a dependency in useEffect? If neither — skip it.

Conclusion

The instinct to wrap everything in useMemo came from a good place: I wanted to write performant code. But premature optimization isn't just a waste of time in React — it actively adds complexity: more dependencies to track, more places for stale closure bugs to hide, more cognitive overhead for anyone reading the code later.

After that review, I went through the codebase and removed about 80% of the useMemo calls I'd written. The app didn't slow down. The code got easier to read. That stung a little.

My colleague's comment was a favor. I just didn't appreciate it until I understood why he was right.

I'm a .NET and React developer sharing what I actually run into building apps at work. This article was originally published on Medium.

I Thought Code Comments Were Anti-Patterns. Then AI Changed My Mind.

Daniel Rusnok — Sun, 15 Mar 2026 16:37:28 +0000

A year ago, I took over a codebase I didn't write. It was vibe-coded — you could tell. Logic scattered across files, inconsistent naming, and comments. Everywhere.

Above every method, inside every loop, explaining things the code was supposedly already saying.

I rolled my eyes and started deleting them.

Fast forward to today. I pair program with AI almost daily and I wonder — should AI-generated comments help me understand quickly generated code, or do they help the AI too?

Comments as anti-pattern

Robert C. Martin was clear about it in Clean Code — a comment is a failure. If your code needs a comment to be understood, you didn't write it clearly enough.

The goal is self-documenting code — names so expressive, structure so clean, that the intent is obvious without explanation.

It's a principle that shaped a generation of developers. And for good reason. We've all seen the damage bad comments do:

// increment i by 1
i++;

// get user
var user = GetUser(id);

These comments add noise, not signal. Worse, they rot. Code gets refactored, comments don't. Now you have documentation that actively misleads anyone reading it — including the AI tools that consume it.

The traditional argument holds. Most comments are bad comments.

Comments, comments everywhere

The project had been built fast, by someone leaning heavily on AI generation. The comments weren't thoughtful — they were everywhere, auto-generated, verbose. Things like:

// This method processes the order and saves it to the database
public async Task ProcessOrderAsync(Order order)
{
    // Validate the order first
    await ValidateAsync(order);
    // Save to database
    await _repository.SaveAsync(order);
    // Publish event to notify other services
    await _eventBus.PublishAsync(new OrderProcessedEvent(order.Id));
}

My instinct was — most of this is noise. The method name already says ProcessOrderAsync. The variable names already tell you what's happening. The comments are just... the code, again, in English.

I cleaned them up. And I felt good about it.

Contextual comments make sense

I use Claude daily now. And at some point I caught myself wondering: does AI actually perform better in a well-commented file? Not just more pleasant to work with — but measurably better suggestions?

I started paying closer attention. Here's a concrete example that kept coming up. Two versions of the same method signature:

// Version A - no comments
public async Task<Result> HandleAsync(CreateOrderCommand command)

// Version B - one intent comment
// Validates business rules before persisting. Does NOT publish events —
// caller is responsible for dispatching domain events after success.
public async Task<Result> HandleAsync(CreateOrderCommand command)

When I ask AI to add error handling to Version B, it respects the constraint. It doesn't add event dispatching inside the method. With Version A, it sometimes does — because it doesn't know the rule.

That comment isn't explaining what the code does. It's explaining why it's structured the way it is, and what it deliberately doesn't do. That's information that can't live in a method name.

So who are comments actually for now?

When Uncle Bob wrote Clean Code, the only reader of your comments was a human developer. The argument was: if you need a comment, you failed to communicate through code. Write better code instead.

But today, your code has a second reader: the AI tools.

You work with AI every day. And AI doesn't read code the way humans do. It reads context. It looks for signals about intent, constraints, and decisions that aren't visible in syntax.

A well-placed comment isn't noise to an AI pair programmer — it's context it can actually use.

Research backs this up from two directions. A 2024 study published at ACL, Code Needs Comments: Enhancing Code LLMs with Comment Augmentation, found that LLMs trained and tested on commented code consistently outperformed those working with uncommented code. And a 2025 code review study tested GPT-4o and Gemini with and without contextual descriptions alongside code — the presence of context measurably changed the quality of the AI's output.

What vs. why

After a year of this, my working rule has shifted — not reversed.

Bad comments explain what the code does. The code already does that. Good comments explain why it does it that way, what constraints it's operating under, and what it deliberately avoids.

// BAD - explains what, code already shows this
// Loop through orders and calculate total
foreach (var order in orders)
{
    total += order.Amount;
}

// GOOD - explains why, code can't show this
// We intentionally skip cancelled orders here.
// Cancelled amounts are handled separately in the reconciliation report
// to avoid double-counting with the refund pipeline.
foreach (var order in orders.Where(o => o.Status != OrderStatus.Cancelled))
{
    total += order.Amount;
}

The second comment survives refactoring. It carries information that no amount of clean naming can convey. And it gives your AI pair programmer the context it needs to not introduce a bug the next time it touches that loop.

Conclusion

I still think most comments are anti-patterns. I still delete the ones that just narrate what the code does. I still believe that if you need three sentences to explain a method, the method probably needs to be broken up.

But I've stopped treating all comments as a failure. Some comments are the only place to record a decision — a constraint that emerged from a bug, a rule from the business, a reason why the "obvious" refactor would break something in production.

Those comments aren't admissions of defeat. They're institutional memory.

And in an era where I'm handing chunks of my codebase to an AI and asking it to extend them, that memory matters more than it used to.

The vibe-coded project I inherited? Still full of bad comments. But somewhere in that noise, there were a few that made the work easier. I wish I'd been more careful about which ones I deleted.

Do you write comments for the AI, for your future self, or are they still mostly noise in your codebase? I'm genuinely curious where other developers have landed on this.

AI Is Quietly Erasing the Line Between Frontend and Backend Developers

Daniel Rusnok — Wed, 11 Mar 2026 20:04:43 +0000

Three months ago I switched from PC to a Mac. Last week I needed to start six projects at once — multiple frontend apps, a backend — and doing it manually in the terminal every single time was killing my flow.

So I turned to Cursor:

Write me a shell script that starts everything with one command.

It worked. I didn't know the syntax. I didn't know the Mac conventions. I wouldn't have been able to write it alone. But in few minutes I had a tool that saved me tens of minutes every single day — built in an environment I barely knew.

That moment made me think about something I'd been noticing across my team.

The walls getting thinner

A backend developer on my team needed analytics dashboards. In the past, that meant writing a ticket, waiting for a frontend developer to pick it up, reviewing it, iterating.

Instead, he spent a day with AI and shipped the dashboards himself. They weren't pixel-perfect. But they worked, they were accurate, and they unblocked the team immediately.

A frontend developer needed a new property saved to the database. New endpoint, new field, migration. Normally a backend task. He knew the codebase well enough to understand the pattern — and AI helped him fill in the parts he didn't know. He didn't need to wait for anyone.

And me, a .NET developer writing shell scripts on a Mac.

None of us crossed into the other role's territory because we suddenly became experts. We crossed because AI lowered the barrier enough that our existing context — knowing the codebase, understanding the goal, recognizing what good looks like — was sufficient to get the job done.

Genuinely exciting and a little dangerous

The exciting part is obvious. Teams move faster. Individuals are less blocked. You don't need to interrupt a specialist for every small thing outside your primary domain. The cost of "I'll just do it myself" has dropped dramatically.

But here's what worries me.

When a frontend developer adds a backend endpoint, he's working in territory where he doesn't have the full mental map. He doesn't know which invariants the data model is protecting or which edge cases the original author thought through. Just happy path.

The specialist would have caught the other paths.

Is the specialist's job harder?

This is the part I think gets lost in the excitement about AI breaking down role barriers.

When AI enables everyone to touch everything, the specialist — the person who actually owns a domain — needs to be more vigilant, not less.

More code is being written in your domain by people who don't fully understand it.
More PRs are landing with logic that looks right but carries hidden assumptions.
More edge cases are being handled confidently by someone who didn't know there was an edge case.

You're no longer only reviewing what your colleagues write. You're reviewing what their AI wrote for them in your territory.

That's a different kind of review. Before, when a colleague added a backend endpoint, I could assume they'd at least seen the pattern before.

Now I'm reviewing code written by someone who asked AI to fill in the parts they didn't know — and AI confidently filled them in.

Now I have to think about those things explicitly, and I think that's harder than it sounds.

Where this leaves us

AI is genuinely changing what individual developers can do.

I'm not going back to manually starting projects in six terminal tabs.
My backend colleague isn't going to stop building his own dashboards when he needs them.
The productivity gains are real.

But. Codebase isn't just a collection of working features. It's a system with assumptions, constraints, and accumulated decisions — and someone has to hold that knowledge. AI doesn't hold it. The person who wrote the ticket doesn't hold it. The specialist holds it.

The barrier to contributing outside your role has dropped. The responsibility of owning your domain hasn't.

If anything, it's grown.

Are you seeing this in your team — people crossing role boundaries more often with AI? And how are you handling code review when AI is doing the crossing? Do you think the specialist has more work with code reviews?

3 TypeScript Features That Make C# Developers Jealous

Daniel Rusnok — Mon, 09 Mar 2026 16:28:41 +0000

If you're coming from C#, these three TypeScript features will change how you think about types.

Three years ago I was writing CQRS handlers in .NET. Today I'm building React components. TypeScript felt familiar — and then it felt weird.

My first weeks on the frontend were humbling. A senior developer told me to stop using let and always use const — something about immutability that felt obvious to him and completely foreign to me. I was also regularly reminded that we had TypeScript and I kept writing plain JavaScript anyway. Old habits.

But once I stopped fighting the ecosystem and started learning its rules, I found features I genuinely wish C# had. Here are three of them.

Union Types with Literal Values

In C#, when you need a property with a fixed set of string values, you reach for an enum. It works — but a string and an enum are two different things, and you're always mapping between them.

// Doesn't work — string and enum are different types
if (request.Status == OrderStatus.Pending)

// You need explicit conversion
if (Enum.Parse<OrderStatus>(request.Status) == OrderStatus.Pending)

// Modern .NET helps with automatic conversion via attribute,
// but you still define the enum separately and add the plumbing:
[JsonConverter(typeof(JsonStringEnumConverter))]
public enum OrderStatus { Pending, Processing, Completed }

In TypeScript, a string literal is the type. No conversion, no attribute:

type OrderStatus = 'pending' | 'processing' | 'completed';
if (status === 'pending') { ... }

I first reached for this with a Button component variant prop — 'primary' | 'secondary'. No separate file, no mapping. The type is the documentation, and the compiler enforces it immediately.

Structural Typing

In C#, a type is what it declares itself to be. If a method expects IAnimal, the object must explicitly implement IAnimal. The compiler checks names, not "shapes".

TypeScript works the opposite way. If your object has the right properties, it is the right type — whether it says so or not:

interface User {
  id: number;
  name: string;
}

function greet(user: User) {
  console.log(`Hello, ${user.name}`);
}

const person = { id: 1, name: 'Daniel', age: 30 };
greet(person);

My first instinct was to fight it. I added as User everywhere, or used satisfies User just so I could see the type and navigate the codebase by type references. Later, I got used to it and stopped adding types explicitly. The IDE watches type mismatches for me in real time.

Utility Types

C# developers are used to writing new types when they need a variation of an existing one. A DTO with fewer fields? New class. An update model with all optional fields? New class. A read-only projection? New class.

TypeScript ships with a set of utility types that transform existing types instead:

interface ComponentProps {
  id: number;
  title: string;
  description: string;
  onSave: () => void;
  onDelete: () => void;
}

// Sub-component only needs part of the props
type HeaderProps = Pick<ComponentProps, 'id' | 'title'>;

// Update form - everything optional
type UpdateProps = Partial<ComponentProps>;

// Remove internal handlers from public API
type PublicProps = Omit<ComponentProps, 'onDelete'>;

My favorite is Pick, and I use it exactly like this in production. When a parent component has a large props interface, sub-components shouldn't receive everything — they work with a slice. Pick lets you define that slice without creating a new type from scratch or reaching for inheritance.

In C#, you'd either duplicate properties in a new class, use inheritance (which often brings unwanted baggage), or reach for libraries like AutoMapper to handle projections. TypeScript just gives you the tools.

Bonus — "as const"

In C#, you'd use readonly or const to prevent mutation. TypeScript has something more powerful: as const freezes not just the value, but the type itself.

Without as const:

const directions = ['north', 'south', 'east', 'west'];
// TypeScript infers: string[]

With as const:

const directions = ['north', 'south', 'east', 'west'] as const;
// TypeScript infers: readonly ['north', 'south', 'east', 'west']

Now directions isn't just an array of strings — it's a tuple of exactly those four literal values. You can even derive a type from it:

type Direction = typeof directions[number];
// 'north' | 'south' | 'east' | 'west'

No separate type definition. No enum. The array is the source of truth, and the type follows automatically.

Conclusion

Union types, structural typing, and utility types aren't just syntax sugar. They represent a different philosophy: types should describe your data, not govern your class hierarchy.

Coming from C#, that shift takes time. But once it clicks, you start wishing the CLR worked the same way.

If you're a .NET developer exploring TypeScript, what feature surprised you most? Let me know in the comments.

From .NET Architect to Frontend Developer — 3 Years on the Other Side

Daniel Rusnok — Mon, 31 Mar 2025 04:54:49 +0000

You might remember me from the days when I wrote about CQRS, DDD, and .NET.

Three years ago, I burned out at my previous job and looked for new opportunities. A change of company led to an unexpected opening on the frontend team.

I took the chance — and over time, transitioned from full-stack to fully frontend. My entire focus shifted.

Why the sudden change?

I always wanted to build things that are more visible.

My creativity was getting thirstier, and backend work started to feel repetitive.

In backend, I satisfied that creativity through architecture — designing service layers, models, and systems.

Now, it’s about layout, animations, and UX collaboration.

How do I feel about React?

React clicked immediately. I love the component-based approach.

Finding the sweet spot between generic reusability and the Single Responsibility Principle is what drives me most.

What surprised me about frontend?

Progress

Last time I touched frontend was 10 years ago — basic HTML, CSS, and jQuery.

Now I work on full apps, and I’m amazed how far the frontend has come. With React, TypeScript, Node.js, and Styled Components — it’s a whole different world.

Tooling

The tooling got so much better. Prettier and ESLint help keep things clean.

VS Code is lightweight and fast compared to classic Visual Studio — which improved, but still feels slow to me.

Bundle Size Awareness

On backend, I could bring in any NuGet package without worrying about size.

In frontend, you really think twice before adding dependencies. We write a lot more ourselves to keep things lean.

What do I miss from backend?

Clean Compiler Errors

Could be just our internal setup, but debugging errors on frontend feels clunky.

VS gave me one-click navigation and clearer feedback.

Unit Testing

Yes, Jest is there. But testing React components isn’t exactly joyful.

In design systems and libraries, sure. But in most day-to-day UI work? Meh.

We have QA engineers with Playwright doing automated testing — so I rarely miss it.

Third-party Libraries

Every lib must have a solid community and minimal bundle size.

You don’t just grab the first one — you evaluate first.

What I Had to Unlearn

OOP Principles

I barely use classic OOP. Inheritance happens only in TypeScript interfaces and models.

Encapsulation? Only if the component lives in a single file.

Polymorphism? Maybe when passing children into a React component and letting it take various forms.

Monolithic Thinking

No more thinking in big blocks (modules, layers, orchestration).

Frontend taught me to think smaller — tiny components that fit like Lego.

Abstraction

In backend, I’d sometimes spend hours building the perfect abstraction.

On frontend, I rarely feel the need — or the space — for that.

Closing

I’ve missed writing — and this post is my way back.

I’d love to keep writing from the perspective of someone bridging backend and frontend — or a backend dev trying to do frontend well.

Thanks for reading! If you’ve gone through something similar, I’d love to hear your experience.
"

Deep Dive into the Single Responsibility Principle

Daniel Rusnok — Sun, 24 May 2020 15:29:07 +0000

Clean code is a software development discipline which aims to raise IT company’s vitality by introducing practises, principles and patterns to improve developer’s programming skills. Programmer’s who follows Clean Code becomes professionals and leaders in their fields.

Deep Dive into the Single Responsibility Principle - Daniel Rusnok - Medium

Daniel Rusnok ・ May 24, 2020 ・ 7 min read
Medium

Four Reasons to Change your software

Daniel Rusnok — Sun, 17 May 2020 16:32:35 +0000

https://medium.com/@danielrusnok/four-reason-to-change-your-software-bf535916152d?sk=0dde468e6012d96c21bbd6700e23a66b

How to manage states with State Design Pattern in C#?

Daniel Rusnok — Thu, 07 May 2020 06:23:16 +0000

https://link.medium.com/kfVfedrPh6

How to use the Decorator Pattern in modern .NET applications?

Daniel Rusnok — Tue, 28 Apr 2020 03:43:58 +0000

https://medium.com/@7467f0f889eb/b5c74a1b8ee?sk=

“Ugly dependency graph? The Mediator Design Pattern is the solution for you.

Daniel Rusnok — Sun, 19 Apr 2020 16:41:52 +0000

https://link.medium.com/wMTFYs3FO5

Forem: Daniel Rusnok

I Thought I Understood Git. Then I Actually Learned the Difference Between Rebase and Merge.

What merge actually does

What rebase actually does

The golden rule of rebase

Interactive rebase

When to use which

Use merge when:

Use rebase when:

Never rebase:

The workflow that actually works

What I wish I had understood earlier

I Spent 3 Months Building a Game Nobody Understood. Here's What I Learned.

What I Actually Built

The Feedback That Broke the Illusion

The Problem Wasn't the Work. It Was the Foundation.

The Five-Minute Scene That Changed Everything

Starting Over (But Not From Zero)

What Three Months of "Wasted" Work Actually Taught Me

I've Been Slowing Down React for 3 Years. Here's What My Code Review Revealed.

The cost of memoization

Have a reason for useMemo

Case 1: Expensive computation

Case 2: Referential stability

Don't interchange it with React.memo

useCallback is useMemo for functions

Profile before you optimize

Common mistakes that break memoization silently

Decision framework

Conclusion

I Thought Code Comments Were Anti-Patterns. Then AI Changed My Mind.

Comments as anti-pattern

Comments, comments everywhere

Contextual comments make sense

So who are comments actually for now?

What vs. why

Conclusion

Further reading

AI Is Quietly Erasing the Line Between Frontend and Backend Developers

The walls getting thinner

Genuinely exciting and a little dangerous

Is the specialist's job harder?

Where this leaves us

Further reading

3 TypeScript Features That Make C# Developers Jealous

Union Types with Literal Values

Structural Typing

Utility Types

Bonus — "as const"

Conclusion

From .NET Architect to Frontend Developer — 3 Years on the Other Side

Why the sudden change?

How do I feel about React?

What surprised me about frontend?

Progress

Tooling

Bundle Size Awareness

What do I miss from backend?

Clean Compiler Errors

Unit Testing

Third-party Libraries

What I Had to Unlearn

OOP Principles

Monolithic Thinking

Abstraction

Closing

Deep Dive into the Single Responsibility Principle

Deep Dive into the Single Responsibility Principle - Daniel Rusnok - Medium

Daniel Rusnok ・ May 24, 2020 ・ 7 min read Medium

Four Reasons to Change your software

How to manage states with State Design Pattern in C#?

How to use the Decorator Pattern in modern .NET applications?

“Ugly dependency graph? The Mediator Design Pattern is the solution for you.

Daniel Rusnok ・ May 24, 2020 ・ 7 min read
Medium