The easiest way to start to tell the 78 Solutions story is with a section on the origin of 78 Solutions.
Etymology
The whole 78solutions idea was several strange coincidences enabled by an available (and pronounceable) .com domain.
78 was originally seven8 - it was a username. My initials are the seventh and eighth letters of the alphabet and I was just cool enough to be into letter number ciphers in high school. “-78” became something of an informal signature. Then I got into grade twelve and stopped being so pretentious.
Years and years later, I started to realize that I was only really good for 1.5 big things a week. They could be really big…and my standard for ‘really good’ was quite high. But if I wanted to ship high quality work and constantly improve, I could solve 1.5 problems a week. I’m lucky enough to have always been able to make a living doing things I would do for free, so I wasn’t really much for vacations then (and I’m still not) so I realized that I was reliably solving 78 major problems a year. 78 was good for 78 solutions a year.
You might think that I went out and snapped up the domain right then. And you’d think wrong because I had bigger problems than adding words to an idea I was just formulating. I was finishing a marketing degree, importing surveillance cameras, failing badly to implement retail intelligence based on home automation and surveillance equipment and had started a magazine with my friend Stacey.
Years and years after that, I started to realize there was something to this 78 idea and all the things that flowed from it. 78solutions.com was available. And the seeds for this site were planted. You might think that I rushed out and started writing content for it. And again, you would think wrong.
When I Come Around
You know how that seven8/78/78 problems/78solutions.com thing just kind of came full circle over a couple of decades? When applied correctly, 78 problems will create many of those fortuitous little coincidences. But they’re not coincidences, they’re signs that you’re getting experienced, skilling up and choosing the right problems.
When I bought 78solutions.com, I was obsessed with another problem - web performance. I started a consulting company shortly after the Regina Streets Magazine folded and my next magazine (end magazine) proved to be a comedy of really embarrassing, expensive and discombobulating errors. You may think discombobulating errors doesn’t make much sense…and that’s a good thing because it means that you weren’t involved in end magazine. My consulting practice started going more and more dev ops heavy and I started writing a lot of scripts to test performance.
Siteimp was born out of those scripts…eventually. I had solved so many problems with performance and uncovered so many ways to both optimize performance and uncover bugs with front end testing that turning into a product seemed inevitable. Suddenly I could do full site scans and started to find a whole lot of things in common. For example, there are some really really slow contact form solutions out there. I had this tiny little Django api and a static form that I used to get contact information sent to my Microsoft Teams channel. It was fast so with a bit of work, Formimp was born. All along, my consulting company was humming along.
Time became a problem.
So Siteimp and Formimp sat, silently making small amounts of money each month. I barely touched them at all and the websites are very poor (I’ll fix it, I promise). But I managed to sell reports through friends I made in business school and add on Formimp implementations at the same time. My marketing degree and serial founder gig/job/calling/vice came around to help each other.
And more years went by.
Then, a few weeks ago, I was working on an Electron app for a product called Fitness Tracker when I started running into some issues. Electron can be quite slow, I needed some integration testing that blended performance and I wanted to be able to replicate support issues quickly.
And everything came around again.
You see, I had this API (Formimp) that accepted form inputs and now sent them exclusively to Slack. I realized that with a few architectural changes, I could use it within Electron and avoid the API altogether. Heck, with a very small bit of work, I could even accept logs through it. And…I already had a performance tool (Siteimp) that was optimized for browsers…but Electron is really a browser. It even had a simple engine to run synthetics.
So, I implemented a custom structured logging utility that integrates well with Siteimp, rewrote Formimp so it was more performant and would integrate inside of Electron and suddenly, it all came full circle. Previous solutions were solving current problems with tweaks. And with such a good understanding of the Formimp problem, the rewrite was extremely fast and smooth.
Circles
That kind of thing has happened for as long as I’ve been practicing the 78 Solutions method. While I don’t fully understand it, it seems to be based primarily around deliberate practice. I reuse code and repackage old solutions to fit into new problems. That is a deliberate, reflective process, but it also involves constant bug fixes and refactors. Constantly reusing code and fixing bugs shows you all of your bad habits in excruciating detail. For example, I have been using the same UIKit based toolkit for websites for a long time because I am a terrible designer. Then I realized that I was implementing terrible designs with a good tool because I am a terrible designer.
Suddenly confronted with the grim reality that I could not design my way out of a wet paper bag, I was at a crossroads. So I did what any sensible person would do these days: I asked ChatGPT (and it has been absolutely excellent). And so this week, I am spending 1 full problem on learning the fundamentals of design, visual hierarchy, font choices and visual flow. I have used what I have learned so far to analyze all my old designs and…yes, excruciating.
But circles. Prior Greg’s design sins are exposed because Current Greg knows more. Dogfooding is one of the world’s great teachers and so as I use Siteimp to look into Fitness Tracker, I realize that that tool isn’t right and will need to be rewritten. But being able to replay bugs, share them with developers and turn customer support into QA teams is very much in reach.
And now that I can design a tiny bit maybe that rewrite won’t look like dog food? Circles. Circles again.