Category Archives: _Micropost ๐Ÿช

Tiny, short thought. Less polished.

Experiment: Categories for my posts

I’m trying something new. I added WordPress tags for higher level categories of content that cut across the typical tags:

  • Deep Dive: Longer, more detailed posts that require significant research. Very expensive to produce.
  • Tech: Normal technical blog post. More polished than Lab Notes, less researched than Deep Dive.
  • Lab Notes: Rough notes, typically technical, usually bullet points about some topic.
  • Essay: Nonfiction writing, usually nontechnical.
  • Micropost: Tiny, short thought.

I hope that by categorizing things this way and acknowledging that this blog is a collection of different art forms (that appear similar because they’re all writing), I’ll be more comfortable publishing publicly. For a while I was scared to publish because I don’t have as much time for deep dives as before, which is what people seemed to really like, but acknowledging these different categories and specifically calling out a shorter, rougher, less polished piece as such takes the pressure off of publishing it.

3 years of Timestamps

It’s been three years since I launched https://timestamps.me, and a little less than three years since I stopped working on it.

Since March 25th, 2020, here are the stats:

  • 4465 uploads
  • $437 revenue earned

This works out to about 4 uploads per day, which for me, is a great success.

Rough recap:

  • Feb 2020: I was taking my gap year and wanted to code again. I had the idea to work on a little tool for exporting locators from Ableton Live sets. I thought it would be fun to just quickly make it into a web app, and ship it. I ended up hyperfocusing on the problem space and making it super high accuracy (handling tempo automation). I also made it work for FL Studio which was difficult but a fun challenge.
  • March: I launch the web app (timestamps.fm at the time) and start trying to get users. I was extremely difficult. I posted on subreddits for DJing, Ableton, FL Studio, and Rekordbox.

Learnings and mistakes:

  • I wasted a ton of time porting to Google Cloud in an attempt to make the site run for free. It was an utter failure and I ended up porting back to Heroku.
  • I spent a ton of time DM’ing music producers that were performing at “e-fests” which were popular at the time (due to Covid-19, which was in full swing at the time). This was doomed to failure โ€” none of them would find value in this niche product.
  • Ironically, the customer and user that got the most use out of it reached out to me, not the other way around. The CEO of a company that makes a high volume of DJ mixes for hotels and restaurants DM’d me on LinkedIn asking to set up a call. He found me via SEO/Google search and was able to find me on LinkedIn because I had been bold enough to put myself as “CEO, Timestamps.fm” on my LinkedIn profile. Lesson: Be bold!
  • If I really wanted to do this in a time and capital efficient way, I should have put in way more customer research before building this whole product (including super advanced features like hyper accurate tempo automation support). I didn’t care about this though because I was on my gap year, and was first and foremost doing it because it was a fun programming challenge.
  • I wasted a ton of time hand coding HTML and modifying a free HTML theme I found online. I eventually rewrote the whole site in Bootstrap which took a bunch of time. The breaking point was when I was trying to make a pricing page with different subscription options. It was going terribly with my hand-hacking of the HTML page, and Bootstrap included great looking UI components for this already. Learning Bootstrap was probably a good investment.
  • If I were to do it again: I would use no-code WAY more. I would try to avoid hand-coding any HTML if at all possible, and just do the minimal amount of code to have an API server running for doing the actual processing.
  • I put up a donation button. In 3 years, I’ve had 3 donors, for a total of $25 in donations.
  • I eventually learned that the majority of DJs don’t care about time accurate records for their DJ mixes. A small subset of them do โ€” those that operate in the radio DJ world where they have licensing or reporting requirements. One DJ said they were required to submit timestamps so a radio show could show the track title on their web ui or something like that. But I was later surprised to see the site continuing to get traffic. Clearly there are some people out there that care. I haven’t bothered to figure out who they are or why. The site continues to be free, with no accounts necessary.

Smart things that I did right:

  • I had a lot of requests to support of DJ software like Traktor. I ignored them which was a great move โ€” it would have taken a lot more time and wouldn’t have moved the needle on the proejct.
  • I negotiated a good rate initially for the commercial customer’s subscription โ€” $40 a month! I then did a questionable move and lowered it significantly to $15 or a so per month when I made it free. The deal was that I would make the site free, but the customer would pay to help me break even on it. I later lowered it even more for them when I switched to Timestamps.me ($~20) which is a much cheaper domain then timestamps.fm ($80). It was a good move to move domains โ€” that domain was a risky liability โ€” if the customer ever left, I would have been stuck with an expensive, vanity domain for no real reason. I wasn’t going to become the next “last.fm” anytime soon.
  • SEO is the main driver, and continues to be until this day. I dominate the results for “ableton timestamps” etc. Posting on reddit and the Ableton forum were good calls.
  • I experimented with different monetization strategies. Pay per use was an interesting experiment and I made a small amount of money.

