Forem: Tomas Listiak

Why Solid.js is winning the framework game

Tomas Listiak — Mon, 09 Mar 2026 00:35:06 +0000

Let's cut through the hype for a minute. Every year, the JavaScript ecosystem births a new "React killer," and most of them fade into obscurity before you can finish reading the README. Solid.js isn't one of those. It's been quietly gaining momentum, and in 2024–2025, that momentum turned into a genuine tidal wave. Here's why — and why you should still think twice before rewriting your production app.

5 reasons Solid.js is winning

1. Reactivity without the virtual DOM tax

This is the big one. React popularized the virtual DOM as a way to abstract away direct DOM manipulation, but it introduced a reconciliation step that costs real performance. Solid compiles your components into fine-grained reactive updates that touch only the exact DOM nodes that need to change. No diffing. No reconciliation. No wasted cycles.

The result? Solid consistently sits at or near the top of the JS Framework Benchmark. We're not talking marginal gains — in complex UIs with thousands of reactive nodes, Solid can be an order of magnitude faster than React in raw update throughput. For applications where responsiveness is non-negotiable — think real-time dashboards, trading platforms, collaborative editors — this isn't academic. It's the difference between a smooth experience and a janky one.

2. Primitives that actually make sense

Solid's API surface is small and razor-sharp. You get three core primitives:

createSignal — reactive state
createEffect — side effects that auto-track dependencies
createMemo — derived computations with caching

That's fundamentally it. Compare this to React's ever-growing hook taxonomy: useState, useEffect, useMemo, useCallback, useRef, useReducer, useTransition, useDeferredValue, useOptimistic... and the subtle footguns buried in each one. How many production bugs have you traced back to a missing dependency in a useEffect array? Be honest.

Solid's dependency tracking is automatic. You access a signal inside an effect, and the effect subscribes. You stop accessing it, and the subscription is cleaned up. No dependency arrays. No stale closures. No exhaustive-deps lint rule arguing with your intent.

3. JSX without the compromises

Here's what trips people up initially: Solid uses JSX, but it doesn't re-run your component functions on every state change. Your component function runs once. That's it. The JSX you write is compiled into real DOM creation code, and the reactive system handles updates from there.

This eliminates entire categories of React pitfalls. You don't need to worry about:

Unnecessary re-renders cascading through your component tree
Wrapping callbacks in useCallback to stabilize references
Memoizing components with React.memo to prevent render waste
The rules of hooks and their ordering constraints

You write what looks like familiar JSX, but the execution model is fundamentally more predictable. Components are setup functions, not render functions that get called over and over.

4. SolidStart is becoming a legit full-stack framework

Solid's meta-framework, SolidStart, has matured significantly. Built on top of Vinxi and Nitro, it gives you:

File-based routing
Server functions and API routes
SSR, SSG, and streaming out of the box
Nested layouts and error boundaries
Built-in support for progressive enhancement

It's drawing clear inspiration from what made Next.js and Remix successful, but with Solid's performance characteristics baked into the foundation. Server functions in SolidStart feel natural — you mark a function with "use server" and call it from your components. Data loading is handled with route-level primitives that integrate with Solid's reactivity.

Is it as battle-tested as Next.js? No. But the trajectory is steep, and the developer experience is genuinely excellent.

5. The bundle size story is unbeatable

Solid's runtime is roughly 7KB gzipped. React + ReactDOM clocks in around 42KB gzipped. When you add a state management library, a memoization helper, and whatever else you bolt on to compensate for React's re-render model, the gap widens further.

But bundle size alone doesn't tell the full story. Because Solid compiles components into direct DOM instructions, the generated code is lean. There's no framework abstraction layer sitting between your logic and the browser at runtime. For performance-sensitive contexts — mobile web, emerging markets with slower connections, embedded webviews — this overhead reduction is meaningful.

Paired with tree-shaking and dead code elimination, Solid apps tend to ship dramatically less JavaScript than their React equivalents for comparable functionality.

The honest counterpoint: why switching might not be smart

I'd be doing you a disservice if I didn't lay out the other side. Frameworks aren't just about technical merit — they exist within ecosystems, team dynamics, and business constraints.

