Tips For Coding Modern

On actual productivity while writing software today

I wrote a few thousand lines of JavaScript last month and spent about three weeks debugging something that turned out to be a stale cache in Vite. That's the reality of modern development more often than not. The tools have gotten faster but also more layered, and every layer has its own failure modes. Here's what I've learned that actually moves the needle. TypeScript isn't optional anymore. I know people who swear they can code without it and stay productive, but I've worked with enough projects that started as quick prototypes and grew into systems nobody understood to know better. The initial typing overhead is real, maybe twenty percent slower on the first pass. But the later you catch a type error, the more expensive it is to fix. A mis-typed prop name caught at build time costs you seconds. The same bug in production costs hours of confused debugging. I'd rather pay the typing tax upfront.

Essential Tips For Coding Modern Development

React still dominates the frontend space, and the shift to Server Components changed how I think about data fetching more than anything in recent years. Before RSC, the pattern was pretty much fetch in useEffect and deal with the loading states. Now you declare data dependencies at the component level and let the framework handle it. It feels cleaner until you hit a case where a client-side interaction needs data that wasn't fetched on the server. Then you spend twenty minutes reading documentation about using use() and trying to understand why your server component is trying to render on the client. It happens. Monorepos with Turborepo or pnpm workspaces saved me on a project last year. We had eight packages that needed to share types and utilities. Without a monorepo setup, every change meant publishing a new version, updating the consumer, and hoping the registry didn't serve a stale build. With a workspace, we could iterate on all packages simultaneously. The tradeoff is tooling complexity and a slightly heavier CI pipeline. Our build times went from about four minutes to maybe six, but the developer experience improvement was worth it. I'd say it cuts integration debugging time by roughly half. Testing strategy matters more than most people admit. The testing pyramid is mostly a myth in practice. Most teams end up with a thin slice of unit tests, some integration tests that mostly verify happy paths, and a whole lot of untested code. What actually works for me is focusing on contract tests for your public APIs and critical user flows. End-to-end tests with Playwright for the things that actually move money or trigger user-facing actions. Everything else gets lighter coverage. I stopped writing unit tests for pure utility functions two years ago and it hasn't caused a single production incident.

One thing nobody warns you about: lockfiles. When you're migrating a project to a newer Node version or switching package managers, the lockfile is the single most important file in your repo. I once had a colleague accidentally overwrite a pnpm-lock.yaml with a yarn.lock and spent six hours reconciling dependency trees. The issue was subtle because everything installed without errors. The runtime behavior was just different. Always check your lockfile format before merging dependency updates from different branches. CSS architecture is another minefield. Tailwind is everywhere now and there's a reason. The traditional CSS-in-JS approach I used for years had real performance problems at scale. Runtime style injection in the browser adds up. But Tailwind's arbitrary values syntax can become unmaintainable if you're not disciplined. I've seen projects where utility class names became paragraphs long and unreadable. The workaround is extracting repeated combinations into component-level classes or using @apply sparingly. Not much, just for genuinely repeated patterns. Here's a counter-intuitive point: sometimes the newest framework isn't the right choice. We evaluated SvelteKit for a dashboard project last year and it was genuinely faster to develop in. But the team was more familiar with React, and the ecosystem of components we needed was better supported there. Switching frameworks mid-project has costs that aren't obvious. Documentation familiarity, hiring pipeline, and library compatibility all matter more than raw performance benchmarks. I'd pick the boring option for internal tools every time.

On the backend, the shift toward serverless and edge functions is real but it's not free. Cold starts are less of an issue now with modern runtimes, but you pay for it in observability. Debugging a request that's been split across four different serverless functions with shared state is considerably harder than debugging a traditional monolith. I recommend keeping shared business logic in a single deployable unit unless you have a compelling reason to split it. Performance claims sound good until you need to trace a single user request across three cloud regions. Database connection pooling is one of those things that sounds obvious but people mess up constantly. I saw a Next.js API route that opened a fresh Prisma connection per request without proper pooling because the developer assumed the framework handled it. Under load, the database ran out of connections within minutes. The fix was setting proper pool sizes in the connection string and making sure the client was instantiated once and reused. This kind of issue only shows up under real traffic, not in local testing. The state management landscape is confusing on purpose. Zustand, Jotai, Recoil, TanStack Query, Redux Toolkit, signals everywhere. Most projects don't need more than one of these. I usually reach for TanStack Query for server state and Zustand for client state that crosses component boundaries. If you can solve your problem with React's built-in state and props, do that. State management libraries add abstraction layers and those layers hide bugs. I've spent days tracking down issues caused by selector memoization failures that would have been impossible with plain state.

