I’ve started using Bear to write up features for a product.
Instead of going straight a user story and coding, I’m spending a bit more time writing about the feature, and it’s risks and benefits.
It’s working well so far.
Another great update to Bear, the notes app. Back in the day the best thing I used for managing notes was Backpack. This is probably the next best thing to Backpack for me.
Tis the season for notebooks! Just backed @rohdesign’s Sketchnote Ideabook on Kickstarter.
Ordered the bundle of three so my youngest can get one.
Hobonichi’s ordered for me and Jen. It’s becoming a little tradition this.
The email shake down
I loved this post from the Signal vs Noise blog about trading off tracking people through email for content.
Not everything needs to be tracked. Not everything needs to pay off. It’s perfectly fine to do things because it’s fun, feels good, is interesting, tickles your brain, or just helps someone out.
— [Let’s stop shaking people down for their email addresses] (https://m.signalvnoise.com/lets-stop-shaking-people-down-for-their-email-addresses)
The benefits of hard work.
Personal projects do make you a better developer.
My focus just now is on a larger project though. It still affords me much of the same benefits, just less of an opportunity to try new things. I’m okay with that though for the sake of getting it off the ground.
A product decision over some code and coffee
For the last few months, I’ve been building a content management system aimed at a particular industry.
I’m close to finishing the first working version of the product. There are still a few things to do, like account management and theme options, but these are trivial things that will not present any problems.
While reviewing the CMS source code this morning, I spotted a way that I can refactor a part of the CMS. The change involves simplifying the different content from multiple types of content to a single base content model that I can base other content on. This is a significant structural change to the product. It involves changes in how the CMS presents and manages the content.
If I spend the time making the change now, it would be much easier to handle any created content and migrations of data in the future.
If I schedule the switch for later on after the release, I’ll always know that I have this change in the structure to make and will be presented with an increasing problem of migrating data.
Thinking on it, I like the idea of taking the hit now and getting this right before the product gets released. I’m just wondering now why I didn’t see this before when I was modeling the content for the CMS.
Michael Wade reminds us of the important things.