DEV Community: Hazeq Bin Mohsin

The Advantage of Being a Multidisciplinary Builder

Hazeq Bin Mohsin — Sat, 31 Oct 2026 12:02:46 +0000

I've always found it difficult to stick to just one creative field.

I enjoy programming, but I also enjoy graphic design, UI/UX, animation, and 3D modelling. Sometimes I'm building an application; other times, I'm designing a brand identity or experimenting with a completely different idea.

For a while, I thought of these as separate interests.

Eventually, I started realizing how much they complement each other.

Design changes how I approach development

When I work on an application, I'm not just thinking about whether the code works.

I'm also thinking about how someone will interact with it.

Where should a button go? Is the interface communicating the right information? Does the experience feel intuitive?

My design background influences those decisions before I even start writing the code.

And development gives me the ability to turn those designs into functioning products rather than leaving them as static concepts.

Different skills create different perspectives

Animation teaches timing, movement, and visual communication.

3D modelling teaches spatial thinking and attention to detail.

Programming teaches logic, structure, and problem-solving.

Design teaches hierarchy, consistency, and how people interpret what they see.

These disciplines might seem unrelated at first, but I've found that learning one often changes how I approach another.

Sometimes the solution to a development problem comes from thinking like a designer. Sometimes a design decision becomes much easier after understanding the technical limitations behind it.

But there's a catch: focus

Having multiple interests doesn't mean trying to work on everything simultaneously.

Context switching can become exhausting, and starting new projects is considerably easier than finishing existing ones.

I've learned that curiosity is valuable, but priorities matter.

Not every idea needs to become a product. Not every experiment needs to become a business. Some things are worth building simply because they teach you something.

The important part is knowing when to explore and when to commit.

I don't want to limit myself to one title

I enjoy being a developer, but I don't think that's the only way to describe what I do.

I want to build software, create visual experiences, experiment with new technologies, and develop products that people genuinely find useful.

I don't necessarily see these as competing interests. I see them as different tools for solving different problems.

And perhaps that's one of the biggest advantages of being multidisciplinary: you don't always have to approach a problem from the same direction.

**I'm curious: Do you prefer specializing in one field, or exploring multiple disciplines and combining them? And has learning one skill ever unexpectedly improved another?

A Feature Can Work Perfectly and Still Be a Bad User Experience

Hazeq Bin Mohsin — Thu, 29 Oct 2026 17:29:21 +0000

A Feature Can Work Perfectly and Still Be a Bad User Experience

You can build a feature that works exactly as intended, passes its tests, and has no obvious bugs — and still leave users wondering why they should use it.

I've always been interested in both sides of creating digital products: how they look and how they work. Working across graphic design, animation, UI/UX, and software development has made me appreciate something that is easy to overlook when building applications.

Making something work and making something work well for people are two different challenges.

1. Functionality is only the beginning

Imagine you're building a task management application.

You implement task creation, editing, deletion, deadlines, and persistence. Everything works. The data is saved correctly, and the interface responds to user input.

Technically, you've accomplished what you set out to do.

But then someone opens the application for the first time.

They don't know where to begin. There are too many competing buttons. Important actions are buried in menus. The interface technically contains everything they need, but finding it requires more effort than it should.

The functionality isn't necessarily broken. The experience is.

This is why I think evaluating software purely by its feature list misses an important part of the picture.

A feature should do more than exist. It should help someone accomplish something.

2. Good design isn't just decoration

When people hear "UI design," they sometimes think about colors, gradients, shadows, animations, and rounded corners.

Those things can contribute to a polished interface, but they aren't the foundation of good design.

Good design also involves deciding:

What deserves the user's attention?
Which actions should be immediately accessible?
What information can be removed without losing meaning?
What should happen when something goes wrong?
How can the interface communicate what to do next?

Consider two buttons that perform the same action. One is surrounded by several competing controls, while the other appears exactly where the user expects to need it.

The underlying functionality is identical. The amount of thought required to use it may not be.

Visual polish can attract attention, but clarity and consistency help people use a product.

3. Developers and designers should think about the same problem

I've found it useful to think about product design and software engineering as connected disciplines rather than separate stages.

