Shipping Efficiently

If you find yourself writing a lot of code for a feature, stop and try to organize your changes into smaller, manageable chunks.

Sure, it takes some discipline, but stopping to actually plan out your work before you do it is worth it because it gives you the headspace to put some genuine thought behind the feature.

There’s one caveat – your company has to appreciate this genuine thought.

I’m not going to discuss the dopamine fix you get from completing tasks, I’ll leave that to Mr. Sinek.

Always Think Low Code.

Suppose you are presented with this requirement

Create a new screen to show users sorted by their last login time

Attempting to be as stack-agnostic as I can here, I can break down this requirement into at least these tasks.

1. Define the Data Structure of User
2. Create a table to house Users
3. Create a getUsers() function to pull Users from the DB (with tests)
4. Create a GET /users endpoint that calls the getUsers() (with acceptance tests)
5. Create a service userService.getUsers() that calls the new GET /users endpoint in the UI
6. Create a screen that uses the new userService.getUsers() to populate a list
7. Create a navigation item for the new users screen

Each of these tasks could be shipped quickly without much worry. Also, notice that the customer isn’t exposed to the feature until all the tasks are complete (coded, reviewed, tested, and shipped).

Shipping this way increases quality, promotes productivity, reduces bugs, and fosters collaboration.

Less code = less congitive load.

But you have to have the culture to back it.

Your team cannot be afraid to ship frequently. They must be open to honest conversation about their decisions. Your infrastructure needs to be resilient. Thinking has to be a priority.

How do you ship?

Are you set up to ship anytime? Find out how I may be of help.