If I were to actually try to start a business again, I would do a lot of things different:

  • Be much more deliberate about picking the market and kind of customer to server
  • If you want to make money, make something that helps people that already make (and spend) money make even more money (the fact that they already make and spend it powerful and important)
  • Pick a product idea that isn’t totally novel so that it’s not so hard to sell it or introduce. It’s great to be able to say “I’m like X, but different because of A and B and specifically designed for C”

WIP: “Interesting” is in the eye of the beholder

I posit that in many software projects there is a small core of the “most interesting” work, surrounded by a larger core of “support engineering”. The “support engineering” is in service of the “most interesting” core in order to make it usable and a good product.

For example:

  • Compilers: Core optimizations vs cli arg parsing
  • Kernels: Core context switching vs some module that prints out the config the kernel was built with
  • Audio software: Core engine, data model, or file format work vs UI work on the settings menu
  • ChatGPT: Core machine learning vs front end web dev to implement the chat web UI

But the funny thing is that “interesting” is in the eye of the beholder. For every person that thinks X is the “most interesting”, perhaps most technical part of the project, there will be a different person that is totally uninterested in X and is delighted to let someone else handle this for them. This very well may be because X is too technical, too in the weeds.

The generalizes to work and society as a whole โ€” people gravitate towards work that suits their interests. The areas they don’t find interesting are hopefully filled by others who are naturally wired differently. This does happen in real life but of course plays out less cleanly.

Tip: Have two checkouts of the repo

It can be handy to have two checkouts of a repo. One is the primary one (A) for working in. And the other is the “spare” (B).

This can be useful in a number of situations:

  • You’re in the middle of a rebase in A and want to quickly reference something in another branch. Instead of having to mess up your rebase state, or go to github, you just go to B.
  • You’re code reviewing an intense refactor of an API. It can be handy to quickly flip back and forth between the versions of the codebase before and after the API change to get a better sense of what changes. Sometimes the diff isn’t quite enough.
  • You’re code reviewing one branch and want to quickly code review another in a way that’s “immutable” to your work environment.
  • If you want to quickly flip back and forth between builds of two different branches.

What’s with the name?

I chose “offlinemark” as a handle for a few reasons:

  • I didn’t want to use my real full name as the handle because of privacy and because I don’t consider my last name a 100% stable API. Ideally this username would last a long time.
  • I like adjectives as usernames, but also including my first name makes it feel a bit personal.
  • It’s highly unique. There’s a strong chance I can always get this username.
  • It’s a bit techy, which is on brand.
  • Aesthetics. I dislike numbers in usernames. I like the visual appearance of the text (all on one line, no underhanging characters).
  • It’s an aspirational reminder. A lot of the best things in life are offline.
  • It appeals to my ironic and quirky sense of humor.
  • And, it will be true one day.

Why I enjoy hanging out with entrepreneurs

I’ve been a regular attendee at the Indie Hackers Berlin meetup lately. I’m not particularly an entrepreneur myself, but I love hanging out with them because they generally have many of the following qualities:

  • High functioning
  • Smart/Clever (to be successfull, you kind of have to be)
  • Ambitious
  • Creative
  • Unconventional thinkers
  • Into self development
  • Leadership

All of which make them very fun and interesting to be around!

Why I write in public

Note to self. I write because:

  • Improved clarity of thought
  • Archive of thought
  • Improves writing skills

In addition, I write in public because:

  • It reinforces a mindset of speaking my mind in public (i.e. courage)
  • Receive valuable feedback and external perspectives
  • Build & maintain relationships โ€” people can learn about me and keep up with what I’m up to

Furthermore, I’ve found that it’s addicting to write in public.

  • It feels good to look back on writing and realize you’ve expressed yourself clear and well. And that you understand the topic well know.
  • It feels good to develop a voice.
  • It feels good to watch yourself improve. You can write better, faster with practice.
  • You become more self-observant of your thoughts, and realize that there are so many interesting things to write about.
  • It feels good to get positive feedback on your writing.

Edit: 2023-08-01

Furthermore, I think it’s a good idea to even default to sharing in public (vs writing in a private Note app, then selectively copying to publish).

If you get busy and don’t get around to that explicit publish step, there is a 0% chance that anybody else might discover your work, which might actually be very good. If you default to publishing publicly, that doesn’t mean you need to actively promote it, but at least there’s a nonzero chance of someone finding it eventually.