opdavies/oliverdavies.uk
1
0
Fork 0
Code Issues Pull requests Actions Packages Projects Releases Wiki Activity

docs(daily-email): add 2022-11-24

Browse source
This commit is contained in:
Oliver Davies 2022-11-28 23:06:25 +00:00
parent 7c7ca2a63b
commit fcd3504d3f
1 changed files with 29 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

29
website/src/daily-emails/2022-11-24.md Normal file
View file

@ -0,0 +1,29 @@
---
title: >
Doing the simplest possible thing
pubDate: 2022-11-24
permalink: >
archive/2022/11/24/doing-the-simplest-possible-thing
---
I spent most of today working on some code I wrote for the first phase of a client project a few months ago.
The previous version used hard-coded data within a Vue.js application, which was sufficient for the previous criteria and in line with the lean approach we decided to take.
It was the simplest thing that worked.
A new requirement means that the hard-coded data no longer works, so I need to refactor and enhance the code to work with different configurations. I have a proof of concept of this working using JSON from an API endpoint, but I would also like to use a static JSON file when needed for local development.
I experimented with a few different ways to approach this before asking myself, "What's the simplest possible thing I can do to get this working?".
I already knew that I needed to make a change to the structure of the data, which I was able to do quickly with the hard-coded data that I already had, and whilst a static JSON file would be a nice-to-have, I could quickly move the hard-coded data into the API endpoint that I'd already created and continue building on my proof of concept.
The idea of "What's the simplest thing?" is something that I use regularly.
When teaching or coaching test-driven development, I want to write the smallest failing test and then find the quickest and simplest way to get it to pass - even if it means returning a hard-coded value for now.
When working on development tasks, I like to break things down as much as possible and find the smallest thing I can do, commit, and push. This gets the ball rolling, and then I repeat the process.
Even when writing an email or blog post, once I start writing, it's much easier to continue once I'm in the flow.
Taking the simplest approach and not making assumptions about future requirements or scope means less and more maintainable code, as well as being a productivity hack.