Starting a new project is exciting, and it can be all to easy to rush ahead and put out whatever cool outcomes you are looking for. For example, with this website, one thing I want to do is build a feature where people can send an SMS to a given number and the website will pick it up behind the scenes and do a neat bit of imaging with it.
The idea will be to demonstrate how instantaneous digital data entry can be done by simplephone. This is really important for data collection in less affluent communities where people may have mobile phone but not smartphones, or people may have smartphones but restrict their internet usage on them to conserve on data plan usage. Allowing simplephone data entry therefore makes participation more inclusive.
However, I may be able to quickly put out that feature, but where will it sit in the website? And how will I know that when I write new code to update other parts of the website that doing so won't break functionality of the feature? The answer to both is laying strong foundations for the project. I need to make sure that the fundamentals are in place before I move on to the more exciting stuff. Even better than that, if I can do the fundamentals really well, I might get a high degree of satisfaction out of it, which will make it more enticing to do them well in the future. There is a principle of 'fall in love with the boring': Boring stuff always needs to be done to support the exciting stuff, so if we can find a way to really love how we do the boring stuff, like putting effort into doing it to high standards and feeling the satisfaction of that, then boring stuff ceases to be boring, and that means the fundamentals are done better.
Coming back to this project, an important aspect of it is automated tests. These tests can check that pages are loading correctly and displaying the right information, that links work, and that generally everything is behaving as expected. These tests are run any time new code is written and before that code goes live. This means that any changes that introduce errors can be spotted before the site goes live, and corrected before that happens.
So that's what I did today for my #100DaysOfCode. I wrote tests to check the link from my homepage to my most recent writings and that those writings display properly. There is just one very small visible change to the site, and that is only visible if you look into the source code. I added the attribute
dusk="writing.index" to tell one of my tests what to look for.
So today's work is practically invisible, but it makes my website stronger and more robust. Sometimes the most important work in any process is the barely noticeable. It's not glorious, but it is vital. And perhaps it should be celebrated more. By doing this on #Day4 of my #100DaysOfCode, I feel like I am setting the right precedent for myself: That I will put the time and effort into falling in love with the boring, and in doing so do the fundamentals really well.
Tomorrow, I will continue strengthening the fundamentals. I will write tests that check the working logic of how I write and save writing posts behind the scenes. That will give the testing foundation to add functionality there, such as auto-saving as I type, and having different categories of posts.