There are projects that come from outside, from paying clients, from partnerships, from collaborations. This one did not have an outside driver. It was a purely internal effort, driven by personal itches. No one was paying the bill.
It was also unlikely to ever get built. I have a hard rule in my development work; no tooling. I do not write my own tooling. I do not write plug-ins for VSCode, Sublime etc. When I first got into web deveopment in 1999, I found a feature in Cold Fusion Studio that allows for creation of IDE wizards that could be use to build out codes. Almost all editors contain some version of these tools. Sometimes they are called snippet, code samples etc. These features always appear to hold a lot of potential.
I learned the hard way. The potential was never there. I spent over a month of nights and weekend coding up a ton of wizards in the Cold Fusion Studio for creating all types of forms, scripts etc. Once they were done, I never used them.
Code reuse has never worked, for me, in a way that lives up to the theorical potential. Too much of what we create in code for clients, while generally similar, is to custom and bespoke. Developers love the idea of code reuse, but in practice its a false ideal. We try, and re-try, but it does not work.
Hence the my mote of ‘No tooling’.
After 25 years of coding, this concept has become almost dogma. I have seen it crop back up in blog articles, team projects and even in my personal projects. In the end, the time required to review and customerize the products of tooling never provides enough benefit. The effort to fit existing tooling to a project, often equals the work to generate the work from stratch.
What Changed?
Nothing really. I remain very sure that writing my own tooling is not a great idea. I buy before I build. Until now. Over the last five years I have noticed trends in software, and more specifically, how I use software that has changed.
During COVID-19 I spent a lot of time working from my basement office. One side of the room has a my desk and monitors. The other side of the room became a wood working space.
Woodworking changed my view of software. The experience of software, the experience of using software.
I have two chisels. One was purchased from Home Depot for ten dollars. Another was purchased from Japan. Same tool. Different makers. Doing the same job. The experience of using these two tools in projects is very different.
The ten dollar chisel never feels good in my hand. The Japanese chisel feels like an extension of my hand.
One tool has tool feel, the other does not. Very quickly I realized that shape and form of the tool was important.
I started to notice how other tools on my work bench has ‘tool feel’. And which ones did not. It was not long before I started to apply this perception to software work.
Can Software have ‘tool-feel’?
Once I started to apply this same observation to my work, I realized very quickly that software can have tool-feel. I started to noticed that command line GIT commands has a feel. Google Calendar had a feel. Some Google GCP projects have a sense of tool-feel. AWS has no tool feel. It never feels like an extension of my (coding) hand.
All products made my Microsoft, for me, lack tool feel. I get no sense of innate craftmanship.
What gives tool-feel?
Mapping maker joy to tools is strange, I know. But once I started I noticed very quickly that the tools I gravitate to in my software work can and often have tool-feel. Some more. Some less.
I wanted more. Once I was aware of this preference, this sense of joy when using a one tool vs another, I got obsessed, and tools for the tell-tale signs. I found them, and quickly. It seems I really needed to just sensative myself to the question and the answers flowed in.
Tool-Feel
While I am still mapping this obsercation, the end result of this effort, was a need to break my ‘no tooling’ rule.
1. Number of Clicks
I noticed that the numbers of clicks to get any task done had a lot to do with how much joy I had with doing the activity.
2. Information Overload
I noticed that the simplicatiy of the UI/UX impacts tool-feel. Simple workflows and processes required less mental work. Less was more. I noticed that the more CTAs in a workflow, the more mental work was needed to adopt a given tool.
3. Install Requirements
The more I have to install the more I have to attend to and watch. Install the app on mobile. Install on desktop? Fewer, more bespoke tools become the preference.
4. Context Switching
My big learning, was that context switching lowered tool-feel.
Again, Why Build Fractional?
As a fractional CTO, I work with a range of clients, from short term coding work, to packages, retainers and mixed stock packages. In a given day I have to switch context between two to three clients. I needed a way to keep on top of the work, and its owner. I started to noticed that applications like Harvest, Toggl, Asana were a problem.
They had no tool feel. Each had their own app install. Complex web sites and almost all work required context switching and countless clicks. Work, unbillable work, just so I could do billable work?
A Better Way
I started too examin the tools I used every day, tools that I used for a range of other activities. Google Calendar popped up. I could not consult with more the one client, if my calendar was not my system of record. I already had it installed on my phone. And it was already my default tab on my browers.
Finally I noticed that Google Calendar knows who and when and what I am doing. If a meeting goes long, I can extend the meeting. I my Calendly integration honors my calendar and does not allow for double booking. Calendly has tool feel. A lot of it. Google Calendars has a ton of tool feel.
My final observation was that at the end of the day, if I track all my work in a calendar, even if I was just coding for a project and not on a zoom with anyone, I had a perfect record of my work. No need to sync or reconcile with time tracking product. No need to install more mobile apps. It is super stable, free and battle tested. No learning curve.
Make Google Calendar Better
That was when I decide to break my tooling rule. It started with a simple script and set Auth0 credentials. Within a few hours I had the worlds more intuitive time tracking system. I found within days that I had tooling that removed work from my day. My simple POC allowed me to work across projects, tracking my work to the second, and account for every minute of the day.
The final nail in my ‘no tooling’ dicate, was when I write a simple CRON that calculated the daily billable value and Texted my at 6pm, as I entered the State Street Subway, how I had done that day. It had simple logic that would redicule me if had not enter notes, or spent too much time on non-billable.
There was a nice warm feeling to be had, as my Orange Line train passed through Back Bay Station, knowing that I had done good work, and was on track. No report to read. No app to open. Just the simple one line SMS message; ‘Yo Cuddles, you worked on three projects today and made $XXXX. 5% ahead of week over week’.
Fast Forward
So we build Fractional. Its the pure express of personal self interest. Its not a one size fits all time tracking system. Its the smallest tool possible. It fits into existing tools. If Google is working that so it this solution. I have has to switch context to get context.
I now run my fractional CTO backoffice from the subway, on the ride between State Street and Backbay!