The ecosystem gap is real

React's ecosystem is staggeringly large. Need a date picker? There are twelve battle-tested options. Need an accessible modal? Radix, Headless UI, Reach UI — pick your flavor. Need a complex data table? AG Grid, TanStack Table, and a dozen others have first-class React support.

Solid's ecosystem is growing, but it's not there yet. You'll find yourself building components from scratch that you'd install as a package in React. For small teams shipping under tight deadlines, that cost adds up fast. Some libraries like TanStack Query have started offering Solid adapters, which is encouraging, but coverage is still spotty.

Hiring and onboarding friction

Try posting a job listing requiring Solid.js experience. Your candidate pool shrinks dramatically. React developers are everywhere — bootcamps teach it, university programs cover it, and most frontend engineers have at least working familiarity with it.

Solid's JSX-but-not-React model also creates a subtle onboarding trap. New team members who come from React will assume things work the way React works, and they'll write bugs because of it. Destructuring props breaks reactivity. Conditionals need <Show> or ternaries that preserve signal access. These aren't hard concepts, but they require unlearning habits, which takes time and introduces risk.

Community size and long-term support

React is backed by Meta. Angular is backed by Google. Vue has a massive and well-funded open source organization. Solid is primarily driven by Ryan Carniato and a dedicated but comparatively small core team.

Ryan is brilliant, and the community is passionate — but if you're a CTO evaluating framework choices for a product you expect to maintain for the next decade, the bus factor matters. The project's sustainability model, corporate sponsorship picture, and contributor depth are all things worth examining before going all-in.

Mature patterns for complex state management are still evolving

Solid's primitives are elegant for local and moderately complex state. But if your application has deeply interconnected global state — think a complex form builder, a CAD tool, or a multiplayer editing system — you'll find fewer established patterns and libraries compared to what exists in the React world (Redux, Zustand, Jotai, XState integrations, etc.).

Solid stores exist and work well, but the collective wisdom on structuring large-scale state in Solid apps is still being written. You'll be a pioneer, which is exciting if you have the appetite for it and risky if you don't.

Migration cost from an existing React codebase

If you have a large React application in production, the migration path isn't incremental. You can't embed Solid components inside a React app the way you might incrementally adopt React inside a legacy jQuery codebase. It's a rewrite, or at minimum a significant rearchitecture at the page/route level.

Rewrites are dangerous. They carry enormous risk, burn team morale, and often take twice as long as estimated. Unless your current stack is actively holding you back in measurable ways — performance bottlenecks you've profiled, developer velocity problems you've quantified — the switching cost rarely justifies the theoretical gains.

So, should you switch?

Here's my take after building with both extensively:

Start new projects with Solid if your team is open to learning and you value performance and developer experience. The framework rewards you with code that's easier to reason about and apps that fly.

Don't rewrite existing React apps unless you have a concrete, measurable reason. "Solid is faster" isn't enough. "Our dashboard drops to 15fps on realistic datasets, and we've exhausted React optimization strategies" is.

Experiment aggressively. Build a side project. Port a small internal tool. Get your hands dirty with signals and effects. Even if you stay in React-land, understanding Solid's reactivity model will make you a sharper engineer — and you'll immediately see why the React team is scrambling to ship their own compiler.

Solid.js is winning because it made fundamentally better technical choices at the core layer, and the rest of the developer experience has caught up. Whether it wins your particular game depends on factors that no benchmark can measure.

The art of clean code: Essential principles for simplifying software development by Christian Mayer

Tomas Listiak — Fri, 04 Jul 2025 23:46:48 +0000

Most developers spend countless hours wrestling with overly complex code that's difficult to maintain, debug or extend. If you've ever found yourself lost in a maze of convoluted logic or struggling to understand code you wrote just months ago, you're not alone. The solution isn't writing more code — it's writing better code.

Christian Mayer's The art of clean code presents nine core principles that can transform how you approach software development. Unlike dense academic texts, this book focuses on practical wisdom that you can apply immediately. The central theme? Reduce and simplify, then reinvest energy in the important parts.

