Spilling the beans

It's now 2021, which means that I have been a professional software engineer for over 10 years. Having also spent thousands of hours outside of work reading, practicing, and and tinkering, I now consider myself a master of the craft. As such, I consider it my duty to try to put into words what I have learned so far in my tech career. It's time to spill the beans. I will attempt to describe exactly what I think it takes to create a masterful technical implementation.

  1. Tooling

    I think it's safe to say that software has become immensely complicated. For any given technology, there is a wide array of best practices, standards and idiomatic ways of doing things. Once you learn one, another pattern comes along and you might have to reevaluate the way you were doing things previously. To help us mortals stay on course it is highly advisable to rely on tools to nudge us in the right direction. The web community is great for tooling and below is my current, go-to toolkit:
    • vscode - hands down the best (and free) code editor.
    • Git/GitHub/Git Bash - Git is currently the most popular version control system, GitHub is the best place to host your git-controlled projects and Git Bash is my favorite command line terminal for windows (comes with git).
    • smartgit - a UI client for git as to me, it's much easiest to work with it through a UI rather than the command line.
    • Lighthouse - a great website auditing tool and it's already built into the Chrome browser.
    • TypeScript - I don't write any JavaScript code nowadays and have switched completely to TypeScript, which I believe helps me write better code and provides a better development experience. I also highly recommend using TypeScript in strict mode.
    • Prettier - a fantastic code formatter.
    • ESLint/Stylelint - static code analysis is fantastic for enforcing code standards. ESLint can analyse your code while Stylelint will analyse your CSS.
    • npm-check-updates - I'm obsessed with staying on the latest release for my app's dependencies and this tells me if I'm not.
  2. Community

    For my work, I largely rely on the work of other developers as the building blocks for my applications. Even this seemingly simple site has a dozen dependencies and a couple dozen dev dependencies. This way I save myself an enormous amount of work trying to recreate the wheel.
    My process for selecting technologies to work with is embarrassingly simple and it really comes down to 3 simple questions:
    • How many stars does it have on GitHub?
    • How many weekly (usually npm) downloads does it have?
    • Does it have any obvious disqualifying factors in its repository like an ancient "last commit" date or a depreciation notice in its README.md?
    For the truly big decisions I also try to understand the public sentiment towards the technology and read about other developer's experiences. At this point I will turn to some good old Googling. Hacker News and Reddit searches are usually worthwhile and they can be easily searched from Google by appending site:reddit.com to your search query for Reddit-only results. Websites like stateofjs.com also offer great insightful into technical trends.
  3. Productivity

    The formula to define one's productivity is: productivity = focus intensity x focus time The steps one must take to maximize their productivity depend on the individual. For me it helps to be in a comfortable position that I can spend hours in, ideally free from distractions. Soundproof headphones and repetitive music work also wonders for me.
    Beside any technical recommendations, it's imperative to always take good care of oneself. This is where good sleep and exercise come into play. Taking care of these will help maintain a focused mind. Lastly, I've found it hard for myself to stay highly focused that I'm uninterested in. If possible, try to make your work interesting - be it through finding it yourself or asking for it from your lead.
  4. Development

    When it comes down to getting down and dirty with the implementation details I like to keep things as simple as I can. Front-to-back-to-mobile should all preferably be implemented with a single technology. My preference at this time is Next.js for frontend and backend development with react-native for mobile. This presents a highly efficient combination allowing one to re-use some code between different code bases (since they're both built with React), especially if using a common UI library like react-native-web.
  5. Deployment

    As with development, it's good to keep it simple. Docker, micro-services, kubernetes, etc... are all best left to enterprise development. I've had great success with serverless deployments.
    After attempting to create my own deployment library for AWS, I think it's much more straight-forward to use a more established platform like Vercel. Much of the vital web things are already baked in like analytics, CDN hosting and automatic deployment from commits. There is zero configuration required if you're already developing with their framework, Next.js.
  6. Maintenance

    When thinking about maintenance of your software you should first consider if it's even worth maintaining. Have you found a product market fit already and have some degree of confidence that your product will be around for years to come? If not, you would very likely be wasting time writing tests and worrying about long-term maintenance. Time that could be better spent on improving the product.

The rise of the long tailed beast

Some time ago I watched a pretty cool video about "long tail websites". A long tail website aims to attract visitors through its sheer number of pages and visitors can be monetized through ads. Of course, and as always, marketing and SEO are key. An example of a successful long tail site could be a thesaurus website listing hundreds of thousands of pages for different words. Much of the site content could consist of data scrapped (ex. sample sentences from children's books), which is exactly what the video creator claims to have done. In essence, this is a way to monetize data. The main challenge here is figuring out how to collect, analyze and present big data in an interesting way.

Having just moved on from Tomati that had hundreds of thousands of restaurant inspection data I got this idea 🤔... and that's how https://score.restaurant/ was born. Will it succeed? Will it get visitors? I don't know, but I want to give it one more shot. At the very least it was a worthwhile experience to get a blueprint to quickly (and freely) create and deploy sophisticated web applications. In my next blog post I'll detail exactly how I did it.

Good night, sweet Tomati

Four years ago, my team and I started a in-house project called Tomati with a goal to aggregate the health inspection data and use it to rate restaurants across Canada and US. Today we officially calling it quits.

While it started out as a passion project to try to expose naughty restaurants, I've come to realize that maintaining over a dozen scrappers for crappy government sites was not a good use of our team's time and resources. Getting exposure through Reddit and getting interviewed by the news was cool, but getting harassed by restaurant owners for minimal gain is just not worth it. In the end, we failed to find a way to keep users to coming back and also, don't want to be in the business of selling negativity.
Lessons Learned:
  • Never cheap out on server auto-scaling in case you accidentally blow up. Getting hugged to death when it's time to shine and getting angry emails and 1 ⭐ reviews is a very feelsbadman moment.
  • Reddit is fantastic for marketing and getting feedback. Just need to find the appropriate subreddits and be prepared to engage with its inhabitants.
  • Figure out how the business will be monetized right away. How will you keep the users coming back? This is where the network effect is most powerful.
On to the next one.

Huegasm is now free and a look into the future...

About 5 years ago I moved to a new apartment and wanted to synchronize my music to the smart light bulbs in my living room. And so Huegasm was born. Originally developed solely as a web app for synchronizing music to Philips Hue lights, its best iteration came in the form of a Chrome browser extension that, as of today, I am offering for free!

Why the sudden generosity? The Chrome browser team announced that they'll be removing the billing API. The $ that the extension brings in monthly is not worth the trouble of trying to migrate users to a new payment system, especially given that Chrome will not allow exporting of its licensing data. The other big benefit for the user is that they'll now be able to load Huegasm from any other browser that supports extension. Chromium-based browsers like Brave should now start working with Huegasm which is awesome.
Huegasm was my first real software engineering project outside of my usual client projects and it it has been a fantastic learning experience. It has shown me the importance of a need for a more thought-out business model which would encourage me to provide more updates and support for the future. A one time fee, which was the case with Huegasm, is just not a worthwhile time investment. Of course, all mistakes can be forgiven in the world of business with a stellar marketing execution.
As I continue to move forward, I want to explore the benefits of creating "long tail" web sites. I must minimize the time spent working on platforms (ex. iOS, Android, Hue) which tend to end up restricting, monetizing and controlling me.