Esther Israel | Dev

Frontend Dev | React · Next · TypeScript · Tailwind 🛠️ | Building Web3 UIs & responsive web apps | Building in public

[Esther Israel | Dev @thesmarrtDev]

Welcome to @thesmarrtDev.

I am Esther Israel - a frontend developer documenting what I build and learn in public: real projects, real mistakes, real progress.

Here is my thread of threads highlighting everything you need to know about this account and why it exists. 🧵

[Esther Israel | Dev @thesmarrtDev]

in a complex React application is specific to the application.

Generic patterns applied to specific contexts produce generic results that is not useful in that context.

Design decisions are similar. The AI has no understanding of your users, or your existing system.

[Esther Israel | Dev @thesmarrtDev]

AI coding tools are genuinely part of my development workflow. But just like everything else, they sometimes help and other times, they create more problems than they solve.

The useful aspect:
💠 boilerplate generation for repetitive patterns.

[Esther Israel | Dev @thesmarrtDev]

I have learned to generate architectures myself and use AI to pressure-test specific decisions rather than to generate the approach.

💠 Complex state logic is where I stop using AI assistance almost entirely. The interaction between state updates, renders, and side effects

[Esther Israel | Dev @thesmarrtDev]

demand. React is not going anywhere. What you are expected to do with it is expanding.

[Esther Israel | Dev @thesmarrtDev]

Where I see frontend development heading based on job postings, tooling direction, and conversations with developers further along than me.

TypeScript is no longer a differentiator. It is a baseline expectation in most serious frontend roles.

[Esther Israel | Dev @thesmarrtDev]

Web3 frontend is becoming a legitimate specialization.

The developer who can build reliable UIs for smart contract interaction, handle wallet connection, and manage the specific UX challenges of on-chain operations is working in a space with less competition and more specific

[Esther Israel | Dev @thesmarrtDev]

Most bugs are not subtle. Most bugs are the most obvious thing, wearing a disguise of complexity that I put on them myself.

[Esther Israel | Dev @thesmarrtDev]

I once spent 3 hours debugging a layout issue that turned out to be a single missing CSS property.

This is not an uncommon experience.

What matters is the lesson I took from it.

[Esther Israel | Dev @thesmarrtDev]

The debugging rule I've since stuck with: before going deep, go obvious.

Ask "what is the most simple thing that could cause this?" first.

Verify that it is not the answer before moving to more complex explanations.

[Esther Israel | Dev @thesmarrtDev]

The inconvenience of creating a branch is seconds but the inconvenience of a broken main could be a weekend or something much more time consuming.

[Esther Israel | Dev @thesmarrtDev]

I once pushed broken code to main on a client project on a Friday.

I had been working quickly. I had tested locally. I had not caught the environment difference that made the same code fail on the deployment server.

[Esther Israel | Dev @thesmarrtDev]

branch, a test, or a review, even when I am working solo and the review is my own. Especially when I am working solo.

That rule has never been broken since and it has saved me from at least 6 situations where working quickly would have produced the same result as that Friday.

[Esther Israel | Dev @thesmarrtDev]

PR descriptions explaining why you made a decision produce better reviews and better code. I made this a requirement for myself.

The live link is in portfolio on my bio and the code is on GitHub. Read the full case study on Medium (https://t.co/XzBsCK3NPn).

[Esther Israel | Dev @thesmarrtDev]

Loanwise is the project I learn the most from when I look back at it. Not because the code was my best work but because it was my most collaborative work. Team of 10: designers, frontend devs, backend devs, data analysts; all working on the same codebase.

[Esther Israel | Dev @thesmarrtDev]

➡ What team collaboration taught me: component API documentation is not optional - it is the infrastructure that makes multi-developer codebases work.

I wrote prop documentation as part of every component. Soon after, other developers were doing the same.