addictedcs

Balancing it with other duties is going to be hard, though I will try to explicitly divide my time into "one-week marketing / one-week dev work." Inside each week, I will try to have days fully reserved for non-work activities.

Programming keeps me in this perpetual cycle of "one more thing for today/this week" which locks me in the IDE without end in sight. I will postpone any dev work that needs to be done until "dev work week" arrives.

1. Read more books, less social media/news.

2. Spend more time with my friends. I haven't seen some of them IRL for more than a year.

3. Exercise more, play tennis with my daughter, spend quality time with my kids.

4. Spend more time with my parents. They've become visibly older in the last years, an observation that scares me.

5. Focus more on marketing for the businesses that I've bootstrapped. All the shiny new features that are developed are not as important as getting more people to use your product.

6. Promote open-source project to 1k GitHub stars[1]. I know it isn't very meaningful, but it's just nice to receive a bit of recognition from the community.

7. Enjoy life, don't stress about all the little things that happen along the way.

Happy new year!

He viewed his performances more as "experiences" and certainly pushed the boundaries of the conventional style of playing classical music. I really like his renditions of Bruckner, and the ending for Symphony N4 probably best describes why [1]. He does not rush, letting the music sync in, undoubtedly different from the "right" version.

Not being afraid of criticism is an essential quality of people who discover new things. Smart people often get dragged into the "correct", "proper" way of thinking, doing science, playing music, drawing, or doing other creative work. This is the best way to learn, but unfortunately, you need to go on an unbeaten path that is often criticized and even ostracized to discover new things. The life of Van Gogh and many others is quite an example of that.

Treating your binary vector as a set allows you to use min-hashing as your LSH schema (min-hashing is just a random permutation of the given set). This simple trick makes LSH with min-hashing quite a powerful tool for binary vectors that are extensively used in recommenders systems and other domains.

I've used LSH + Min-Hash for image search (and subsequently for audio fingerprinting). If interested, I've blogged about it here [1].

On a different note, I wouldn't recommend building an app that is strongly integrated into the Shopify platform due to a myriad of reasons.

Shopify App store will not give you enough exposure to grow your customer base naturally, you will have to invest in your distribution channel anyways, but now you are tied to a 20% commission since your app is public.

App store ranking system is heavily tuned towards the rate of installations your app has, which means products that offer free, or very cheap pricing plans are getting to the front page. If you offer free or very cheap pricing you will get inundated with customer support requests. The biggest chunk of Shopify customers, have very little understanding how to run an e-commerce store. Handling these requests will be a nightmare. This also means that the Shopify App store is not used anymore by stores that are running on Professional or Shopify Plus platforms, since it is full of apps that are borderline scam, and they can't find valuable services by a simple search.

* Focus on the current assignment. Implement it using clean code principles, don't overthink the problem.

* Rather than spending time on design decisions, allocate time on handling edge-cases. These will save you from PageDuty alerts.

* Plan excessive for future use-cases only around data models that insert/read into the database. Data migration is super-painful. A more generic design around your database is almost always preferable.

* Have a feature toggling[1] service in your codebase. It will provide you with a better understanding of how you can implement new features alongside existing codebase in the same branch. Releasing features from long-running separate branches is almost always a wrong decision.

* Always keep in mind time-constraints and how urgent is the requested functionality. Don't let perfection be the enemy of productivity.

* Have a process in place that allows for the technical debt tasks to be tackled independently. It helps fix some bad design decisions, which become apparent in light of new requirements.

* actor-based approach to concurrency[1]. Very useful when you want to design your code lock-free. Treating instances as agents that read messages from a mailbox, frees the developer from using low-level threading primitives. First time I've used this approach in production with AKKA and Scala. In F# it is much cleaner because the language itself is built on a better platform.

* exhaustive pattern matching[2]. Writing in F# means using pattern matching a lot. Exhaustive matching gives you the confidence to refactor and maintain your code. The compiler will warn you when adding a new value in your type and not covering the execution path that uses it. It catches a lot of errors before you even push the changes to CI.

* obviously immutability, conciseness, currying, these have been mentioned so far by others.

One nitpick in F# are Exceptions [3]. They approached it similarly to how it is done in C#. You are allowed to define and throw an exception that will "jump" somewhere in the execution path. I prefer when a method returns Option-style types. This way, you know what to expect from a call, and pattern matches on the result without adding one more execution path in your code, which covers exceptions separately. It was added to support C# style error handling, though I very much prefer an error-code-based approach.

If you want a more interactive source you can play with python notebooks from the music information retrieval site [2]. I've found it helpful, as you try some of the described music theory concepts in a programming environment.

Shameless plug, I've also written about how audio fingerprinting works [3], which touches on some of the topics regarding music theory.

Overall I invested a lot more time in it than the monetary reward I received. I don't complain since I enjoy working on audio/video fingerprinting and databases. On top of it, the pay at this stage is on par with a regular SE job with the bonus of working on things that I enjoy. I can call it a bootstrapped business now.

In some sense, I think about opensource similar to the work of art. You do it because you genuinely like to create/build things and showcase them to the general public. You don't do it because of the monetary reward. A good writer is one that has to say something, not one who writes for the sole purpose of getting on the NT bestselling list. Opensource is similar.