Front-end development is not automatically easy. Project timelines should reflect that.
Tags: html, webdev, css, productivity
Published: 2021-03-07 04:58:01

_(thanks Unsplash for the cover image)_

I've had the title of "front-end engineer" in some sort of capacity for almost 9 years now. In these 9 years, one thing has not changed:

| "Oh, that's just HTML and CSS, that'll take like, 2 days right?"

This *could* be true, but it is not usually true. We see this in discourse on Twitter, in meetings throughout our workplaces, and in general the vibe that front-end is not really "development", "engineering", or "programming".

## Why do questions / statements like this matter?

This sentiment towards a craft really "grind my gears" so to speak. It emboldens the following assumptions:

- That front-end (HTML, CSS, and JavaScript) languages are easy.
- That there is no lead time to "getting things ready"
- That there is no lead time to really get a project into a "let's go" state.
- That there is nothing to clean up (if it's an existing project)
- That you can write code once and it works and it's good to go (browser testing across devices is a thing!)
- That organization and writing clean, maintainable code takes no time at all.

These assumptions are harmful to any craft - but we see it all the time with front-end engineering.

## What is a better response?

Timelines are important to any project - I'm definitely not disputing that. Front-end engineers are usually sandwiched between design and back-end engineers - both of whom are usually given a bit of lead time to really understand the problem. Many front-end engineers want to be and *need* to be part of that lead time / discussion.

- **Ask the ones writing the code** 
This might sound wild, but _ask the people who are making the changes_ and adjust your business priorities accordingly. They may waffle on an answer, but their waffling is *also* a good indication it may take a bit more time than you realize.

- **If you allow time for design, allow time for development** 
It is not unfathomable that the time it took to research / come up with finessed designs might be around the same time a developer needs to execute the designs.

- **Give front-end engineers the respect they deserve**
Front-end engineers have to support a wide range of clients, deal with languages that are *constantly* changing (like, literally, every 4-6 weeks a browser might support something new), and constantly have to watch out for themselves by not painting themselves into a corner when a new design comes across the table.

## Design is not easy.

This applies to the actual creation of designs (UX, visual, content, etc) but also architectural design of a codebase. Companies _all the time_ find themselves in a situation where a codebase is not "feasible" to be upgraded because things weren't thought of when it was designed.

## How do you overcome this problem?

**Slow down.** Take a bit more time to create a _scalable_ system, no matter the language, that can take you from small to large. I'm not advocating for perfection - **I'm advocating for sensible and pragmatic development**.

Invest in what you're making - whether you're a small startup or a company that can throw tens of millions of dollars at a project on a whim.

Allow your engineers this time. It will help you (and your team) later.