[email protected]
Engineering

Jumping in: Front-end development from the middle of the project

When you find yourself thrown into the middle of a project, here are some ways to thrive.

By

I’m a front-end engineer at Postlight, which means I work somewhere between the designers and the database. In addition to being the awkward middle child of the development pipeline, often I work on existing projects that already have a codebase in place. When you find yourself thrown into the middle of a project, here are some ways to thrive.

1. Translate

Design — translate — compromise — repeat

Be ready to translate

Front-end development is translating. You’re asked to translate designs from Sketch or Framer or Photoshop to CSS, and you’re asked to translate behavior from InVision or a user story into JavaScript. Like translating a piece of writing, you can’t automate every part of the task. There are idioms and norms that have to be bent to fit the new context.

A static mock — i.e. a flat picture of a product — has different constraints from a living web app, and a written description of a user experience can hide complexity that the code makes clear. It’s easy to take a mock as a checklist, whose boxes you can check off as you convert each piece of UI into the nearest available code implementation. Instead, take a pass at translating, and pass your draft back to the designer with a few notes about where you chose to deviate and why. Treat it like an ongoing conversation.

Be ready to compromise

Front-end development with a team is about compromise. Most big, interesting web projects use a CSS framework of one type or another, and there are always gaps between any framework’s presets. You might be given tools for working with a 12-column grid, but a user card could have a free-form info box that looks cramped under those conditions. Your framework might provide three tints of your base colors, but your button hover might feel gentler with a fourth. When you run into these clashes, figure out how to reconcile them without just overriding either the comps or the framework.

2. Sort

Identify — separate — shore up

Sort out what’s there

To take an example from a recent project, GIF Battle used both Tachyons and Flexbox Grid for layout and styling, and it was my first exposure to both, which… was a little confusing on day one. I like both tools (Tachyons in particular is a really interesting way to rethink how styles are organized and assembled), but they’re hard to grok if you can’t quickly read the abbreviated class name.

However the existing styles are organized, take time to get the lay of the land before making any changes. Ask questions to understand the reasoning behind the current work. Give the previous team the benefit of the doubt and live in their world for a bit.

Configure your editor and linter to use the team’s preferred settings, and ask about the rationale behind rules you don’t understand. You are using a shared dotfile for these things, right? Right? Getting this sorted early means you won’t waste time on style bugs in code reviews.

Shore it up

Enforcing linter rules (or adding a linter if there isn’t one) is a great way to become familiar with a codebase. It’s also a good way to turn a rough MVP into a consistent set of source files you can compare and contrast (or delete! or combine!).

If you’re comfortable with a JavaScript testing framework (we dig on Jasmine or Mocha with Chai), update the tests so you have a passing suite at your back before changing anything.

3. Extend

Extend rather than rewrite

Extend with the same patterns

If you took your time understanding the code, you should now be able to update functionality and styles using the same vernacular. Work in small pieces and run them by the rest of the team.

Don’t start over. It’s tempting, I know, but the chances of covering the complexity of a site on a green-field redo are slim, and you’ll probably add a lot of time and grief. Even if you perfectly understand your fresh new codebase, you’ll have to reintroduce the team to it. It can work, but it’s an invitation to confusion and slowness.

Don’t start over on the sly. You know what I mean: don’t decide you’re going to change indentation in every file you touch and hope nobody notices. This doesn’t happen as often on a team with good code review habits, but there’s nothing sadder than seeing a tabs-v-spaces diff war.

The group’s understanding trumps your own.

Most importantly, take care of the devs that will join the team after you. Developers come and go in the life of a project. The people maintaining a site in the long run are rarely the people who built it.

This means that business logic, framework deviations, and tricky exceptions should exist outside of your head, ideally in the code itself. What’s obvious to you now will be obscure in a few months, and it’s your job to teach future-you what you’ve learned about this system. The group understanding trumps any one team member’s mental model.

The typing-into-boxes part of programming is an often solitary pursuit. A lot of developers (like myself!) are self-taught and have spent time alone with their computers forming opinions. It’s easy to approach a project as something to “fix” or to “do the right way”, and put yourself in opposition to everyone else touching the codebase. If you treat the ship-of-Theseus team as your collaborators, though, and do what’s best for the changing, evolving product, you can balance the pull of your programmer ego.

Story published on Aug 24, 2016.