DEV Community: cartmann68

Who should decide UI?

cartmann68 — Wed, 03 Dec 2025 09:43:35 +0000

What do you do as a product manager when your design team push for a clean, modern interface, while developers argue for the old, familiar UI?

tldr;

You should always go with the solution of the designers because they are designing for users not programmers.

1. Programmers are not the audience.

Developers spend their life inside complex tools, terminals, logs, IDEs — clutter doesn’t bother them because they’re trained to survive it. But users are not developers. Normal people don’t want interfaces that look like a cockpit from the 1990s.

2. Designers are literally trained to solve this problem.

A designer’s whole job is:

visual hierarchy
readability
spacing
usability
clarity
human factors

A programmer’s job is not design. Their taste is shaped by tools built for power-users.

3. Old, cluttered interfaces only feel “better” to developers because they expose internal structure.

Developers like seeing everything at once because it mirrors how they think: data → structure → options → panels → nested menus. Users, on the other hand, get overwhelmed and leave.

4. Modern UI isn’t “minimalism for the sake of minimalism.”

Good modern design reduces friction. Not fewer features — fewer obstacles. Clearer choices. Better flow. Safer defaults.

5. Every successful product on earth follows the designer, not the engineer

Apple, Google, Stripe, Figma etc. all prefer a clean and modern UI. If “cluttered 1990s UI” were better for users, the entire industry wouldn’t have abandoned it.

6. **Engineers usually change their mind once they use the cleaner version**

At first they complain because everything moved. A week later they admit the new design feels calmer, faster, easier to navigate.

7. The business side also points in one direction

Clean modern UI =

lower support tickets
higher conversion
higher user trust
easier onboarding
better perceived quality

Clunky UI = “This looks old, I don’t trust it.”

Conclusion

Design for users, not for developers.
Follow the clean, modern design.
Developers can adapt — users won’t.

If you want harmony between teams, the compromise is this:

UI = clean, modern
Advanced settings = tucked away so power-users can still access them
Internal developer tools can be as ugly and cramped as programmers enjoy

Customer-facing products should be modern and clean.

🔥

cartmann68 — Wed, 03 Dec 2025 09:30:46 +0000

Why JavaScript Is the Best Programming Language in the World

Neo Hacker ・ Aug 29

#webdev #javascript #react #programming

Why you need event-driven architecture

cartmann68 — Wed, 03 Dec 2025 09:25:49 +0000

Events are often used to decouple logic and keep a system modular.

Events allow for a very modular architecture. Your system emits events at different points in time and this allows you to create a completely independent and pluggable module which hooks into these events without needing to make any changes to the core part of your system. For example, you might create a Notification module which listens to various events in your system and sends e-mail, text messages, push notifications and performs other actions related to notifying your users. All of this without ever needing to change any part of your existing codebase. Your module can have a single responsibility, be completely self-contained and independent.

For example, POS systems often have a local law requiring them to implement the payment system as a completely separate module. Without events and hooks this becomes impossible. You look at the code and see that everything depends on everything, the payment system is intermingled with every other part of the system. You throw your arms up in the air and say, no way, this can't be done. Payments are the very core of a POS system. It runs through everything. But that is just a sign of a badly architected system. It doesn't need to be this way. Everything should not depend on everything. That's a brittle system. With an event-driven, modular architecture you simply emit events and let the payment module hook into these events and handle the logic.

Think of a radio broadcast (emitting events). The broadcaster simply broadcasts into the air. Anyone who wants to and has a radio (listener) tuned to the frequency hears the message. The broadcaster doesn’t know or care who’s listening.

Why abstractions are good

cartmann68 — Wed, 03 Dec 2025 09:18:50 +0000

Have you noticed how our world is built on abstractions? Abstractions are everywhere. We have abstractions in code - one library depends on another library which depends on another and so on. But it's not just code. We use abstractions every day. Every time you plug something into a wall outlet - you are using an abstraction, a huge electrical infrastructure with its own abstractions, completely invisible and hidden from you. When you drive your car, you don't operate with gears and wires, instead you turn a key, push a button, turn the steering wheel. You don't care how it works - you don't even want to know how it works. You're using abstractions to get where you need to go.

A World without abstractions and dependencies

