"value":"\n <p>I spent most of today working on some code I wrote for the first phase of a client project a few months ago.<\/p>\n\n<p>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.<\/p>\n\n<p>It was the simplest thing that worked.<\/p>\n\n<p>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.<\/p>\n\n<p>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?\".<\/p>\n\n<p>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.<\/p>\n\n<p>The idea of \"What's the simplest thing?\" is something that I use regularly.<\/p>\n\n<p>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.<\/p>\n\n<p>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.<\/p>\n\n<p>Even when writing an email or blog post, once I start writing, it's much easier to continue once I'm in the flow.<\/p>\n\n<p>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.<\/p>\n\n ",
"format":"full_html",
"processed":"\n <p>I spent most of today working on some code I wrote for the first phase of a client project a few months ago.<\/p>\n\n<p>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.<\/p>\n\n<p>It was the simplest thing that worked.<\/p>\n\n<p>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.<\/p>\n\n<p>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?\".<\/p>\n\n<p>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.<\/p>\n\n<p>The idea of \"What's the simplest thing?\" is something that I use regularly.<\/p>\n\n<p>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.<\/p>\n\n<p>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.<\/p>\n\n<p>Even when writing an email or blog post, once I start writing, it's much easier to continue once I'm in the flow.<\/p>\n\n<p>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.<\/p>\n\n ",