DEV Community

Discussion on: How we use "ship small" to rapidly build new features at GitHub

Collapse
 
kpollich profile image
Kyle Pollich

Thanks for this, Mike! Really enjoyed this post. I have one question about the "parallel work streams" you mentioned.

  • 1 engineer can start working on the backend that feeds data to this page.
  • Another engineer can start working on the frontend.
  • The designer works on the UI. If they can code, they jump in and write markup + CSS.

What does the frontend work look like while the UI design is still being worked on? Is this like a "wiring up" of the initial boilerplate/wireframe that gets put up?

Thanks again!

Collapse
 
mscccc profile image
Mike Coutermarsh

❤️✨

Depends on how design heavy the feature is. Usually we have low fidelity sketches done during planning. Then we have our own design system, Primer, that we can copy/paste components from to build out the page. We can get really far with that alone.

This page for example: github.com/actions/starter-workflo...

I remember when we started it, we had some rough design ideas. We were confident we'd be showing "boxes" with workflows in them. So one engineer got started by passing an array of fake data to the frontend, and then looping over it to render a partial for each item in the array.

As this was happening, the designer was iterating on what the final page should look like. Once they had that, we were able to go in and adjust that partial/layout to look how the designer wanted.

My recommendation for people would be to always start on the piece you feel you have enough information to be confident in implementing (even if it looks terrible first pass). Just getting fake data on the page can sometimes be more work than we anticipate, so getting that out of the way and working is usually a nice win and saves time later.