Imagine a world without abstractions. Let's say you wanted to build a house. You'd need tools and materials but if you couldn't rely on abstractions and depend on the work of others, you would need to create all the tools and materials yourself. Just think of how much work goes into making something as simple as cement. You need limestone, clay, sand, and gypsum. But in order to get those things you need quarries, explosives, heavy machinery, fuel, trained operators, safety systems, transportation. And each of those depends on even more things. It's almost an infinite chain of dependencies.

If you were building a house without using any dependencies, you'd need to create your own tools. Think of how many things are involved in making a power drill - motor, a chuck, a trigger, a shell. A motor needs magnets. Those magnets alone require an entire industry: mining rare earth metals, crushing ore, separating the elements through complex chemical processes, sintering them at high temperatures, machining them, coating them so they don’t corrode.

In software development, a function relies on a library, that library relies on other libraries, all of it runs inside an environment, which depends on system libraries, which itself sits on top of an operating system, which depends on hardware, which ultimately depends on silicon and the physical world underneath it.

The real world depends on abstractions, an almost infinite supply chain of dependencies. And that’s the whole point: none of us could ever build anything meaningful alone. We stand on top of the work of millions of people we’ll never meet, quietly building layer after layer so the world feels simple on the surface. Abstractions are what let us make progress. They let us create without having to reinvent the entire universe first.

Once you see that, you start appreciating the hidden scaffolding underneath everything — and you realize how impossible life would be without it.

What DRY actually means

cartmann68 — Wed, 03 Dec 2025 09:16:26 +0000

A lot of junior developers misunderstand DRY (Don't Repeat Yourself) as a strict rule against any code duplication. To them DRY means:

never repeat a line of code
never have two components share similar structure
never write anything twice

If something looks similar, they feel obligated to merge it, abstract it, or build a “super component” with flags and conditions. Of course, the result is always the same: Overcomplicated, brittle, unreadable code that was technically DRY — and practically unusable..

Pizza Recipes

Imagine if a cookbook tried to follow the the DRY principle to the extreme. Instead of having separate recipes for different types of pizza, it would try to create one giant single pizza recipe that covers every possible variation - one "single universal pizza recipe".

“Use tomato sauce unless you’re making quattro formaggi — in that case, ignore this and jump to the cheese section.
Add pineapple only if not using anchovies or mushrooms. If using both, skip pineapple and go to page 245, see section b.
If using olives, skip basil unless also adding mushrooms…, in that case turn to page 658”

Technically DRY — only one pizza recipe. But completely unusable. In real life, we keep multiple recipes, even if some steps repeat. And that’s correct. Repetition of harmless steps is not a problem. Confusing everything into one monstrosity is a problem. It's perfectly fine to have every pizza recipe start with "Take the dough and roll it out." because clarity is more important than eliminating every repeated line.

IKEA Furniture Manuals

Imagine if IKEA tried to be DRY by shipping one giant instruction manual for all their furniture instead of separate manuals for each product.

“If assembling a chair, skip to page 573.
If your item uses bolt type B2, follow section 19.
If you’re building something with drawers, go to section 1447 unless it’s the office series…”

That would be completely insane and unusable. Instead, IKEA provides individual manuals for each product, even if many steps repeat across manuals. Because clarity is more important than eliminating every repeated step.

The same principle applies to code. You don't search the codebase for every instance of "class extends Model" to merge them into one mega-class. You create many small, focused classes that are easy to understand and maintain.

The DRY principle is about avoiding duplication of knowledge, not avoiding duplication of keystrokes.

Duplicating logic is bad.
Duplicating meaning is bad.
Duplicating rules is bad.

It's not about trying to avoid duplicating structure. It is often the healthy, maintainable thing to do. Don't try to eliminate every repeated line of code by merging unrelated logic, stuffing everything into one mega-component, making endless if-statements, adding flags or creating abstractions nobody understands. That only produces coupled, brittle, unreadable code that is dangerous to change. This is not what DRY means.

True DRY is about removing duplication of concepts and rules, like centralizing email validation, having one shared price-calculation function, using a composable that handles quantity logic, or extracting truly shared behavior. This produces code that is clear, testable, easy to maintain, and respects boundaries.

Remember, we don't have one huge pizza recipe or one giant IKEA manual. Nobody wants that.