Add daily email for 2025-01-29
Make it work, then make it good
This commit is contained in:
parent
f994093b5c
commit
2e2a055897
34
source/_daily_emails/2025-01-29.md
Normal file
34
source/_daily_emails/2025-01-29.md
Normal file
|
@ -0,0 +1,34 @@
|
|||
---
|
||||
title: Make it work, then make it good
|
||||
date: 2025-01-29
|
||||
permalink: daily/2025/01/29/make-it-work
|
||||
tags:
|
||||
- software-development
|
||||
cta: ~
|
||||
snippet: |
|
||||
When developing new software, my main objective is to make it work. Then, I make it look nice.
|
||||
---
|
||||
|
||||
I've recently been writing a new custom module for a Drupal application.
|
||||
|
||||
I needed to create a form populated with options from an API endpoint, submitted the form values to another API endpoint and display some results to the user.
|
||||
|
||||
I'd architected and planned the steps I was going to need and knew how I was going to approach adding this new functionality.
|
||||
|
||||
My first objective was to make it work.
|
||||
|
||||
To get all the functionality in place so it was working as soon as possible with minimal distractions.
|
||||
|
||||
This meant I would find any issues sooner rather than later and what I'd created could be reviewed and tested by stakeholders, regardless of how it looked.
|
||||
|
||||
If needed, it could have been released at this point.
|
||||
|
||||
It was working.
|
||||
|
||||
Next, I did a second pass to make it good.
|
||||
|
||||
I updated the markup and styled it to match the provided designs.
|
||||
|
||||
I made small updates to terminology and messaging to ensure the tone of voice was correct and consistent with the rest of the application and various other small tweaks and improvements.
|
||||
|
||||
I could do all this knowing the functionality was already working, and I could focus on making it good.
|
Loading…
Reference in a new issue