A designer might propose an interaction that feels natural but becomes difficult to implement reliably. A developer might implement a technically elegant solution that introduces unnecessary complexity for the user.

Neither perspective is sufficient on its own.

The important question is not simply whether a design looks good or whether an implementation is clever.

It's whether the solution works well within the technical constraints while helping the user accomplish their goal.

Sometimes that means simplifying the design. Sometimes it means changing the architecture. And sometimes it means questioning whether the feature needs to exist at all.

That last question is particularly important.

Building something because it is technically possible doesn't automatically make it worth building.

4. Every additional feature has a cost

When developing software, it's tempting to keep adding capabilities.

A new setting sounds useful. Another menu option seems reasonable. One more customization feature could make the product appeal to more people.

Individually, these decisions might make sense. Together, they can make an application unnecessarily complicated.

Every feature introduces some combination of interface elements, decisions, maintenance requirements, and potential edge cases.

That doesn't mean applications should be stripped down to the point where they become limited or frustrating.

It means each addition should have a purpose.

When deciding whether to introduce a feature, I think it's worth asking three questions:

What problem does this solve?
How frequently will someone benefit from it?
Does the value justify the additional complexity?

These questions aren't a perfect formula for product decisions, but they can help separate genuinely useful functionality from features that merely make an application look more capable.

5. Start with the experience, then decide what to build

One practical approach is to describe the user's goal before designing the interface or writing the implementation.

For example, instead of starting with:

"I need a dashboard with five cards, three menus, and a settings panel."

Start with:

"The user needs to understand what requires their attention and decide what to do next."

That second description gives you a problem to solve rather than a predetermined collection of interface elements.

You can then explore different layouts, remove unnecessary steps, and determine which functionality is actually required.

Only after that does it become easier to evaluate implementation choices.

This doesn't eliminate iteration. In fact, iteration is essential. The initial design might be wrong, and real usage may reveal problems that weren't obvious during development.

But starting with the user's goal gives those iterations a clearer direction.

6. What I want to keep in mind when building products

As I continue working across software development and design, there are a few principles I want to carry into every project:

Clarity over unnecessary complexity. Users shouldn't have to decode an interface before they can use it.
Purpose over feature count. More functionality isn't automatically more value.
Consistency over isolated brilliance. An interaction should make sense within the rest of the product.
Usability alongside functionality. A feature isn't finished simply because its implementation works.
Iteration over assumptions. A design that seems obvious to its creator may not be obvious to someone encountering it for the first time.

None of these principles is particularly revolutionary. The challenge is applying them consistently, especially when deadlines, technical limitations, and ambitious ideas compete for attention.

Final thoughts

I think one of the most interesting parts of building software is that the engineering and design problems are often inseparable.

The code determines what a product can do. The design helps determine how people understand and use those capabilities. Product thinking connects both to a problem worth solving.

A technically impressive application can still be difficult to use. A beautiful interface can still fail to deliver value. The goal is to bring those pieces together.

When you build software, what do you prioritize first: functionality, usability, or visual design?

And have you ever used an application that worked perfectly but somehow still felt frustrating to use? I'd be interested to hear what made the experience that way.

What Building Real Software Taught Me About AI Coding Agents

Hazeq Bin Mohsin — Sat, 24 Oct 2026 13:04:08 +0000

AI coding agents are getting better at writing code. But after testing several of them on real projects, I've learned that choosing the right tool is only part of the problem.

The more important question is: Can the agent actually help you ship working software?

As an independent developer, I care less about impressive demonstrations and more about what happens when an AI agent has to work with an existing codebase, understand a project's requirements, fix bugs, or implement a feature without breaking something else.

Here's what my experience has taught me so far.

1. The best AI isn't necessarily the best coding agent

It's tempting to evaluate AI tools by how well they answer questions or generate code snippets. But working on an actual application introduces a different set of challenges.

A coding agent might generate a beautiful component but misunderstand how it fits into the existing application. It might implement a feature that looks correct but fails when connected to a backend. It might even introduce new bugs while attempting to fix old ones.

I've experimented with several tools, including ChatGPT, Claude, DeepSeek, Kimi, Grok, and Codex.