I've been thinking a lot about the ideas in the book, and it's helped me really focus on the most important ideas that have shaped my approach to software development. In this article, I'll share some of the most valuable lessons that have shaped my career and impacted my journey in a positive way.

While this article is inspired by the concepts presented in the book, it's not a straightforward summary or review. Instead, I aim to share my own reflections and insights, combining the ideas from the book with my own experiences and perspectives as a software engineer.

I've taken the concepts that resonated with me the most and expanded upon them, adding my own thoughts and examples to illustrate how these ideas can be applied in real-world scenarios. As such, this article should be seen as a personal interpretation of the book's ideas, rather than a pure distillation of its contents.

That being said, I strongly encourage readers to explore the original book, as it offers a wealth of knowledge and insight that cannot be fully captured in a single article. Christian's writing provides a depth and nuance that is well worth the investment of time and attention.

My goal here is not to replace the book, but rather to offer a complementary perspective and inspire further exploration of the ideas presented.

Note: Throughout this article, I will be using JavaScript for code samples, as it is the language I am most familiar with. It's worth noting, however, that the original book uses Python for its examples. Despite this difference, the concepts and principles discussed remain language-agnostic, and the JavaScript code snippets are intended to serve as a concrete representation of the ideas being presented.

Chapter 1: How complexity harms your productivity

Before diving into solutions, let's understand the problem. Complex code doesn't just slow you down — it compounds exponentially. When your codebase becomes a tangled web of dependencies and unclear logic, every change becomes risky, every feature takes longer to implement, and your productivity plummets.

Think about it: When was the last time you confidently made changes to a complex piece of code without worrying about breaking something else? Complex systems create fear, and fear leads to slower development cycles, more bugs, and ultimately, frustrated developers.

// Complex: Hard to understand and maintain
function processData(d) {
  if (d && d.length > 0) {
    for (let i = 0; i < d.length; i++) {
      if (d[i].status === 'active') {
        if (d[i].type === 'user') {
          if (d[i].lastLogin) {
            const diff = new Date() - new Date(d[i].lastLogin)
            if (diff > 86400000) {
              d[i].status = 'inactive'
              sendEmail(d[i].email, 'reactivation')
            }
          }
        }
      }
    }
  }
  return d
}

// Simple: Clear intent and easy to follow
function markUserInactive(user) {
  sendReactivationEmail(user.email)
  return { ...user, status: 'inactive' }
}

function shouldDeactivateUser(user) {
  return user.status === 'active' &&
    user.type === 'user' &&
    isDaysSinceLastLogin(user.lastLogin) > 1
}

function deactivateInactiveUsers(users) {
  return users.map(user => {
    if (shouldDeactivateUser(user)) {
      return markUserInactive(user)
    }
    return user
  })
}

Complexity manifests in several ways:

Unnecessary abstractions that make simple tasks convoluted
Deeply nested code that's hard to follow and understand
Unclear variable and function names that require mental translation
Monolithic functions that try to do everything at once
Tight coupling between components that should be independent

The good news? Most complexity is unnecessary. By following proven principles, you can write code that's not only cleaner but also more powerful and maintainable. The key is recognizing that every line of code you don't write is a line that can't have bugs, doesn't need maintenance, and won't confuse future developers.

Chapter 2: The 80/20 principle

The Pareto Principle states that 80% of effects come from 20% of causes. In software development, this translates to focusing on the critical 20% of your code that delivers 80% of the value. But how do you identify this crucial 20%?

Start by asking these questions:

Which functions are called most frequently?
What features do users interact with daily?
Where do most bugs occur?
Which code paths handle the majority of your data?

By identifying and optimizing these critical areas, you'll see disproportionate improvements in your application's performance and maintainability. Stop trying to perfect everything and start perfecting what matters most.

The 80/20 principle applies to multiple levels:

Feature level: Most users only use 20% of your application's features regularly. Focus your development effort on making these core features exceptional rather than building countless edge-case features.

Code level: 20% of your codebase likely handles 80% of your application's core functionality. These critical paths deserve extra attention for clarity, performance, and reliability.

