A couple of years ago I noticed that social media started taking too much attention from me than they deserve. I didn’t spend too much time overall, just several times per day I checked Facebook, Twitter, Instagram. The most obvious solution was to use a website blocker. But it didn’t work out for me since these blockers were browser extension and it was enough to disable that extension to continue browsing my Facebook feed.
In August I’ll join Antler startup accelerator program in Stockholm which is aimed to help to find co-founders and found a startup.
As a technical co-founder, it’s important to make an MVP most effectively. This blog post would be a reminder for me about things that should be avoided.
This blog post contains a lot of JS charts, so it’s better to view it in a browser.
Lately, I’ve been thinking about startup trends. A few years ago everyone was obsessed with blockchain, then chatbots, AI, ICOs, and so on. Every other year there is a new hype train that people want to jump on.
Many of these new hot startups get submitted to Product Hunt. So I decided to parse all featured products submitted since its launch on November 24, 2013, until June 30, 2019, and try to get some insights from the data.
I try to unload all information that has any meaning to me from my brain to external storage because I don’t like to rely on my memory nor do I trust it.
In this blog post, I’m going to describe my current approach of working with a personal knowledge base.
Over the 8 years that I use git, I tried different GUIs and TUIs but nothing really stuck with me (I’ll list a few of them below anyway). Some of them had great UI but didn’t cover my whole git workflow. While others had a lot of commands the user experience wasn’t that great. So I always ended up in a terminal running some command because either it was faster or a git tool I was using at that moment hadn’t supported the needed command.
A couple of years ago I decided to go all in with git CLI and incrementally improve my workflow.
First I was thinking of making my config clean, adding comments, and publishing it to GitHub. But other people have other approaches to working with git, use different command line shells, and even have their own mnemonic rules for creating command shortcuts. So most developers can’t use my config out-of-the-box and would be required to tailor it (which few will do).
So instead, I decided to write a blog post, where I show you how you could incrementally improve your own git CLI workflow.
Recently I shut down one of my projects ListList, so I decided to write a guide on how to properly do that since there is not so many info about that topic on the Internet.
This guide is about closing a web product, but with some minor changes, you could apply it to other types of products.
I won’t discuss whether it’s the right decision to close a product and what can you do to avoid that. I also won’t discuss legal, financial, technical, and other issues that you might be required to deal with (especially if you’re closing a big product).
My focus in this guide will be on establishing good communication with your customers to make the shutdown less painful for them. They rely on your product and will be upset about its closure. Your goal is to make that as less uncomfortable as possible.
Recently I had this issue when I find some good information source, but I don’t like the medium it gets delivered. Usually, it’s some email newsletter that pop ups in my inbox, which gets me distracted. It’s a way much better to get it delivered to my RSS reader. Or you can set up cron jobs errors to be delivered to your email inbox. But you prefer to get them in a Slack channel.