There is always a frontend (so design that first)

• 
  Stathis Sideris

Full stack developer, the elusive creature of the software world.

I have worked at different levels in the stack (maybe I'd go as far as calling myself a full stack developer) and I recently realised that when adding a new feature I'm in the habit of designing the frontend first. Which I guess is the "orthodox" approach when you have a proper UX designer, but I've noticed that developers who are more comfortable with the backend tend to gravitate towards thinking of the data and API of the feature first.

• When designing a new full-stack feature, it's always better to start with the frontend.
• Starting with the frontend allows you clarify what the new component should be able to do, both in terms of the user-visible capabilities, but also what's required by the API and by the data modelling at the database level.
• This may sound too one-sided, but remember that for full stack features the frontend is the final deliverable. For your business users, the database is an implementation detail, they just want to see that button.
• Developing the backend first (or front and back in parallel) almost always results in subtle mismatches that need to be corrected later. This is true even when front and back are developed by the same person.
• Sometimes the mismatch is so great that in order to avoid the refactoring cost you just end up kludging the two together.
• Beware of overfitting.
• Why the title? What about backend systems that don't have users?
• What is a backend?
• "A backend is a system that no one interacts with?" Oh really? What about logs? What about monitoring? What about alerting?
• "Ok, a backend is a system that does not need a user to drive it, but will reveal its state to developers for supervision/debugging/monitoring." Oh really? What about releases? What about manually triggered jobs? What about config? What about comprehension through running parts of the computation?
• Give real-life examples of config-writing frontends, monitoring setups,
• Frontends that are not often thought as such:
  • Github
  • CI (Jenkins etc)
  • Monitoring frontends (Grafana, Kibana, custom)
  • AWS logs
  • AWS web console itself
  • Custom config editors
  • Tools for diagnosing/revealing part of the internal logic to business stakeholders.