Everything you've been told about programming is wrong

As someone who has been in software development for almost two decades, I saw massive changes in way software is written.

I stood before two options. Become a hater and shout at cloud how it’s all wrong, or realize, that everything I’ve been told about programming is subject to change and it may be time to revisit my core assumptions about how proper code looks like.

Separation of concern

Separation of concern has always been core of software development. In web development this has been realized by sub-rule of separation of content and presentation. So you have your functionality, you have your content, you have your presentation. We even have separate languages for each - JavaScript, HTML, CSS.

But then React with hooks happened and functionality and content started to exist in very same function.

And then Tailwind happened (we don’t talk about styled components) and you no longer have separate file for presentation. It ends up in same function as the rest of code.

function MyComponent() {
  // functionality, content and presentation all in same function

  const [myState, setMyState] = useState(0);

  return (
    <h1
      className="p-1 pb-3 font-sans font-3xl"
      onClick={() => setMyState((a) => a + 1)}
    >
      This is my state: {myState}
    </h1>
  );
}

So what should be call this? Co-location.

Co-location to the rescue

I’m fully in camp of co-location. I liked having .css file right next to my component, but not having it at all is better. How do we solve the issues that gave rise to separation of concern - namely spaghetti code? We just make a smaller components, so code does not become unreadable, yet you can make complex changes by editing just single file.

I would approach backend API in similar way too. For example, I’d put data transfer objects next to API that produces them.

It is always massive pain to navigate through layers of code to find those few places to change for simple function extension anyway.

DRY - Do not repeat yourself

DRY is a good rule, but nor nearly as important as it is sometimes made to be and its importance just decreases.

For example while using Tailwind, we can see quite a lot of repetition. This code is actually taken directly from Tailwind docs.

<nav class="flex justify-center space-x-4">
  <a
    href="/dashboard"
    class="font-bold px-3 py-2 text-slate-700 rounded-lg hover:bg-slate-100 hover:text-slate-900"
    >Home</a
  >
  <a
    href="/team"
    class="font-bold px-3 py-2 text-slate-700 rounded-lg hover:bg-slate-100 hover:text-slate-900"
    >Team</a
  >
  <a
    href="/projects"
    class="font-bold px-3 py-2 text-slate-700 rounded-lg hover:bg-slate-100 hover:text-slate-900"
    >Projects</a
  >
  <a
    href="/reports"
    class="font-bold px-3 py-2 text-slate-700 rounded-lg hover:bg-slate-100 hover:text-slate-900"
    >Reports</a
  >
</nav>

Why is importance decreasing? Because we have better tooling.

Tooling to the rescue

When you have repeated content next to each other, it’s trivial to solve this by proper tooling, namely multi-cursor editing.

It may be best solution in many cases, even when we could extract class here to own variable to be reused or create additional component.

Frontend and backend has clear boundaries

This has been case only for a short time. There was backend with JSON API and there was your favorite SPA on the frontend.

Before this, we generated HTML from templates at backend, so separation was not clear in sense it was not always clear who should write certain pieces of code (backend dev or frontend dev) and backend was eating into frontend.
We did not see this as problem as mostly everyone was full-stack developer and few frontend developers usually came from backend background.

Now frontend frameworks, such as Next.js or Svelte kit or Nuxt are rendering on server, so it it clear frontend anymore? It’s not and frontend developers can live with increasingly dumbed down backends, such as Firebase, Supabase or Pocketbase, so in this case it’s frontend that is eating backend.

We see also resurgence of HTML first approach with HTMX, which would bring backend to the front again (pun intended), but clear boundary is still broken.

SOLID and other OOP principles

SOLID principles are often used in interview questions and I think it’s all wrong. It’s all about OOP design and OOP is dying. It’s being replaced by more and more functional approach and powerful OOP languages of past, such as C# or even previously quirky languages like JavaScript can be written almost completely functionally. It’s even considered best practices in many cases and I believe it’s overall better approach.

Why I think new approach is better

All that matter to me in the end is developer experience and when we look at developer surveys, such as State of JavaScript or State of CSS, it’s usually React and Tailwind approaches that has best reported developer experience.

Conclusion

Overall this post is just stream of consciousness I had.

Time to time, I have to realize that big part of software development is unlearning obsolete assumptions and techniques and look into stuff with beginner’s mind.

Tooling changes, problems and scale change too. Patterns that were once useful are useful no more.

This industry looks nothing like what it was when I started and I love it.