Lately I've been dividing web application development into four distinct aspects to help me assess skills and interest in candidates:

• UI
• Domain modeling
• The SDLC
• The gluey bits

1) User Interface (UI)

UI is visual and interactive design—how the product looks and feels. Ideally, skills here lean way into visual design. As objective as an art can be: Accessibility standards, Tufte, McCandless, etc. Using the tools available - markup and CSS. A/B testing to measure performance.

The primary ability in this area is building effective interfaces for human-computer interaction.

Capability in this area is rare, hard to identify, and invaluable.

2) Domain modeling

This is the heart of everything. Get really good here, go deep in a few business domains, and you'll eat until you're ready to retire.

The domain models include functionality! Regardless of whether you use OOP or a functional paradigm. In the functional approach, your functions have signatures and the closer they are to taking your domain entities (Product not ProductViewModelWithPriceCakedOn)the happier you will be long term. Most of your business logic should be here. Most problems in software are the result of poor abstractions.

3) The SDLC: writing, testing, running and observing software

includes discovery and definition phases. There's a ton here. How you work on the code. How you run the code. Observability, security, developer experience, change management (including CI/CD etc), resiliency, scalability, automation, performance. Get this stuff right and you can build amazing things with a smallish team. Get this stuff wrong and you'll thrash for years.

4) The gluey bits.

The gluey bits are everything else. The React components and how you store state. The routes in your service and how the router framework (express, django etc) is used. Most of the code in those how to build a todo list using React and Express examples is gluey bits.

(All this stuff has migrated into the front-end, and so we have made an odd thing: The "front-end engineer" who isn't skilled in the UI concerns. I suspect this is a temporary thing.)

Of these four elements, this is the least valuable. Not because it's not valuable, but because it doesn't do anything - or it shouldn't do anything. Often it does do things and that's where a lot of problems in software ownership root from. Strew business logic and other aspects of capabilities across your gluey bits and you end up with a mess when the business says "ok, we do XYZ, now our goal for the new year is to add XYA. We already do X and Y so it ought to be easy" - and the business never wants to hear we have a ton of tech debt, we have that logic all over the place, we can't really even do Y we just fake it in the gluey bits.

This is also an area where individuals and orgs get bogged down. As an IC, you want to avoid getting stuck write lots of gluey bits. As an org leader or CTO, a rough but informed napkin estimate of how much time engineers spend writing gluey bits - especially in a distributed system or anywhere the word "microservices" has made it into reference architecture or spec - is a good measure of how effective a team can build new things fast. Lots of glue === you're gonna go slow. Minimum viable glue === rocket ship.