My results varied depending on the task.

Some tools performed better at frontend work, while others were more effective at backend implementation and debugging. The tool that impressed me in one area wasn't necessarily the one I'd choose for another.

The lesson? Evaluate AI tools on the work you actually need them to do, not just on their demos.

2. Context matters more than I initially expected

A coding task rarely exists in isolation.

When working on an existing application, an agent needs to understand more than the immediate instruction. It needs to account for the project's architecture, existing conventions, dependencies, data structures, and intended user experience.

Consider a seemingly simple request: add a new feature to a productivity application.

The implementation might involve:

Updating the interface.
Connecting the feature to existing application state.
Persisting data correctly.
Handling errors and edge cases.
Making sure existing features continue to work.

An agent that only understands the visible interface may produce something convincing without delivering a complete implementation.

I've found it useful to be explicit about requirements, constraints, and expected behavior rather than relying on a vague description of the desired result.

The more consequential the change, the more important it becomes to understand the surrounding code.

3. Different tools deserve different jobs

One of my most useful observations has been that I don't need to choose a single AI tool for everything.

I can use one tool to explore an architectural decision, another to help implement a feature, and another to investigate a stubborn bug.

For example, when developing an application, my workflow might involve:

Planning: Define the expected behavior, constraints, and acceptance criteria.
Implementation: Use an appropriate coding agent to make a focused change.
Review: Inspect the generated code and check whether it follows the project's architecture.
Testing: Run the application, exercise the feature, and check for regressions.
Refinement: Address any problems before moving on.

This approach is more deliberate than handing an agent a broad instruction and assuming the job is finished when it returns code.

It also makes failures easier to diagnose. If something goes wrong, I can investigate a specific change rather than untangling a large collection of unrelated modifications.

4. AI-generated code still needs an engineer behind it

AI can accelerate implementation, but generating code and delivering reliable software are not the same thing.

A feature can compile and still behave incorrectly. A database operation can work in a basic demonstration but fail under unexpected conditions. An interface can look polished while being confusing to use.

That's why I believe developers should understand the code they're shipping, even when an AI agent wrote much of it.

I want to be able to explain why a solution works, identify its limitations, and modify it when requirements change.

This doesn't mean manually writing every line. It means retaining enough understanding and control to take responsibility for the final result.

AI should increase a developer's capabilities, not eliminate the need for engineering judgment.

5. The biggest productivity trap is accepting code too quickly

It's easy to confuse the amount of code generated with the amount of progress made.

An agent might produce hundreds of lines in seconds. But if the implementation is incorrect, those lines become additional work to understand, debug, and replace.

I've learned to value focused changes over unnecessarily large implementations.

A practical approach is to break substantial tasks into smaller steps, define what success looks like, and verify each important change before building on top of it.

For a frontend feature, that might mean checking the component's behavior and integration. For a backend feature, it might mean verifying data validation, error handling, and persistence.

The appropriate checks depend on the application, but the principle remains the same: generated code is a proposed solution, not proof that the task is complete.

6. My approach going forward

I'm continuing to experiment with AI-assisted development as I build and improve my own software products.

Rather than chasing every new tool, I want to develop a workflow that combines the strengths of AI with the parts of engineering that still require careful reasoning, testing, and product judgment.

My current priorities are straightforward:

Choose tools based on demonstrated performance on relevant tasks.
Give agents clear requirements and enough project context.
Keep changes focused and reviewable.
Test actual behavior instead of trusting a successful code-generation response.
Treat failures as useful feedback about both the tool and my workflow.

I don't think there's one universally best coding agent. The best choice depends on the project, the task, the available context, and how effectively the developer can evaluate the result.

And as these tools continue to evolve, I expect that conclusion to evolve with them.

Final thoughts

AI coding agents have changed how I approach software development. They can help me explore ideas, accelerate implementation, and solve problems that would otherwise take longer.

But the goal isn't to generate the most code in the least amount of time.

The goal is to build better software.

I'm interested in learning how other developers are approaching this shift, especially those working on real applications rather than isolated coding exercises.

What's your experience with AI coding agents?