Bug fixing: 80% of bugs typically come from 20% of your code. Identify these problem areas and invest in refactoring them rather than constantly patching symptoms.

This principle extends beyond code to your entire development workflow. Focus on the tools, techniques, and knowledge that provide the highest return on investment. Learn the core concepts deeply rather than chasing every new framework or trend.

As developers, understanding the business impact of our technical decisions amplifies the value of clean code. When we align our engineering practices with business outcomes, we can better identify which code improvements deliver the greatest return. I've written about this approach in detail in my article on how to drive efficiency and profit as an engineer, which explores how to prioritize technical work based on business impact.

Chapter 3: Build a minimum viable product

Perfect is the enemy of good. One of the biggest mistakes developers make is trying to build the ideal solution from day one. Instead, embrace the Minimum Viable Product (MVP) approach to coding.

An MVP approach to coding means:

Writing the simplest code that solves the problem
Getting feedback early and often
Iterating based on real-world usage
Avoiding premature abstractions

This doesn't mean writing sloppy code — it means being intentional about what you build and when. Start simple, validate your approach, then add complexity only when justified.

The MVP mindset in practice:

Start with a static config before building robust configuration systems. If you only have one environment, don't build a complex configuration framework. When you need flexibility, add basic configuration. Only when you have multiple, distinct use cases should you build a sophisticated configuration system.

Use simple data structures before optimizing for performance. An array might be fine before you need a hash table. A text file might work before you need a database.

Build features incrementally. Instead of trying to anticipate every possible requirement, build what you know you need. Real user feedback will guide you better than theoretical planning.

// MVP Phase 1: Simple hardcoded approach
function sendNotification(userId, message) {
  // Start simple - just email notifications
  const user = getUserById(userId)
  sendEmail(user.email, message)
}

// MVP Phase 2: Add basic flexibility when needed
function sendNotification(userId, message, type = 'email') {
  const user = getUserById(userId)

  if (type === 'email') {
    sendEmail(user.email, message)
  } else if (type === 'sms') {
    sendSMS(user.phone, message)
  }
}

// MVP Phase 3: Add structure only when complexity justifies it
class NotificationService {
  constructor() {
    this.handlers = {
      email: new EmailHandler(),
      sms: new SMSHandler(),
      push: new PushHandler()
    }
  }

  send(userId, message, types = ['email']) {
    const user = getUserById(userId)

    types.forEach(type => {
      if (this.handlers[type]) {
        this.handlers[type].send(user, message)
      }
    })
  }
}

The MVP approach reduces waste, accelerates learning, and keeps you focused on solving actual problems rather than imaginary ones.

Chapter 4: Write clean and simple code

We all know that clean code is about more than just following style guides. It's also about making your intent crystal clear. Your code should read like well-written prose, with each function, variable, and class name contributing to the story as a whole.

Key principles for clean code:

Use intention-revealing names. Instead of d or tmp, use daysUntilExpiry or temporaryUserData. Your future self will thank you.

Functions should do one thing well. If you can't explain what your function does in a single, clear sentence, it's probably doing too much. Break it down.

Keep functions small. A good rule of thumb: If your function doesn't fit on your screen without scrolling, it's too long.

Minimize dependencies. The fewer external dependencies your code has, the easier it is to understand, test, and maintain.

Write self-documenting code. Comments should explain why, not what. If you need comments to explain what your code does, consider rewriting it to be clearer.

// Bad: Unclear and requires comments
function calc(p, r, t) {
  // Calculate compound interest
  return p * Math.pow(1 + r, t)
}

// Good: Self-documenting
function calculateCompoundInterest(principal, annualRate, years) {
  return principal * Math.pow(1 + annualRate, years)
}

Structure your code for readability:

Use consistent indentation and formatting (use linter and/or formatter)
Group related code together
Separate different concerns with whitespace
Order functions logically (called functions near calling functions)

Clean code extends beyond just the code itself — it encompasses your entire development workflow. This includes maintaining clean, structured conventional commit messages that make your project history as readable as your code. When your commits follow a consistent structure, they become valuable documentation that helps team members understand the evolution of your codebase.

