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.
- Define the
- Create a table to house
- Create a
getUsers()function to pull Users from the DB (with tests)
- Create a
GET /usersendpoint that calls the
getUsers()(with acceptance tests)
- Create a service
userService.getUsers()that calls the new
GET /usersendpoint in the UI
- Create a screen that uses the new
userService.getUsers()to populate a list
- 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.