Have you found a tool that consistently performs well for your particular workflow, or have you also discovered that different tools excel at different tasks?

I'd be interested to hear what has worked for you, what hasn't, and how you verify that AI-generated code is actually ready to ship.

I Couldn't Find a VS Code Theme That Felt Right — So I Built One Myself..

Hazeq Bin Mohsin — Tue, 23 Jun 2026 17:17:06 +0000

Most themes force a choice: vibrant and tiring, beautiful and unfunctional, or readable and dull.

The default icon theme was boring, the icons were not recognizable much at small scale. The color theme missed good syntax highlighting and blender background colors.

I went through Ayu, One Dark Pro, Monokai Pro, and dozens of others. Every one of them fell short. The icons had gaps. The syntax highlighting wasn't deep enough. The colors either burned my eyes or made everything look blender and lifeless. After ten hours of coding, I'd just feel exhausted.

So I stopped looking. I opened Adobe Illustrator and started building.

The first version was called Syntax Shine — it was just a personal syntax theme. I tweaked every token color until I could stare at a complex React component at 2 a.m. and still read it clearly. The improvement was immediate. That's when it clicked: if this helped me this much, it could help others too.

I expanded it into a full icon theme, published it as VS Seti Plus, and it somehow got 300+ installs and two 5-star reviews. But the name confused people, especially AI — most assumed it was based on the built‑in Seti icons. It wasn't. Every icon was designed from scratch.

So I rebuilt the brand from the ground up. It's now called Spect.

What Spect Actually Is

Spect is a complete visual system for VS Code — 250+ original icons and 7 color themes, all free.

Pixel-Perfect Icons

Every icon is hand-crafted in Adobe Illustrator and uses exactly one color from an 8‑color functional palette (Red, Orange, Yellow, Green, Blue, Purple, Gray, White). These are clean, scannable shapes that stay recognizable even when your sidebar is collapsed to 4 pixels wide.

Most icon packs assign the same symbol to similar file types. Spect doesn't. JS, MJS, CJS, and OJS each get their own icon. JSX and TSX are visually distinct. HTML, HTM, and XML are clearly separated. Python scripts and modules are different. Those small distinctions matter when you're navigating a massive codebase at speed.

Color Themes That Work

Spect has seven theme variants, not just one dark theme:

Theme	Best for
Dark Classic	All‑purpose. Warm copper strings, soft gold functions, deep blacks.
Dark Professional	My own choice — deeper backgrounds, brighter foregrounds.
Dark Contrast	Daylight work. Elevated contrast and bright borders.
Dark Colorblind	Maximum luminance contrast. Fiery bright text on the darkest backgrounds.
Light Classic Clean whitespace, bright token colors.
Light Professional	High accessibility with deep token colors for long work.
Light Colorblind	Maximum readability on a bright white background.

Every theme has 40+ syntax token rules — strings, regex, keywords, functions, variables, types, numbers, HTML/XML, CSS, Markdown, JSON, diffs, and more. Nothing gets left unstyled.

The command palette, autocomplete suggestions, and hovers float with subtle translucency. You can even see the code behind them. It's one of the specialties of Spect — And it just feels more premium and beautiful.

I never intended to build a product. I just wanted my own workspace to feel comfortable.

But when I published it as VS Seti Plus, something happened: developers started loving it, and it got 2 reviews, each featuring a 5-star gift, in under 50 downloads.

That feedback keeps me going. Every icon, every token color, every contrast ratio is there because I personally needed it during a long coding session.

How to Try It

Just search for "Spect" in the VS Code Extensions panel. That's it. Install the first result you find there.

Link to the marketplace

What's Next

I'm actively maintaining Spect. The last update added 40+ new icons (CoffeeScript, F#, Zig, Nix, Elixir, Haskell, and more) and two new light themes. There's a colorblind‑specific variant for both dark and light modes, because accessibility shouldn't be an afterthought.

If you try Spect and something feels off — a missing icon, a color that doesn't work for you, a language that isn't covered — open an issue. I actually read them and fix things fast.

Also, keep in mind that this is not an advertisement, but a personal project I made for myself.
Happy coding.