As the new year starts, so does a good time for a new set of goals. Having recently transferred from the delivery side of BlueBolt to the sales side (in a Sales Engineering capacity), I bring into the new year an ability to focus a lot more on my personal brand. It seems that year after year, I strive to write more; and damnit, this year I'm going to!

I have learned a lot after each attempt on what I need to set myself up for success. As with most anything I set my sights on, I need goals and a plan. 10,000 words is too broad of a goal to achieve on its own, but if I break it down into smaller posts, it comes across as manageable. The goal breaks down to at least 417 words per post, twice a month. Counting the words in this post, I am already 8.81% of the way to my goal for the year!

Knowing how long each post is makes filling my quota feel achievable. The hardest part isn't in hitting word counts, though. If fact, I was a little surprised when I typed out a stream of conscience in 2017 that hitting 500 words is easily achievable. Figuring out what to write is the hardest part for me. It's like cooking. I'm plenty good at creating food ad-hoc, but it'll be my go-to favorites. My culinary skills really shine when I have a recipe from which I can gain inspiration, modify to my audience's tastes, and plate a delicious meal. To have something to write about, I am going to focus on two different projects that I have been rattling around, trying to find a good reason to actually execute on my vision.

Shopify App For Managing Webhooks

The stock UI to manage webhooks in Shopify is terrible. It's just a simple modal that lets you specify the topic, the URL to submit to, and the API version to use. There is a button to test the endpoint, but all it does is submit a test record - one that is incomplete and completely unreflective of content the store has. There are no options to pause or suspend the broadcast, only delete the entry. There is no logging of whether the call succeeded or failed, only that it was broadcast.

Since the Shopify Admin API allows for managing webhooks, an app can tap into a lot of information that the Shopify Admin doesn't surface. I wasn't able to find any apps already in the store that provide for this functionality, so I think I am onto something unique. I have a rough outline of the steps I want to take to have this reach its full functionality. Or if not fully functional, at least an MVP.

Project Estimator, Possibly in Episerver CMS

BlueBolt's practices are split into roughly five different offerings: Shopify, Episerver CMS, Epi Commerce, Bravo Squared search solution, and an amalgamation of smaller projects - DNN, Salesforce, BigCommerce, Insite, etc. I have pretty well solidified my knowledge of what the backend of Shopify can do, what creative things we can massage out of the platform, and BlueBolt has some great talent for working with the front-end of Shopify. We also have world-class talent for Episerver; but this is a platform that I have been reticent to dedicate real time learning. In retrospect, I think mostly it has been because every Epi project seems to start completely from scratch... lots of stuff that has to be recreated, with slight tweaks for each and every project. I haven't been able to really find the enthusiasm to dive into the product because I haven't known what to build.

Related to this is that at BlueBolt, we piece together our estimates using a complex spreadsheet. Talking with my peers, this seems to be the way almost every agency does it. The spreadsheet gets more complex the larger and older the agency gets, until it reaches a point where no one knows who created it or why certain "features" are included. Explanations of The Spreadsheet seems to include a lot of "but we don't use that" or "I don't ever change this". It is a fascinating peek into the odd bureaucracy that sneaks into the sales/estimation process.

So what if I take the spreadsheet and give it a similar UI, but store everything into a database? There is a laundry list of features that a spreadsheet inherently includes which would need to be added, but I think a basic, useful intro should be a great place to start. Of course, "starting" the project is going to back itself way the hell up into trying to find a better way to actual start a project. More on that in the future.

Timeline

Twice a month, I am going to publish a blog post. That's means two weeks per post. The first week will be for outline, research, proof-of-concept, and initial draft. The second week will be for editing, replaying the steps taken, and publishing. To keep myself interested, I think I will be alternating posts between the two projects or one post a month for project work and one post about running/family/non-coding topics.

Wish me luck, and please return often - hopefully once a fortnight!