Deeee

Dev, builder, chaos conjurer. Turning caffeine and code into things that (mostly) work.

[Deeee @still_derin]

The architecture behind it is what makes it reliable. Good frontend is about aesthetics and also about building interfaces that are fast, scalable, accessible, and resilient. What's the biggest misconception you've heard about frontend development?

[Deeee @still_derin]

Myth: Frontend development is just making things look pretty.
Reality: I spend far more time thinking about state management, data flow, API integration, performance, and edge cases than I do picking colors.
The UI is what users see.

[Deeee @still_derin]

Sometimes the best way to measure your progress isn't by starting something new, but by looking at something you built months ago and noticing all the things you'd improve today.

What’s the biggest “I can’t believe I wrote this” moment you’ve had when revisiting old code?

[Deeee @still_derin]

One of the first projects I built was a simple Todo app.
At the time, I was just excited that it worked.
Looking back, there are quite a few things I'd do differently now.

I'd:
Structure the project into reusable components instead of putting too much in one file.

[Deeee @still_derin]

Improve state management to make the code easier to maintain.
Add proper form validation instead of relying on basic checks.
Build a proper backend so tasks persist beyond the browser.
Write cleaner, more readable code with scalability in mind.

[Deeee @still_derin]

5. Ignoring the React warning messages I used to treat warnings like background noise. Turns out, React was usually trying to help me avoid bugs before they happened. Looking back now, these mistakes were part of my learning process.

[Deeee @still_derin]

5 React mistakes I made as a beginner

1. Using array indexes as keys
It works, until your list changes and React starts reusing the wrong components. Stable IDs are almost always the better choice.

[Deeee @still_derin]

4. Using useEffect for things that didn't need it Not everything belongs in an effect. Sometimes the value can be calculated directly during rendering, which keeps the code simpler.

[Deeee @still_derin]

The code still needs to work, of course.
But I've started appreciating that readability is a feature too because eventually, every piece of code becomes someone else's problem. Sometimes that someone is you.

[Deeee @still_derin]

Lately, I've been practicing writing code that is easy to understand a month later.

It's surprisingly easy to write code that works.

It's much harder to write code that someone (including your future self) can quickly read and understand.

[Deeee @still_derin]

Lately, I've been paying more attention to:
- naming things clearly
- reducing unnecessary complexity
- keeping methods focused on one responsibility
- making the intent of the code obvious

[Deeee @still_derin]

But then you look back a few weeks or months and realize problems that once felt difficult now feel routine. That's been a good reminder for me recently. Growth is often easier to see in hindsight than in real time. Just trying to stay consistent and trust the process.

[Deeee @still_derin]

One thing I've been realizing lately is that progress rarely feels like progress when you're in the middle of it.
Most days look ordinary:
fixing bugs
revisiting concepts
refactoring code
building features
figuring out why something isn't working
It doesn't feel like much.

[Deeee @still_derin]

To me, it feels like the industry is quietly drifting away from skill and toward presentation theater so I’ll ask again: Is it proof of work, or proof of formatting that actually gets you hired today?

[Deeee @still_derin]

Question for recruiters/devs:
At what point did we decide that “perfect CVs” mattered more than people who can actually build things?

[Deeee @still_derin]

Meanwhile, the “optimized CV” crowd is out here surviving interviews like it’s a copy-paste tournament. I'm genuinely curious, do we hire builders or do we hire documents? And for devs, if your work doesn’t fit neatly into a PDF, is it even seen?

[Deeee @still_derin]

It's small, but it makes a surprising difference once your code starts growing.
What's a code pattern you find yourself using often?

[Deeee @still_derin]

One pattern I've started appreciating more is early returns.
Instead of:
if (policy != null)
{
if (policy.IsActive)
{
ProcessClaim();
}
}
I prefer:
if (policy == null) return;
if (!policy.IsActive) return;
ProcessClaim();

[Deeee @still_derin]

It's the same result but with less nesting and easier to read.
What I like most is that it makes the "happy path" stand out.
You can quickly see the conditions that stop execution and focus on what the code is actually trying to do.