Clean code is not about being clever — it's about being clear. Choose clarity over cleverness every time.

Chapter 5: Premature optimization is the root of all evil

"Premature optimization is the root of all evil." This famous quote by Donald Knuth highlights one of the most common developer pitfalls. We often optimize code that doesn't need optimization while ignoring real performance bottlenecks.

The right approach to optimization:

Write clean, working code first
Measure performance with real data
Identify actual bottlenecks
Optimize only what matters
Measure again to verify improvements

Most performance problems come from algorithmic issues, not micro-optimizations. Focus on choosing the right data structures and algorithms rather than premature micro-optimizations that make your code harder to read and maintain.

Common premature optimization mistakes:

Micro-optimizing loops before profiling shows they're bottlenecks
Using complex data structures when simple ones would suffice
Caching everything without measuring what actually needs caching
Over-engineering for scale you may never reach

When to optimize:

After profiling shows a real performance problem
When user experience is noticeably affected
When you have concrete performance requirements to meet
After you've exhausted simpler solutions

// Premature optimization: Complex and harder to understand
function processUsers(users) {
  // Trying to be "clever" with micro-optimizations
  const len = users.length
  const result = new Array(len)
  let i = 0

  while (i < len) {
    const user = users[i]
    const isActive = user.status === 'active'
    result[i] = isActive ? { ...user, processed: true } : user
    ++i
  }

  return result
}

// Clear and simple: Optimize later if needed
function processUsers(users) {
  return users.map(user => {
    if (user.status === 'active') {
      return { ...user, processed: true }
    }
    return user
  })
}

// Actual optimization: Based on real performance data
function processUsers(users) {
  // After profiling showed this was a bottleneck with 1M+ users
  // We found that spreading objects was the real performance issue
  return users.map(user => {
    if (user.status === 'active') {
      // Avoid object spreading for better performance
      const processed = Object.assign({}, user)
      processed.processed = true
      return processed
    }
    return user
  })
}

Remember: Readable code is easier to optimize later than optimized code is to understand. Write for clarity first, then optimize based on real data.

When you do need to optimize, focus on the architectural and algorithmic improvements that provide the most significant gains. Sometimes, the biggest performance wins come from choosing better tools or technologies rather than micro-optimizations. For instance, Microsoft's recent TypeScript compiler rewrite in Go demonstrates how architectural changes can deliver 10x performance improvements while maintaining code clarity.

Chapter 6: Flow

Flow is the state of complete immersion in your work. When you're in flow, you're not just more productive — you're also happier and more creative. But flow is fragile, and complex, poorly organized code can shatter it instantly.

Creating conditions for flow:

Minimize context switching. Each time you have to mentally shift between different parts of your codebase, you lose flow.
Reduce cognitive load. Clean, well-organized code requires less mental energy to understand.
Eliminate distractions. This includes both external distractions and code-based distractions like unclear naming or inconsistent patterns.
Work on one thing at a time. Multitasking is the enemy of flow.

Structure your development environment to support flow:

Consistent patterns reduce the mental effort required to understand code. When your error handling, naming conventions, and code organization follow predictable patterns, you can focus on the problem you're solving rather than deciphering the code structure.

Clear separation of concerns means you can work on one aspect of your system without having to understand everything else. When authentication, business logic, and data access are clearly separated, you can modify one without affecting the others.

Minimal setup time for development tasks keeps you in flow. If it takes five minutes to run tests or deploy changes, you'll lose momentum. Invest in tooling that makes common tasks instant.

// Flow-disrupting code: Inconsistent patterns and unclear structure
function handleUserLogin(req, res) {
  const email = req.body.email
  const password = req.body.password

  // Different error handling patterns
  if (!email) {
    return res.status(400).json({ error: 'Email required' })
  }

  if (!password) {
    throw new Error('Password required')
  }

  // Inline validation logic
  if (email.indexOf('@') === -1) {
    res.status(400).send('Invalid email')
    return
  }

  // Mixed promise patterns
  User.findOne({ email: email }).then(user => {
    if (user) {
      bcrypt.compare(password, user.password, (err, result) => {
        if (result) {
          res.json({ success: true, user: user })
        } else {
          res.status(401).json({ error: 'Invalid credentials' })
        }
      })
    } else {
      res.status(401).json({ error: 'User not found' })
    }
  })
}