Performance optimization should start with measurement. The biggest mistake I see is developers optimizing based on intuition. Lighthouse scores are a starting point, not a diagnosis. The actual tool to use is the browser's performance tab with a meaningful user journey recorded. You'll find that the bottleneck is almost never where you expect it to be. I once spent three days optimizing React re-renders on a dashboard, only to discover the real issue was uncompressed images being downloaded on every navigation. The image optimization took forty minutes and improved perceived performance more than the rendering work did. Code reviews are where most quality control happens, and they're getting worse because of AI tools. I've reviewed pull requests where the code was technically correct but completely over-engineered because an AI assistant expanded every simple function into a five-file architecture. My advice is to treat AI-generated code the same way you'd treat a junior developer's submission. Read it critically, question the abstractions, and ask whether a simpler approach would do. The "smart" solution is rarely the right one in production systems. CI/CD pipelines need to be fast enough that developers actually use them. I've seen pipelines that took twelve minutes, and the pattern was clear: developers were merging directly to main and skipping tests because waiting felt pointless. Cutting that down to under three minutes changed the behavior entirely. Parallelize what you can, cache dependencies aggressively, and fail fast on the cheapest checks first. A lint check that takes thirty seconds should run before a test suite that takes four minutes.

Documentation falls off a cliff in most projects within six months. The solution I've found that works is keeping documentation as close to the code as possible. TypeScript types are documentation. JSDoc comments on exported functions are documentation. README files are not, unless they explain the architecture decisions that aren't obvious from the code. I started putting a design.md file in every new project that explains the why, not the what. The why is what you need when you come back to a project six months later and have no context. There's a practical limit to how much you can parallelize learning. The recommendation to "learn AI, web3, Rust, and Kubernetes simultaneously" is bad advice. Pick one stack and go deep enough to hit the edge cases where the tutorials stop helping. That's where real expertise forms. I know several developers who can name every new framework released in the past year but struggle to debug a basic race condition. Depth beats breadth in this industry. The tools change every eighteen months. The fundamentals don't. One specific workaround I use regularly: when dealing with third-party API rate limits, I implement a token bucket algorithm rather than simple request queuing. It handles burst traffic much more gracefully. I built a small wrapper around axios that tracks token consumption per endpoint and throttles accordingly. It saved us from a situation where our automated tests were accidentally DDoSing a payment provider's sandbox because three test suites were making concurrent requests without coordination. The wrapper added about eighty lines of code and eliminated an entire class of flaky test failures.

Memory leaks in modern JavaScript apps are usually caused by event listeners, interval timers, or closures holding references to large objects. React's useEffect cleanup function is your friend here, but it's easy to miss dependencies in the dependency array and create a stale closure that captures outdated state. ESLint's react-hooks/exhaustive-deps rule catches most of these, but it also produces false positives that people disable. I disable that rule as often as anyone, but I've learned to re-enable it specifically when adding new effects. Worth the extra typing for the catch rate. The industry trend toward BaaS and managed services is real for a reason. Setting up your own auth system, deployment pipeline, and monitoring stack is a full-time job. Using Supabase, Vercel, or similar platforms lets you ship faster. The downside is vendor lock-in and limited control when something breaks in ways their support channels can't help with. I use managed services for everything except the core business logic. The logic that makes the product different from every other product should run on infrastructure you control and understand completely. Debugging production issues at 2 AM is still the worst part of this job regardless of how good the tools get. Having structured logging from day one makes a massive difference. I use a simple pattern: every log entry includes a correlation ID that flows through all service boundaries. When something breaks in production, I can trace a single request across the entire stack in under a minute instead of spending hours correlating timestamped log entries from different services. Setting this up takes about an hour and pays for itself on the first incident.