// Flow-supporting code: Consistent patterns and clear structure
function validateLoginData({ email, password }) {
  if (!email || !password) {
    throw new ValidationError('Email and password are required')
  }

  if (!isValidEmail(email)) {
    throw new ValidationError('Invalid email format')
  }

  return { email, password }
}

async function authenticateUser({ email, password }) {
  const user = await User.findOne({ email })

  if (!user || !await bcrypt.compare(password, user.password)) {
    throw new AuthenticationError('Invalid credentials')
  }

  return user
}

async function handleUserLogin(req, res) {
  try {
    const loginData = validateLoginData(req.body)
    const user = await authenticateUser(loginData)
    const session = await createUserSession(user)

    res.json({ success: true, session })
  } catch (error) {
    handleAuthError(error, res)
  }
}

I know that flow can mean different things to different people. For some, it's about being productive in the moment but for others, it's about creating sustainable conditions for long-term creativity and problem-solving.

Chapter 7: Do one thing well and other Unix principles

The Unix philosophy teaches us that small, focused tools that do one thing well can be combined to create powerful systems. This principle applies beautifully to code design.

In practice, this means:

Functions should have a single responsibility
Classes should represent a single concept
Modules should have a clear, focused purpose
Systems should be composed of small, interchangeable parts

This approach makes your code more:

Testable: Small, focused functions are easier to test
Reusable: Single-purpose components can be used in multiple contexts
Maintainable: Changes are localized and predictable
Debuggable: Problems are easier to isolate and fix

// Bad: Function doing too much
function processUserData(data) {
  // Validate data
  if (!data.email) {
    throw new Error('Email required')
  }

  // Transform data
  const cleanedData = {
    email: data.email.toLowerCase().trim(),
    name: data.name.replace(/\w\S*/g, (txt) => 
      txt.charAt(0).toUpperCase() + txt.substr(1).toLowerCase())
  }

  // Save to database
  database.saveUser(cleanedData)

  // Send welcome email
  emailService.sendWelcome(cleanedData.email)

  return cleanedData
}

// Good: Separate responsibilities
function validateUserData(data) {
  if (!data.email) {
    throw new Error('Email required')
  }
}

function cleanUserData(data) {
  return {
    email: data.email.toLowerCase().trim(),
    name: data.name.replace(/\w\S*/g, (txt) => 
      txt.charAt(0).toUpperCase() + txt.substr(1).toLowerCase())
  }
}

function saveUser(userData) {
  return database.saveUser(userData)
}

function sendWelcomeEmail(email) {
  return emailService.sendWelcome(email)
}

Other Unix principles for clean code:

Composition over inheritance: Build complex behavior by combining simple parts
Text interfaces: Use simple, readable data formats when possible
Fail fast: Make errors obvious and early rather than hiding them
Modularity: Design systems as collections of independent components

Chapter 8: Less is more in design

Simplicity is the ultimate sophistication. In software design, this means removing everything that doesn't directly contribute to solving the problem. Every line of code you don't write is a line that can't have bugs, doesn't need maintenance, and won't confuse future developers.

Practical simplification strategies:

Eliminate unnecessary features. If a feature isn't essential, don't build it.
Remove dead code. Unused code is worse than no code — it creates confusion and maintenance overhead.
Simplify data structures. Use the simplest data structure that meets your needs.
Reduce abstraction layers. Every abstraction has a cost — make sure the benefit justifies it.

Question every addition to your codebase:

Does this solve a real problem?
Does it make the code clearer?
Will this be maintained over time?
Can I solve this more simply?

If the answer to any of these is no, consider leaving it out.

The power of constraints:

Working within constraints often leads to more creative and elegant solutions. When you can't add complexity, you're forced to find simpler approaches that are often better in the long run.

Design for deletion: Make it easy to remove features and code when they're no longer needed. Loosely coupled systems are easier to modify and simplify over time.

Default to no: When deciding whether to add a feature, library, or abstraction, default to "no" unless there's a compelling reason to say "yes."

Chapter 9: Focus

Focus is the foundation that makes all other principles effective. Without focus, you'll constantly chase shiny objects, over-engineer solutions, and create complexity instead of eliminating it.

Developing focus as a developer:

Define clear objectives for each coding session
Eliminate distractions during deep work periods
Practice single-tasking instead of juggling multiple problems
Take regular breaks to maintain mental clarity
Use time-boxing to create urgency and prevent perfectionism

Focus isn't just about individual coding sessions — it's about maintaining a clear vision for your project. What are you trying to achieve? What problems are you actually solving? Keep these questions front and center.

Strategies for maintaining focus:

Write down your goals for each development session. This simple act helps you resist the urge to fix unrelated issues or chase interesting tangents.

Use the two-minute rule: If something takes less than two minutes and isn't related to your current task, either do it immediately or add it to a list for later.

Batch similar tasks like code reviews, email responses, or refactoring work. Context switching is expensive, so minimize it by grouping similar activities.

Regular reflection helps you stay on track. At the end of each day or week, ask yourself: Did I work on what mattered most? What pulled me off track? How can I maintain better focus tomorrow?

// Unfocused code: Trying to solve multiple problems at once
function processOrderData(orders) {
  // Main task: Process orders
  const processedOrders = orders.map(order => {
    // Suddenly fixing a different problem
    if (order.customerId && !order.customerName) {
      // This should be in customer service, not order processing
      const customer = getCustomerById(order.customerId)
      order.customerName = customer.name
    }

    // Back to processing orders
    const total = order.items.reduce((sum, item) => sum + item.price, 0)

    // Another tangent: Logging
    console.log(`Processing order ${order.id} - Total: $${total}`)

    // Yet another concern: Validation
    if (total > 10000) {
      // This should be in validation layer
      sendHighValueOrderAlert(order)
    }

    // Finally back to the main task
    return {
      ...order,
      total,
      status: 'processed'
    }
  })

  // Even more scattered concerns
  updateAnalytics(processedOrders)
  cleanupTempFiles()

  return processedOrders
}

// Focused code: Single responsibility, clear purpose
function calculateOrderTotal(order) {
  return order.items.reduce((sum, item) => sum + item.price, 0)
}

function processOrders(orders) {
  return orders.map(order => ({
    ...order,
    total: calculateOrderTotal(order),
    status: 'processed'
  }))
}

// Separate concerns handled elsewhere
function enrichOrdersWithCustomerData(orders) {
  return orders.map(order => {
    if (order.customerId && !order.customerName) {
      const customer = getCustomerById(order.customerId)
      return { ...order, customerName: customer.name }
    }
    return order
  })
}

function validateHighValueOrders(orders) {
  orders.forEach(order => {
    if (order.total > 10000) {
      sendHighValueOrderAlert(order)
    }
  })
}

Bringing it all together

The nine principles in "The Art of Clean Code" are designed to improve the quality of your code and enhance the development experience. By prioritizing simplicity, clarity, and intentional design, you will discover that:

Debugging becomes easier because your code is more predictable
Adding features takes less time because your foundation is solid
Collaboration improves because your code is easier for others to understand
You enjoy coding more because you spend time creating instead of untangling messes

Start small. Pick one principle and apply it consistently for a week. Notice how it affects your development experience. Then add another. Sustainable improvement comes from consistent practice, not dramatic overhauls.

Remember: the goal isn't perfect code — it's code that serves its purpose clearly and efficiently. These principles will help you write code that you'll be proud to revisit months or years later, code that does exactly what it needs to do without unnecessary complexity.

Explore also a short essential guide to writing clean and effective code, which covers fundamental development principles like DRY, KISS, YAGNI, and SOLID that complement the concepts discussed in this article.

Your future self will thank you for every moment you invest in clean code today.

Buy the book

The art of clean code: Best practices to eliminate complexity and simplify your life (by Christian Mayer)