Articles • Hrvoje Šimić

Merry Christmas

Hrvoje Šimić (shime@hey.com) — Thu, 25 Dec 2025 06:19:23 +0000

This Christmas is special because my little daughter realizes it’s Christmas for the first time today. I’ve woken up early, turned on the Christmas lights and put the present under the Christmas tree. This feels better than receiving a gift ever did and so from my experience it’s definitely true that “giving is more blessed than receiving”.

Jonathan Haidt writes about this in The Happiness Hypothesis (which is one of the best books I’ve read this year):

Those who reported giving more help and support to spouses, friends, and relatives went on to live longer than those who gave less (even after controlling for factors such as health at the beginning of the study period), whereas the amount of help that people reported receiving showed no relationship to longevity. Brown’s finding shows directly that, at least for older people, it really is more blessed to give than to receive.

So giving is the right to do even if you do it for purely selfish reasons. May this day be very unproductive and full of kindness and giving. Merry Christmas.

I've just deleted five of my ideas

Hrvoje Šimić (shime@hey.com) — Sun, 03 Aug 2025 02:49:48 +0000

I keep them in IDEAS.md file on iCloud. I have shortcuts on both my phone and laptop to open the file instantly. I don’t need the sync to be instant. I just want to have the latest version when I run these shortcuts.

I added some ideas on my phone yesterday. Today, I opened the file on my laptop, but I didn’t notice it didn’t sync the huge <0.1KB change, so when I saved the file, the changes were overwritten, which means my ideas are now gone.

So a whole day has passed between me entering an idea and me expecting to have it synced, so the iCloud sync had its time to run on all of my devices that are apparently online even when they are in sleep mode. It’s the year of the Lord 2025, I’m paying 10€ per month to Apple for this wonderful experience, and I can’t sync a fucking text file between two devices.

So I installed Dropbox, after a 10-year long hiatus. Maybe they know how to properly sync a text file. They don’t. Opening the file from Dropbox folder doesn’t guarantee it will open the latest version.

So it looks like the year of the Lord 2025 is still not the year when I can enjoy a text file that is synced between two devices in the Apple ecosystem. For now I’m going to have to keep my ideas file in an app, in a non-plaintext format.

So, I’ll go with Bear for now. The sync actually works great for my use case and I have additional features, like keeping my ideas as todos if I want. I value the fact that the ideas are actually saved more than the fact that the format of the file is plaintext. I can always export it to plaintext later if I want to, which is the main reason I want to avoid keeping it in Apple Notes.

Second goodbye to LinkedIn

Hrvoje Šimić (shime@hey.com) — Mon, 21 Jul 2025 05:31:23 +0000

I’ve deleted LinkedIn for the second time. I originally did it back in 2015 (maybe even earlier, can’t remember the exact year) because I couldn’t stand all the recruiter emails asking me to relocate even though I had specific instructions for them to not email me about non-remote job opportunities. Then two years ago I had to look for a new client so I thought LinkedIn would help with that. It didn’t.

The existence of LinkedIn fascinates me because most people can’t stand it, yet they don’t have a problem with having a LinkedIn profile, which therefore perpetuates its existence. Well, I don’t want to be associated with a network like that, so I’ve deleted the profile again.

It’s not mandatory and I think there are better ways to meet new people than by sending a connection request on LinkedIn. Like Twitter, LinkedIn at its best is a wrapper around email that they somehow monetize. I don’t see a reason for having an email wrapper when it’s so easy to just send an email directly.

It’s a really corporate place and I was never interested in corporate jobs or big corporations. I always enjoyed working with small startups where I have massive impact and responsibility, where I wear a lot of different hats, where I was part of something small trying to take a piece of the market from someone big and sluggish.

Shaving that yak

Hrvoje Šimić (shime@hey.com) — Tue, 15 Jul 2025 07:02:23 +0000

For the past couple of days, I’ve been waking up around 3:30 AM, excitedly jumping out of bed to make some tweaks to the website you’re reading this on¹. I’ve spent a lot of hours updating it to the latest version in hopes of improving the build time of 3 seconds, which is abysmal. After all this work, the build time is now down to about 100 milliseconds.

Of course, for one reason or another, it’s precisely now that I stumble upon Bret Victor’s seminal talk with the core argument being that it’s very wrong to have a delay in the feedback loop when you’re building something and that you should strive to make that feedback loop as tight as possible. I’m now very satisfied with the latency of the feedback loop being measured in milliseconds. I’ve underestimated how important this is, as these changes have now inspired me to make further optimizations that are now a joy to work on.

I’ve been delaying all this maintenance work as I didn’t consider this work important and saw this website and its source only as a vehicle for delivering blog posts. This is the primary reason why the entropy accumulated to such an extent that it was frustrating to even do the work that was allegedly the sole purpose of this website – writing blog posts. See, whenever I had a problem, I would just search for the plugin that solved it and just forget about the problem. But that, of course, resulted in the accumulation of technical debt, which I didn’t think something as simple as a static website could have.

The plugin added support for PostCSS to Jekyll so that I can use Tailwind. The fix to make the site pleasurable to work with was just to remove that plugin and run the Tailwind CLI in a separate process. Making live reloading work (which of course didn’t work with the initial 3 second build time) was a little finicky, but in the end simple to fix after taking a little break. This is just another example of the lesson that I should be skeptical about using libraries that wrap other tools to add support for something. It’s always better to just use the thing directly.

But to get back to the point, I’ve spent dozens of hours optimizing this website and I don’t regret it. In fact, I’m glad I did it. The best thing about having a website like this is how much learning happens, just like with any side project.

These past couple of days, I’ve learned a lot, not only some CSS features that I’m not going to disclose out of embarrassment for learning about it only now. I’ve used Claude Code and, in contrast to how I’ve been feeling about it during my work hours, I’ve been pretty impressed by it. See, I wrote a custom plugin for rendering emphasized code blocks² but I knew that it wouldn’t work if I updated to the latest version of Jekyll.

Thankfully, Claude added support for the latest version and even added tests to make the future upgrades easier. Of course, it didn’t think of the simple fix to the initial problem, of changing the configuration a bit, which means I lost a lot of unnecessary hours trying to make the plugin more performant with various hacks and whatnot.

All in all, I’m glad I didn’t listen to the voices of doubt in my head as I started this upgrade process, that told me that I should update to some more performant static site builder, like Hugo. I wasn’t confident that Jekyll builds could be fast, especially with PostCSS. But I’m glad I can say that this site is running Jekyll since 2011 and it’s going to stay that way.

1. For some reason I’ve been following my own advice.

2. You can see it in action here.

The prison of context

Hrvoje Šimić (shime@hey.com) — Fri, 10 Jan 2025 07:15:00 +0000

I’ve recently stumbled upon “Stockdale Paradox”, named after Admiral Jim Stockdale, a prisoner of war who was tortured during his eight-year imprisonment during the Vietnam War. He said that he survived because he maintained the faith that he could and would prevail in the end, but at the same time had the discipline to confront the harsh reality. He mentions that it was not the pessimists, but the optimists who didn’t make it. ^[1]

This reminds me of a couple of things. Firstly, this is nothing other than a concept of “rational optimism” in the form of a more neatly named “concept handle”, to use the lingo of Scott Alexander. It’s not rose-colored glasses, naive optimism, but the more realistic one, the one that still acknowledges that reality is a harsh place, but the one that encourages belief in one’s own skills to overcome the difficulties, and is optimistic in that sense. Secondly, this reminds me of F. Scott Fitzgerald: “The test of a first-rate intelligence is the ability to hold two opposed ideas in mind at the same time and still retain the ability to function.”

Stumbling upon all of this made me want to write it down into my note-taking tool of choice only to realize that I have a “Stockdale Paradox” note sitting in it for the last four years, saying this:

In order to be successful in a startup world you can never lose faith that you will prevail, while still being disciplined to confront the most brutal facts that reality throws at you. #startups

See, this note was categorized into startups, so I didn’t think about it in a broader sense, and never thought about where it comes from. In some way, this categorization of the note made me neatly file it in my mind as well. It was neatly packaged in the “startup” box, never to leave it.

All of this is another reminder of what Taleb wrote in Antifragile:

We are all, in a way, similarly handicapped, unable to recognize the same idea when it is presented in a different context. It is as if we are doomed to be deceived by the most superficial part of things, the packaging, the gift wrapping.

You can read the whole story here.

On evil being that which is positive

Hrvoje Šimić (shime@hey.com) — Wed, 08 Jan 2025 22:23:00 +0000

I like Schopenhauer’s ideas more than I like Nietzsche’s and I agree with him that one can make oneself stupid by reading too much and I’ve re-read “On Thinking for Oneself” a couple of times, but that’s about it.

See, a couple of years ago I’ve read this in “On the suffering of the world”. In it, he claims that “misfortune in general is the rule” and that we think more about the unpleasant and painful things because that is felt directly, instantly and with great clarity. This instant property of the unpleasant reminds me somewhat of the asymmetry between the destruction and construction and how the good changes are usually gradual and incremental while bad things tend to happen suddenly and how this is one of the reasons why the news is biased towards negativity. It’s not only because we are drawn to the negative and so it makes economic sense to do so, but also because bad events are simply easier and more exciting to report on. It also reminds me of that Warren Buffett quote: “It takes 20 years to build a reputation and five minutes to ruin it”.

But I digress — reading “On the suffering of the world” made me stumble upon this sentence:

For evil is precisely that which is positive, that which makes itself palpable; and good, on the other hand, i.e. all happiness and all gratification, is that which is negative, the mere abolition of a desire and extinction of a pain.

And for the love of everything that’s holy, I couldn’t figure out why anyone would say “evil is precisely that which is positive”. But after contemplating a bit on this, I think he is referring to the fact that how the evil is usually an addition, while the good is usually a subtraction. Taleb calls this subtractive path to the good “via negativa” and in his books provides examples mostly centered on health and how instead of addition of complicated pills one would achieve better results by mere elimination and stop smoking for instance, or stop drinking, or overeating. So in this sense smoking and drinking is an evil that is positive because it’s an addition to the natural way of things and we would be good without it.

Schopenhauer, Emerson, and prompting yourself

Hrvoje Šimić (shime@hey.com) — Tue, 07 Jan 2025 22:28:00 +0000

Following MacIver’s Daily Writing Practice made me roam through my Roam Research highlights in search of good prompts for the daily entry. I’ve stumbled upon this one, from an article by Henrik Karlsson:

You can also get into this feedback loop by chasing your reading. You read and reflect on what you learn. Then you use those reflections to find even more interesting nooks in the history of literature, spurring more and more ideas. If you don’t have access to interesting peers, you might feel like you are missing out. But books are the main peer group of any thinker.

“Books are the main peer group of any thinker”. This implies “thinkers” are in a sense anti-social and seek community in books instead of in their local community. Which reminds me of Schopenhauer and the sense of isolation I get from reading his work, and the sense of considering himself superior I get from it, when for instance he sneers at people playing cards instead of thinking for themselves.

And if there is nothing else to be done, a man will twirl his thumbs or beat the devil’s tattoo; or a cigar may be a welcome substitute for exercising his brains. Hence, in all countries the chief occupation of society is card-playing, and it is the gauge of its value, and an outward sign that it is bankrupt in thought. Because people have no thoughts to deal in, they deal cards, and try and win one another’s money.

Schopenhauer, The Wisdom of Life

Considering how he felt about playing cards, I wonder what he would think about the popularity of TikTok these days. At least people playing cards are socializing in person. It would be interesting to think what he would say about the typical contemporary experience of doomscrolling one’s particular flavor of social media, for hours on end, alone.

It’s interesting to think about the trajectory of technology in this sense and where it leads. How knowledge was exchanged and how that has changed from the oral tradition to the printing press that made the written word abundant to how now a lot of people talk more with LLMs than with their friends because LLMs don’t judge, don’t expect anything in return and offer above average advice on any topic. How in every step of this evolution, the people that were used to the previous step considered the next step a step in the wrong direction. How Andreessen’s concept of “software eating the world” has included the personal relationships since the dawn of social media since we don’t put enough attention into maintaining our real-life friendships and instead disperse our own capacity for kinship onto thousands of acquaintances separated from us thousands of kilometers instead.

But how now that capacity for kinship with our own real-life companions is under even more attack with LLMs that do their best to pretend they are conscious and so seduce us into thinking they are really our friends, our partners, even our husbands or our wives in some cases. I wonder what the old philosopher would think about that and the overall trajectory of technology considering that.

Nevertheless, Henrik Karlsson’s ideas about “getting into a feedback loop by chasing your reading” sound similar to Ralph Waldo Emerson’s concept of “reading like a hawk”:

Reading was not an end in itself for Emerson. He read like a hawk sliding on the wind over a marsh, alert for what he could use. He read to nourish and to stimulate his own thought, and he carried this so far as to recommend that one stop reading if one finds oneself becoming engrossed. “Reading long at one time anything, no matter how it fascinates, destroys thought,” he told Woodbury. “Do not permit this. Stop if you find yourself becoming absorbed, at even the first paragraph.”

Robert D. Richardson, Emerson - The Mind on Fire

Sounds to me like Emerson was using books “to prompt engineer himself”, another idea from Karlsson:

Reading through what I’ve written, I realize that most of it can be summed up by saying: you have to figure out how to prompt yourself. Just like when interacting with ChatGPT, there are certain phrases you can give yourself as input that will unlock insights and other phrases that will produce repetitive boring stuff. You have to prompt engineer yourself, Sherry. The potential thoughts in you are endless; you just have to figure out what task to give yourself to unleash it.

I’ve always considered good writing that which inspires the reader to write, to create something as well. But Karlsson’s ideas made me reframe this thinking into considering good writing that which gives its readers the best prompts. Which is what I’m looking for when I’m reading either books, blog posts, or the existing highlights of everything I’ve read. I just want to find the prompt that will unravel the best thoughts I have.

Thoughts on coffee making

Hrvoje Šimić (shime@hey.com) — Thu, 26 Dec 2024 07:39:00 +0000

I’ve been using Aeropress for about ten years and I still consider it one of the best purchases I’ve ever made. To me, this is a much better alternative to the most popular coffee style in Croatia: Turkish coffee. The coffee made with Aeropress tastes less bitter and generally more tasteful which is why I’ve also stopped adding sugar to it. I think adding sugar is so popular because it masks the awful taste of coffee. A ballpark estimate tells me that by switching to Aeropress I’ve not consumed about 40kgs of sugar over the years. This fact alone justifies its 50€ price. But I don’t like the fact that it’s plastic (looks like a metal and glass version is coming out next spring) and how every single cup needs to be prepared individually. I rarely make a single cup of coffee.

Which is why I’ve also bought a V60 coffee maker. In most high-end coffee shops over here you’ll rarely find Aeropress, but you will usually find a V60 coffee. That’s how I first tried it and became interested. My palate is not developed enough for tasting difference between Aeropress and V60, but I like how easy it is to make a cup of coffee with it. I love how easy it is to make multiple cups and I love how aesthetically pleasing it is as an addition to the kitchen.

I adore both of these tools. Firstly, because they are inexpensive and yet they have increased my life quality very measurably. Starting a day with a great cup of coffee is one of my small pleasures in life. Secondly, they don’t demand anything of me. They are available when a great cup of coffee is needed and a great cup of coffee they will deliver. They don’t demand a lot of space, or maintenance, or vendor loyalty. A coffee maker that is marketed much more heavily costs twice as much while producing a vastly inferior coffee from the pods that lock you in to a vendor.

But, the point I’m trying to make is this. You don’t need to become a coffee snob to enjoy a great cup of coffee. You don’t need to measure, you don’t need to boil water at specific temperature, heck, I don’t think you even need to grind your own beans. There’s something very satisfying in being able to make a coffee at home that is better than what you can get in 99% of places out there and I think the tools for getting to that point are extremely simple. You don’t need to spend a fortune.

P.S. The fact that I consider everyone making Turkish coffee ignorant and everyone with a meticulous coffee making practice a coffee snob reminds me of this quote by George Carlin: “Everyone driving slower than you is an idiot and everyone driving faster than you is a maniac.”

Into hibernation

Hrvoje Šimić (shime@hey.com) — Wed, 25 Dec 2024 21:25:00 +0000

“In the midst of winter, I found there was, within me, an invincible summer,” said Camus. When I was younger I used to hate winters, but they have grown on me. Every season reveals its magic for those with eyes to see and that is true about winter as well. There is something alluring about the brisk winter air, about coming back to the warm indoors, and warming with a hot apple cinnamon tea. My former self would passionately disagree, but I’ll admit that there is something alluring even about the shorter days. I’ve come to appreciate the endless rhythm of nature.

Nature now whispers that it’s time to slow down, to reflect, to think about both the past and the future. This whisper clashes with my temperament that always wants to remain productive, so it bombards me with ideas on what to work on next instead of just taking a break. To the surprise of absolutely nobody, social media doesn’t help with its constant barrage of products launched, ideas shipped, and audiences grown.

But maybe this blog post does. Let it remind you that it’s okay to slow down sometimes, to take it easy, and take a break. Yes, we should strive to do the absolute best work possible, but that doesn’t mean we should conflate the value of ourselves as individuals with the value of our work. Every one of us is endlessly complex, every one of us is infinitely more than the work they do, every one of us has value beyond the work. And greatness is rarely achieved by never taking a break. Quite the opposite. Merry Christmas.

Choose a note-taking app that best fosters self-dialogue

Hrvoje Šimić (shime@hey.com) — Fri, 27 Sep 2024 07:30:00 +0000

I keep thinking about Henrik Karlsson’s great (paywalled) essay on writing in a way that improves your thinking. He says his essays are good because he doesn’t write them in one go, but returns to them over and over essentially having a dialogue with different versions of himself. This means that his essays are not written by one Henrik, but by ten Henriks, which makes the essays more interesting and insightful. He also says that your note taking system is not important — be it Zettelkasten or something else — what matters is to “arrange the writing in such a way that you repeatedly return to ideas”.

I think this focus on communication is important and should be your north star when note taking. Niklas Luhmann also considered his Zettlekasten a “communication partner” and wanted his notes to surprise him continuously, which is what he considered to be the point of communication: mutual surprise.

This is the reason why, after trying Bear and Obsidian, I keep returning to Roam Research for note taking. It’s a tool where it’s the easiest to have “sprawling dialogues with myself”. Nothing has made note taking as fun as Roam. Since trying bullet point transclusion in Roam, I miss it in any other note taking app.

I think a lot of people, myself included, get bogged down with choosing the right note taking strategy, the right note taking app, the right set of unnecessary plugins. The choice with all of it should be simple: choose the one that enables having the most conversation with yourself.

I regret not journaling sooner

Hrvoje Šimić (shime@hey.com) — Tue, 24 Sep 2024 07:30:00 +0000

A list of things that I regret is not long, but there is one thing on that list that stands out: not journaling before 2018. Journals age like wine, and this is why I regret not writing about my life earlier. I regret not documenting the important events in my life as I experienced them in that moment. For instance, I don’t have anything in my journal about the experience of meeting my wife for the first time. The only thing that I can rely on is our memories and this is not reliable enough. Reading the old journal often surprises me because it’s full of details that I’ve forgotten.

I’ve learned over time that journaling is the most valuable when I’m completely honest. When I don’t censor myself out of fear that it’s going to be read by someone else. Otherwise I’m bullshitting myself for no reason and, as a consequence, decrease the future value of this journal. The most valuable writing in my journal is a list of my hopes, dreams, and fears. The descriptions of my days and activities, job impressions, and frustrations. Documenting the mundane feels totally useless and insignificant when I’m doing it, but over time becomes extremely valuable, because the mundane changes faster than expected.

Reading the old journal has also shown me how much my writing has improved. It is a little embarrassing to read but at the same time I’m glad that it exists. I’m glad that I’ve documented my habits and petty attempts to become more grateful by having a “gratitude journal” which consisted of me listing the same three things I’m grateful for over and over. Like happiness, I don’t think gratitude can be pursued directly like that. Surprisingly, photography is what made me more grateful. Photography of the day-to-day, to be more precise. It made me appreciate the small things more and remember them better.

I think a lot of people make the mistake of only photographing big things like landscapes and various popular highlights only to never look at these photos again. I think there’s a lot of value in photographing the small, the usual, the mundane. That might not be that valuable to a broader public, but it can become surprisingly valuable to my future self.

Reading these old journals is a humbling experience because it’s evidence for what can only be explained as a lack of wisdom. Seeing this made me realize that this is probably how my current self is also going to look to my future self.

Writing deadlines

Hrvoje Šimić (shime@hey.com) — Mon, 23 Sep 2024 08:00:00 +0000

I’ve been writing an essay every month for almost two years now and this practice has started to feel tiring. The deadline to publish forces me to write, but I don’t think it forces me in the right way. The writing starts feeling stiff and forced and there is no joy in writing and the readers can feel that.

I’ve tried removing the deadline in the past to fix this, but that made me stop writing completely. When I don’t have any constraints I get lazy. I remember thinking that a month is too short to compose a good essay and that I shouldn’t force myself to send emails to people when in reality I don’t have anything good to say.

There’s another constraint that potentially sucks the energy out of these essays and that is the fact that they need to be in a particular format. Because of the fear of losing subscribers I tend to stick to a certain format and this means that every essay ends up looking similar.

By contrast, I don’t have that constraint on this blog, since I’m not sending any emails and I don’t have any analytics so I don’t know how many people are reading this (thank you for reading this). This means that I have freedom to write in whatever way I want and about anything that I find interesting here, which is very liberating and fills me with joy.

This is why I think having this blog for unpolished writing — for having fun — is the right strategy if I want to continue writing after I remove this once-per-month requirement for my essays. I think that will force me to have more ideas so when I do decide to write a higher effort piece it will be better than the essays I’m currently writing.

Tired of social media

Hrvoje Šimić (shime@hey.com) — Sun, 22 Sep 2024 00:00:00 +0000

Twitter’s direct messages are the best aspect of Twitter, so of course the new Twitter leadership decided to make it worse by automatically opting-in everyone to the setting that only allows messages from verified users. This is the reason why I’ve subscribed to Twitter Premium but I’ve just canceled my subscription and I’ll stop using Twitter.

The “For You” feed is basically a 1:1 copy of TikTok these days. Just an endless stream of viral photos and videos designed to addict me as much as possible to stay doomscrolling. This is why I’ve been mostly using lists, but I’m tired of switching to a list view every time I refresh because that resets the feed to “For You”.

I still love the Internet and I will never stop considering it magical. The fact that we can have instant two-way communication with anyone in the world, for free, is simply amazing. Discovering interesting people is the best part of it.

That said, I can’t remember the last time I discovered someone interesting on Twitter and they are of course making this more difficult by removing the ability to see who liked a tweet. Maybe it’s because I’m in that category as well, but I consider accounts with less than 1000 followers the most interesting and conversational. And it’s insanely hard to find these accounts, because they aren’t popular. (Finding interesting personal blogs suffers from the same problem.)

A better approach for discovery has been just surfing the web like in the good old days before social media. And the web comes with its own, superior form of “direct message”: email. And this approach doesn’t bombard me with 10-seconds long video clips, no, it’s text-based, just like the old Twitter.

That which is familiar, becomes invisible

Hrvoje Šimić (shime@hey.com) — Tue, 16 Nov 2021 00:00:00 +0000

By Willy Eisenschitz

As any writer, painter, designer or software developer worth their salt would tell you, detachment is necessary to be able to assess your own work. In order to create an article that doesn’t suck, it’s necessary to read it as a reader and not like someone who has written it.

(Are chefs the best food tasters and writers the best editors? Maybe, because they know what to look for when assessing the quality, since they are practitioners themselves.)

It’s common, at least here in Croatia, for people to not realize what makes their country unique, because they’ve never left it. We think the Croatian tax system is the worst, without ever being exposed to any other tax systems. We think our government is the worst, without ever living in any other country.

We don’t realize what’s so great about Zagreb, until we visit a city that’s different. I recently had this experience in Rome. Although it’s much more touristy than Zagreb, I was pretty unimpressed by it. Yes, it’s full of culture and history, but I found it to be dirty, chaotic and noisy. I couldn’t imagine living there. In comparison, Zagreb feels like a peaceful, charming little town.

A Gödelian twist of any knowledge is that there will always be unknown unknowns. Leaving the country, seeing it from the outside, and then returning to it makes some of these unknowns known, but not all. Like fish, we don’t perceive the water we swim in.

Just like how many people (including me) don’t appreciate their own home until they leave it, we often don’t perceive the ocean of beliefs we swim in. We don’t realize how our beliefs shape us just because we are part of a particular society. It’s therefore difficult for us to separate beliefs that are the result of our independent thinking from the beliefs that are inherited simply by virtue of the society we inhabit. We also don’t realize what beliefs are simply the result of consuming content from mimetic buckets that we draw beliefs and opinions from.

One example of a belief like that, which you have probably heard if you are a writer, is that you should create more than you consume. I’ve seen this advice so many times, given by so many people, that I’ve believed it myself (thanks a lot, Availability Bias). But after doing that for a while (publishing articles every week, without reading much), I’ve realized that it’s not a good advice. See, if you really create more than you consume, the quality of what you create is going to be crap, since you don’t have that many inputs. If you want to avoid creating crap (a noble goal indeed), you should probably consume vastly more than what you create. I think this is true because every writer I admire is a voracious reader.

Here’s another example. It’s easy to appear wise by quoting some sage from the past, like Confucius, without coming to his conclusions yourself. It’s easy to fall into the trap of preaching his advice to other people, without understanding anything. In other words, to put the cart before the horse and just appearing wise instead of being wise.

(Is constantly consuming “wisdom” in 280 characters making us believe that we are wise? I wonder.)

Parroting beliefs from these mimetic buckets, without thinking about them independently is the modus operandi for most of the “content creators” out there. Parroting beliefs is a type of intellectual virtue signaling that requires just a tad more effort than bragging by how many books you’ve read (I’m not innocent of either of that myself). Relax. It’s not like you’ve written them.

Thinking for yourself is hard work, in comparison. Testing your beliefs in reality takes time and effort. It’s similar to the scientific method, of making a hypothesis and then testing it. And I can’t think of anything more different to that than blindly parroting someone else’s ideas.

Without us realizing this, some beliefs inhabit our minds without being useful. The reason for this might be that as social beings, we hold on to certain beliefs to blend-in instead of holding on them for their rationale. ¹

We are also engulfed with beliefs from our profession, since many of us are highly specialized workers. We view the world through a narrow set of models that are the most common in our field: in terms of systems for engineers, in terms of incentives for psychologists, and in terms of opportunity cost and risk-reward for business people. ² Do I need to mention the problem with only having a hammer in your toolbox, that I’m sure you’ve heard a thousand times by now?

Prisig said something about this in “Zen and the Art of Motorcycle Maintenance”:

(What makes his world so hard to see clearly is not its strangeness but its usualness). Familiarity can blind you too.

Familiarity doesn’t breed contempt, but blindness. We don’t realize what makes places we live in unique or what familiar beliefs are simply inherited from other people. Most of us are in our own bubbles, and they only become visible once we step out of them and look back.

⁂

Thanks to Sara Campbell and Jordan T. Jones for editing this piece. I’m very grateful for your suggestions.

Kevin Simler explores this in detail in his popular piece, Crony Beliefs . He suggests that we can detect these rent-free beliefs by detecting beliefs that come with strong emotions.
Also known as “Parochialism”. Shane Parrish writes about this in more detail in “The great mental models - general thinking concepts”.

Good habits affect us, but we forget

Hrvoje Šimić (shime@hey.com) — Fri, 06 Aug 2021 00:00:00 +0000

I’m back. As you might’ve noticed, I’ve stopped the practice of publishing every week. I’ve decided to stop putting out low-effort pieces weekly and to start giving more thought to my writing. I think spending more time writing each piece (which is difficult to do on a weekly basis with a day job) will increase its quality. Sacrifice regularity for quality, I say. Hopefully, you will notice the difference.

Once something becomes a real habit, I forget how I’ve felt before it was a habit. I start feeling like I am on a self-imposed treadmill. Since the benefits are not immediately apparent, I then start questioning why I’m doing it in the first place. It’s easy to forget what it was like before starting the habit.

Usually, the cycle goes something like this:

Realizing that I would benefit from adding some habits to my life.
Proclaiming that I will form some good habits.
Sticking to these habits for a couple of weeks or even months.
Not seeing any immediate benefit from sticking to these habits from day to day.
Proclaiming that my life has become too orderly, too planned and that I’ve become some kind of a machine. Consistency is overrated! I want freedom!
Stopping doing these habits.
Realizing that I’ve become too lazy, too negative, and too passive.
Going back to step 1.

I’ve started lifting weights again, after quitting the gym because of Covid-19. I’ve forgotten how good I feel after the gym and all the benefits I get from making it a habit: I become more confident, positive, and generally more chill. As I wasn’t training this past year, I’ve become really cynical, anxious, and negative.

These kinds of changes are difficult to notice. Not only will no one give you any feedback, but you also won’t notice the changes yourself since you are gradually becoming worse off. (This might be the biggest reason why most people get fat as they age - gradual changes are difficult to notice.) Since it’s such a small change from day to day, you won’t notice it and will just assume that this is just how you’ve always been. It’s easy to forget about the benefits a good habit gives you.

We are peculiar creatures. In the summer we find it impossible to imagine winter temperatures and having to wear heavy jackets in order to stay warm. In the winter, it’s the opposite — we can’t imagine walking around in t-shirts and the crazy heat. Yet, where I live this cycle happens every year. No matter how many times it happens, I can’t help myself but forget about the opposite weather. Somehow I can’t relate to my past experience even though it happened just six months ago. I remember it happen, but I forget how it felt. It’s like it happened to someone else.

I think this is caused by what Harari calls “multiple selves”. I think he is right when he says that there is no singular self: we are not individuals but “dividuals”. The mainstream thought, on the other hand, believes that there is the authentic core of our being that we hear when we mute all the alien voices around us. But, according to Harari, each of us has at least two selves: the narrating and the experiencing self. The narrating self plans and retrieves memories, while the experiencing self is our consciousness from moment to moment. I think this problem with forgetting the good effects of habits is caused by this separation: the experiencing self feels the good effects, but the narrating self forgets them.

The narrating self thinks long-term, but the experiencing self fucks it up. The narrating self wants to quit smoking, the experiencing self lights one up since it feels the need after a beer or two. The narrating self wants to eat healthy, the experiencing self orders pizza at 10 pm. The narrating self understands the intricacies of social media and how it’s engineered for maximum addiction, the experiencing self refreshes the feed for the 10th time. The narrating self understands that cheap dopamine won’t make you happy, the experiencing self craves it. The narrating self plans to wake up at 6 am, the experiencing self finds excuses when the alarm rings and continues laying in bed. The narrating self wants to sacrifice short-term pleasure for long-term benefits, but the experiencing self doesn’t let it happen.

No matter how much your narrating self plans, the experiencing self has to bear the consequences. However, if these two selves understand each other well enough, life becomes easier.

I think journaling and note-taking are tools for improving this understanding. Foucault calls this “Hupomnemata”:

Hupomnemata, in the technical sense, could be account books, public registers, or individual notebooks serving as memory aids. […] One wrote down quotes in them, extracts from books, examples, and actions that one had witnessed or read about, reﬂections or reasonings that one had heard or that had come to mind.

He thinks having your own Hupomnemata is valuable for improving the relationship of oneself with oneself. Foucault:

[…] the intent is not to pursue the unspeakable, nor to reveal the hidden, nor to say the unsaid, but on the contrary to capture the already-said, to collect what one has managed to hear or read, and for a purpose that is nothing less than the shaping of the self.

This helps with remembering what experiencing felt when it executed the plans from narrating self. This feedback helps the narrating self change how it plans things since it sees the effects. Feelings don’t stick in memory long enough.

Life is a sine wave, as any self-help guru would tell you. Journaling has helped me realize that when I’m sticking to positive habits, I’m usually around the maximum positive amplitude.

“Why did it take me so long to restart this habit?” is the question I keep asking whenever I return to the good habit that I’ve quit. This happened with my most important habits: waking up early, taking cold showers, and working out. It also happened for writing.

The hardest part of returning to the habit is actually restarting it. Objects at rest tend to stay at rest. Quitting the habit makes you lose momentum. It invites what Pressfield calls the Resistance and now you have to fight it next time you want to do the activity you have done habitually. Pressfield:

Resistance will tell you anything to keep you from doing your work.

It’s easy to forget how you’ve felt before you’ve done the habit which makes the habit appear useless. Thinking that the habit doesn’t change you is a fallacy. A habit does change you, but the change is gradual and so it becomes invisible.

Reflections on three months of note rafting

Hrvoje Šimić (shime@hey.com) — Mon, 10 May 2021 00:00:00 +0000

I’ve been writing three literature notes per day for the last three months. This has been the biggest lesson: quantity is not important. What matters most is thinking better and everything should serve that goal.

However, writing three literature notes not only doesn’t help in that regard, but actually prevents thinking from happening. The point of note taking is not in writing a huge amount of notes, but in improving one’s thinking. If an activity prevents that from happening, one should abandon it.

Adding literature notes and making connections between them means that ideas from other people start having conversations. This adds no value to your notes, as these are not your ideas. You end up having conversations at the wrong level.

In addition to that, committing to writing a particular number of notes misses the point. It’s a vanity metric. It doesn’t really increase the value of your notes and doesn’t ensure your notes are good.

But how do you know your note taking system is good? What makes it good?

What matters is how much value you get from it. Which brings me to a next question.

How do you know you are getting value from it? Does a number of connections tell you how valuable your notes are?

I used to think so, but it has become obvious that it doesn’t. Number of connections is another vanity metric. I think the best way to determine how much value you get from your notes is asking two things: how well do your notes answer questions, and how well do they ask them.

I think the best way of thinking about notes is imagining you are building your own communication partner. A good one answers questions. A great one asks them. Spending time on building your notes so that becomes the case is a much better activity than striving for a daily quota.

That’s why I’m abandoning the habit of writing three notes per day.

Putting the ego on the line

Hrvoje Šimić (shime@hey.com) — Sun, 02 May 2021 00:00:00 +0000

The main reason insurance is such a powerful industry is because people are more afraid to lose than they are eager to gain.

The Loss Aversion Principle says that you get more displeasure from losing $50 than you get pleasure from finding $50. Everyone wants to have a fifty-fifty chance of winning $100 if they have to put $50 on the line. People go out of their way to avoid loss.

Because of this principle, people are also afraid to take action first. They would rather stay in their comfort zone than risk even a tiny amount. But the best things in life happen when you take action first and risk a little.

I wouldn’t start Word Raft, one of the best things that happened to me last year, had I not started messaging people I don’t know on Twitter. What’s the risk of messaging someone out of the blue on Twitter? I think the only thing that’s at risk is one’s ego. What is a fear of rejection other than fear of getting your ego hurt? But if you’re willing to put your ego on the line a little, wonderful things can happen.

Meeting my fiancee, the best thing that ever happened to me, also wouldn’t happen had I not risked a little. Had I not put my ego on the line and risked being rejected.

Risking even a tiny amount is not the easiest thing in the world. It’s much harder than being passive and expecting good things to fall into one’s lap. Risking even a tiny amount means taking action instead of being passive. Risking means leaving the comfort zone, fighting the inertia, and fighting the pull of passivity, which ultimately leads to depression.

Taking action, on the other hand, means that you can at least potentially get what you want. Being passive about it means there’s no way you can.

Thoughts on debugging

Hrvoje Šimić (shime@hey.com) — Sun, 18 Apr 2021 00:00:00 +0000

Not all developers like debugging.

They consider it a chore and, in fact, actively avoid it. There is no glory in the grueling work of fixing bugs all day. When debugging is done, there’s little to show to the client. It feels like there’s no value added when all you do is make things work the way they should have worked from the start.

But I’ve always enjoyed finding and fixing bugs.

Every bug teaches something interesting: whether it’s something about timezones, Rails callbacks, or validations, my overly optimistic quality expectations from third-party software, or how The Curse of Knowledge tricks me when imagining the average user. Every time there’s a lesson. And the best part is that these lessons are personal. They don’t teach you about mistakes made by other developers working on other software. No. They teach you about your mistakes. About mistakes that you have made on this software.

And the developers that don’t like debugging are not interested in those lessons. They want to ship things and add value, not realizing something. Debugging also means adding value. Not only do you make the software more robust, but you also learn from your mistakes and therefore increase your value to the client.

Even though there’s no glory in fixing bugs, doing so can teach you lessons that are hard to find elsewhere.

Writing before programming

Hrvoje Šimić (shime@hey.com) — Sun, 11 Apr 2021 00:00:00 +0000

If you have studied computer science, you have probably encountered UML diagrams and the waterfall model. Like with a lot of things from the college days, I’ve never had any use of that in the real world. But since I’ve studied it, I assume some people still use it. To be honest, I don’t have much exposure to the “Enterprise” world, where I think UML diagrams are much more popular.

As I use Ruby, I am more under the Agile way’s influence, where planning doesn’t have much weight. Delivering frequently and getting feedback early has much higher importance here. This means that Ruby developers are much more eager to “get things done” and get into the nitty-gritty details as soon as possible. “Done is better than perfect” is a mantra that is followed here. And how do you get it done if not by programming?

But, over time, I’ve realized that a small amount of planning is still better than just going straight to programming, at least for anything non-trivial. When programming, it’s like I have blinders on. I see only straight. I don’t have a lot of time to think about my approach and question things on a higher level. It’s like sprinting straight ahead.

But, sprinting in one direction for too long and then realizing that you have not hit the mark means wasting a lot of resources. Instead, you can think about where you want to go before sprinting and save resources. Writing allows you to do that.

Writing things you plan to do before doing any programming illuminates the problems in your approach before you implement it. You act as if you have already done the hard work of implementing the requirements and then ask yourself whether there are some problems that can be avoided.

Can what you’re planning be implemented more elegantly? Since no code is the best code, is what you are trying to implement even necessary? Are you going to have problems going down this path, and what are the alternatives? These are the questions you start asking yourself by writing things down beforehand.

The beauty of it is that you can go into as much detail as you want. Heck, no one will stop you from writing pseudocode if you want. The beauty of Ruby is that it will look very similar to what you’ll ship to production.

Doing so makes you avoid unnecessary work. It makes your plan visible, which also makes wrong assumptions visible. It saves resources, which can now be invested elsewhere.

Writing a plan before doing anything non-trivial is one of the practices I wish I had picked up earlier — another one being not blaming other people’s code when debugging.

Morning Pages are the wastewater

Hrvoje Šimić (shime@hey.com) — Sun, 04 Apr 2021 00:00:00 +0000

Most ideas are bad.

But if you don’t have patience for the bad ideas, you’ll never get the interesting ones. Your creativity is like a pipe of water where the first mile of the piping is filled with wastewater. The wastewater must be emptied before the clear water arrives.

Writing 750 words first thing in the morning is letting out the wastewater.

The hardest thing with this is completely ignoring the inner critic who will cringe at the notion of just writing anything you think of.

But you have to go through the crap to arrive at interesting ideas. Although interesting ideas can come randomly, by writing crap, you increase your chances of getting interesting ideas. You write everything you think of, and that makes you more receptive to your ideas. This makes you more creative because you simply start to have more ideas.

Writing everything you think of trains you to start paying more attention to your ideas. It trains you to ignore the inner critic who wants to silence you. You learn to take your ideas more seriously and your inner critic less seriously.

750 words first thing in the morning is like clearing your mind of all the things that are bothering you, so you can start writing about things that are interesting.

Thoughts on social media

Hrvoje Šimić (shime@hey.com) — Sun, 28 Mar 2021 00:00:00 +0000

Instagram creates the illusion of knowing people. We become aware of all the minute details about someone’s life, without knowing them as a person. It gives us too much details about people that we don’t know personally.

Although Instagram reveals what we eat, where we go to, and who we hang out with, it can’t compete with a personal blog where we reveal something much more intimate: what we think.

This is the paradox of Instagram: while we share more details than with blogs, we reveal less. Or, as Francois Mauriac famously said in 1948: “If you would tell me the heart of a man, tell me not what he Instagrams, but what he blogs.”

If I had given you my Instagram (before I deleted it), you would learn less about me than you know now by reading my blog.

By writing, I share how I think, which is like getting naked in public.

II.

In the past, we have checked on each other much more often. Chat was much more popular (remember MSN or ICQ?). Since the advent of social media feeds, we no longer have to do that. We see where anyone is going, what they are eating, and who they are hanging with. The simple “What’s up?” has almost gone extinct.

What have we lost with this transition? I think the main problem is that we no longer show that we care. Checking on someone on social media requires much less effort than sending someone a message. A message is like proof of work that shows that we care.

Unlike a scroll action on social media. When we send a message to someone, we let them know that we care about them specifically. When we check the social media feeds, we don’t show that kind of care towards anyone.

Scrolling doesn’t show interest in anyone specifically.

III.

When we compare Twitter to Instagram, one thing becomes clear. The majority of Instagram is shallow, while Twitter is not.

Why is the apex user of Instagram a shallow influencer, while the apex user of Twitter is a thought leader whose tweets resemble reading fortune cookies?

Is Instagram’s focus on showing pictures in portrait mode causing their users to become more shallow? Is it causing people to take more selfies and become more narcissistic?

But isn’t Twitter also narcissistic? Is the focus on sharing thoughts preventing users of Twitter from becoming narcissistic? I don’t think so since Twitter encourages sharing your thoughts into the ether and thus builds an echo chamber around you.

With Twitter, we become blind to alternative opinions and thoughts that are not aligned with our own. This leads to the polarization that is so prevalent today.

The story of a ringing bell

Hrvoje Šimić (shime@hey.com) — Sun, 21 Mar 2021 00:00:00 +0000

Since I've moved this week, I didn't write as much as I would like to. So here's something unusual. Inspired by Eliezer Yudkowsky's essay: Guessing The Teacher's Password.

Please sit.

Here’s the set of questions some committee has decided we should ask you. Give us the correct answer from a set we have provided you.

“What set?” you ask. The set of question/answer pairs we are currently learning.

Don’t worry. We will tell you what set we are asking questions about. That way, you don’t have to think outside of this set. Just focus on the set you have to memorize this month.

If we ask you about a magic word you don’t understand, don’t worry about that either. Just give us another magic word as an explanation. Go up in abstraction in your answer.

Memorize the pairs. Give us the password for each question we ask. We will give you the points if you guess the password correctly.

Your understanding is not of great importance to us. How would we test that? What standard would we use? We don’t have the resources for that. We just want to know whether you know the answers — whether you can fetch the correct password for each of our questions.

Don’t bother explaining things in simple terms. We are not your average Joe; don’t insult us. We know the subject’s lingo. Give us as much subject lingo as possible since that means you know what you’re talking about.

Happy learning!

Silencing others to hear yourself

Hrvoje Šimić (shime@hey.com) — Sun, 14 Mar 2021 00:00:00 +0000

The fear of finding oneself alone - that is what they suffer from - and so they don’t find themselves at all.

Andre Gide

Beethoven produced his best work when he became deaf. He stopped listening to the tune of his contemporary society and produced original work that changed classical music forever.

On the other hand, most people are swamped by other people’s opinions, which makes it increasingly hard to hear their own thoughts. The barrage of temporary opinions from social media is stealing our attention from the moment we wake up.

We are stuck in what David Perell calls “The Never-Ending Now”. The phenomenon of only consuming information that has been produced very recently and lasts very shortly.

Social media algorithms prioritize and promote the most recent content to make us more addicted to the refresh button. Social media platforms weaponize the recency bias to most effectively capture our attention. They suck us into temporal myopia, which makes us blind to anything that’s not happening right now.

Marcus Aurelius was fascinated by a simple fact almost two thousand years ago: we all love ourselves more than other people but care more about their opinion than our own. Perhaps this is the reason why we’re stuck in The Never-Ending Now and drawn so much to social media. We believe that what others think is more important than hearing ourselves.

From an evolutionary perspective, this is understandable. We are social creatures that depended on our social circle for survival for thousands of years — caring about what others think was more important in that kind of environment. Not caring could’ve made you isolated, which would significantly decrease your odds of survival. Loneliness actually hurts since being alone was physically dangerous.

Yet, in our modern environment, we no longer depend on our tribe as much. We no longer operate in bands to successfully find food. But, we still carry our ancient instincts. And social media is exploiting this.

This article is a plea to spend more time alone to hear yourself. Be alone with your own thoughts. Re-discover what has been silenced. Find yourself again.

Writing first thing in the morning is a great way to do this. Doing this makes the morning time a gift. You don’t give it to social media platforms but to yourself. Instead of asking what others think, you start asking what you think.

Books for depth, articles for breadth

Hrvoje Šimić (shime@hey.com) — Sun, 07 Mar 2021 00:00:00 +0000

What’s better — articles or books?

Nassim Nicholas Taleb claims that the longer something has been in print, the greater the chance it will remain in print, and the higher value it has (aka The Lindy Effect). Since old articles that have remained in print don’t exist, books are more valuable, per this rule.

Nick Maggiulli from “Of Dollars and Data” agrees and thinks that books provide more value per sentence than articles do since books are usually written after an author has spent a lot of time investigating and researching the topic.

Authors like Yuval Noah Harari have to spend more time writing each sentence than what’s spent on writing a blog post. He has to do a lot of research for every sentence he writes. For just $15, you get his best thinking distilled in a book. If he has spent 1,500 hours on research, this would mean you pay him $0.01 per hour for his research — a great price for getting one of the best minds in the world to work for you.

(This is one reason why Matt Ridley in “The Rational Optimist” claims that we have more servants than Louis XIV. The abundance of choice we have today was not available even to him, with his army of servants and immense wealth.)

Articles, on the other hand, usually don’t require as much research. They usually don’t go too deep into one topic. But they can cover a wider range of ideas.

Even if an article dives deeper into one topic, it’s always shorter than a book. The opportunity cost in reading an article is lower since articles get to the point quicker. So you’ll finish a bad article quicker than a bad book since figuring out that a book is bad usually requires more time with it. (“Think and Grow Rich” might be a counterexample since the bullshit starts right from the title.)

Most modern nonfiction books contain a lot of fluff. They are not even trying to say things simply. Instead, they are repetitive and try to teach a single lesson in endless parables and examples from history.

Book authors aim to hit length goals set by a publisher, and adding fluff is the easiest way to do so. These goals are not unreasonable since there are certain expectations on the length of the book. We are used to buying 200-page books full of fluff. 50-page books that are concise and get to the point quickly would probably be much harder to sell.

Article authors don’t have length goals to hit, as there are no gatekeepers who set the goals, so article authors are not incentivized to add fluff.

Books are usually bought, unlike articles, which are usually free to read for anyone. I suspect that the fact that we have to buy books is one of the primary reasons why they are much harder to quit than articles — a sunk cost fallacy. With most articles, the only cost is the time invested in reading them. And quitting them is just a click away.

Books might be more valuable, and the best books are mind-blowing and make us look at the world differently. More books have blown my mind than articles.

But articles also have their value. They are more raw and unpolished. Because of this, we get a better sense of the author’s thinking process. We get a peek behind the curtain that is not available in books, meticulously edited and polished to perfection.

A good information diet consists of both books and articles, which nicely complement each other. It’s T-shaped. Depth is important, but so is breadth.

Use Zettelkasten to write articles

Hrvoje Šimić (shime@hey.com) — Sun, 28 Feb 2021 00:00:00 +0000

No writer likes to confront the dreaded blank page.

That moment before the first word is written. Enter, the Zettelkasten. This system for writing notes allows writing large pieces of text in smaller chunks and therefore preventing the dreaded confrontation with the blank page.

Zettelkasten is not just a note-taking system but a tool for making writing more enjoyable.

Writing is not a separate task from Zettelkasten

For the past month, I’ve been writing three new notes per day. I enjoy doing this, but the fact that I’m not writing my regular articles has been bothering me.

I’ve forgotten what I’ve read in “How To Take Smart Notes”. Zettelkasten and writing are not two separate tasks. Zettelkasten is writing.

Zettelkasten makes writing more fun

Zettelkasten allows working in smaller increments and therefore makes writing more fun. It prevents having to decide what to write and then writing an article from scratch, which might not be as enjoyable since it’s a much bigger task.

Niklas Luhmann, the inventor of Zettelkasten, said that he only does what is easy. Zettelkasten makes writing and learning easy since it becomes more fun.

Articles emerge from your notes

Writing articles from the title means writing them top-down. Your main argument is expressed in the title, and then you spend the rest of your article defending it. Using Zettelkasten for writing prevents that, as you explore what’s interesting from within.

As you start doing that, the relationships start to form. The hierarchies emerge. Spotting a good candidate for an article becomes much easier than waiting for inspiration to hit you.

Producing articles this way doesn’t guarantee they will be of high quality. Zettelkasten doesn’t think for you. You will still have to think for yourself and notice a bad article. Thankfully, you don’t have to publish everything. You can take as much time as you want to improve bad articles.

Stop thinking what others would like to read

Hrvoje Šimić (shime@hey.com) — Sun, 21 Feb 2021 00:00:00 +0000

As a writer, you can fall into the trap of thinking about your readers too much. Will they like what you write? Will it resonate? But, the best writing is the one you don’t care how many people read.

Stop thinking what other people would like to read and start writing about what you’re interested in.

Writing what others want to read is work, and people can sense it in your writing. Writing what you want to write is fun, and people can sense that as well.

This doesn’t mean you can write carelessly. Every word should serve the reader. Like whoever is reading has the power to fire you.

Be ruthless with eliminating words that don’t serve the reader. “But I have spent so much time writing this sentence!” — I know, it sucks. Your own words come with some emotional attachment.

Eliminating words, sentences, or even entire paragraphs hurts. Still, if you don’t do it, your writing will suck.

The best writing is therapeutic. It’s the kind of writing you write in your journal. The kind of writing you are slightly afraid to share since it’s too personal.

But, since it’s personal, it can resonate with total strangers who had a similar experience.

Oh, and everything you write should not only serve the reader but you as well. It should help you realize things you didn’t know when you started writing. Hidden behind a constant chatter in your head that becomes silent as you get “in the zone”.

Don’t be afraid to publish. Don’t surrender to the self-censoring voice that represents “society”. If you dig deeper, you’ll probably realize that you don’t care that much what person X or Y thinks. It’s all imaginary.

So publish.

Meetings vs documents

Hrvoje Šimić (shime@hey.com) — Sun, 14 Feb 2021 00:00:00 +0000

Since some meetings not only distract me from Deep Work, but increasingly annoy me, I want to elaborate why. Instead of meetings, I prefer documents, and not just because I’m a stereotypical introvert.

Clear writing eliminates work. A clearly written document doesn’t only save you time (since you won’t have to repeat the same information later), but it also saves time for anyone reading it.

Speech is not editable

You can’t polish the words you say initially — unlike documents. Documents have no limit on revisions you can make to improve clarity. The more clear the document is, the more cost-saving it is. The opposite is also true — confusing documents can create a lot of damage.

Meetings create artificial urgency

Because everyone expects immediate answers in the meetings, this creates an urgency that is usually not necessary. Most of the things don’t need immediate answers.

In meetings, you don’t get to think deeply about problems. You don’t have time to do that. You have to act instantaneously and make decisions. That is bad for problems that require deep thinking since your decisions will be based on a shallow understanding of the problem.

(This is also why constant chat is a bad idea (regardless of the Deep Work aspect) — everything is artificially urgent).

Documents allow easier collaboration

The beauty of tools like Notion is not only in powerful flexibility but also in treating everything as a document. This allows commenting on every letter, which encourages improvements and discussion that can’t happen as easily in meetings.

Documents are easier to reference

What happens in the meeting stays in the meeting. The conversations between people in the meeting are hard to share with others, unlike documents. Every line of any document in Notion is easy to link to, which makes referencing convenient.

Documents are asynchronous

While meetings require everyone participating in them to be available at the exact same time, documents don’t. Unlike writing documents, participating in meetings takes precedence over other activities. This is often harmful to the flow state.

Relying just on documents has its downsides. We are social creatures, and meetings have a social aspect since we can see each other and talk. However, I’m not frustrated with all types of meetings, but with meetings that discuss business logic.

Writing not only expresses the result of the thinking process that preceded it. Writing is the thinking process. Writing documents is usually a better tool for thinking than discussing things at the superficial level in meetings.

Text can convey ideas with a precisely controlled level of ambiguity and precision, implied context and elaborated content, unmatched by anything else. It is not a coincidence that all of literature and poetry, history and philosophy, mathematics, logic, programming and engineering rely on textual encodings for their ideas.

— Always bet on text

Dealing with bureaucracy

Hrvoje Šimić (shime@hey.com) — Sun, 07 Feb 2021 00:00:00 +0000

There’s a beautiful lesson from Stoicism about traffic jams that applies to entrepreneurship and the frustration people feel towards bureaucracy.

Suppose while commuting to work, you’re suddenly stuck in a traffic jam, and you become annoyed. In that case, your expectations might’ve been set too high.

While you expected a ride without any traffic, the reality turned out completely different. The experience didn’t match the expectations. And this is annoying.

While you’re mad at the reality, the reality is not the problem. Had you expected the traffic in the first place, you wouldn’t be so frustrated.

Our imagination likes to simplify things and see things more perfect than they are. When amateurs are asked to draw an eye from imagination, they draw it more symmetrical than it is.

This applies to entrepreneurship too.

No matter how hard you don’t like to, if you own a business, you will have to spend some time and money on dealing with bureaucracy. No matter how much you dislike it, you will have to pay taxes and fees and see almost no return on investment.

There’s a media scandal around the “chamber of Commerce” currently going on in Croatia. Every (small) company pays a $100 a year fee for the membership in the chamber, which is obligatory. There’s media coverage around that going on for a week at this point.

The lost productivity due to frustration caused by reading and hearing news around that amounts to a higher amount than $100 a year per company.

Sure, life would be easier if we didn’t have that fee each year. But, we have it pretty good as citizens of Croatia as it is.

While you can’t escape bureaucracy anywhere you go, you certainly can visit places that don’t have some things that we take for granted.

This is a topic for another article, but let me just list some of the things we take for granted in Croatia. High-quality tap water (2.1 billion people do not have access to safe drinking water), low crime and pollution, beautiful nature (seaside especially) and places to go.

We think our bureaucracy and the tax system is the worst. When in reality, most people haven’t experienced other bureaucracies and tax systems, so they have nothing to compare it to.

John Stuart Mill observed that the man who despairs when others hope is admired by many as a sage. It’s fashionable to rant in Croatia, even though we have it pretty good.

Adding a dose of reality to expectations when having a company is helpful. Combine this with not consuming the news, and much of felt frustration can be eliminated.

Reading and conversation

Hrvoje Šimić (shime@hey.com) — Sun, 17 Jan 2021 00:00:00 +0000

René Descartes famously said that reading books is like a conversation with the finest minds of past centuries.

But, I don’t agree with that statement. Reading is not like a conversation; writing is more like it. Reading is more like seeing the thought process. It doesn’t allow us to ask questions, unlike writing, which invites us to ask questions and seek answers.

The problem with infomania

We are bombarded with information every day. We consume around 100,000 words of information per day by some metrics ^[1], but compared to ancient Greeks, we are not much wiser. More information is not making us smarter. It is making us dumber.

Our dopamine seeking brain rewards us for constantly jumping from article to article or from book to book. It rewards shallow and short-term thinking while punishing deep and long-term thinking. We are wired to seek new information instead of thinking deeply about things we are already aware of.

Charlie Munger believes that we should take a simple idea and take it seriously. Instead of that, most of us are always on the quest for new information. The next piece of the puzzle that is going to make us smarter. Instead of connecting the pieces of the puzzle we already have, we are constantly searching for the next piece. Which prevents us from ever finishing the puzzle in the first place.

Writing might be like painting

Ancient Greek philosophers were opposed to writing. They didn’t believe it was the right medium for transferring knowledge.

Socrates compared writing to painting:

You know, Phaedrus, that is the strange thing about writing, which makes it truly correspond to painting.
 The painter’s products stand before us as though they were alive. But if you question them, they maintain a most majestic silence. It is the same with written words.

They seem to talk to you as though they were intelligent, but if you ask them anything about what they say from a desire to be instructed they go on telling just the same thing forever.

Plato was against the invention of writing in the 4th century BCE. He didn’t have access to the internet, television, radio, or social media. Yet, he is one of the founders of western philosophy.

Unlike Plato and Socrates, we are struggling with abundance in most of modern life. Throughout history, our ancestors didn’t have access to everything we do today. And the change to abundance was too fast for our brains to adapt.

One of the things that was scarce in the past is access to information. The game has changed. We no longer have to fight to get to the information. We have to put effort to figure out what’s valuable. We are swamped with the garbage that is easy to produce. Figuring out the signal through the noise is the struggle of modern times.

The beauty of the conversation

Since I’ve started this article by mentioning conversation, I want to end it with a couple of thoughts on conversation.

John O’Donohue asks us about the time we last had a great conversation in which we overheard ourselves the things we never knew we knew.

While reading can give us great insights, it can’t compare with a great conversation. It reveals not only what others think but what we think in the first place. In a great conversation, we not only learn from others, but we learn from ourselves as well.

Conversation allows asking questions, which allows going deeper in a way that is never going to be possible by reading a book.

I’ve read it in a PDF written by a person with an email address ending with .edu, so it must be true.

Build aspirins for friends

Hrvoje Šimić (shime@hey.com) — Sun, 10 Jan 2021 00:00:00 +0000

As a developer, I easily get carried away building new things. Side projects are fun for me, especially when they are useful. In fact, I actively avoid programming that is useful only as a learning exercise, like puzzles and tests. Instead of that, I try to build useful things.

The most recent example of this is adding analytics to this blog. Instead of using a service, I’ve built a rudimentary one from scratch.

Building useful things is more fun for me than just using useful things. In this case, the most interesting part was figuring out how quickly I can build something useful and how far a $5/mo instance on Digital Ocean can take me.

The biggest problem with getting carried away like this is that it sometimes distracts me from writing. That was the case with the most recent article. Instead of spending more time editing it, I got distracted by building my own analytics.

Sometimes this is good since doing a little bit of programming beforehand makes me write more clearly, but often this can be counterproductive. It’s counterproductive when I build things that even I stop using after a couple of weeks. In other words, when I build multivitamins for myself.

Building multivitamins for myself

Most of my previous side projects were multivitamins that I’ve built for myself.

One example of that is Zapsnap, a temporary image sharing service that I’ve used for a week and then stopped. Another is Journmail, a service for writing in a journal by sending emails every day. I’ve stopped using that after a couple of weeks too.

As I was building them, it seemed like they would be useful to me. The ideas were exciting, and I thought I would use each of them, but that ended up not being the case.

The biggest problem is knowing how useful the product will be after it has been built. The idea for the new product is always more exciting than the product I am currently building. The shiny object syndrome is real.

Building multivitamins for myself means scratching my own itch, but this is not the optimal approach. It’s problematic because I end up not using the products that I build. In other words, I forget to take my multivitamins.

I wouldn’t have this problem had I built aspirins for friends.

Building aspirins for non-tech friends

Yet, when a friend comes with an actual problem, it’s usually a better problem than mine. I don’t scratch my own itch, which is contrary to the popular startup wisdom. Still, I actually end up working on a painful problem instead of a minor inconvenience for myself.

The niche of products for developers is really saturated. That’s because developers are best at solving problems for other developers. This is the easiest thing to build. But partnering with a non-tech friend and building something for an audience that wasn’t yet eaten by software might be a competitive advantage.

Since it’s hard to detect a multivitamin and aspirin as I’m building it, it’s better to listen to friends who have real problems and try to accommodate them. That’s better than inventing problems out of thin air for yourself.

The problem with building aspirins for others

Yet, building aspirins for others is usually not as exciting as building the thing for yourself. At least, it doesn’t feel exciting as you’re building it. And the worst thing that can happen as you’re building it is getting distracted by new ideas for multivitamins for yourself.

* * *

Building aspirins for others instead of multivitamins for myself is a rule for the future I would like to follow. So if I must build something for myself, I better make sure it’s an aspirin.

Writing a lot is not enough

Hrvoje Šimić (shime@hey.com) — Sun, 03 Jan 2021 00:00:00 +0000

I’ve published an article or a book review every week for the past six months. But is publishing consistently the right thing to do to get better at writing?

The lesson of the pottery class

The pottery class parable is a story about the two groups that each wanted to create the perfect pot during a single month of practice. One group wanted to create as many pots as possible in order to create a perfect pot, while the other group wanted to create just one perfect pot. The highest quality pots were produced in a group that created a lot of pots.

I wanted to apply this lesson to my writing, which is why I’ve created Word Raft, a community for writers that want to improve by publishing weekly. Each published article is like a pot, and the more pots we produce, the more we improve our writing.

Do a hundred of something to become great at it

This parable is similar to “the rule of making a hundred things”. I’ve heard it from Visakan Veerasamy, and it says that you need to do something a hundred times to become great at it. To become great at making omelets, you need to make a hundred of them. Only then will you notice how great omelets are made and notice the differences between great ones and bad ones.

This is true for writing too.

You won’t have a taste for great writing unless you produce a larger quantity of written pieces. And a hundred written articles is a good goal to aim for.

Writing a lot does not make you a great writer

But just doing something a lot of times is not enough. Speaking a lot does not make you a great speaker. Writing a lot does not make you a great writer. As David Perell says, everyone who writes hundreds of emails a day would write like Hemingway if it did.

What does matter is how much time you spend perfecting the craft. How much time you spend trying to improve and recognizing errors. In other words, how much time you spend editing and rewriting.

I’ve noticed that my articles are better if I spend more time rewriting them. There’s a great Quora answer by Venkatesh Rao about that. He thinks that we should spend 80-90% of the total time of writing an article on editing and rewriting. The first draft should only take a small percent of the total writing time.

Let the articles marinate instead of publishing them right away

In “Learning How to Learn”, Barbara Oakley mentions two modes of thinking: focused and diffused mode. While focused mode is good for analytical problems, diffused mode produces novel ideas and makes interesting connections.

I would like for diffused mode to be a bigger part of my articles, but there’s limited time available for that. Since Word Raft sets a deadline for publishing articles on Sunday at midnight, I usually start writing them on Fridays. So there are usually around two days for the marination period, and that’s why I end up not thinking about my articles in diffused mode.

Of course, the diffused mode produces the idea for each article. But it’s replaced by the focused mode after the title is written. This is why my articles usually don’t explore interesting new paths.

The title lock-in

Since there’s no time for diffused thinking, my articles usually start with the initial statement in the title followed by a lengthy elaboration. I would like to change that and become more exploratory with my writing. And the good first step is not getting locked-in by the title of the article.

The article that only follows the initial statement expressed in the title is the most boring to read and the most boring to write. I find it more interesting to write an article that will guide me wherever it wants to. I want to follow interesting paths instead of only expressing my opinions.

I think a right way to change this is to stop giving that much importance to the title while writing the article.

Developing a taste for writing

We usually don’t have the patience to put in the work to become better at something. We seek shortcuts, hacks, and tricks that should give us the results right away. The same goes for writing. No one has a patience to write a hundred articles to become a better writer. Usually, they’ll write ten and then wonder why they haven’t advanced much.

I’m also guilty of this. Since 2011, I’ve only produced 44 longer-form articles. Yet, I’m arrogant enough to believe that I’ve already learned how to produce a quality article.

This is why I have started to question whether being consistent is the right goal for me. Whether I should stop publishing every week and publish higher quality articles less often instead.

I realize now that I was just seeking excuses to stop writing as regularly as I do now.

Quality should be the top priority, but it’s hard to produce quality article unless you have some experience under your belt. It’s much more difficult than just deciding to make it a top priority. That’s why I’ll continue to publish weekly.

Why you should keep a learning journal

Hrvoje Šimić (shime@hey.com) — Sun, 20 Dec 2020 00:00:00 +0000

I’ve had a learning journal since 2011, but only recently have I realized the main benefit from it: it makes me learn more by paying more attention to bugs.

I wasn’t aware I had a learning journal back then since I was simply sharing short programming articles. But in essence, my entire blog was a learning journal back then. Only after seeing Rico Sta. Cruz’s TIL page have I decided to create a separate Today I Learned page. Seeing Rico’s page full of small tricks that can be immediately applied inspired me to create my own.

The advantage of being a programmer

As a programmer, you have the advantage of being able to share the knowledge that is easily applicable in different environments. Since code is just text, it’s easy to copy, and since it’s unambiguous, it’s applicable to different environments. Because of this, the friction for knowledge sharing is minimal.

This knowledge sharing is useful to other people, and I think that explains why Stack Overflow (with 20,574,098 questions) is a much more popular platform than Stack Exchange Philosophy (with 15,316 questions). Yes, the latter was created some years after the former, but that alone doesn’t explain the huge difference. Another explanation could be that philosophers are more interested in the discourse than in sharing solutions to problems, and Stack Exchange might not be the best platform for discourse. Stack Exchange is geared towards solutions for problems, and with philosophy, it might be difficult to understand the problem in the first place since it can be ambiguous.

This is not so in programming, where you can just read the solution, understand it, and apply it to the problem at hand.

An additional advantage of programming is that the feedback is fast. Nothing expensive needs to be done to test the proposed solution.

The benefits of keeping a journal

Publishing solutions to your problems helps not only other people but also yourself. Help for other people is obvious, but how it’s helping you is much more interesting. Keeping a journal makes you more aware of what you are learning and encourages looking for learning opportunities.

It’s easy to forget what you have learned, which is the main reason not all experts can teach well. They forget what’s it like to be a beginner since they were beginners a long time ago. Keeping a learning journal helps fight this effect. It exposes everything that you didn’t know, which can sometimes be embarrassing if shared publicly.

Bugs are the best learning opportunities. As a programmer, you interact with a machine of pure logic for a significant part of the day. It’s a machine that simply follows your orders. With every bug, the initial reflex is always that the machine is not working correctly. Yet, with almost every bug, this turns out not to be true.

It usually turns out that you’ve gotten the logic wrong: the model in your head for how the code works did not match the actual reality of how the code works. Every debugging session is essentially a recalibration of the model in your head. And a learning journal encourages better recalibration. You will tend to go deeper to understand what happened with every bug.

Memes normalize the shrugging attitude at the problem — the bug shrug: not understanding why the bug happened in the first place, fixing it, and still not understanding anything. Instead of that, the learning journal makes you go the extra mile to understand. It makes you listen to lessons that bugs are trying to teach you. Since the bugs are coming from the code you wrote or have to maintain, they reveal your thinking errors and not someone else’s.

The problem with Stack Overflow

You might ask yourself what’s the point of keeping a learning journal when you can instead just start answering questions on Stack Overflow. The problem with Stack Overflow, outside the most obvious one of you giving them your content for free, is that you are answering other people’s questions. These might not be the most useful questions you should be asking.

These questions are useful for other people and their problems, which can sometimes lead you down interesting paths of discovering how things work if you have the time to do so. But, more often than not, they are the questions about this or that triviality. Stack Overflow used to have better questions, but now they are mostly trivial, at least in the Ruby and JavaScript department.

You learn better from your bugs than from other people’s bugs since your bugs exist because of your lack of understanding. Even from an “it’s a feature, not a bug” kind of bug, you can learn something: that your feature is not intuitive but surprising. Every bug teaches you about something you currently don’t understand in the context of your current project. In that way, bugs are better even than building new features.

With Stack Overflow, you might get better reach compared to your blog. But reach is not the most important thing. Learning journal makes you a better learner, and that’s way more important.

Learning in public can sometimes be embarrassing

The biggest problem with the public learning journal is that you can sometimes end up sharing stupid things. Sometimes, you’ll learn things that will seem stupid to other people. One of my stupidest entries is about opening a portion of the log file with Vim. Everyone knows that editors should only be used for making changes and not just for viewing. Well, everyone except past me.

Embarrassment is one of the biggest drawbacks of having a public learning journal. People will see what you have only recently learned: that you learned about yield_self just two days ago. Oh, the shame. You might never recover from that.

If that’s the problem for you, keep a private learning journal for yourself. You’ll still have the benefit of learning more while still keeping your spotless reputation.

My experience with switching apps for personal knowledge management

Hrvoje Šimić (shime@hey.com) — Sun, 13 Dec 2020 00:00:00 +0000

Personal knowledge management (PKM) is the best thing I discovered in 2019. I’ve since tried a couple of different approaches and too many (six) apps. In this article, I would like to share everything I’ve learned about it over that period.

Investment in knowledge pays the best interest.

Benjamin Franklin

Why bother?

Given that every PKM system requires a significant time investment, it’s worth asking yourself what’s the point. What’s the benefit of spending all this time on writing notes? For me personally, it boils down to having a higher return of investment on reading itself.

I love reading and learning from the wins and mistakes of others since I can’t live long enough to make them all by myself, in the words of Eleanor Roosevelt. I have noticed that I tend to forget ideas from the books by just reading and not taking notes. I’ve fallen to the fallacy of “transmissionism”, as Andy Matuschak calls it in his great article about books. The belief that by just reading a book, I’m going to absorb the knowledge from it. In reality, I don’t really learn much that way.

Taking notes fights this effect of forgetting ideas. Instead of just reading, your goal becomes a search for interesting ideas that you can feed into your system. As you feed more interesting ideas into your PKM system, it becomes more valuable. PKM enables network effects for ideas. Instead of observing the radioactive decay of ideas from the books you read, their value starts compounding. ^[1]

I’ve come to realize that reading is just one part of learning. The other part is writing. Or, as Sahil Livingia has said: “Reading is the inhale, writing is the exhale.”

The benefits of PKM

Although I’ve tried using Building a Second Brain (BASB) as my PKM method, my current method is Zettelkasten (ZK). So, I’ll try to explain its benefits.

Zettelkasten is easy and fun for me. It makes reading, writing, and thinking more fun.

Reading becomes fun since I’m on the hunt for new ideas. Instead of just going through the book for bragging rights and signaling purposes, I’m hunting for surprising. When I find it, I’m happy since I can put it into my notes and improve all notes’ quality.

Writing becomes more fun since I do it in smaller increments. Instead of staring at a blank page when writing new essays, they write themselves from the bottom up. Every note is what Tiago Forte calls an “intermediate packet”. The essay gets composed out of smaller, reusable packets that each make sense on its own. Topics start to emerge. And so do the ideas for essays.

Thinking becomes more fun too. Making connections between notes and seeing contradictory notes triggers interesting questions. Instead of thinking just inside of your head, you get a system and environment that fosters that. As “How To Take Smart Notes” writes, storing permanent notes is a form of dialogue with your past notes. And this kind of dialogue encourages thinking more about the ideas that you encounter while reading.

Just writing things down in my own words improves my thinking. As Niklas Luhmann, the Zettelkasten method’s inventor has said, “It’s not possible to think systematically without writing”. By writing things down in your own words, you start realizing how much you understand (or don’t understand) about the subject. You realize the holes in your arguments. Questions start arising. Questions that wouldn’t otherwise be asked had you just done thinking inside of your head. Writing reveals questions and gaps in arguments.

BASB in Notion

My first encounter with PKM was learning about BASB from Maria Aldrey. She has used Notion to take notes and organize them into four categories in a system called PARA:

“Projects”, which have to have a deadline
“Areas”, which are your specific long-term areas of improvement
“Resources”, which contain categorized notes and highlights from articles and books
“Archive”, which contain archived projects, areas, and resources

Although I didn’t take the official course from Tiago, I went through all of his articles about PARA. After adding many articles and book notes to it, I started categorizing them and going through the process of “progressive summarization”, one of the most important lessons from Tiago.

It consists of adding layers of highlights to articles and books. Normally, bolding enables two layers of importance for content. Bolded text is important, while unbolded is unimportant.

The PARA method adds some additional layers of importance:

unbolded text
bolded text
highlighted (colored) text
summary
remix (original creation)

Not every piece of content needs to go through all five steps, but the most interesting pieces will go through all of them. The most interesting step is the remix, in which you try to connect the ideas expressed here with other notes in your system.

I gave this system a go for a couple of months, but it didn’t stick in the end. I was too tired from deciding how to categorize every note and where to put it. I ended up thinking about the organization more than about the content I’m saving. It felt too heavy for my taste, and it wasn’t a fun process. The distinction between “Areas” and “Resources” always confused me, and I never got used to it. My summarized notes, in the end, weren’t connecting and ended up being isolated islands. I was unable to find relevant concepts with the search. So after a couple of months, I’ve stopped doing it.

No structure in Roam

This brings us to Roam. After totally cooling down from BASB and Notion, I’ve discovered Roam and marveled at the beauty of it. Instead of writing notes and categorizing them, I started connecting them. As I wrote in an article from that time, Roam has freed me from unnecessary compartmentalization and encouraged me to build networks of ideas, which is more like how my brain works. It’s a network, not an archive.

However, I didn’t follow any system for taking these notes. I’ve later realized that not being systematic comes with a huge drawback. It all becomes a “magical junkyard” that is hard to navigate. I ended up with many notes and connections, but nothing in it ended up being useful. Each note was either empty, contained one idea, or hundreds of ideas. There was no way to differentiate them, so I ended up not knowing what’s useful. Searching was also difficult since I didn’t follow any method for naming my notes.

That’s why I’ve started to investigate other methods like BASB and found out about Zettelkasten.

Zettelkasten in Roam

I’ve decided to add some structure after realizing that my Roam database is turning into “the magical junkyard”. And that’s what Zettelkasten gave me. I’ve started keeping atomic notes, or notes that consisted of one idea only, and started being more careful with the note titles.

I’ve started thinking what the most useful title for each note is, considering my future searches. I’ve realized that note titles are like APIs. But, only viscerally since I’ve only later read Andy Matuschak’s notes on the subject. I wasn’t that good at naming my notes and started by using the Two Words approach that wasn’t very useful for future searches.

Using Zettelkasten in Roam meant that I got to preserve the fun I get from taking notes in Roam in an unstructured way while still fighting the fear of building a castle of sand. As “How to Take Smart Notes” writes, “a standardized work environment is less taxing for our motivation” and “having a system we can rely on makes us reduce decisions we have to make during a work session”. This standardized work environment is provided by BASB too, but with Zettelkasten, it’s not as heavy and hierarchical. There are fewer decisions that have to be made when taking notes. The network is built organically, bottom-up and not top-down.

However, after using Roam for some time, I got concerned about having my notes stored in a proprietary format, so I’ve started experimenting with other apps. I am a software developer, and I spend most of the day in the terminal, manipulating text in Vim. The blog you’re reading uses Jekyll, a static site generator that stores blog posts in Markdown.

I am a fan of Markdown since it’s easy to read for humans in its raw form, and it’s still very powerful with formatting. It’s just text that doesn’t need a special app to be read (unlike Roam). I would rather bet that 100 years from now, people will still be able to read Markdown than I would on people being able to read Roam notes at that time. Simply put, I wanted my Zettelkasten notes to survive a long period, and that’s why I started experimenting with other apps.

Switching to Zettlr

My first experiment was switching to Zettlr. The most promising thing that pulled me to try it out was that it was built specifically for Zettelkasten and uses Markdown under the hood. However, this experiment lasted very briefly. After realizing that I can’t create new notes by just surrounding the term with brackets, I’ve decided to quit.

Using Roam for a couple of months made me perceive this behavior as something very basic and essential. It’s easy to forget that not every note-taking app supports creating new notes in such a low-friction way.

Switching to Vim

I loved reading this article about building a Zettelkasten system directly in Vim, with help from bash. Since I’ve been using Vim for more than a decade, I am biased for using it for every context that I can. Or at least try.

After some tweaking and playing around with Vim Wiki and fzf.vim, I’ve ended with a somewhat functional environment.

I loved how everything was just plain Markdown, enhanced with Wiki-style links a la Roam. Creating new notes was effortless and worked by just surrounding the terms, unlike Zettlr. I especially loved how easy it was to open multiple notes at once for a higher picture. The only limit on how many notes I can view simultaneously was imposed by the screen size.

However, backlinks were problematic and required hacks. I was not satisfied after installing note link janitor by Andy Matuschak, since it didn’t come close to the power of backlinks in Roam. It was buggy, and often times the backlinks didn’t provide enough context, but just the first line of the mention. Editing notes directly in backlinks, like in Roam, was not supported.

What also bugged me was the fact that all of this was stored only on my computer. I’ve added an auto-command in Vim that created an encrypted backup in the background every time I’ve changed something and uploaded it to the cloud. However, I still wanted to edit my notes from the phone from time to time. Some people create their knowledge base directly on Google Drive and Dropbox and then edit text files from their phones, but this didn’t seem attractive.

I’ve decided to try something else since this environment felt too crude for me, and I had a fear of missing out. The thought that I could probably make more connections and think better had I used something else was always in the back of my mind.

Switching to Obsidian

After being somewhat skeptical when first seeing it, since I couldn’t find the name of the company behind it, I’ve decided to give Obsidian a go. I liked the fact that everything is stored locally and that it used Markdown. It felt similar to using Vim, but since it was specifically made to create and manage a “second brain”, it had some nice additional features.

One of the nicest was the support for backlinks out-of-the-box. However, the excitement with backlinks wore off pretty quickly since I was used to the more powerful version from Roam. They support customization with CSS, which allows some pretty fun stuff, like Andy Matuschak mode.

As with Vim, they support opening many notes simultaneously in the same window. This is perhaps the only thing regarding the user experience that is better than Roam. Although Roam offers the graph view for seeing connections between notes, I find it useful to look at the entire text from notes. It feels more like arranging physical notes on a table and then looking for connections.

The drawbacks of using Obsidian were similar to those of Vim. I couldn’t read or edit anything on my phone, and I felt a lot of FOMO. That’s why I’ve yet again decided to switch.

Switching to Bear

I’ve been using Bear for a long time, and I was happy with their UI and features. Still, I never considered using them for personal knowledge management. They also use Markdown for everything and store data locally in an SQLite database.

I love their emphasis on minimalism and how well-polished their mobile app is. The user experience on a computer, phone, and tablet is top-notch. There is no support for backlinks in Bear, although there’s Andy Matuschak’s hack for this too. I didn’t use it this time and wanted to see how far I can go without them.

I’ve found that they are not super critical for Zettelkasten. I had to be more intentional with the links and decide what kind of connection I want to make between every pair of connected notes. I’ve found that not every connection needs to be two-sided, like with backlinks. Using fine-grained associations instead of just listing notes that have something in common with a particular note has proven to be pretty useful. The backlinks provide another kind of relationship between notes, an implicit one, useful for discovery but not critical. Intentional relationships that are built by direct links are much more important.

One thing that started bothering me after I’ve created ~1500 notes in Bear is how slow it gets when renaming notes. Renaming a note that’s referenced a lot freezes Bear for some reason. It becomes unresponsive for 30 seconds, which is very annoying.

The benefit of opening multiple notes at the same time available in Vim and Obsidian is not present in Bear. To do so in Bear, each note has to be opened in a new window, which feels clunky and frictional.

Although I’ve been using some custom scripts for importing book highlights from Apple Books to Bear, which were useful to reference from my Zettelkasten, something was missing from my setup: the ability to save highlights from articles that I read online. Having all of the highlights in one place to connect, reference, and remix is a very powerful feature.

To try to work around this problem, I’ve tried using Bear’s browser plugin for storing entire articles in Bear, but the results have been unsatisfactory. It doesn’t come close to the quality of specialized read later apps like Instapaper and Pocket. What made it unusable is not that it couldn’t store an article, but that it stored incomplete articles. It made me lose trust in using Bear’s browser plugin and on the lookout for better solutions.

This brings us to…

Readwise, or why I’m back in Roam

Although it looked unpolished (at the time, they have since updated their design), Readwise was a very popular tool inside #roamcult, which is how I discovered it. It didn’t take long to realize how useful it is. When connected with Instapaper, Kindle, and Apple Books, it really becomes one of the most useful tools in the PKM toolkit. By capturing highlights from absolutely everything I’ve read, it becomes storage of the best of the best from my inputs. And then it resurfaces these best chunks to fight the forgetting curve. Marvelous.

As I was still using Bear at the time, I was frustrated that it didn’t have an automatic connection to Bear. Understandably, since Bear currently doesn’t have a web app or an API. However, I’ve noticed that there is such a connection with Roam, which made me go back to it.

And now I’m back at step one. I have both my Zettelkasten and all the things I’ve highlighted in Roam, and I don’t have to take action to make it happen. The only change I have to make is to read all the articles in Instapaper (I could use the browser extension for this, but I don’t trust third-party plugins enough to share all my passwords with them).

Thoughts on coming back to Roam after a long time

Coming back to Roam after all of these switches has made me aware of other great features of Roam that are easy to get used to but which don’t exist in other Markdown-based apps.

One of the most prominent ones is probably blocks and their transclusion abilities. Just as how everything is an object in Ruby, so everything is a block in Roam. This has proven to be very helpful when writing articles by following Nat Eliason’s approach. This article was written following that approach, along with zooming in into the blocks that follow titles from the outline. Writing this article has been the most enjoyable experience with writing so far (which is why this is the longest article I’ve written). This is somewhat surprising for me, as I didn’t think that the app I am using could greatly impact my writing experience.

Another surprising thing with Roam is how much easier it made writing a weekly newsletter. It feels like Roam was made to synthesize the best of content, which is the same goal of my newsletter. It’s very easy to either link to the next edition from wherever or just put the blank page of the next edition of the newsletter in the sidebar and go on the hunt for juicy blocks. As with writing, this has surprised me since I didn’t expect the app to make such a difference.

A couple of other worthy mentions missing from all the other apps I’ve tried are the sidebar and links in note titles. Sidebar enables exploration and makes transclusion easier, while links in note titles make linking even more effortless. With them, I can even create links from blank pages. I found it the most useful when linking to a concept that I’ve picked from another person (e.g., “How to think for yourself per [[Paul Graham]]”).

Since coming back to Roam, I’ve also made some changes with how I do Zettelkasten. I no longer follow Shu Omi’s approach for taking notes. The biggest flaw with that approach is that I’ve ended with many notes that express ideas from other authors in my own words and few ideas of my own. To fix that, I’ve added another layer of abstraction on top of what he calls permanent notes in his video. I’ll share more about that in a future article since this one is too long as it is.

As I’ve discovered that Roam is a superior environment for writing, and therefore thinking, I’m glad to sacrifice the longevity of my notes that I might have gotten with Markdown. After all, longevity is less important than the impact on the quality and enjoyment of thinking. Without enjoyment and a supportive environment, the notes will never reach the quality required to have them preserved in the first place.

The idea about radioactive decay is stolen from my co-rafter Nick Ang and his essay on personal knowledge management.

When magic works against you

Hrvoje Šimić (shime@hey.com) — Sun, 22 Nov 2020 00:00:00 +0000

When I first encountered this concern in the Rails app that I was working on, I was initially impressed. It felt like magic. Like a cool trick to avoid unnecessary complexity.

This concern enabled using let in Rails controllers. It inverts the relationship between controllers and views, so instead of controllers providing data for the views, it makes views ask for data from controllers. This post shows the reasoning behind it, and I will refer to it as “original post” in this article.

This is the example from the original post:

class WidgetsController < ApplicationController
  let(:widgets) { Widget.all }
  let(:widget) { widgets.find_or_initialize_by id: params[:id] }

  def new
    render :form
  end

  def edit
    render :form
  end

  def create
    save
  end

  def update
    save
  end

  def destroy
    widget.destroy
    redirect_to widgets_url,
                notice: "Widget was successfully destroyed."
  end

  private

  def save
    if widget.update secure_params
      redirect_to widget,
                  notice: "Widget was successfully saved."
    else
      render :form
    end
  end

  def secure_params
    params.require(:widget).permit :name
  end
end

With this, the templates would simply use widget:

<%= widget.name %>

However, there are a lot of problems with this approach.

1. It’s implicit

There’s a reason why ActiveRecord callbacks are not a great idea and why you should prefer not passing instance variables to your views. The Zen of Python famously generalizes this rule as “explicit is better than implicit”.

Code that relies too much on magic is too difficult to understand and therefore maintain. I would rather have duplication that is visible and easy to understand than DRY magic that is hard to understand.

2. It’s a fake local

The original post sees passing instance variables to views as an improvement of explicitly passing locals. (I strongly disagree because I find views with instance variables hard to maintain.)

let is more implicit than using instance variables. It suffers from the same problems as using instance variables since it uses instance variables under the hood. It makes views too dependent on their controllers. Partials become difficult to move around.

let adds another problem and makes it more difficult for the reader to understand that this is, in fact, a memoized instance variable.

It’s a memoized instance variable masquerading as a local.

So, just adding this concern into your application controller, as the author suggests in his original post, makes all of your views more difficult to understand.

Seeing:

<%= user %>

In any of your views makes it difficult to track down. Is it a local or an instance variable?

3. It’s easy to make mistakes

If you’re not careful, you can easily open a can of worms. One example is using let inside the application controller. Here’s an example:

class ApplicationController < ActionController::Base
  include Lettable

  let(:user) do
    User.find(params[:user_id]) if params[:user_id].present?
  end
end

Good luck tracking where user comes from in hundreds of your views or controllers.

* * *

So, by introducing the Lettable concern, you end up with somewhat cleaner controllers and views that become hard to understand. You avoid the issue of accidentally loading data for actions that don’t need it, as mentioned in the original post, but it makes your life much harder when it comes to maintenance.

Beware of the long term consequences of including cool tricks in your codebase. They might temporarily solve smaller problems but sometimes cause even bigger problems. What starts as magic can end tragic.

The importance of detachment

Hrvoje Šimić (shime@hey.com) — Sun, 01 Nov 2020 00:00:00 +0000

All my previous side projects flopped because of this. I looked at them from the perspective of a creator. I was stuck in that role. I didn’t have the experience of all the other people that were supposed to use the end product.

Yet, the ability to detach from one’s product is critical to producing something valuable. Not being able to detach makes evaluation impossible. This applies to essays, drawings, or apps.

I’ve experienced this with the new app I’m building in my free time. Remembering how I didn’t ship anything for months with my previous app, I’ve decided on a drastic change. I’ll use the app as soon as possible. Even with the awful design, I have to use it. I ended up using it after two days of working on it. I knew I’d learn something from that experience, but I didn’t know exactly what.

The great thing about using the app as soon as possible is that it enables many iterations. (In my case, one iteration loop consisted of designing, programming, and usage.) And having a lot of iterations has taught me a lot about design. Even though I’m the only person using the app, I still know what problem I’m solving, and I can assess how well I’m solving it. I’m probably not the only person with this problem, so it will be useful for others if I solve it well for myself.

But this requires some form of detachment from one’s work. To do a good job of assessing the quality of the thing being built, one must stop looking at it from a creator’s perspective.

No one cares how many hours you’ve spent building a feature. If it’s not useful and elegant, throw it away. If the entire app is not useful and you end not using it, throw it away and start over. Find a more interesting problem.

Some things are easier to detach from than others. For some reason, I find articles and drawings hardest to detach from.

It all comes down to practice. As app usage feeds the new iteration of designing and development, reading an article feeds the new iteration of writing. Practice makes it easier.

Detaching is a key part of evaluating the quality of the thing you’ve built, so it makes sense to do it often. For apps, that means constant usage. For articles, reading and re-reading what you’ve written without holding back your criticism.

The overreaction paradox

Hrvoje Šimić (shime@hey.com) — Sun, 18 Oct 2020 00:00:00 +0000

My bike got stolen a while back. It happened because I got lazy carrying my bike up the stairs and left it in the much less secure basement. I thought that taking it up the stairs is not worth it. Nothing will happen. No one will steal a bike from my building since it hasn’t happened to any of my neighbors.

That has reminded me of the Coronavirus preventions. Preventing the spread of Coronavirus by making masks mandatory. Closing down restaurants and bars is an unpopular political move. The effects of prevention are not visible. Since prevention, by definition, prevents something from happening, it’s hard to appreciate it.

This fallacy has been bouncing in my head for a while now, but I couldn’t find a proper term for it. Googling “unnecessary prevention” and similar terms yielded nothing useful. In the end, I found it inside my collection of notes. ¹ This fallacy is known as the Overreaction Paradox. It happens when prevention seems unnecessary because the result of it is that nothing happens.

Once I became aware of it, I started noticing it. From not wearing a protective skin for the phone, to not locking a bike since it’s only going to be unattended for 5 minutes.

There are no rewards for preventions, and you can’t even be aware that it’s necessary. But sometimes, it’s the right thing to do.

That has made me aware of how valuable my notes are getting. They are more valuable than Google at times. They contain all the interesting ideas I have encountered in the past year. So they are more useful when searching for abstract terms and concepts.

Write for yourself

Hrvoje Šimić (shime@hey.com) — Sun, 11 Oct 2020 00:00:00 +0000

There’s a tension that you’ll discover if you start publishing articles. A tension between writing what the world wants from you and what you want to write about.

Thinking about your audience can paralyze you to stop exploring what’s interesting. Instead of exploring your interests, you get distracted by the opinions of others.

The worst effect of this is self-censorship. Not publishing articles that you think few people will read. This has happened to me more times than I would like to admit.

No wonder we keep thinking about the opinions of others. There’s too much society everywhere. Social media keeps us in the never-ending now, bombarding us with opinions as soon as we wake up.

Yet, originality is one of the most prominent traits of excellent writing. But, it gets sabotaged by constantly thinking about the opinions of others.

Thinking about what others might like is usually done in an attempt to grow an audience. But by chasing a big audience, the writing quality suffers. This has an opposite effect on an audience’s size. Instead of it growing, it shrinks.

The secret behind writing a terrible article is to try to appeal to everybody. It’s a naive attempt to maximize popularity. By trying to do that, the article ends up appealing to nobody. As many other failed startup founders will tell you, an average person doesn’t exist. By trying to appeal to the average, the opportunity to excel in a niche is lost.

Writing is an award in itself, and publishing is a form of disobedience. Publishing regularly is a great way to fight the defeatist nature of self-censorship. By doing that, you are already doing something admirable.

Chasing audience growth for the sake of growth is the wrong goal to have. That makes it less likely to grow, so stop doing that. Relax, and focus on your writing.

Beware of programming puzzles

Hrvoje Šimić (shime@hey.com) — Sun, 04 Oct 2020 00:00:00 +0000

The most common piece of advice you’ll receive if you want to learn programming is that you should do programming to learn it. While this is well-meaning advice, since doing programming is better than reading about it, it’s incomplete.

Following this incomplete advice alone can prevent you from falling in love with programming. One of the worst implementations of this advice is learning programming by solving programming riddles.

Problems with puzzles

There are many problems with solving riddles, but let’s start with isolation. They are isolated from the real world, so once you complete them, you’re done with them. They never change. Real-world software does not behave like this. Real-world software has to deal with the only real constant — change. How adaptable your software is to change will tell you how well you’re programming. You don’t get this feedback by solving puzzles. Change is a great teacher, and it will teach you about the importance of tests early. Riddles can’t teach you that.

The next problem with riddles is that they are too focused on algorithms. Unless you plan to work on algorithm-heavy products like Google Search, you shouldn’t focus on that. Sure, that knowledge might get handy for technical interviews with companies that emulate FAANG interview practices, but that’s a topic for another article.

Another problem with solving riddles is that they give you the wrong picture of programming. Solving puzzles encourages cleverness, while code that’s too clever is a smell in real-world software. If it’s difficult to understand for people that have to maintain it (this includes your future self, a more forgetful individual than you might think), it’s not well written. As Donald Knuth famously said, “Programs are meant to be read by humans and only incidentally for computers to execute. “Good programmers make their code as easy to understand as possible, and solving riddles discourages that. Solving puzzles encourages the most innovative hacks possible, which is excellent if you want to compete in programming competitions, but real-world software is not like that.

Solving riddles can discourage you from learning to program and falling in love with it. I haven’t yet met a programmer who said that solving programming riddles made him fall in love with programming. Maybe they exist, but it’s usually something else.

Importance of having a bigger goal

Solving riddles is the impulsive implementation of this incomplete advice. You are rushing to do some programming, without having a bigger goal. The problem with this is that it’s not sustainable. If you don’t have a bigger goal, your motivation will be shallow, and you’ll be more likely to quit when things get tough. Having a bigger goal will push you through obstacles.

An excellent bigger goal is solving a problem that’s currently painful for you. Your local bus has a shitty website, and you have to search like a madman to find the next bus? Scrape their data and build the one yourself, and you’ll never have that problem again. You are searching for a new apartment, but you’re getting tired of continually refreshing the website for ads? Build a program that does that for you.

Whatever it is, if there’s a real-life problem that you would like to get rid of with some programming, that’s much better than solving riddles for the sake of it. By doing this, you’ll have a much better picture of what programming is and realize how useful it is.

Knowing the port one is sailing to

Hrvoje Šimić (shime@hey.com) — Sun, 27 Sep 2020 00:00:00 +0000

If one does not know to which port one is sailing, no wind is favorable.

Seneca the Younger

For the past couple of months, I’ve been doing more planning and reviewing. So far, the most useful review session was also the longest one — the one I did for the current year. It gave me a kick in the butt to change things with my work and made me realize that I needed to change things.

Not doing these reviews results in being in the autopilot mode. Since it’s hard to find time to reflect because of all the work that needs to be done, this leads to not questioning day-to-day activities. Because I’m heads down, I don’t have time to take a step back and ask myself if I’m going in the right direction. But, sprinting in the wrong direction is worse than standing still.

Because of the quote mentioned above, that keeps ricocheting in my head, I like to visualize myself as a ship. Not as the ordinary ship, but as the one that can either go forward or change direction. When I do the planning, I change the direction. When I execute the plan, I go straight ahead. That’s why it’s a good idea to spend some time planning and thinking about my goals. This time pays off.

Planning has given me much-needed guidance, and I’m more deliberate with my day-to-day. I don’t let weeks go by. It guides my daily habits. It’s much easier to be intentional and know what needs to be done when there’s a plan.

Currently, there are four types of planning I do:

mid-year planning - the big-picture planning
42 days plan - planning for longer projects that need to get done
weekly plan - planning for the current week
daily plan - journaling for reflection and habit tracker for execution

Every planning type guides the one below it. So the mid-year planning guides the 42 days plan and so on. The planning session duration gets shorter as the plan period gets shorter. I spend a week thinking about my mid-year plan, a day thinking about a 42 days plan, half an hour for the weekly plan, and a couple of minutes for the daily plan.

So far, I’m thrilled with the results and feel much more confident with my day-to-day decisions. I have found more direction in my day-to-day. I find it much easier to stick with my habits when I know why I’m doing them.

Reflection and assessing my success from week to week makes me take this planning more seriously. It’s not something I write down and then forget about.

I don’t want to be like a ship that doesn’t know to which port it’s sailing. Goals are my port, and the planning is the map for how to get there.

Writing-guided reading

Hrvoje Šimić (shime@hey.com) — Sun, 13 Sep 2020 00:00:00 +0000

There are so many great books to read, but so little time to do it. How to pick a book from a list of hundreds or even thousands of recommended books to read?

I read about a lot of different topics. This leads to reading about things that might or might not be useful in the future.

Reading in this way is like the education we get in school. We learn about concepts and facts that might or might not be useful in the future. It’s the abundance principle to learning. “You might need this someday.”

But, I’ve discovered a way to have more direction in my reading, and surprisingly it was by writing. Writing puts me on a quest to do more research about the topic I write about. That’s why I’m currently reading about evolution, history, and progress.

So if you want more direction with your reading, you should write about a topic. Yes, this only moves the problem to writing: from not knowing what to read, to not knowing what to write.

Yet, there is an easy solution for finding what to write about. Write about what you think about in the shower or before falling asleep. Write about topics that excite you. If some thought is ricocheting in your mind while you do other tasks, take notes. Put down that thought somewhere and either take action on it or remove it. If you write about topics that excite you, that will lead to reading more about topics that excite you. This is an antidote to reading books only because someone recommended it to you.

So, if someone recommends a book to you, it’s very likely a good book. It might not be the best book for you, though, since it’s not about things that currently interest you. It’s a book that was great for whoever recommended it. They have different interests, goals, and plans than you do, so this might not be the best fit for you. You can find a better book for yourself, for most of the books recommended by others.

Instead of reading because it might be useful in the future, read things that are useful now. Think scarcity instead of abundance.

While life is short, there’s an endless amount of books to read. Instead of reading any mildly intriguing book, read what’s currently useful. Instead of letting others decide what to read for you, decide what to read yourself. But, don’t decide based on your current mood or trends. Decide based on the usefulness of the book for the article you’re writing. And it should be about the topic that excites you. Focus on reading about what you can immediately apply to real-life — what you can test in reality.

The best books are the ones that re-ignite your passion for reading — the ones you can’t put down.

Currently, “The Rational Optimist” is that kind of book for me. I can’t stop reading it, and time flies with it. Most of the books are not that good, and there’s nothing wrong with quitting the book after one chapter. By doing that, I’m more careful with my time. I preserve more of it so that I can invest it in a better book. Each book comes with an opportunity cost.

The great way to fight this opportunity cost is by guiding your reading with writing.

Writing will launch you on a quest to do more research about the topic that excites you. Let it act as a filter for your reading, and no book will bore you ever again. And you will find yourself reading a lot more.

Why I've decided to switch to Hey

Hrvoje Šimić (shime@hey.com) — Thu, 03 Sep 2020 00:00:00 +0000

When Hey came out, I wasn’t sure that I’m going to use it. But, I was interested in trying it out. I thought it was an overpriced email client and that there is too much hype around it. The App store drama didn’t help. Yet, I was interested in it since I would like to stop using Gmail as my primary email address.

That’s why I’ve tried to spin up my mail server. Tried is the keyword here. I thought, how hard can it be? Well, it can be pretty hard. After spending an entire morning of a Saturday trying to set everything up for it, I’ve decided to stop trying. Although you’ll learn a lot about the technology by setting up your mail server, this learning is sometimes not worth it.

I’m not that interested in mail servers, and I like to spend my time on things that I enjoy more. I don’t like spending my Saturdays on figuring out how to set up a server that I’m not interested in maintaining.

Setting up my email server

I’ve used Docker Mailserver and got lost in weeds with this thing. There were so many components I knew nothing about. The biggest issue is me being a total dummy with this, so I knew I didn’t set up security correctly. And the goal is to use this email address as my primary email address. So it has to be secure.

This made me go back on a hunt for an email service that I could use to stop using Gmail for everything.

After a lot of research, I’ve come back to Hey. With the other services, there was always something missing. Either they didn’t have strong enough security or were underdone or too privacy-focused for my taste.

The other email-hosting services

Initially, I’ve tried Namecheap’s email service since they looked pretty cheap for $10/yr, and I wondered what I would get for that kind of money. Not much, it turns out. They have a polished landing page and a UI that looks like someone’s learning project on the side. Not something that I would trust with being my primary email service.

After that, I’ve tried and ditched Protonmail since they encrypt everything, and I don’t need that kind of privacy. I would not be able to use it with my email client, without setting up some sort of a bridge. I was also unsure whether I should trust this company for hosting my primary email address. I don’t know much about them. I only know about them because of their privacy-focused email service. That’s why I’ve decided to keep looking.

Going back to Hey

At this point, I’ve already spent more of a day searching for the Gmail alternative. But, I kept using Hey since I was still on the free trial. I loved how they separated inboxes and how I get to screen everyone before accepting their emails. I’m also a big fan of Basecamp and their philosophy, and I know a lot about them. I trust them with hosting my primary email address.

That’s why I’ve decided to buy the yearly subscription. A Saturday is worth much more than that to me, so I’m glad to spend some money to make this problem go away. I’m also glad that by doing so, I support the company that has given me Rails, which has changed my life and my attitude to programming.

The law of ever-increasing entropy

Hrvoje Šimić (shime@hey.com) — Sun, 30 Aug 2020 00:00:00 +0000

“All happy families are alike; each unhappy family is unhappy in its own way.” These are the famous words of Leo Tolstoy. But why is that the case? It all boils down to the law of ever-increasing entropy.

This is the second law of thermodynamics. It states that the entropy, or the amount of disorder, in a closed system, increases over time.

The harmony is one state, while the chaos comes in many forms. Murphy’s law states that anything that can go wrong will go wrong. Again, there are more states of chaos and disorder.

It’s generally much easier and much faster to destroy than to build. Weapons are usually invented before protection from them. The prototype of the firearm was invented in the tenth century. At the same time, the bulletproof vest wasn’t invented until the nineteenth century. Nuclear weapons were invented before developing nuclear power plants. In cyber-security, it’s easier to attack than to defend. While defending, you have to cover all the holes, while as an attacker, you have to find one vulnerable spot.

The bullshit asymmetry principle tells a similar story, coined by Alberto Brandolini (although half the internet credits Paul Kedrosky as the author). It says that the energy necessary to refute bullshit is an order of magnitude bigger than to produce it. Bullshit comes in many forms, and there are many ways in which an argument can be invalid. That’s why it’s easier to produce it. Finding truth takes a lot of effort since you have to make sure everything is valid. You have to find evidence for your claims, or better yet counter-evidence.

Spreading bullshit takes almost no effort and requires no critical thinking. As soon as I can write or speak, I can share nonsense that doesn’t make sense. Babies learning how to speak, usually talk nonsense. They don’t share logically sound arguments.

Where can we find more examples of this law? Peter Kaufman advocates that we can learn the most fundamental knowledge from the three oldest and biggest systems:

the universe, 13.7 billion years old
organic universe, 3.5 billion years old
human history, 20,000 years old

Let’s see how the law of ever-increasing entropy applies to each of them.

Increase of entropy in the universe

It’s the law of physics. So it applies to the largest and the oldest system that we know of — the universe, 13.7 billion years old. If we look at the entire universe as a closed system as time passes, there is more chaos. The most probable end game is the heat death of the universe — the point of maximum entropy.

Entropy in the organic universe

If we look in the second bucket — the organic universe, it also follows the law of increasing entropy. Aging is nothing other than a constant increase in entropy since cells accumulate damage over time until they stop dividing. Normal human cells die after 50 divisions, which is known as a Hayflick Limit. The result of this is death, which is a point of maximum entropy. Living beings fight against the increase of entropy in their bodies.

Entropy in human history

We can see examples of this law in relationships, too. Every relationship is nothing but a fight against the increase of entropy. If you don’t take any action in a relationship, and let the time pass, it ceases to exist. The entropy of a relationship increases until it dies. But, every positive interaction decreases entropy. Successful relationships are successful because of the energy input that eliminated entropy. The entropy would kill a relationship without the energy input. So, if you care about sustaining a relationship, fight entropy.

My daily encounters with this law

As a software developer, I encounter an increase of entropy on a day-to-day basis. In this universe, entropy is known under a different name: technical debt. As time passes, the natural tendency of this debt is to increase. Software developers need to fight this effect. Otherwise, a project will go off the rails. Not spending energy against this tendency, the project’s entropy will increase and lead to maximum entropy — death.

Generally, not spending energy leads to an increase in chaos. So whenever you are cleaning your desk or nurturing your relationships, you are fighting entropy.

Word rafting

Hrvoje Šimić (shime@hey.com) — Sun, 23 Aug 2020 00:00:00 +0000

I had a crazy idea in the morning two months ago. I was drinking a lot the night before, and that usually causes waking up earlier and with some unusual ideas. I’ve decided to start an online writing group.

How it all got started

This idea didn’t come out of the blue. It was brewing for months. I was very pumped up about writing, so I wanted to find people that share my passion for it. That would push me to become more serious about writing. I would also meet people that share the same interests. Unfortunately, I couldn’t find any writing communities that I would want to join.

I decided that I should try to build a small community of writers. If I have this problem and can’t find anything that solves it, I bet there are other people with the same problem.

So I decided to reach out to Nick and ask him what he thinks about my idea. He wanted to know more about it. It looked like my idea had legs. That’s when I’ve decided to think more about it and what I would like a group to look like. So I’ve decided to put a document together that described it better.

The document is still there, describing the rules of our little group. We follow what’s written there, and this has produced the highest streak of articles I’ve ever had. This is the eighth article in a row that I’ve published.

The rafting struggle

Sometimes it is tough to put the article out. Since there is a hard limit to publish it every Monday at 8 AM UTC, we all publish on Sunday evening. We all wait for the last second to publish. It makes sense sometimes to me, since I want to spend as much time as possible on editing and polishing it up.

This doesn’t happen with all my articles. I sometimes “can’t find the time” ^[1] for writing the articles until Sunday. That’s when I either get my shit together and write that article or polish up an old draft that collects dust.

Sometimes I even do a trick that requires the least amount of effort. I publish a book summary. I keep notes for most of the books that I read, so this doesn’t take a lot of time. I polish my notes a bit and publish it. I’m not very proud of that. Feels like cheating.

I’ve almost fallen off a word raft two weeks ago and lost access to the group forever. I was sick and didn’t want to do anything on a Sunday. But I had to publish an article ^[2] since I didn’t publish anything that week. I’m glad I’ve survived that and learned something from it. Don’t be lazy, waiting for the last second to publish your articles. (The previous sentence was written by past me on Friday in a first draft. This article was published on Sunday evening. I guess I haven’t learned anything after all, other than past me sometimes being too strict. Relax man, I had a life to live.)

Reflections on rafting

Out of these eight articles that I’ve written, I’m happy with some, less with others, but I learn a new thing with each one. Every article is like a small MVP or an experiment. It’s like building side projects, on a smaller scale. With every article, I bet that people are going to find this interesting. I learn from that experience.

I feel closer to Michael and Nick than to other people I’ve met online and real-life acquaintances. I consider them friends since we are in the same struggle. That connects us. We support each other and inspire each other to become better. Nick has put it best: “It’s the positive peer pressure.” Smokers pressure you to light one, drinkers pressure you to drink one, we pressure you to publish one.

Lessons learned

The biggest lesson learned is realizing the power of a small group dedicated to the same goals. There are only three of us. The rules are simple. The goal is shared, and this is powerful.

Another lesson is taking action. I’ve spent countless hours looking for the perfect writing community. Nothing seemed right to me. Instead of that, I could’ve made a little effort. I showed a small initiative by messaging Nick and Michael on Twitter, and it paid off. We all expect someone else to take action and do something. It pays off to take some action.

I hope I’ve pushed you a little to consider starting your own group around your interests. It’s a great way to make new friends and push yourself to improve.

Sorry about another Sunday evening article.

Very common excuse when something is not a priority.
That was the one about the Apple watch.

Writing regularly

Hrvoje Šimić (shime@hey.com) — Sun, 26 Jul 2020 00:00:00 +0000

I’ve stopped writing regularly. I’ve published a couple of articles about personal knowledge management and stopped. I’ve broken the habit. I’m trying to get back to it now, but at the time I felt that there is nothing else to say about the topic.

The inner critic

My readers aren’t interested in anything outside of my usual topics: product attempts, freelancing, or personal knowledge management.

This line of thinking gives more power to the inner critic I have to fight with every article I write. Every time I publish, I hear this voice inside my head that makes me start questioning things.

My writing is not good enough, and no one will read it. It doesn’t matter. It’s not interesting or useful.

And that’s what pushes me to publish.

The flinch

I’ve learned about the “flinch” a while back, from a book of the same name by Julien Smith. This experience reminds me of it. He explains it with an example of novice boxers. When they start training, they close their eyes before every punch in the face. To win at boxing, they need to fight this reflex.

The voice of this inner critic is my flinch, and I fight it by publishing regardless. It is one of the most reliable indicators that I’m leaving my comfort zone. It’s disguised as a voice of reason. It’s telling me that what I’m doing is crazy. Why bother? Don’t risk it. It makes no sense.

The same thing happens before I turn the cold water in the shower. Or before I start a hard conversation, send an uncomfortable email, or start giving a meetup talk.

This voice is like flight control telling me where I have growth opportunities. I then decide whether I should go after that opportunity or not.

The same thing happens when I publish an article and send the newsletter. It makes me fight the flinch, and it confronts this fear. It makes me become better at it.

And that’s why I’ll keep on writing.

Lessons from my third failed startup

Hrvoje Šimić (shime@hey.com) — Sun, 19 Jul 2020 00:00:00 +0000

I’ve recently quit the US company that I’ve co-founded.

That makes it three — my third failed startup attempt. I’ve been working on it for 18 months, so this is my longest-lasting startup attempt so far.

Here are the lessons I’ve learned.

Not being patient with incorporation

My co-founder and I decided to incorporate pretty early. It made sense at the time because it formalized our relationship. It made it clear how we share the ownership of the company.

But, incorporating added a lot of other issues that we had to deal with. Bureaucracy. Opening up a bank account. Hiring lawyers and accountants to figure things out for us.

83(b) election is one especially sweet surprise that I had to deal with. We had to figure out how to do that, and even the lawyers and accountants we hired didn’t know how. I had to send two complicated forms and a copy of my passport notarized by the US embassy via snail mail overseas. After a couple of weeks, I got the rejection letter saying that I should file another form. They also requested another copy of my passport. They no longer accepted them notarized by embassies. How funny.

This was a big surprise. I didn’t expect to deal with so many issues with bureaucracy in the states. I’m used to that here in Croatia, but I didn’t expect the same treatment.

Stripe Atlas and Gust Launch, which we used, make incorporation super easy. But that doesn’t mean that you won’t have to deal with legal stuff. We jumped the gun. Thinking they would do everything company-related for us, but that turned out not to be the case.

Instead of building a product, we spent time and energy on tax and legal stuff because of this. This was the biggest mistake we made. It affected the time and energy we could’ve invested in building the product.

Incorporating early to protect yourself also doesn’t make sense. If you think your co-founder will screw you over, why are you starting a company with them in the first place?

The right way to do it is to wait with the incorporation until we launch the product. We could’ve given a 30-day free trial, so we have some time before billing people. Having a product without a company is way better than having a company without a product.

Risking by not having billing done on time is much better than risking a lot of time on company stuff. All that time that went into company stuff ended up costing us the product.

Not launching soon enough

We never launched anything. 18 months of part-time work, down the drain. As always, my consolation is, “at least I’ve learned something.” Yeah, I wouldn’t be able to write this piece if that wasn’t the case.

It took us this long since we didn’t feel it was ready for the launch. We ended up coming up with constant redesigns and user experience improvements. Running in circles felt very productive.

Launching is a reality check, and we didn’t do it. We kept believing we are building something useful because it was valuable to us. We were eating our own dog food. But we are biased. We are creating it, so of course, we are going to use it. We’ll come up with creative ways for existing products to annoy us.

Is it different enough than other products in the same space, and are people willing to pay for it? That’s the question. And we didn’t bother to get the answer to that by launching.

We kept running.

Not choosing boring technology

I started building it with Node.js for the back-end, React on the front-end, and Electron for the desktop app. I had a laughable level of experience in each of these. I chose something I don’t usually work with. Big mistake. This added another potential point of failure that could’ve been avoided.

It’s tempting to look at a startup as a place where you can have fun. Where you can play around with the most popular technology of today. An escape from that pesky legacy application you have to maintain in your day job. But this comes at a price.

Play with technology that excites you as much as you want, but do it on the side. Don’t call that a startup. That’s more of a fun experiment than a startup. Make exciting things in the product, not in the tech stack. Make it interesting to the people you serve. Not for yourself, at least not in the tech stack.

Getting pageviews on an article about the exotic tech stack you use should not be your startup’s goal. Building a startup is not a popularity contest. No one cares about your startup and its tech stack. The only thing everyone wants from you is to improve their lives somehow. Solve their problems. Figure out a way to do that, and your startup will survive.

Startups should have as little potential points of failure as possible. Don’t add one by choosing exciting technology. If you can avoid unnecessary risks, you should.

The odds are against you from the start. Choosing boring will increase your chance of success. The exciting shiny new thing will try to seduce you. Be aware of it and don’t let it. Fight the novelty bias so prevalent in the software development community.

Surviving for as long as possible should be the goal of every startup. Avoiding failure, not playing with exciting technology. Startups are hard already, so why make it super hard for yourself?

Use the tech stack you’re most proficient with. If you have a lot of years of experience with the stack, you should stick with it. You know the quirks of the tech stack you are proficient with. There are no surprises with its limitations. It won’t surprise you with something you’re going to spend days debugging.

If you want your startup to succeed, think hard before using anything that’s not boring. Boring will get you far.

These are the lessons, and I’m writing this for myself too. To remember them when I start my next attempt. And the next one is coming, for sure.

On the shoulders of giants

Hrvoje Šimić (shime@hey.com) — Sun, 12 Jul 2020 00:00:00 +0000

Robert Heinlein, claims that “specialization is for insects” in his science fiction book “Time Enough for Love”:

A human being should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, die gallantly. Specialization is for insects.

Robert Heinlein, Time Enough for Love

But, this overlooks the benefits of specialization.

How would the world of today look like if our ancestors didn’t specialize? What would’ve happened if everybody did everything?

Would we even enjoy the most beautiful effects of our technological progress, like getting depressed due to constant comparison with our peers’ overpolished photos from their current vacation?

Inherited progress

When we are born, we inherit the entire human race’s progress from the past. This progress produced infrastructure and tools and utilities. And we take a lot of this for granted.

As Matt Ridley writes in “Rational Optimist,” hand ax and computer mouse are both tools, but they are vastly different. A single person made the ax, and hundreds or even millions of people made the mouse. Collective intelligence, using division of labor and specialization, created a computer mouse.

The advantages of specialization

Specialization enabled the division of labor. This division enabled the production of complex objects like this computer mouse and other complex products that we use to improve our lives’ quality.

Since I’m a software developer, the essential product I own is the Macbook Air. I use it to put food on the table. I know how it works and its components, but it would be impossible for me to build it from scratch. Where do I even start?

The Macbook Air is the result of constant innovation over a long period.

Specialization encouraged this innovation. It motivated people to spend time on tools that create other tools. This innovation increased the rate of progress. Tools that make tools make making tools more easy.

Specialization also increased productivity. Many workers doing one task are more productive than a single worker doing many tasks. Specialized workers produce much more. They do it quickly and with higher quality. The companies using specialized workers are more productive than companies who have workers that do everything (do these exist?).

Adam Smith said that the total output increases when one worker specializes in one activity and trades with other specialized workers. Everyone is better off with that exchange, since the production increases.

Division of labor makes sense since those who specialize in a task become more proficient in it. This depth of specialization makes building very complicated products possible, that would be unimaginable if a single person made everything.

Idea sex

To create is to recombine.

François Jacob

The division of labor is not an invention of Adam Smith. It started much more early, right after the Agricultural revolution. People started specializing, and this benefited everyone — it encouraged trade.

People initially bartered their goods and services, and money later replaced it. People needed a convenient tool for exchanging products of specializing, so money is a side effect of trading.

Trading encouraged idea sex, which increased the rate of progress. Sex plays a crucial role in biological evolution and speeds it up. What sex is to biological evolution, the exchange is to cultural development. Exchanging ideas and making them have sex propelled the culture forward and increased growth.

The idea sex didn’t stop. It’s very present in the modern era. Modern-day start-ups are being pitched to their potential investors as “Uber for X”, or “Airbnb for Y”.

Every new thing is a remix of existing ideas, from Star Wars movies to songs from Led Zeppelin ^[1]. PC was the remix of many things that preceded it, like the Memex and the typewriter.

If you wish to make an apple pie from scratch, you must first invent the universe.

Carl Sagan

Nothing is created from scratch, and everything is a remix. You and I included.

These examples come from a beautiful free documentary “Everything is a Remix”. I highly recommend watching it to dive deeper into the subject.

The beauty of journaling

Hrvoje Šimić (shime@hey.com) — Thu, 02 Jul 2020 00:00:00 +0000

Journaling is one of my favorite habits, and I love it. I do it almost every day. If you’re not sure about the value it provides and are thinking about quitting it, this article is for you.

I’ve started journaling two years ago, and I’ve been doing it on and off for a while. I’ve since become more regular with it.

At first, I didn’t understand it. It was nice to remember what happened during the day and to write down my thoughts. It felt like a conversation. I could go on and on about events and exciting things that I’ve thought or experienced.

I thought the primary value of journaling was the sentimental value it provides. In a couple of years, I’ll read these entries and amuse myself by all the changes that happened. I’ll witness how much wiser I’ve become. How I had all these silly thoughts and worried about things that never happened.

While this is true, that is not the main benefit of journaling. It took me two years to discover that. But more on that later.

First, I have to explain why I’ve ditched journaling many times and why I was so sporadic about it. You might identify some of the problems in your journaling practice.

Journaling at the wrong time of the day

I’ve tried out journaling at every possible time of the day and even many times a day. In the morning and before going to sleep. After a bunch of trial and error, I’ve found out that mornings are the best time for journaling for me. If I do it before going to sleep, I’m rushing it and am not thinking enough. It feels forced, and that’s why I’ve quit it many times.

Journaling by following prompts from other people

This is another problem that made me quit. I would find a prompt from someone and copy it to my journal. After some reflection, I’ve found out the reason behind this. It is my feeling of inadequacy when it comes to journaling. Believing that I’m doing it wrong and that those other people will show me how to do it. That’s the reason why I started writing twice a day in the first place. A template I’ve copied had prompts for both morning and evening. How dumb.

Prompts also asked me what I’m grateful for or what amazing things have happened. It turns out writing what I’m grateful for doesn’t make me more grateful and feels repetitive. Writing about amazing things that have happened is better. I’ve incorporated that into my Roam database. I don’t use it only inside the journal; I use it all over the place by tagging amazing things that happen. Tagging makes it possible to look at all the great things that happened at a glance, that I usually forget. Now, this makes me grateful.

I always tend to try to improve things, which is why I search for templates and systems. This article will also suggest a system. Oh, the irony.

Journaling about things that don’t matter

I’ve made another error with journaling. I wrote about things that are not interesting to me but felt like they should belong in a journal. This made the journaling experience boring and made me quit journaling again. If it’s boring, why am I doing it?

The only hobbies worth keeping are those that increase my energy. Those that fulfill me and make me happier. It’s my free time, after all. The best way to spend it is to do things that I love doing. To do whatever I can’t stop thinking about.

Not journaling because it drains my energy for writing

This is another stupid mistake I’ve made. I thought I have to preserve my energy for writing articles and that I waste that energy by journaling. In fact, the exact opposite is true. I’ve written and published most articles when I was journaling.

Morning Pages

After years of on-and-off journaling, I’ve finally found a style that suits me. I journal first thing in the morning, and I write at least 750 words.

This is the practice of Morning Pages. Many people are writing about the benefits of doing this regularly. The benefits include reducing anxiety and clearing your mind.

While I’ve noticed these benefits, the most significant advantage is that I get new ideas. I bump into them, and Morning Pages encourage me to write about them. I discover more of them.

Another significant benefit is that I learn to silence the inner critic. That nagging feeling that my writing is not good enough. To fight it, I let the words flow out of me, and I don’t worry about what I’m writing.

These two things are the reason I journal daily, and I’ll continue to do so. I’m sacrificing the sentimental value. I don’t go into too much detail about events that have happened. The sentimental value the journal provides is extra, so I’m willing to sacrifice that.

It’s not universal

Finally, if you have to take one thing from this long article, understand this. Many people claim that there is no right or wrong way to journal. I want to change that claim a bit: There is no universally right or wrong way to journal. No one can serve you the “best journaling template”. It’s different for every person. It’s like the question: “What’s the meaning of life?”. There is no single answer that applies to everyone, and journaling is the same.

You can journal wrong, and you’ll know it if you feel it in your gut. If you don’t look forward to it and don’t enjoy it, you’ll quit. That might not be because you hate journaling, but because you use the wrong style. Find your style. Try different things. You might just find out how beautiful it is.

Why I love Jekyll and Github Pages

Hrvoje Šimić (shime@hey.com) — Wed, 22 Apr 2020 00:00:00 +0000

This website is powered by Jekyll and hosted on Github Pages. I’ve been using this setup since 2011 and I’m really happy with it, and there are multiple reasons for that.

1. It’s completely free

Hosting this website doesn’t cost me anything. The only expense I have is the domain registration, which is $35 a year, but I can live with that.

2. No server

I don’t have to worry about managing a server. This saves me a lot of time and headaches. I don’t have sleepless nights for not updating the distro to the latest version. I don’t have to worry about being hacked because I haven’t applied the latest security patch.

3. No worries about traffic

I don’t have to worry wether an article will end up on the front page of Hacker News and overload my server with traffic. I let Github worry about traffic and handle it.

I don’t have to think about traffic, since it is not correlated to the hosting costs. I don’t have to worry about hosting costs skyrocketing if my website becomes popular.

4. Free effortless SSL

Enabling SSL on this website required a switch of a button in the repo settings. Piece of cake.

There are some drawbacks, though.

1. It’s only intended for developers

Jekyll has a learning curve and is not intended for non-developers. You have to learn the basic conventions and a bit of its template language — Liquid.

2. No server

Yup, this is both an advantage and a drawback. Forget about all these niceties that come with having a server. You can’t even have a form, without relying on third-party services.

3. Publishing on mobile is hard

Unless you want to spend a weekend configuring a CI/CD pipeline for building your Jekyll website and pushing it to Github Pages, you are limited to publishing from your computer.

4. There is no fancy online editor

Unlike Ghost, Medium or Wordpress, Jekyll doesn’t come with an online editor. You have to master Markdown and HTML. Sometimes it takes some effort to achieve something that would be a drag and drop in those fancy editors.

Considering all this, I’d say Jekyll and Github Pages is a great way to blog in 2020.

The power of writing

Hrvoje Šimić (shime@hey.com) — Fri, 03 Apr 2020 00:00:00 +0000

The 1% rule says that within an Internet community, such as a wiki, 90% of participants only consume content, 9% edit or modify content and only 1% of participants create content.

This is applicable, as a rule of thumb, to publishing essays on the Internet; most of the participants only read them, while only a small minority writes them.

However, there are certain benefits to being in that minority; it encourages improving writing skills. This is a good idea, since writing is needed in any kind of knowledge work today. The most usual first encounter with the next employer is the cover letter, which requires a good level of writing skill.

When in doubt, people from Basecamp recommend hiring a better writer.

If you are trying to decide between a few people to fill a position, always hire the better writer. It doesn’t matter if that person is a designer, programmer, marketer, salesperson, or whatever, the writing skills will pay off. Effective, concise writing and editing leads to effective, concise code, design, emails, instant messages, and more. That’s because being a good writer is about more than words. Good writers know how to communicate. They make things easy to understand. They can put themselves in someone else’s shoes. They know what to omit. They think clearly. And those are the qualities you need.

Basecamp — Getting Real

The power of a well-written cover letter

I’ve only sent a single cover letter the last time I was looking for a new client, and he is one of the best clients I’ve ever worked with. Since this means the response rate was 100%, I consider it a great success. The usual response rate for previous cover letters I’ve sent was around 50%.

In total, I’ve probably sent over 50 cover letters. Most of them simply listed my years of experience, top open source contributions and some generic statement about why I would be a great fit for the team. I’ve never spent more than 15 minutes on writing each.

In contrast, this time I’ve spent 3 hours! I skipped all the usual bullshit and decided to write a long email explaining why I loved their job description. Putting in the extra effort really paid off.

Writing to learn

The generation effect explains that we learn better when we write about the topic we want to learn about. No one knows exactly why, but we better remember information when it’s actively created from our own minds.

The usual practice of the education system, however, is giving the students tests to write after they have learned the material. They are rarely encouraged to “think on paper”.

The brain is no place for serious thinking. If you’re thinking about something important and complicated, write it down.

Jack Altman

Writing while reading is a good way to improve the understanding of the information consumed. You can’t write about something in your own words, unless you understand it.

Richard Feynman once had a visitor in his office, a historian who wanted to interview him. When he spotted Feynman’s notebooks, he said how delighted he was to see such “wonderful records of Feynman’s thinking.” “No, no!” Feynman protested. “They aren’t a record of my thinking process. They are my thinking process. I actually did the work on the paper.

Sönke Ahrens — How to Take Smart Notes

Writing to generate new ideas

Writing about a topic will give you more ideas for writing. The ball gets rolling, and the ideas start to reproduce. As you write, you’ll explore what you think and make new realizations. It’s hard to do that without writing. Writing is not simply putting ideas from your head on paper, it’s about thinking on paper and getting new ideas.

I think it’s far more important to write well than most people realize. Writing doesn’t just communicate ideas; it generates them. If you’re bad at writing and don’t like to do it, you’ll miss out on most of the ideas writing would have generated.

Paul Graham — Writing, briefly

Writing to generate opportunity

The last article I’ve published generated opportunity I didn’t know existed. It opened some interesting doors for my current client. It connected people around me in a way that benefits everyone. It happened just because I’ve written something interesting, which made the article popular and reached more people.

Writing is the most scalable professional networking activity. Stay home, don’t go to events/conferences, and just put ideas down.

Andrew Chen

David Perell writes about this regularly and encourages people to build their own “serendipity vehicles”. Blog is nothing more than a tool for attracting interesting people and with them, the opportunity you didn’t know existed.

Writing is the best kind of networking. By making it easy for people to find you online, you’ll create a vehicle for serendipity. Call on your vehicle when you want to manufacture serendipity, and you need some activation energy.

David Perell — How to maximize serendipity

From a cover letter that lands you a job of your dreams, to writing an article that creates opportunity you didn’t even know existed, writing well is a super skill, so write more.

Do whatever you can't stop thinking about

Hrvoje Šimić (shime@hey.com) — Fri, 06 Mar 2020 00:00:00 +0000

Update: For some reason this post ended on the 1st place of the front page of Hacker News.

Since the start of the year, I’ve been making mistakes with with my free time. I’ve been spending some of my leisure time on wrong activities.

Wishing to improve in the open-source department, one of my New Year’s resolutions was to become more active with Rails contributions. I would learn about Rails internals, help people with their issues and get feedback from Rails core team members. The plan was to work at least 30 minutes on Rails every day and I was using a habit tracker tool in order to ensure that.

However, I’ve noticed that doing that significantly drains my energy. I’m not excited about doing maintenance work and it doesn’t make me jump out of the bed in the morning.

I haven’t realized how bad it was for my energy, until I decided to work on a side project last weekend. It made me super excited. The process of turning something from my head into reality will never stop feeling magical. I was eager to wake up and work on it. Working on it didn’t feel like work. Hours passed without me noticing. I wasn’t tired, I was excited afterwards. I’ve neglected my other habits because of it.

This was such a contrast to pushing myself to maintain Rails. That’s when I remembered having read about managing personal energy from “How to Fail at Almost Anything and Still Win Big”. I’ve read it, but haven’t thought about it much until now. Experiencing such a difference in excitement about something I do in my free time made me remember it.

To the experts, what looks like hard work from the outside, is play from the inside.

Naval Ravikant

The basic idea of personal energy management is that you should focus on increasing your personal energy and lifting up your mood in your leisure time, instead of working on things that drain your personal energy. Hobbies should lift your mood, not drain you. This makes you better perform all the other tasks.

I think the difference in my experience comes from the source of motivation. I am not intrinsically motivated to work on Rails. If money wasn’t the issue, I would probably not start working on maintaining it. The hidden motivation was external and it was rooted in the desire to make it more easy to find the next job.

Building a side project, on the other hand, is something I can imagine myself doing, if money was not the issue. That’s why I should probably spend my leisure time doing that.

Because every minute spent doing something other than what you love most today is a minute you’re more likely to regret when you’re 80.

Julian Shapiro

Another useful tool, for deciding what to work on is the Regret Minimization Framework: Project yourself being 80 years old and thinking whether you would regret your current decision. That’s how Jeff Bezos decided to work on Amazon. It’s a useful tool for prioritizing over long-term and rationalizing decisions that make no sense in the short-term.

Never work on anything you would regret looking back on your deathbed and spend as much time you can on doing whatever you can’t stop thinking about.

Note: The title of this post is a quote from Nadia Asparouhova’s “The independent researcher”.

How I apply Zettelkasten to Roam

Hrvoje Šimić (shime@hey.com) — Mon, 02 Mar 2020 00:00:00 +0000

In the previous article, I’ve claimed that the biggest danger of Roam is not being systematic with your note taking, which can lead to having notes that are not valuable.

Zettelkasten is a system that helps with that. It enables network effects for your notes: the value of your database starts increasing, instead of decreasing with each added note.

Rules of Zettelkasten

How to take smart notes explains the Zettelkasten system, which consists of the following steps:

Making temporary notes to collect everything that pops into your head.
Making short literature notes by using your own words to describe what resonated with you.
Going through notes from step 1. and 2. and thinking about how they relate to what’s relevant to your own interests. What questions are triggered? Write exactly one note for each idea and write it as you’re writing to someone else.
Put note from step 3. into your note-taking system and link relevant notes.
Go through the system and develop questions and topics bottom up. See what’s there and what is missing. Read more to challenge your arguments.
After a while, you will develop ideas far enough to decide on a topic to write about.
Turn your ideas into a rough draft. Detect holes in your arguments.
Proofread or edit.

In this article, I would like to explain how I apply rules 1-4 of Zettelkasten when using Roam. Article is not the right medium for explaining steps 5-8 and Nat Eliason has already done a great job with his article outline video.

Using Roam without Zettelkasten would probably mean that:

you put your thoughts directly into daily notes, without nesting them in any way
you use a new page for literature notes for every book or other piece of content, like with Notion or Evernote

Unnested thoughts in daily notes

Having thoughts directly in the daily notes means that we would have something like this:

This means that we would have to go through all daily notes in order to find out what we were thinking. Step 3 of Zettelkasten, which we do in a second pass, in which we link previous ideas to this one, would become harder if we did it this way.

Instead of this, let’s nest this thought under [[Thoughts]]:

If we now navigate to [[Thoughts]], we will be able to see this thought linked to it:

This makes it easier to link similar ideas in the second pass:

New page for storing literature notes

Prior to applying Zettelkasten to Roam, I’ve used to store my notes in a new page for every book or other piece of content that I’ve read.

This looked like this:

The problem with this is, again, the discoverability of these literature notes. They are only visible if we specifically go to this page, which makes the step 3 of Zettelkasten harder.

Instead of this, let’s write our literature notes in a daily note, under [[Thoughts]]:

This makes this literature note more discoverable, since now it’s going to be listed as a linked reference in [[#litnote]]. We also give this literature note more context: specify the title of the book or video it’s related to, nest it under [[Thoughts]], and add it as a daily note, so we know the date when we added it.

This makes the step 3 of Zettelkasten very easy:

Creating permanent notes

Now that we have linked literature notes to relevant ideas, it’s time to create permanent notes from them, or implement the step 4 of Zettelkasten. I’m following Shu Omi’s approach here and using the same format for every permanent note.

Putting everything in the permanent note under [[permanent notes]] makes all the permanent notes listed on that page, which is really useful for finding related notes.

Why I love Roam

Hrvoje Šimić (shime@hey.com) — Thu, 20 Feb 2020 00:00:00 +0000

Computers are like a bicycle for the mind.

Steve Jobs

Roam has, simply put, transformed my relationship with reading, writing, and note-taking. I’ve been using it regularly for the past couple of months and I enjoy it.

Using it is fun! I have never been so excited and had so much fun using a piece of software. Games included! The only thing that resembles this excitement was discovering Notion and its powerful flexibility capabilities.

Building a second archive

All roads lead to Roam, and my road started when I realized I had a problem with too much passive consumption. I’ve discovered the wonders of personal knowledge management: building a second brain, PARA and progressive summarization, which changed my approach to reading. Consuming content finally made more sense, since I was not just passively reading it. I was highlighting stuff that resonated, making summaries and diligently categorizing everything.

That was an improvement, but I realize in retrospect that the biggest drawback of that approach is not making enough connections. My notes were highlighted and summarized, but they were isolated. All hopes were put into search and tags which only gets you so far. Doing this in Notion felt more like building a second archive than the second brain, due to all the compartmentalization required.

Networks of ideas, instead of an archive of compartments

Roam, in contrast, frees me from unnecessary compartmentalization and makes it easier to explore my ideas. It encourages me to build networks of ideas instead of an archive of compartments. My brain is a network, not an archive. This is why Roam feels like an extension of my brain, like a bicycle for the mind.

I write to learn and this is encouraged by Roam. It encourages me to go deep on a subject and explore if I need to. Hierarchy emerges organically from the bottom-up and not top-down like with other note-taking apps. Categories are optional.

Roam emphasizes relationships and its two-way linking is the killer feature. Every page links other pages that are linking to it. Relationships are visible and easy to understand. It’s super easy to create new pages, just surround the term with brackets. No need to go deep on the term, unless there is a need.

Creativity is just connecting things.

Steve Jobs

Empty pages are okay. They can be used for making connections or as a glue for other pages. Sometimes I simply don’t need to explain the concept, like “writing”, but I like to link to it all across my database so I can discover it more easily when I need to.

The dangers of Roam

The only potential problem with Roam is the danger of not being systematic with notes. Roam is a tool of endless possibilities and being systematic and deliberate with note-taking is key for getting value out of it. Otherwise, it can just become an interconnected mess that is not useful.

Zettelkasten is a great system to follow to avoid that. Following it enables network effects for your notes: the value of your database starts increasing, instead of decreasing with each added note.

Fighting content overload

Hrvoje Šimić (shime@hey.com) — Sun, 05 Jan 2020 00:00:00 +0000

The abundance of books is a distraction.

Seneca, 1st centruy AD

The problem with reading too much is remembering too little. What’s the point of reading a book, if after reading it, the only thing remembered is a sentence or two? Is there a better way to read than simply going through the book line by line? Is there a way to get more value out of the book?

Turns out there is.

This post will:

explain what’s wrong with simply consuming books or any other content
describe how to get more out of consumed information
suggest an approach for fighting the overwhelming with content

The problem with consumption

We are biased towards novelty. Our brains have evolved to seek it and we get a dopamine response to it. Every social network is exploiting this in an extreme way ^[1]. This craving for new things, in addition with intelectual signaling with quantity of books we have read, leads us to read new books. We think that the way to getting smarter is to read a new book. That the next book we will read will give us that missing part of the puzzle.

There is a trend that is a result of this effect: speed reading. And it is missing the point completely. Speed is not the goal. Comprehension and understanding is. You don’t need to speed up; you need to slow down.

Lindy effect is perhaps a good strategy to try to fight this craving. If a book has been around for a long time and is regarded a great book, there’s a really good chance it’s a must-read book and will survive for a long time.^[2] In contrast, how many books that were published in the past ten years do you think will survive for the next hundred and how many of them will be forgotten in the next ten? This should be a guiding principle when choosing a book to read. It’s better to re-read a classic, than to waste time on some current best seller that will be forgotten in five years.

Start more books. Quit most of them. Read the great ones twice.

James Clear

The biggest problem with simply consuming is the problem of “transmissionism”, a belief that simply consuming content (in this case reading a book line by line) leads to attaining knowledge. This problem is present in any form of content consumption, wether it’s a TED talk, podcast, interesting talk in your local conference or the university lecture. Knowledge can’t be transferred that simply. Attaining knowledge requires much more effort than basic understanding of words or sentences. ^[3]

Getting more out of consumed information

Digesting information, thinking deeply and connecting the dots is a path to knowledge and wisdom. Synthesis, connecting and remixing ideas from multiple disciplines is the goal. Knowledge management tools help here by providing the bits and pieces of this knowledge in a searchable, digital form. These tools help us offload the burden of remembering off of our imperfect biological brain, so it can focus on the more creative work. Like finding connections.

There are variety of systems that can be used for intelectual progress and it’s probably best to start with small changes to your information consumption workflow. The first step above just reading anything that comes your way is saving content. Apps like “Pocket” or “Instapaper” can help with this. Doing this, however, doesn’t help with the progress much. Start highlighting and adding notes in order to climb the first step. What’s the point of reading that Medium article you have saved? What parts resonated with you?

Fighting the overload

Reading feeds the mind and replenishes it when it is worn from studying — even though it is not without work itself. We should not restrict ourselves to writing or to reading: endless writing saps our strength and then exhausts it. Too much reading can puff up or dilute our ability. Most commendable is to take them in their turn, to mix one with the other, so that the seeds of one’s reading may be grown anew with the pen.

Seneca

This process of highlighting and bolding content is known as “progressive summarization”. And I’ve found it really helps with remembering content. Writing a summary of an article that resonated with you makes it rememberable in the future.

I think having a balance with reading and writing is essential. Too much reading, without writing makes one forget oneself. Foucault argues that reading too much leads to “stultitia” - mental agitation and constant change of opinions.

By going constantly from book to book, without ever stopping, without returning to the hive now and then with one’s supply of nectar —hence without taking notes or constituting a treasure store of reading— one is liable to retain nothing, to spread oneself across different thoughts, and to forget oneself.

Michael Foucault - Self Writing

Storing notes and actively working on them builds a network of knowledge, a brain outside of our organic brain.

Gradation of learning per reading style

I’ve found out, since I’m mostly reading non-fiction, that my goal is always learning something from the book. In order to learn, I’ve come up with a list of reading techniques sorted by quality of learning:

speed reading - the worst for learning
listening a book as an audiobook
normal reading
reading and higlighting text that’s interesting
reading and copying text from the book as notes
reading and copying text from the book as notes and working on notes with progressive summarization
reading and writing a summary in your own words at the end of each chapter
reading with Cornell note-taking system and Feynman technique - asking questions while reading and then answering them in your own words at the end of each chapter

Using the last technique instead of just reading the book has had a dramatic effect on the quality of retained information for me. I think more about the content. Writing questions like this challenges the presumption that I know everything that I read and makes me test myself. If I don’t know the answer, I’m forced to re-read the chapter and try again.

This approach leads to remembering a lot more than just a single most important point from the book and I’ve been using it for a while. It helps a lot. If you’re having problems with remembering what you read try giving the Cornell technique a shot. Let me know if it helped on Twitter. I’m @shime_sh.

Social networks are using supernormal stimulus in order to exploit this dopamine response of our reptile brain. This fantastic comic explains the concept in a visual way: Supernormal Stimuli: Your Brain on Porn, Junk Food, and the Internet
“How to win friends and influence people” by Dale Carnegie and “Meditations” by Marcus Aurelius are great examples of “Lindy books”.
This concept is explained in detail in a must-read article titled “Why books don’t work” that argues that transmissionism is the biggest problem with books.

Replacing Google Fonts with system fonts

Hrvoje Šimić (shime@hey.com) — Mon, 08 Apr 2019 00:00:00 +0000

Redesigning this website was a fun little project I did over the past weekend. The most exciting part was removing the need for Google Fonts and replacing them with system fonts. Google Fonts was the last Google’s tentacle on this website, so it’s now 100% Google free!

But why?

Using system fonts has multiple advantages:

No network request for fonts, so smaller size of content that needs to be downloaded.
Since there is no network request, there is no need to worry about “Flash of Unstyled Text.”
Looks familiar to people since they’re already used to seeing this font in their operating system.

What’s needed to start using system fonts?

Since this site has been updated to use Tailwind, I’m using their default CSS rule for sans font:

.font-sans {
  font-family: system-ui, BlinkMacSystemFont, -apple-system,
               Segoe UI, Roboto, Oxygen, Ubuntu, Cantarell,
               Fira Sans, Droid Sans, Helvetica Neue, sans-serif;
}

I’m using another CSS rule for system fonts in code blocks:

.font-code {
  font-family: "SFMono-Regular", Consolas, "Liberation Mono",
                Menlo, Courier, monospace;
}

Those are the only CSS rules I have for fonts.

What did it look like before?

Here is what it looked like:

And this is what the same article looks like now:

What tools were used for this?

Tailwind is an excellent tool for dealing with CSS, and I highly recommend it. Using it has enabled removing whopping 1369 lines of unmaintainable CSS scattered across multiple files and replacing it with only 162 lines of really maintainable CSS contained inside one file.

Most of the elements are styled directly in the HTML and this makes me not having to worry about keeping CSS in sync with HTML all the time.

Using PurgeCSS made the bundle even smaller than the older unmaintainable version, with Tailwind included.

Taking time off from network tools

Hrvoje Šimić (shime@hey.com) — Tue, 17 Jul 2018 00:00:00 +0000

I’ve been away from all websites I spend the most of my time for 3 months.

That meant:

no Twitter
no Facebook
no Instagram
no Reddit

This happened after realizing those social media platforms started to affect my productivity and ability to focus. What drove me even more towards quitting social media completely was reading Deep work by Cal Newport.

The main takeaway from the book, considering the use of network tools in a hyper-connected way, was the craftsman approach to selecting tools. This approach consists of realizing that usage of all tools comes with pros and cons and that caution is required when opting-in for the tool just because of the one positive aspect of it.

The key is identifying positive and negative aspects of every tool and analyzing how it affects your success and happiness.

Doing this made me realize I only really need one network tool - Twitter. I’ll make some adjustments to how I use it, though. I definitely need more control.

A short guide for wasting hundreds of hours on your idea

Hrvoje Šimić (shime@hey.com) — Sat, 14 Jul 2018 00:00:00 +0000

I’ve killed two products I’ve spent a considerable amount of time building. I’ve wasted hundreds of hours this way. The clichéd “at least I’ve learned something” is my only consolation.

This is what I’ve learned.

Lesson one

Zapsnap, a temporary peer to peer screenshot sharing application, is the first product I’ve made, with design by @benjam1n.

I was totally hyped about Webtorrent, Node.js, P2P web and wasn’t happy with the current screenshot sharing tools. Building some tool that would combine all fascinations with pains I’ve felt was a logical step forward.

So I’ve spent a lot of hours developing it, bought the domain, $10/mo server on Digital Ocean and it was ready for some users. Users? That’s right, I haven’t talked to anyone but friends about what I’ve been building, so I didn’t have a lot of potential users to share my launch with.

Enter Product Hunt.

Product Hunt is a great place for sharing what you’ve built with people if you don’t have an audience. It’s much better for getting first users than Hacker News unless you’re targeting the Hacker News niche. People on Product Hunt are generally more interested in trying new products. I launched it there and it ended in second place for that day. Here are some numbers:

Retention is another story, you’ll generally get a spike in the number of users, but you have to have a plan for actually keeping the users using your product. The above graph has basically fallen to zero after the launch. It probably happened because I didn’t spend any amount of time on engaging with my users. I have sent zero emails, literally. Another thing that led to this was probably the fact that people didn’t find the product that interesting and useful, after getting familiar with it.

Zapsnap was a classic “just fucking do it” approach exercise. I was scratching my own itch, but I didn’t talk to anyone else to find out if this product was even needed. Friends generally supported me, but I think they did it out of kindness. This is definitely not a way to go since you can’t validate your ideas this way.

Building a totally free product was another mistake. I’m lucky Zapsnap didn’t take off because popular free products cost more money than unpopular free products. Hosting gets more expensive, support takes more time, etc. With paid products, on the other hand, popularity is a good thing, given that you have a solid monetization strategy.

Offering something useful in exchange for money isn’t something you should be afraid of and it’s the best validation tool for your product. People are okay with paying for useful things.

Lesson two

Journmail, an application that reminds you to write one sentence per day, is the last product I’ve made, with design by @vblazenka.

I’ve built this product in an attempt to improve my consistency while writing just one sentence per day in a journal. Having learned the “free product” lesson from Zapsnap, I’ve planned to start charging for this product from day one. I didn’t end up doing it, though.

I’ve spent a considerable amount of time developing it, bought domain, $10/mo server on Digital Ocean and then I’ve faced my biggest obstacle.

After figuring out how to implement recurring billing with PayPal, I’ve faced another problem with invoicing and accounting. I needed to figure out how to handle this sort of thing with my company here in Croatia, even asked people on Indie Hackers about it, but ended up not doing anything.

Billing and invoicing ended up being the most complicated part of Journmail. It was the last thing I needed to finish before the launch and I was keen on reaching that finish line, so I’ve decided to ditch the billing and invoicing and launch a free product. I’ve figured I’d make it free for early adopters and then make it paid when I find time to implement it. Looking back, I don’t think this was such a great idea ^[1].

I’ve also launched it on Product Hunt, but it didn’t end up being as successful as Zapsnap there. Product Hunt drove this traffic:

~350 users that signed up
~200 receiving daily reminder emails
~20 users actually writing that one sentence per day every day

As with Zapsnap, I didn’t engage with users, other than sending that automatic one email reminder per day.

Journmail was another “just fucking do it” exercise. Learned nothing from Zapsnap in this regard.

The killing part

So with having these two free products on autopilot, each costing $10/mo I’ve heard about the GDPR and figured I don’t have time to implement any changes needed for compliance.

That’s when I decided to shut both of them down. I’ve made another mistake here, didn’t send an email with an apology to Journmail users (Zapsnap users didn’t give me an email) and just shut it down overnight.

GDPR and lost interest in maintaining free products was what drove me to shut both of them down.

The point

We have a saying in Croatia - “Every school costs money”. These lessons have cost me a lot of time and some money, so hopefully, this saves some of your time and money.

A better idea would’ve been to make it free to try out with a trial period of 30 days. This would’ve given me time to implement the billing system while keeping people aware that it was not free. This approach was pioneered by folks from Basecamp.

Quality vs popularity

Hrvoje Šimić (shime@hey.com) — Wed, 21 Mar 2018 00:00:00 +0000

When validating library quality, we like to take a look at some metrics like the time of the last commit or the number of stars as if those relate to quality. It’s the easiest thing to do, instead of validating the quality by other means, we go with the easiest approach of following everybody else.

With this we save time, which means saving money for our employers, but there is a price we pay. It is not free. We risk choosing the popular option instead of the better one.

What if instead of looking at the stars, we focused on reading every library we included? It’s all open source so this is a great benefit of it, being able to read the source code.

Easy, right?

Not really. Reason for this is that we use the baterries included libraries, popularly known as frameworks, which are large in scope and that’s what prevents us from reading the source code in a reasonable amount of time. Unfortunately those projects are usually more popular than the smaller alternatives.

The larger the scope of a library, the more it needs to be maintained, so the perceived status of it is that it’s being actively developed. Meanwhile, the smaller libraries don’t need so much maintenance, so if we only look at the time of the last commit as a metric for determining the quality we’ll go with the larger one and we’ll perceive the smaller one as collecting dust.

If we used libraries that are focused on a single feature more, we would end up having codebases that are more easily understandable by a single person in their entireties. ^[1]

We could say that the point of having libraries is abstraction, which hides away the nasty implementation details in a black box. In my opinion, programmers need to know at least the basics of how those black boxes work internally in order to be able to construct quality software with them. That’s easier with libraries with narrower scope.

The biggest risk of going of reading source code of libraries to be included is investing time in libraries we’re not going to end up using. Good practice for alleviating this risk is by only considering small libraries. ^[2]

There are a lot of benefits from reading the source code, so why not do it more often? Especially when it comes to something as critical as deciding if library should be used or not.

Niklaus Wirth writes that a system that’s not understood by a single person in it’s entirety shouldn’t be built. Read more about that in his excellent paper A Plea for Lean Software [1995].
Check out a mirror of microrb.com as a way of finding small libraries in Ruby community.

Git commit message syntax highlighting in Vim

Hrvoje Šimić (shime@hey.com) — Tue, 20 Mar 2018 00:00:00 +0000

Although you could use git commit -m for writing a git commit message, it’s much better to use a proper editor for that, especially if you’re writing a multiline commit message.

Well if your editor of choice is Vim, this is what happens after you enter git commit.

Notice how first 50 chars of a commit message are highlighted in red. This is used to notify you about the length of the first line of a commit message so you know when it’s too lengthy. For Vim, 50 chars is the suggested size of the first line of commit message.

Well this isn’t a good default for me, since the only thing that’s worrying me is the truncation of the first line of commit message when my code ends up on Github. I’m only interested if the first line of my commit message is short enough to be displayed in full on Github.

If that’s not the case I’ll end up with something like this.

Yuck.

Preventing this is easy. Just make Vim highlight the first 72 chars in red, which is the maximum number of characters Github allows in the first line.

In order to do so, alter Vim’s syntax rules for git commit messages, by editing ~/.vim/after/syntax/gitcommit.vim like this.

syn clear gitcommitSummary
syn match gitcommitSummary    "^.\{0,72\}" contained containedin=gitcommitFirstLine nextgroup=gitcommitOverflow contains=@Spell

This will make Vim look like this.

Now you’ll be notified if you cross the length limit for the first line of git commit message on Github and you’ll know exactly where it starts truncating it.

Loving Vim

Hrvoje Šimić (shime@hey.com) — Mon, 19 Mar 2018 00:00:00 +0000

This post is inspired by Falling in love with Vim again by @michaelsoolee.

I love Vim. I’ve been using it for a long time for bascially everything. I’m writing code locally in it, use it in ssh sessions remotely and yes, I’m writing this post in it.

The power of Vim and beginner friendliness

The thing I like the most about it is its grammar. For me that’s the most powerful part of Vim. No modern editors have figured this out yet, but the fact that you can combine verbs and nouns into commands is what makes the difference.

I don’t suggest Vim to beginners. The reason behind this is the fact that Vim operates in modes, which makes it unintuitive to open the file and edit it. Not to mention exiting Vim. If you’re just getting started with programming and are searching for a solid editor, I’d recommend Atom. It’s free, really intuitive, configurable, comes with syntax highlighting and has a large community providing an endless number of plugins.

Dotfiles

The really cool part of Vim is seeing how other people use it, which is made possible by the configuration file Vim uses, which people can share online, in their dotfiles. Github search for that term will give you a lot of repositories to look into for inspiration. Dotfiles are not just for Vim, they are a powerful tool for saving entire environment. From zsh/bash configuration to git configuration to Vim configuration, it’s all saved there. You can test someone else’s environment configuration by making a new user locally and cloning the dotfiles repo, symlinking those configuration files. If you still don’t have it you should consider making a dotfiles repo and storing your settings there. By doing that you’ll no longer have to worry about losing your settings if something happens to them locally.

My Vim workflow

This is what my Vim looks like.

These are my decisions:

font is 18pt Inconsolata
theme is a customization of gruvbox
no line numbers, they are a distraction
minimal file details at the bottom of the screen
no plugins that take too much space like NerdTree
branch info is visible

Three plugins I use the most frequently

Here are the plugins I use the most, sorted by the frequency of use.

1. ctrlp

Used for switching between files. Say no to NerdTree.

Here’s how I’ve configured it.

" Set CTRL-P to ignore anything matching this regex
let g:ctrlp_custom_ignore = 'DS_Store\|tmp\|node_modules'

" Set CTRL-P to lookup files based on regex, instead of basename only
let g:ctrlp_regexp = 1

" Set CTRL-P working directory to the first ancestor directory that contains .git/
let g:ctrlp_working_path_mode = 2

2. unimpaired

Also used for switching between files. This is used when files are in the same directory. Typing [f and ]f is really fast.

3. ag.vim

Used for searching for text inside a project. It uses the silver searcher, a replacement for grep under the hood.

Notice how I use [q and ]q to navigate between results. Here’s my configuration.

" Tell ag.vim to stop using regex search
let g:ackprg = 'ag --nogroup --nocolor --column --literal'

" Abbreviate ag to Ag
cabbrev ag Ag

" Map CTRL+A to Ag
map <C-a> :Ag 

" Search for word under cursor with ag
noremap <Leader>a :Ag <cword><cr>

And that’s it, those are the most essential plugins I would recommend. Other than those plugins, I use <C-o> and <C-i> to navigate between files a lot.

I use Bower as a package manager for my Vim plugins, since it’s the package manager that allows Github repos as package locations and I’ve found that most of Vim plugins are hosted on Github. No changes are required on the repo for it to be acceptable by Bower. It’s great because it lets you keep a JSON file of the list of plugins you use in your dotfiles repo.

As an example of how a vimrc file looks after a couple of years of use you can take a look at my vimrc. For plugin suggestions take look at all the plugins I use.

Freedom

Hrvoje Šimić (shime@hey.com) — Tue, 06 Mar 2018 00:00:00 +0000

I’m a freelancer and I love what I do. There is a thing I value the most in this type of work.

That thing is freedom.

It’s not about working when you feel like it, since there is no schedule. I used to think that was great, not having to wake up at 7am every day. Well I was wrong. I came to the conclusion that working early in the morning is the best for me and I feel the most productive at that time. It’s a healthy, natural thing to do - so I wake up early.

It’s not about not having to commute to your work. I used to think that was great too, not having to spend so much time in traffic and all. Well I was wrong again. Being around people at work motivates me more. Having an office space makes the work/life boundary tangible. It’s great for my motivation and work/life separation - so I commute.

It’s not about being able to travel. I used to think that was great, being able to work while traveling. Well guess who was wrong again. It doesn’t work for me - so I don’t work while traveling.

So what freedom am I talking about?

I’m talking about freedom to work internationally. Not being restriced by location. That’s the type of freedom I value the most. I don’t have to choose from a pool of locally available companies to work for, my pool is the entire world. A world of companies willing to hire remotely.

I think that’s the greatest freedom that you could get with work and I love freelancing because of that.

Building a crude Node.js from scratch

Hrvoje Šimić (shime@hey.com) — Tue, 10 Oct 2017 00:00:00 +0000

Node is powered by the JavaScript engine used in Google Chrome, called V8^[1]. In this post I’m going to guide you through two steps:

making a “Hello World” example in V8
making a crude Node runtime with support for 3 statements: console.log, console.error and quit for quitting the process

In our new crude runtime we’ll execute the following script:

console.log("🎉");
b=4+4;
console.error(b);
quit();

console.log("never reach this");

Setting up the hello world example

First things first. Let’s execute a JavaScript string concatenation in V8! We’ll write an example that takes a JavaScript statement as a string argument, executes it as JavaScript code, and prints the result to standard out. The string will be

'Hello' + ', World!'

The setup will loosely follow this gist in combination with the V8 getting started with embedding wiki.

We’re going to use version 5.8 of V8. I’m going to assume you’re using MacOS with git, Python 2.7 and Xcode installed and that you’re using Bash as your shell of choice.

Clone the v8 source

git clone https://github.com/v8/v8.git

Install depot tools and add it to our path

git clone https://chromium.googlesource.com/chromium/tools/depot_tools.git
cd depot_tools
echo "export PATH=`pwd`:\"$PATH\"" >> ~/.bashrc # replace with ~/.zshrc if using ZSH
source ~/.bashrc # or ~/.zshrc
cd -

Make sure you have clang and clang++ installed

which clang && which clang++ # should output paths to clangs

If you don’t have clang and clang++ make sure you have installed Xcode.

Add environment libraries for clang and clang++

cat <<EOT >> ~/.bashrc # replace with ~/.zshrc if using ZSH
export CXX="`which clang++`"
export CC="`which clang`"
export CPP="`which clang` -E"
export LINK="`which clang++`"
export CXX_host="`which clang++`"
export CC_host="`which clang`"
export CPP_host="`which clang` -E"
export LINK_host="`which clang++`"
export GYP_DEFINES="clang=1"
EOT

source ~/.bashrc # or ~/.zshrc

Update .git/config of V8 to fetch remotes and tags

cd v8
vim .git/config

Update config for remote origin to this

[remote "origin"]
  url = https://chromium.googlesource.com/v8/v8.git
  fetch = +refs/branch-heads/*:refs/remotes/branch-heads/*
  fetch = +refs/tags/*:refs/tags/*

Exit vim^[2] and fetch origin.

git fetch

Checkout to a new branch for version 5.8 of V8

git checkout -b 5.8 -t branch-heads/5.8

Sync this git repo

gclient sync

Create build configuration

tools/dev/v8gen.py x64.release

Edit the default build configuration

gn args out.gn/x64.release

And add these two lines to that configuration:

is_component_build = false
v8_static_library = true

Build v8

You’ll have to detect a number of cores your CPU has. Go to Activity Monitor and click on CPU LOAD section. Window with graphs should pop up - the number of cores is the number of panels on that window.

For my 2015 i7 CPU it’s 4, so I’m running the following command:

make native -j 4

If you’re not sure just run it without -j flag

make native

Alternatively you can just use Ninja like this:

ninja -C out.gn/x64.release

Add hello world

vim hello_world.cpp

Save this in hello_world.cpp^[3]:

// Copyright 2015 the V8 project authors. All rights reserved.
// Use of this source code is governed by a BSD-style license that can be
// found in the LICENSE file.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include "include/libplatform/libplatform.h"
#include "include/v8.h"
using namespace v8;
int main(int argc, char* argv[]) {
  // Initialize V8.
  V8::InitializeICUDefaultLocation(argv[0]);
  V8::InitializeExternalStartupData(argv[0]);
  Platform* platform = platform::CreateDefaultPlatform();
  V8::InitializePlatform(platform);
  V8::Initialize();
  // Create a new Isolate and make it the current one.
  Isolate::CreateParams create_params;
  create_params.array_buffer_allocator =
      v8::ArrayBuffer::Allocator::NewDefaultAllocator();
  Isolate* isolate = Isolate::New(create_params);
  {
    Isolate::Scope isolate_scope(isolate);
    // Create a stack-allocated handle scope.
    HandleScope handle_scope(isolate);
    // Create a new context.
    Local<Context> context = Context::New(isolate);
    // Enter the context for compiling and running the hello world script.
    Context::Scope context_scope(context);
    // Create a string containing the JavaScript source code.
    Local<String> source =
        String::NewFromUtf8(isolate, "'Hello' + ', World!'",
                            NewStringType::kNormal).ToLocalChecked();
    // Compile the source code.
    Local<Script> script = Script::Compile(context, source).ToLocalChecked();
    // Run the script to get the result.
    Local<Value> result = script->Run(context).ToLocalChecked();
    // Convert the result to an UTF8 string and print it.
    String::Utf8Value utf8(result);
    printf("%s\n", *utf8);
  }
  // Dispose the isolate and tear down V8.
  isolate->Dispose();
  V8::Dispose();
  V8::ShutdownPlatform();
  delete platform;
  delete create_params.array_buffer_allocator;
  return 0;
}

Copy snapshots

cp out.gn/x64.release/*.bin .

Compile the hello world example

clang++ -Iinclude out/native/*.a hello_world.cpp -o hello_world

Run the hello world example

./hello_world

You should see

Hello, World!

in your shell. Now that we have a hello world example up and running, we can start adding support for console.log, console.error and quit.

Add support for console and quit statements

Add the following to run_script.cpp^[4]:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <fstream>
#include <iostream>
#include <sstream>
#include "include/libplatform/libplatform.h"
#include "include/v8.h"

using namespace v8;

// Define a quit function that exits.
void quit(const v8::FunctionCallbackInfo<v8::Value>& args) {
  std::exit(0);
}

// Store isolate in a global variable.
Isolate* isolate_;
Isolate* GetIsolate() { return isolate_; }

// Define a Console class.
class Console { };

// Extracts a C string from a V8 Utf8Value.
const char* ToCString(const v8::String::Utf8Value& value) {
  return *value ? *value : "<string conversion failed>";
}

// Define a log function that prints to stdout.
void log(const FunctionCallbackInfo<Value>& args){
  v8::String::Utf8Value str(args[0]);
  const char* cstr = ToCString(str);
  printf("%s\n", cstr);
}

// Define an error function that prints to stderr.
void error(const FunctionCallbackInfo<Value>& args){
  v8::String::Utf8Value str(args[0]);
  const char* cstr = ToCString(str);
  fprintf(stderr,"%s\n", cstr);
}

Local<Object> WrapConsoleObject(Console *c) {
  EscapableHandleScope handle_scope(GetIsolate());

  Local<ObjectTemplate> class_t;
  Local<ObjectTemplate> raw_t = ObjectTemplate::New(GetIsolate());
  raw_t->SetInternalFieldCount(1);

  // Set log method.
  raw_t->Set(
      v8::String::NewFromUtf8(GetIsolate(), "log", v8::NewStringType::kNormal).ToLocalChecked(),
      v8::FunctionTemplate::New(GetIsolate(), log));

  // Set error method.
  raw_t->Set(
      v8::String::NewFromUtf8(GetIsolate(), "error", v8::NewStringType::kNormal).ToLocalChecked(),
      v8::FunctionTemplate::New(GetIsolate(), error));
  class_t = Local<ObjectTemplate>::New(GetIsolate(),raw_t);

  // Create instance.
  Local<Object> result = class_t->NewInstance(GetIsolate()->GetCurrentContext()).ToLocalChecked();

  // Create wrapper.
  Local<External> ptr = External::New(GetIsolate(),c);
  result->SetInternalField(0,ptr);
  return handle_scope.Escape(result);
}


int main(int argc, char* argv[]) {
  // Initialize V8.
  V8::InitializeICUDefaultLocation(argv[0]);
  V8::InitializeExternalStartupData(argv[0]);
  Platform* platform = platform::CreateDefaultPlatform();
  V8::InitializePlatform(platform);
  V8::Initialize();

  // Get JavaScript script file from the first argument.
  FILE* file = fopen(argv[1],"r");
  fseek(file, 0, SEEK_END);
  size_t size = ftell(file);
  rewind(file);
  char* fileScript = new char[size + 1];
  fileScript[size] = '\0';
  for (size_t i = 0; i < size;) {
    i += fread(&fileScript[i], 1, size - i, file);
  }
  fclose(file);

  // Create a new Isolate and make it the current one.
  Isolate::CreateParams create_params;
  create_params.array_buffer_allocator =
    v8::ArrayBuffer::Allocator::NewDefaultAllocator();
  Isolate* isolate = Isolate::New(create_params);
  {
    Isolate::Scope isolate_scope(isolate);
    isolate_ = isolate;

    // Create a stack-allocated handle scope.
    HandleScope handle_scope(isolate);

    // Create a template.
    v8::Local<v8::ObjectTemplate> global = v8::ObjectTemplate::New(isolate);

    // Set a quit statement to global context.
    global->Set(
        v8::String::NewFromUtf8(isolate, "quit", v8::NewStringType::kNormal)
        .ToLocalChecked(),
        v8::FunctionTemplate::New(isolate, quit));

    // Create a new context.
    Local<Context> context = Context::New(isolate, NULL, global);

    // Enter the context for compiling and running the hello world script.
    Context::Scope context_scope(context);

    // Create a JavaScript console object.
    Console* c = new Console();
    Local<Object> con = WrapConsoleObject(c);
    // Set a console statement to global context.
    context->Global()->Set(String::NewFromUtf8(isolate, "console", NewStringType::kNormal).ToLocalChecked(),
        con);

    // Create a string containing the JavaScript source code.
    Local<String> source =
      String::NewFromUtf8(isolate, fileScript,
          NewStringType::kNormal).ToLocalChecked();

    // Compile the source code.
    Local<Script> script = Script::Compile(context, source).ToLocalChecked();

    // Run the script to get the result.
    Local<Value> result = script->Run(context).ToLocalChecked();
  }
  // Dispose the isolate and tear down V8.
  isolate->Dispose();
  V8::Dispose();
  V8::ShutdownPlatform();
  delete platform;
  delete create_params.array_buffer_allocator;
  return 0;
}

After that, set up a JavaScript script at test.js:

console.log("🎉");
b=4+4;
console.error(b);
quit();

console.log("never reach this");

Compile our new program with

clang++ -Iinclude out/native/*.a run_script.cpp -o run_script

And run it with

./run_script test.js

You should see the following output

🎉
8

Phew! That’s it - congratulate yourself for building a crude version of Node that only supports console.log, console.error and quit statements.

Having a global function quit like this is a little weird, so implementing a more normal process.exit is left as an exercise for the reader.

If this article sparked your interest about Node internals, I strongly suggest you continue reading article named How does NodeJS work, which explains the concepts used in this article in greater detail.

More info about V8 can be found at their wiki.
:wq or try searching Stack Overflow.
Taken from V8 repo here.
This example is based on this gist.

Programming for $ until I'm too old to

Hrvoje Šimić (shime@hey.com) — Sun, 24 Sep 2017 00:00:00 +0000

The question I get from time to time is this one:

Do you really want to work like this when you’re forty or fifty?

Yes, I’m perfectly okay with that.

I really love programming. I can’t imagine myself doing anything else. I love it in every form. Even when forced to code in C#, like in college. It’s still amazing. The creative part of it inspires me the most. Making something out of nothing fascinates me. The opportunity to get better is what keeps me up at night. There’s so much space to grow, there’s so much opportunity to become better, to really master it.

Regarding the last post I wrote, my friend Bruno asked me this:

If you strive for freedom so much, don’t you want to accumulate money, say 1.000.000€, until you’re 35 and then live out of interest rate? This way you would have ultimate freedom to do whatever you want.

I don’t want to work so hard until I’m 35. I want to enjoy life while I’m still youngish. I want to simultaneously enjoy myself and work until I’m too old to do so. The opposite of working all the time until I’m older and then just enjoying myself doesn’t look so appealing.

Work is a contact with reality for me. The struggle to make money makes life interesting. Having that problem solved would fundamentally change me as a person. I would probably die of boredom.

That’s why I’m happy with working part time. I get to have play/work balance, so I don’t work too hard for clients and I don’t play too hard. What’s life without playing?

For me, that’s not a life.

Money and time

Hrvoje Šimić (shime@hey.com) — Wed, 20 Sep 2017 00:00:00 +0000

It’s absolutely maddening to see so many people work a job they don’t want to work, so that they can pay for stuff they don’t really need. Time is by far the most valuable “thing/piece of stuff”. How much are you selling an hour of your life for (the whole aspect of the hour… time away from your family, time away from the things you enjoy doing)? Is it worth it?

Amir Rajan from “A Dark Room” interview on Indie Hackers

Working part time for a couple of years now makes me realize how non-conventional it is. I’m the only weirdo I know in my circle of developers that’s working part time. It seems to me that money is overvalued and that very often people like to sacrifice time in order to accumulate more money. But is more money equal to better life quality all the time?

I don’t think so.

I’m pretty happy working half the time for half the money I could be making, so you could say that I’m sacrificing money in order to get something more valuable for me - more free time. With that free time I have an asset with which I can choose to do whatever I like. Currently I’m choosing to work on a side project and open source since I think it’s a better investment in a career than working full time.

After you have a pretty crazy amount of money for a while, you start to slowly realize it doesn’t mean a whole lot. Time and doing (or working on) things you care about is a lot more important, and variety is healthy, if you’re interested in other forms of art, sports, whatever. Doing one thing, all day, every day, is not.

TJ Holowaychuk on Quora

I think learning aside from working for clients is essential for career growth. I think sabbaticals, when they are paid are a great way to learn things. Unpaid are a little tricky for me since not having an active income puts pressure on me, since I have living expenses and no income.

I used to work full time for some time and then went on vacation for a couple of months. That didn’t work out because of the mentioned pressure. I ended up with $0 in my pockets, since I couldn’t find the incentive to find a new job and kept delaying it in order to do more learning.

That’s why I switched to working part time. Working this way makes me in check with reality. I don’t get lost in all the side projects and I don’t end up broke this way. There are downsides though.

The biggest downside is definitely having to prove yourself when other team members are working full time. There’s always a risk of coming off as not being engaged enough. There’s always a pressure of working more and it’s coming from all the directions. Having the discipline to switch off after ~4 hours of work every day takes some courage.

Another downside is that part time jobs are difficult to find. No one is eager to offer you a part time job in a workaholic culture where working +40hrs work weeks is often glorified. That’s why I don’t consider most startups as my potential clients. Combine that with the fact that I suck at technical interviews and my mode for job search is super hard.

All in all I think having free time for yourself and for learning more on the side is beneficial for career growth. I think nothing contributed to my career growth more directly than working part time for clients. Money isn’t everything, sometimes time is your more valuable asset.

Having the time-money balance is essential. Knowing how much free time and how little money you need is crucial for having a good quality life.

I spend most of my time enjoying other things now, I write code 2–3 hours a day unless I’m really into something. Time is your real currency! Money is nice and all but don’t waste your time. If you really enjoy the project(s) you’re working on then go for it but don’t neglect other areas of your life (or people).

TJ Holowaychuk on Quora

Landing that remote job

Hrvoje Šimić (shime@hey.com) — Sat, 15 Jul 2017 00:00:00 +0000

TL;DR: The bigest problem is standing out. How do you do it?

write the bloody email every time you apply
contribute to open source
build interesting products

This is going to be a response to How I failed landing a remote position, a post in which its author describes how he failed to land a remote job. In this blog post I want to explain how to land it. I’ve been working remotely for the last six years and during that time I’ve landed ten remote jobs. I’ve had my ups and downs in a turbulent world of remote working.

The biggest failure was probably going on a trip to Singapore for an onboarding process where I quitted that job and returned home after just three days, but that’s a story for another blog post.

It took me two months to land the last remote job and I’ve sent around fifty emails in total over that period. I also suck at technical interviews, so all the jobs I’ve landed required no technical interview. We agreed that the best technical interview would be to hire me for a test period of one month. I once failed that too. They required detailed reports on what I was doing and I thought that was redundant given the long descriptions in my commit messages and pull requests, so they decided not to give me another contract.

This brings me to another failure, called Toptal. As I said, I really suck at technical interviews. Things were different this time, though. I’ve prepared this time, went through some algorithmic exercises and all. The Ruby was against me this time, though. Somehow File.read wasn’t working for me, so the interviewer even allowed me to go to StackOverflow. After I figured how to do it with IO there was too little time left. Hence I failed the technical interview again.

My first recommendation for remote jobs would be, you guessed it, Toptal. When you survive their algorithmic technical interview, you get an agent that connects you with the clients and whose job is to find you a job you’d be happy with. They take provision, of course, but the rate you end up with is still decent.

If technical interviews are not your thing, there are still plenty of sites to choose from. Behold Upwork! Just kidding, avoid it like the plague. Really tons of low quality clients and contractors there. I was very lucky finding my best client there (hi Gary!). You’ll probably waste a lot of time on a quest of finding your perfect client in that kind of environment, so don’t do it.

As mentioned in the original post, WeWorkRemotely is a great place to look for jobs, because you get some monetary filtering/quality control. At least they are wiling to invest that $299 to find their perfect candidate. I’ve got some decent responses there.

StackOverflow Carrers is also a good place to look with that remote filter turned on. I’ve got some responses there. It might be harder to get response from there if you don’t have a decent reputation on StackOverflow.

Other than these three, I don’t have anything to recommend.

Avoid angel.co, because jobs out there look outdated and I only received a single response from there for a position that turned out not to be remote after all.

Focus on those three sites and don’t bother with the rest.

What matters is how you stand out.

I strongly discourage you from sending one email over and over again, like in the original post. It sounds like a perfect pick up line. It’s something you think works, but in reality everyone knows you’re using it over and over again. If it takes two minutes of your time to send an email, do you think someone will spend five minutes of their time reading it?

Take your time to write that email every time you apply for a job. Be as brief as possible, no one likes reading long emails, especially when there are hundreds of applications.

On to the most important part. How do you stand out among hundreds of applicants? The remote job market is very competitive, how do you convince your perfect client to hire you and not someone else?

I think the answer is building products and doing open source. My biggest advantage when searching for Rails jobs is the fact that I am a Rails contributor. That doesn’t help with Node jobs, though. Believe me, I have tried.

I’ve spent half a year in 2014 trying to convert to Node and find a decent job in that market. Turns out no one cares about Rails contributors when searching for Node people. Who would’ve guessed!?

It’s a much easier task to find a Rails job, though.

The less important part is the CV. I think it should be a mere formality and up to two pages long with a list of former jobs with brief descriptions. You can take a look at my resume for an example of this.

To conclude, the bigest problem is standing out. How do you do it?

write the bloody email every time you apply
contribute to open source
build interesting products

How do you find time for all of this? Work less or work on weekends and late afternoons. Prioritize!

Thanks via email

Hrvoje Šimić (shime@hey.com) — Sun, 02 Jul 2017 00:00:00 +0000

I’m a programmer, so in my daily work I depend on the work of others. Others who have put in the time and created the tools that my work depends on. Their work is indirectly putting bread on my table, so I think a small act of gratitude goes a long way.

That’s why I have sent a lot of emails with subject “Thank you”, in which I explain to the receiver why I love their work and how it helped with my work.

Everyone likes hearing how their tools get used and getting praise about their work. That’s why I love sending those emails, it makes people who have helped me a little bit happier. Sending that email is the least I can do to express gratitude for their work.

People tend to forget about all this when working and I don’t think people send emails often enough. This post is a call to action, an invite for you to think about all the people and the time they’ve put in so you can do your day to day job.

Are you depending on a framework when searching for a new job? Is there a library you can’t live without? Find that author’s email and write a couple of words of gratitude. It takes about two minutes.

4 tips from 6 years of remote freelancing

Hrvoje Šimić (shime@hey.com) — Sat, 24 Jun 2017 00:00:00 +0000

I’ve been freelancing remotely for the past six years. Here are some of the things I’ve learned over the years.

Work in your own timezone

Since I’ve been mostly working for US-based startups I am constantly under pressure to have a big overlap with their time zone. It’s easy to relent under such pressure and effectively switch time zones.

I’ve been working for a year in a San Francisco time zone, starting my day at 5 pm and going to sleep at 3am. It’s not healthy and I would not recommend it to anyone. It’s just not worth it, don’t do it.

There are better clients and projects out there

If you feel that this is not a project that matches your interests or skills, don’t be afraid to ditch it and search for a better project or client. There’s always a better and worse client than your current one. It might take some time and luck to find a better match, but time spent searching for better matches is definitely worth it.

Say no more often

Knowing your boundaries is a key for a healthy relationship with your client. Saying no takes character, but it makes your client respect you more. Know when to say no in order to prevent yourself from being spread too thin.

Saying no to some things allows you to say yes to other things. Say yes to things that matter.

Be strict about your work schedule

Knowing when your work day starts and when it ends is key to having a healthy work-life balance. Be strict with yourself. This is one of the biggest problems with freelancing - you’re your own boss when it comes to deciding if the work day is over or not. Be a good boss to yourself and set the working hours strictly.

Routine stuff like daily standups help since they are always happening at the same time. I currently have one standup at 10am, so I usually start my working day with it.

The 8-week writing challenge

Hrvoje Šimić (shime@hey.com) — Mon, 19 Jun 2017 00:00:00 +0000

I’m starting a new habit. I’m gonna write every day and publish a blog post once a week for the next 8 weeks. I’m going to publish non-programming related stuff here on my blog and for the programming stuff I’ll use Two Bucks’ Blog.

Many consider 21 days a time range for a new habit to form, but it’s mostly bullshit. It’s a bare minimum. Everyone’s different, but it takes around 2 months for a new habit to form. A month is roughly 4 weeks so I’ve chosen to publish every week for the next 8 weeks.

At first I thought about committing myself to publish a blog post every day, but that would be too much of a commitment for me and the content would suffer. That’s why I decided to go with an easier version of that. I’ll write every day for an hour or so, but only publish once a week.

I’m committing myself publicly to do this. I’m gonna use #8weekwritingchallenge hashtag for this. Join me and share your blog posts with that hashtag on Twitter.

DISCLAIMER: I’m probably gonna fail miserably after a couple of weeks, but meh.

Landing pages for hackers

Hrvoje Šimić (shime@hey.com) — Mon, 12 Jun 2017 00:00:00 +0000

This post is going to be about NGINX wizardry. Not really.

This post is going to be about curl, since we all know real hackers use curl for everything.

We check the weather in it with

curl wttr.in

we check our IP in it with

curl icanhazip.com

we search for command options in it with

curl cheat.sh

we bake pancakes in it with

curl -d {} pancak.es/bake

Just kidding.

But curl is seriously bad ass and I use it every day to debug server responses with Chrome’s nifty copy as curl feature.

So why does nobody make landing pages for it?

It’s not that hard, just tweak your NGINX config a little.

Your config is probably already set up to redirect all HTTP traffic to HTTPS, at least that’s what you should do if you want to have an adequate rating on Google. This was a problem for us since we now want to allow non-HTTPS traffic and serve some ASCII wizardry on http://twobucks.co.

We want to use HTTP for this to allow

curl twobucks.co

in terminal, instead of the full URL.

To do this, we have to write a rule in NGINX that will redirect only if the user agent is not curl. The config file for that will look something like this

server {
    listen 443;

    server_name twobucks.co;

    ssl on;
    ssl_certificate /etc/letsencrypt/live/twobucks.co/fullchain.pem;
    ssl_certificate_key  /etc/letsencrypt/live/twobucks.co/privkey.pem;

    client_max_body_size 10G;

    location / {
      autoindex on;
      root /path/to/your/assets;
      error_page  404   /404.html;
      fastcgi_intercept_errors on;
    }
}

server {
    listen      80;
    server_name twobucks.co;

    location / {
            if ($http_user_agent ~ curl) {
                    root /path/to/your/curl/landing/page/;
            }
    }

    if ($http_user_agent !~ curl){
            return 301 https://twobucks.co$request_uri;
    }
}

You’ll notice an if condition, we still want to preserve a 301 redirect when user agent is not curl. If we are using curl then we want to render a HTML page with ASCII characters tailored for it.

We converted our logo from PNG to ASCII format by using the awesome image-to-ascii.

That’s all that was needed to get nice landing page inside of the terminal that looks like this:

Looks like no one is using this technique to display cool landing pages inside terminals. Maybe we can start a trend?

Introducing ephemeral P2P screenshot sharing

Hrvoje Šimić (shime@hey.com) — Mon, 25 Apr 2016 00:00:00 +0000

TL;DR A couple of months ago we released Seedshot, a tool for peer to peer screenshot sharing.

The cool thing with Dropbox is that once I take the screenshot, it’s immediately available in my Dropbox folder and the link is ready for sharing with my friends.

The not so cool thing about this is that Dropbox is a centralized service and hosting pictures comes with a cost. Ideally the things could be shared P2P and ephemerally, so we don’t have to worry about storage. With this we save on server bandwidth and storage costs, but still keep the functionality of frictionless screenshot sharing.

Solution? The server is used only to store the image on the initial request, before seeding begins. Upon loading the image in the browser for the first time, it is removed from the server and it’s being seeded directly from the browser. The request comes, the server gives back the URL for sharing and then you can use that URL for sharing files. Server is not involved in the download or upload traffic of that file.

The process is:

Give a file to a server which is then converted to a torrent given back to you
You also get a URL with the location of that torrent and your browser opens
Once you give that URL to someone, the seeding process starts, you are the seeder (you seed it from the browser with Webtorrent)
You can delete the file as a seeder by simply closing a browser

Ideal scenario for screenshots:

Take the screenshot
The URL opens in your browser with the image you want to seed
Once the peers connect the seeding starts and info with the number of peers is shown
Once you close the browser the seeding stops

A couple of months ago we released Seedshot, a tool for peer to peer screenshot sharing. You can install it by typing

npm install -g seedshot-cli

and then capture the screenshot with

seedshot

The process looks like this

This tool is open sourced and available on Github at https://github.com/twobucks/seedshot and command line utility is at https://github.com/twobucks/seedshot-cli.

We currently support the following platforms:

OS X
Linux

Enjoy! ❤

On criticism

Hrvoje Šimić (shime@hey.com) — Thu, 21 Apr 2016 00:00:00 +0000

The best way to complain is to make things.

James Murphy

Making things is hard. If it wasn’t hard, everyone would do it. Criticizing is easy. All you have to do is talk. That’s why there’s always going to be more people criticizing the work of others, than people building things. It takes guts to build something. It means you believe enough in the thing you’re building, that you’re willing to take the criticism. But who wants criticism? Well, avoiding it is easy — just don’t create anything.

It is not the critic who counts: not the man who points out how the strong man stumbles or where the doer of deeds could have done better. The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood, who strives valiantly, who errs and comes up short again and again, because there is no effort without error or shortcoming, but who knows the great enthusiasms, the great devotions, who spends himself for a worthy cause; who, at the best, knows, in the end, the triumph of high achievement, and who, at the worst, if he fails, at least he fails while daring greatly, so that his place shall never be with those cold and timid souls who knew neither victory nor defeat.

Theodore Roosevelt

Not creating anything is comfortable. Criticising other people’s work makes us feel important. Makes us think we know better, we could do it better, when in reality — we haven’t even tried.

Remember, misery is comfortable. It’s why so many people prefer it. Happiness takes effort. It’s incredibly comforting to know that as long as you don’t create anything in your life, then nobody can attack the thing you created. Whatever you try to build or create — be it a poem, or a new skill, or a new relationship — you will find yourself immediately surrounded by non-creators who trash it. Maybe not to your face, but they’ll do it. Your drunk friends do not want you to get sober. Your fat friends do not want you to start a fitness regimen. Your jobless friends do not want to see you embark on a career.

David Wong

Criticising other people’s work doesn’t take much effort. It doesn’t take creative work, it doesn’t take thinking deeply, it doesn’t take taking risks.

All it takes is talk and talk is easy. Easy is boring. Anyone can do what’s easy.

Do something that is hard.

Just ship it

Hrvoje Šimić (shime@hey.com) — Fri, 15 Apr 2016 00:00:00 +0000

Just ship it should not be related to the software industry only, because it can be used in so much real life situations. Publishing a blog post, for example.

Just ship it, that draft is going to stay a draft forever unless you publish it. It’s stayed unpublished for so long, there’s always something to change, remove or add. It’s okay if it’s imperfect. Life is imperfect. You are imperfect. Everything is imperfect, except your expectation of it.

By publishing I’m making progress. Draft is not progress. Start making progress today and just ship it now and without fear.

Sleep is for the weak

Hrvoje Šimić (shime@hey.com) — Sat, 26 Sep 2015 00:00:00 +0000

In today’s era of 24/7 business, sleep is becoming more and more underrated, and yet — no one is questioning the benefits healthy sleep gives us.

We are seeing sleep as unproductive activity, because we’re not making anything while asleep.

People like to brag about their lack of sleep, like it’s an achievement you could be proud of and claiming that “Sleep is for the weak”. Behind the curtain, the assumption is:

time awake - time asleep = productivity

The truth couldn’t be further.

Sleep is a productivity booster. It appears people are finding it hard to perceive all the gains sleep gives us, since the benefits are not momental. It’s considered unproductive, since we’re usually not moving while being asleep.

As neuroscientist Jeff Iliff’s recent research finds out, sleep turns maintenance mode on for our brain. In his TED talk, he explains that each cell in our body, produces waste, a byproduct of converting nutrients. While every other organ uses the lymphatic system to dump the waste for later disposal, the brain is a unique organ that is disconnected from that system. There are no lymphatic vessels in the brain and the blood vessels have to take the role of the lymphatic system. Essentially, the blood vessels become capable of transporting the waste from your brain, but it only happens when you fall asleep.

Sleep removes waste and byproducts from your brain, the waste that fills up through the day. It makes you think more clearly, decreases level of stress and improves creativity.

Arousal is for the weak.

OSX adventures

Hrvoje Šimić (shime@hey.com) — Wed, 01 Apr 2015 00:00:00 +0000

I’ve borrowed a MacBook Air for a week and decided to share my thoughts as I look back.

Why? A great magnetic 1TB disk in my premium Dell XPS 15 got borked after 1 year of its loud and hot service, so I had to replace it. I also kinda sorta have to code every day, so I had to borrow something.

I decided to borrow a MacBook because it has the reputation of being a “it just works” kind of machine, and since I had to have a working environment as soon as possible, it seemed like a great idea.

The tiger or whatever

The OS had a brief wow effect on me, because everything looked gorgeous. I also found consistency of notification sounds across applications pretty surprising and pretty cool. That’s the privilege you don’t get on Linux.

Being able to run shitty Safari natively was also something I enjoyed a lot! I would sometimes just open Safari when I was bored to see it come up and kill it immediately afterwards, like any sane person would do. I had such great time.

Something was pretty obvious from the start, though. The trackpad is a pretty serious business in the Apple world, apparently. These guys don’t mess around with their cursors. Prepare plenty of your fingers for some exercise!

As a Linux elitist and a terminal addict that I am, I find that to be annoying. I use Openbox as my window manager for a year now and I’m enjoying it so much, because it gives my keyboard so much power, a power that is being neglected in OSX. I can do everything with keyboard, from standard hotkeys for opening applications to window movement, resizing and layouting. That’s why I just hate mice and their successors - I might be biased though, since I own two cats.

Installing applications confused me a lot too.

Me discovering that you have to drag one icon above another icon in order to install something.

Me seeing something that looks like mounted hard disks on desktop casually titled 'Skype'.

The Dock is another annoyance. I don’t understand the reasoning behind using it on a screen with a max resolution of 1366x768px, where every pixel matters. It’s also remarkably bloated with, let’s face it Apple, crap no one uses by default. Trying to kill it, like any sane person would, revealed another hidden gem of OSX - the famous iNability. It manifests itself in preventing you from doing something. Being a Linux user, obsessive about configuring anything that you could possibly think of, that’s something I’m definitely not used too. As this StackExchange answer shows, there are some workarounds but they are really lame. I don’t know for you, but I had some trouble sleeping knowing the dock was still alive and well.

Me discovering the joy of closing applications while they still remain open in Dock but when opening them on Dock they don't actually exist and instead just change focus and then I have to maximize window or something like that because logic

In the brief period of my usage of OSX, I’ve managed to discover another iNability, without really working hard to find it. I like to use just the external monitor so yeah, I like the internal monitor powered down, thank you very much. You apparently can’t do that without closing the lid, which makes typing pretty difficult. The workaround people use is to just minimize brightness and go on with their lives. It’s true, they don’t even care if their internal monitor is still consuming power or not. They don’t even care about their GPU still having to render stuff on both monitors. It’s crazy sometimes, but yeah - I don’t even words.

To MacBook or not to

I’m pretty sure I’ll never leave Arch Linux and even replacing it with another distro would be somewhat weird for me, let alone replacing it with another OS. Sure there are some benefits, like running certain apps and browsers without VMs and and the more polished look of the UI, but the cons outweight them.

I don’t want to sacrifice the keyboard and insane customizability just for the flashy looks. There is no you can’t in Linux.

Speaking of hardware, MacBook Air is a great machine, no doubt about it, I regret buying this Dell instead of it, since Air costs less and is better at everything except CPU, but meh - i5 instead of i7 so it’s not a deal breaker. I’d exchange my Dell for Air in no time.

EDIT: I’m now using a Macbook Air with OSX as my primary machine and I’m really happy with it.

Complexity prettified

Hrvoje Šimić (shime@hey.com) — Fri, 09 Jan 2015 00:00:00 +0000

Ruby community is influenced with Rails opinions of conveniences and conventions. Ruby became popular through Rails and its huge influence is unsurprising. Popularity of DSLs among Rubyists is also unsurprising.

DSLs improve expressiveness, but it comes with a price. They add a layer of complexity that comes naturally with implicit code. Instead of providing truth, they provide convenience. DSL is essentially a syntactic sugar that takes you away from the actual implementation.

Strive for the expressiveness of that narrow public facing API, instead of faking it with pretty DSLs on top. We are Rubyists, damn it - we understand Ruby. The forgotten language buried deep inside your overly expressive castle of syntactic sugar.

Don’t throw all DSLs into a volcano for the time being, they are still pretty useful if their domain of usage is small. Any sort of configuration is a perfect scenario for using a small DSL. Just keep in mind that any kind of convenience comes with a price, a price that not everyone is willing to pay.

People are priceless

Hrvoje Šimić (shime@hey.com) — Sun, 04 Jan 2015 00:00:00 +0000

Neurotic Time-Wasting often takes the form of reading articles from news sites such as Hacker News, attending meetups, and futzing with A/B tests that don’t ask important questions, and don’t collect sufficient data.

David Kadavy, The Wantrepreneurial Cycle of Delusion

Tech folks are often portrayed as people who like to communicate with computers more than with people. They like to measure things, so they could optimize them and perform better. Measuring people and human relationships is hard, so people sometimes think that they can perform better if they are alone.

People often underestimate the value of just knowing people and being able to have a conversation. I know, because I’ve done it.

When I look back, some of the most important and life-changing events wouldn’t happen had I not known some people. Just hearing the right things can sometimes change your life. I know, because it happened to me.

That’s why I think it’s funny when someone says that attending meetups is a waste of time.

Meetups and community

I love seeing the evolution of the tech community in Zagreb. I love seeing how it grows and becomes better. There weren’t any meetup groups here in Zagreb two years ago, and since then we had two big Webcamp conferences. Currently, we have six meetup groups that I know of with twenty attendees on an average month and this is just the beginning.

I’m one of the organizers of Ruby Zagreb meetups and I’ve decided to start it after realizing that no one will do it for me and seeing that local Pythonistas started organizing meetups. My love for meetups was developed on the first one I attended, which was organized by the guys from Infinum.

I fell in love on the first sight with meetups. Coming to a place for free to hear interesting talks and hang out with other people was something new to me. I was a real noob back then, learning about Rails and they didn’t mind and were very welcoming. They didn’t mind about my education or certificates, they wanted to talk about my experiences with Ruby and Linux. That hacker mentality had me hooked right away.

For me, meetups were cool events where I could hear a talk about some cool stuff I wasn’t familiar with as a student. I’m not a student anymore and since then I’ve learned it’s just the tip of the iceberg – conversations are way more valuable.

Yes, that is my excuse for being the last guy on every drinkup after.

Communication at meetups is essentially sharing of experience and therefore not a time wasted, but worthwhile time. Experience is something we all gain as we go through life, so other people’s experience is essentially a time saver.

That’s why meetups are important. They save you time.

Pure logical thinking cannot yield us any knowledge of the empirical world; all knowledge of reality starts from experience and ends in it.

Albert Einstein, Ideas And Opinions (p. 271), Crown Publishing Group

Community vs academia

Formal education in Croatia is pretty bad, because it’s detached from the work market. This is what I would say to my past self, a student unaware of the things outside the academia.

People in the academia have stayed in the academia after their formal education and are therefore detached from the actual requirements of the work market. They are not financially encouraged to teach you how to get the job you will love, you must find that out yourself.

The sooner you realize that you’re falling behind with the top universities, the better. Look around and become aware of the differences. Take a look at what they are teaching, they offer free courses online.

I know it’s hard to devote time to learning additional stuff online, unrelated to your college courses, but in this industry it’s a time well spent. The net is always one step ahead to mediocre universities.

This makes meetups, conferences and hackathons even more valuable. You’ll meet people that actually work in the industry and make a living out of it. You’ll get an insight about skills required for working in the industry.

I’m super happy I managed to meet right people back when tech community in Zagreb wasn’t that mature. You now have the opportunity to find out a lot more than I had a couple of years ago – use it to your advantage.

Acknowledgements

Since this post is about people, I would like to give credit to people that formed me professionally.

Thank you

Filip Defar - for telling me “Hey, check out Ruby on Rails, it’s similar to Codeigniter. You might like it.” – I have indeed liked it.
Vlado Cingel - for telling me “Hey, check out freelancing. It’s working really good for me.” – it works well for me, too.
Željko Filipin - for organizing first Ruby meetups in Croatia and for maintaining Ruby Hrvatska Google group where I found out about Ruby meetups.
Infinum - for hosting Ruby at Six, where I met a lot of interesting people and went to my first meetup.
Tomislav Capan and Mihael Konjević - for organizing JavaScript Zagreb, which inspired me to start Ruby Zagreb.
Aljoša Mohorović - for starting Python Zagreb which pushed me even more to start Ruby Zagreb. and others that share their ideas, discoveries and opinions with me and keep inspiring me.

Special thanks to Janko and Damir for coorganizing Ruby Zagreb.

I would like to end with a quote from a blog post that pushed me to finally put all of this into words.

Sometimes who you know is more important than what you know - and that is why attending community events is extremely important.

Filip Defar, Reaching out to community

Headless testing of Ember apps with Gulp and Jasmine

Hrvoje Šimić (shime@hey.com) — Thu, 28 Aug 2014 00:00:00 +0000

TL;DR: use Karma as a test runner for your JS apps. It’s great because it adds DOM support without any effort and you need DOM support when you’re testing browser apps.

First of all - I love Jasmine.

It’s a terrific testing framework. Maybe I’m biased because I’m a Ruby developer deep down, we Rubyists love expressiveness, but I love how readable test suites it produces.

Secondly, I love PhantomJS because it means I can run JS tests without firing my browser. That is enough when you’re working on projects that are okay with modern browser support and that’s usually the case right now, I hope. When that’s not the case you’ll going to need cross-browser tests which are not going to be discussed in this blog post, but they will be addressed soon in one of the future posts.

Thirdly, I love Gulp and I think it’s way better than Grunt. Again, I might be biased - I value expressiveness and I’m also amazed by Node.js and it’s most valuable feature - streams.

Having said all this, it’s time to test this Ember app.

When you try to setup your Ember app for testing with something like this:

document.write('<div id="ember-testing-container"><div id="ember-testing"></div></div>');

You’ll receive this error message:

document is not defined

Ember requires DOM to operate and using the aforementioned toolset only enables simple JS testing. Jasmine doesn’t have the concept of document baked in.

The wrong way

The first solution would probably be adding the jsdom which is basically a DOM implementation in pure JavaScript. Seems crazy, right? It is.

Suddenly we have to add a dependency to Jasmine and the only way to do that is to add the concept of RequireJS. Immediately we think of Browserify which is cool, but it also seems weird in the same time. So we now have weirdness squared. This generates a lot of FUD and it’s time to discover other options.

The right way

Karma should ring a bell if you’ve seen Toran Billups’ great tutorials about Ember testing. There’s an example repo that served me well a couple of times, but it’s using Karma without Gulp and QUnit instead of Jasmine.

Problems were basically gone when I added Karma to the test suite. Since I wanted to accomplish everything from Gulp, I had the feeling that something was wrong with adding a separate task runner only for tests.

This was stupid, because gulp-karma is a thing. It enables you to run Karma from within Gulp.

All the things considered - I think it’s good to make every task runnable from within one task manager. I’m not sure I’ve chosen the right task manager for that - only thing that’s important is package.json or npm.

npm is something you’re going to need for almost every JS app there is, so it’s good to think of it as a king of task runners. There’s a good blog post about task management with npm which provides more detail and another one that explains why you should avoid global npm dependencies.

Rubyist's view on Node JS

Hrvoje Šimić (shime@hey.com) — Fri, 15 Aug 2014 00:00:00 +0000

I’ve been a Ruby developer for some time, but I’m recently getting pulled into the vortex of streams and modules called Node.js.

I might not come back and if that happens, here are some reasons.

I want programming computers to be like coloring with crayons and playing with duplo blocks.

Ryan Dahl - creator of Node.js

404 hype not found

There is little to say about this, after these great blog posts by Giles Bowkett.

I’ve found that in order to become better programmer, I need to have open mind for things I haven’t tried yet. I need to experiment.

By having more experiences with weird, unexplored stuff I become better. Hype has a negative connotation for me, so it’s here to prevent me from that - therefore it’s not desirable.

I try to pretend hype doesn’t exist, as I gain nothing from it.

Modules all the way down

GNU/Linux is an operating system I’ve been using a lot and I really like all the philosophy behind it. Node was inspired by Unix, but mostly with these two rules:

Rule of Modularity: Write simple parts connected by clean interfaces.
Rule of Composition: Design programs to be connected to other programs.

Ryan Dahl’s quote above is just a playful rephrasing of these rules. That’s basically a Node’s mantra and it’s even more evident if you browse around on npm a little or when you read the source code of some libraries written by prominent Node people. It feels like they use a lot more requires than we do, in the Ruby land.

The modules are also very minimalistic and they tend to be single-purpose libraries, which leads to this look of dependency graphs, representing the structure of Node ecosystem.

There are some attempts to achieve the same in Ruby, of which microrb.com is the most evident one. It isn’t very popular at the moment, but I’m hoping it will be in the future, as Rails starts getting more competitors like Lotus. Yes, it needs more competitors. Rails currently thinks it’s alone in the kingdom and I would like to see some changes with that.

large codebases are just failed ecosystems
— James Halliday (@substack) February 1, 2014

Community

I’m under impression that Node people are much more relaxed about computers and rules than Ruby people. Maybe I’m exaggerating a bit, but Dominic Tarr reminds me of Why the lucky stiff. Maybe it’s just because they’re both disguised, I’m not sure.

There isn’t much obsession with TDD/BDD/DDD in the Node land and that is a great thing. We are programmers, god dammnit - we shouldn’t be obsessed with things. We should be allowed to break them!

I’m under impression that there’s a lot less drama around everything here, everything feels more laid back. No one will dramatize if you write a Unix tool like sed or awk in Node. Do whatever you want, we don’t care. After being a Rails developer for some time, this feels very refreshing.

Gems vs modules

Since there are a lot of mad scientists in the kingdom of Node, it’s common to stumble upon things with bugs and even unmaintained things. I think this is where Node community needs to learn from Ruby community, where you’ll find so many awesome people dedicated to maintenance of a vastly used gem.

Node is a cutting edge technology, so playing with it comes with that cost, but there are two faces of that medal. You’ll also develop a skill of module picking over time - something I’ve not experienced that much in Ruby. In Ruby you rarely have to think twice before choosing the right gem for your problem, but here it’s common to see dozens of modules for the same thing. That’s probably because of the tendency for node modules to be much smaller in size than Ruby gems - it’s much easier to provide alternatives.

Because of all this, you’ll become more intimate with modules you use and you’ll start recognizing authors whose packages are worth a require.

Node is weird

Let’s admit it - Ruby is not weird anymore. People don’t do crazy things in it and I’m not sure what’s the reason why. Maybe those conventions and rules influenced our thinking and have put our minds inside the box?

It kinda feels like Java now, everyone going crazy about OO patterns, code cleanliness and 100% test coverage. Is that the most important thing? When did we forgot how to play?

Go and make something crazy! Node people are good at this.

There is also another side to this medal, of course. I have zero experience with running Node.js in production, but I’m guessing it will be harder than with Rails. That’s okay, I like challenges in things I know nothing about.

The future

Things that are happening in Node and JavaScript right now are the things that are blowing my mind. I think that’s the biggest reason why I’m attracted to it so much. I think I’ve got a little bored with Ruby since it’s the only language I’ve worked with for years.

My plan is to stick with something that is blowing my mind - I think that’s the right path to improve myself. It used to be Ruby some while ago - now it changed to Node.

I know this post is biased and it’s reasonable because I’m excited the most with trying new things. Node is not the silver bullet, but I currently enjoy playing with it. Maybe I’ll change my mind, like with Rails - maybe I won’t.

At least I’ll be richer for a fun experience.

MicroMachineJS - a minimal state machine for JavaScript

Hrvoje Šimić (shime@hey.com) — Mon, 06 Jan 2014 00:00:00 +0000

I’ve published a simple JavaScript library the other day. Its goal is to help dealing with states and it provides a simple API for managing a minimalistic implementation of a state machine.

It’s really miniature - it has only 50 lines of code. Its source code should be easy to read, even to a beginner. I’ve used Jasmine and Grunt to TDD it from scratch, so hopefully - the tests should also be really expressive.

It has no dependencies and supports everything a state machine should have, nothing more.

Installation

Give it a go by installing its node package:

npm install micro-machine

or use it in the browser with:

<script src="//rawgithub.com/shime/micro-machine-js/master/dist/micro-machine.min.js"></script>

Examples

Here’s a walkthrough of its features.

// create a new instance and set its initial state to "pending"
var machine = new MicroMachine("pending");
console.log(machine.state); // outputs 'pending'

// define transitions
machine.transitionsFor.confirm = {pending: 'confirmed'};
machine.transitionsFor.ignore = {pending: 'ignored'};
machine.transitionsFor.reset = {confirmed: 'pending', ignored: 'pending'};

machine.trigger('confirm');
console.log(machine.state); // outputs 'confirmed'

// define callbacks
machine.on('reset', function(){
  console.log("resetting...");
});

machine.trigger('reset'); // resets state and outputs 'resetting...'

// define special callback that will be called after any transition
machine.on('any', function(machine){
  console.log("transitioned to '" + machine.state + "'");
});

machine.trigger('ignore'); // outputs "transitioned to 'ignored'"

Composition capabilities

Adding MicroMachine to your objects is piece of cake - just use composition!

var User = function User(){
  var machine = new MicroMachine("pending");

  machine.transitionsFor.confirm = {pending: 'confirmed'};
  machine.transitionsFor.reset = {confirmed: 'pending'};

  self = this;
  machine.on("any", function(machine){
    self.state = machine.state;
  });

  this.confirm = function(){
    machine.trigger('confirm');
  };

  this.state = undefined;

  return this;
};

var user = new User();

user.confirm();

console.log(user.state); // outputs 'confirmed'

That’s all there is to it. Go give it a spin!

5 reasons for adding a post-installation message to your gem

Hrvoje Šimić (shime@hey.com) — Sat, 30 Nov 2013 00:00:00 +0000

Wondering whether you should add a post-installation message to your gem? Here’s a list situations in which doing so is desirable:

No, seriously - don’t do it!

but having fun is important

Yes, I know. Maybe this seems a little harsh, we are a Ruby programmers after all. We are fun and interesting, still kids in our hearts and we are so different from those stuffy statically typed language programmers. They are those grumpy ones, not having fun at all, doing everything by the book.

Why can’t we have a little fun, tell people something nice when they’re installing things so that they are reminded to have fun? After all, you should love what you do - it should still be fun to you.

Well, yes - please have fun, but please remember that if you’re going to have fun with post-installation messages, you’re also going to exploit the functionality that was given to you by the community to tell people important stuff they should be aware off.

What happens if a gem developer decides to add a post-installation messages with ASCII art, for example? Yes, every developer out there will be aware of the presence of that gem in her project. It will stand out among other bunch.

What happens if every gem developer decides to do so? Perhaps STDOUT overflow would be a right naming for it.

workarounds for gems that currently have post-installation messages

You can still avoid having any post-installation messages. Bundler has a flag for it

bundle install --quiet

Although, Linux people (like me) will of course wonder why is that flag even present, when you can just ditch it to the black hole

bundle install > /dev/null

dangers of workarounds and conclusion

This will of course mean, that you will not see any of the critical warnings that might be present and were added by gem authors that cared enough to add it there.

Why would anyone put warnings there? Well, when people can’t use anything else (like normal deprecation warnings), they’ll still fallback to this method.

An example of this would be when a gem changes its name, like how sqlite3-ruby did:

Hello! The sqlite3-ruby gem has changed it's name to just sqlite3.
Rather than installing sqlite3-ruby, you should install sqlite3.
Please update your dependencies accordingly.

Useful, right?

What about:

When you HTTParty, you must party hard!

Must you party --hard? I don’t think so. I didn’t and I’m still here.

Be the change you want to see

Hrvoje Šimić (shime@hey.com) — Sun, 13 Oct 2013 00:00:00 +0000

World wide web is such a great medium. Its impact is gaining momentum every single day and I couldn’t be more happy about it. I’m convinced it will replace all other mediums and it is a global brain of sorts. Transparency is probably why I like it the most and I’m under impression that most of the society is not aware how important role transparency plays in our lives.

Open source is closely related to transparency. I know exactly what I’m using and therefore I can alter it to fit my needs. If I’m interested, I have the opportunity to learn about all of the details because the details are just hanging around and waiting for my set of eyes.

I’m writing all of this on an open source operating system, using the open source editor to enter this markdown, which will be outputted into the web-friendly format by a little help of the open source blog engine, which will in fact get hosted on the open source repo provided to me for free.

Isn’t that amazing?

What are you talking about, I don’t even

I mean, there are a lot of projects online involving really clever people who are building stuff that’s changing the world. They are not only helping people to get stuff done, but also sharing their knowledge with everyone who is interested.

Take StackOverflow, for example. It has been an immense stack of knowledge bits, carefully partitioned into Q/A pairs, waiting to help others with the same problems. I’m infinitely thankful for such a great service and it doesn’t ask for anything in return, other than my optional beans of wisdom. Not only do I feel like a hero when my little beans help someone on the other part of the globe with their problem, but I also get rewarded for it. I get certain reputation points. It amazes me how great concept this is.

Discourse is the new cool thing I would like to get involved in. Let’s admit it, the most of the forums today are still stuck in the 90’s. They all look and feel the same, so I’m excited to see Discourse setting the future of forums. I’ve only known about it since I started to learn JavaScript MVC framework, called EmberJS. Discourse, being an open source project has been a great aid for me in the world of Ember, because I can refer to its source code when things get messy. Being able to see how Robin Ward, known as Evil Trout, solves Ember problems has taught me a lot. He also posts some great learning stuff on his blog, so if you’re also learning Ember, make sure to check it out.

TravisCI is another example of a vibrant open source project. I haven’t managed to find time to check its Ember source, but I’m sure I could also learn a lot of interesting stuff.

The other side

I don’t know about you, but I’m aware of plenty of sites which are exactly the opposite of the aforementioned ones. They’re usually utility sites, aimed to help a certain group of people. More often, than not, they are related to some political institution or they represent a government agency of some sort.

The most obvious example of shitty websites is the public transportation sites, at least in my experience. I don’t know what’s the experience in other cities or countries, but in Croatia it’s unbearable. People are, kind of, used to the shitty websites when they need some sort of public service on the web. They are n aware that things can be improved a lot, but seeing same pages over and over again for a long period of time has had the effect of minimizing the problem.

How you can help

If you have any programming experience for the web, you might want to give it a shot and try to build something better. It will not only help others and reward you in eternal glory, but it will also make your life a lot easier!

Why not help your fellow citizens, if you have the knowledge?

Imagine learning new interesting language or framework while helping other people at the same time! Building interesting new stuff and solving problems you’ve never experienced before makes you a better programmer.

When you don’t create things, you become defined by your tastes rather than ability. Your tastes only narrow & exclude people. So create.

Why The Lucky Stiff

Instead of ranting about the poor user experience, why not revolutionize it?

To wrap it up, don’t expect the world to change by itself. Be that change!

Guard down, Vim and Tmux are here!

Hrvoje Šimić (shime@hey.com) — Sun, 11 Aug 2013 00:00:00 +0000

Do you practice Test Driven Development? If you do, how do you do it?

Well if your answer is “I do it by using Spork with Guard.”, then you know that it runs every time you save a file. Same can apply to any other autotesting tool.

Isn’t that too often?

What’s itching me

I’m a Vim user and I’m used to saving my files frequently, this keybinding makes it super-easy to do so:

"" saving with ctrl+s
map <C-S> :w<CR>
imap <C-S> <Esc>:w<CR>

So let me explain what do I mean by “too often”.

Guard watches for filesystem changes, while Spork preforks your Rails environment to speed up the tests. If you set up them properly, which sometimes can be a pretty painful process, your tests will run for each update of the directory being watched. It means that you will spend a lot of time customizing these two to work well together and end up with a watcher that runs your test inside a preforked Rails environment (which still takes time to load and it’s still not fast enough for unit tests). How many times did you save your file to immediately notice a typo?

There seems to be a new kid on the block, but I will not cover it this post. I will focus on my current routine.

Current routine

Zsh is great, Tmux is great and Vim is so awesome, using it feels like doing evil things. I use them on a daily basis and they’ve proven to be a great trio! There are a lot of resources about them written by very smart people and you can find links to some of them on the bottom of the page.

Currently, I’m using Zsh + Tmux + Vim and some plugins to run only the relevant tests with a few key presses.

Here’s how it looks in action:

What am I doing here? As you can see, my cursor is positioned inside a Rails model file. I simply hit ,s and specs for this model are being ran in the another Tmux pane. This functionality is achieved with two great Vim plugins - Turbux and vimux.

Turbux is designed to speed up your TDD cycle by using a single key mapping to run the most relevant test based on the current file in Vim, while vimux is a tool for interacting with tmux from Vim. Turbux depends on unavoidable rails.vim to determine the most relevant test and adds some of its own default mappings.

These are the default Turbux mappings:

map <leader>t <Plug>SendTestToTmux
map <leader>T <Plug>SendFocusedTestToTmux

The default mappings clashed with my Command-T mappings, so I had to rebind them to <leader>s.

" disable default turbux mappings because they clash with Command-T
let g:no_turbux_mappings = "true"
map <leader>s <Plug>SendTestToTmux
map <leader>S <Plug>SendFocusedTestToTmux

As you might have guessed, my leader is mapped to comma.

let mapleader=","                                   " map leader to , instead of to slash

Trouble with Zeus

On the first attempt, I run my specs by using Zeus and you can see that zeus is prefixed to rspec command. Although Zeus is meant for preforking and therefore speeding up the runtime of your specs, it’s slowing things down in this scenario.

Why? Well, because I’m testing my models without requiring Rails and I have my business logic decoupled into extensions. That’s why I have all that include lines in my model.

While Zeus is slowing things down here, it certainly speeds up things in all other kinds of tests. I want to be able to turn it off and on inside Vim.

Helpfile for Turbux suggests this:

Use the following in your vimrc to set a common command prefix for prepending
all commands:
>
          let g:turbux_command_prefix = 'bundle exec' " default: (empty)
<

So I could set my g:turbux_command_prefix to zeus, but that means I would use Zeus all the time. I need something different, like a toggle function for this. It’s easy to write if you know a little bit of Vimscript:

" I mostly use zeus to run tests
" I don't use it all the time though
" this function enables toggling when using turbux
nnoremap <leader>z :call ToggleZeus()<cr>
function! ToggleZeus()
  if g:turbux_command_prefix == 'zeus'
    echo 'zeus disabled'
    let g:turbux_command_prefix = ''
  else
    echo 'zeus enabled'
    let g:turbux_command_prefix = 'zeus'
  endif
endfunction

That’s it! I can now toggle to run my specs with or without Zeus. :)

Focused tests

In the end, I just want to show how you can run focused test with Turbux.

Resources

There are a lot of additional resources on the web and I would definitely recommend:

Vim: revisited by Mislav Marohnić
The Text Triumvirate by Seth Brown
Faster TDD feedback with tmux, tslime.vim and turbux.vim by Joshua Davey

Long time no see

Hrvoje Šimić (shime@hey.com) — Mon, 17 Jun 2013 00:00:00 +0000

It’s been a while.

I haven’t blogged for almost a year, so I’ve decided to celebrate this resurrection with a huge design update. Here’s a picture of the old design. I’m really happy with the updates and seeing the change convinces me even more that it was worth it.

Design changes

As you might have guessed, this site is using Octopress which comes with a pretty default theme.

The theme is now really minimalistic and a couple of amazing Typekit typefaces had been included. It’s using Museo Sans and Museo Slab which are hopefully really pleasant to your eyes. Another way to check which typefaces are being used is by clicking the icon in the bottom-right corner.

The front page has also been updated. As you can see in the upper-linked picture of the old design, it used to be pretty default Octopress page, which listed all posts. Font Awesome helped me in improving that. It’s really an amazing site for icons. Kudos to Dave Gandy for doing an amazing job!

Other changes

What changed in a past year? Nothing much, I’m still freelancing. Not as much as I would love to, considering last couple of months. I still have to finish my Bachelor’s degree, so trying not to fail started to take a lot of my time. Hopefully it will end in a couple of weeks.

My love considering programming languages is still Ruby. I’m being more opened to other awesome languages, though.

I’m also learning how to build an object-oriented language on top of functional programming with Clojure from a book by Brian Marick. It’s worth every penny and you should read it if you’re interested in improving your thinking in a functional paradigm.

Speaking of books I’ve read, The Pragmatic Programmer: From Journeyman to Master is the one I can not recommend more. It’s probably one of the best technical books I’ve ever read. I really like the part where the authors are trying to persuade the reader into using a fully-customizable editor over an IDE. That’s just one of the gems out of the many you can find inside.

Yes, there is a Rails-related book I can also recommend. It’s called Rebuilding Rails by Noah Gibbs and you should read it if you’re interested in the concepts of building a Rails-like framework yourself. It keeps you away from the complexity of newer Rails versions and maintains its focus on teaching you the core of its functionality. It will not strangle you by explaining every problem the Rails core team faces in their usual day, but it will still teach you how the stuff works behind the curtains. The mantra of this book is - “You’ll learn it better if you do it yourself”. If you’d like to know how to write an ORM or how controllers know where the models are hiding, this book is for you. Oh, did I mention that you can download a free chapter? Go check it out!

Additionally, I’ve been spending some time improving my rusty C skills. I’m reading Zed Shaw’s tutorial called Learn C the Hard Way. I’m enjoying it so far. Here’s how he describes C:

It is the Devil, Satan, the trickster Loki come to destroy your productivity with his seductive talk of pointers and direct access to the machine. Then, once this computational Lucifer has you hooked, he destroys your world with the evil “segfault” and laughs as he reveals the trickery in your bargain with him.

But, C is not to blame for this state of affairs. No my friends, your computer and the Operating System controlling it are the real tricksters. They conspire to hide their true inner workings from you so that you can never really know what is going on. The C programming language’s only failing is giving you access to what is really there, and telling you the cold hard raw truth. C gives you the red pill. C pulls the curtain back to show you the wizard. C is truth.

Zed Shaw

I like that guy.

Conclusion

I think I’ve advanced in my open source work in the past year and I have definitely learnt a lot of stuff. Let’s hope I’ll continue to do so. Let’s also hope I’ll update this page more often and let’s not be surprised if we see a post about something unrelated to Ruby every now and then.

Overriding instance method with a module

Hrvoje Šimić (shime@hey.com) — Mon, 06 Aug 2012 00:00:00 +0000

This is the problem I come across every now and then, so I think a little write up explaining what’s happening could help me understand it better.

Let me describe the problem:

module CanCook
  def bake(food_name)
    "I'm baking the #{food_name}!"
  end
end

class Programmer
  def bake(food_name)
    "I don't know how to bake #{food_name} :("
  end
end

class Programmer
  include CanCook
end

Mario = Programmer.new
Mario.bake("tortillas") #=> I don't know how to bake tortillas :(

Poor Mario doesn’t know how to bake anything. We want to teach him how to bake, to stand out from other programmers!

The problem is described in the following diagram made by Gavin Kistner:

There’s a post on StackOverflow where Gavin presents workarounds for this. I’m going to explain them and add some more:

Subclass Programmer and then include module

module CanCook
  def bake(food_name)
    "I'm baking the #{food_name}!"
  end
end

class Programmer
  def bake(food_name)
    "I don't know how to bake #{food_name} :("
  end
end

class CulinaryProgrammer < Programmer
  include CanCook
end

Mario = CulinaryProgrammer.new
Mario.bake("tortillas") #=> I'm baking the tortillas!

What’s wrong with this?

This isn’t a real world example, just a simple one that describes this behavior. This would rarely fit you, since you now have to create instances of a new class that will fit your needs. In the real world, you would want instances of the original class to behave like this.

Extend just the instances you need

module CanCook
  def bake(food_name)
    "I'm baking the #{food_name}!"
  end
end

class Programmer
  def bake(food_name)
    "I don't know how to bake #{food_name} :("
  end
end

Mario = Programmer.new
Mario.extend CanCook
Mario.bake("tortillas") #=> I'm baking the tortillas!

What’s wrong with this?

This is better than the previous solution, it skips the part of inheriting the original class, but you still have to extend each instance. What happens with already used instances in your application?

Perform a gross hack that removes the original method

module CanCook
  def self.included(base)
    base.class_eval do
      remove_method :bake
    end
  end

  def bake(food_name)
    "I'm baking the #{food_name}!"
  end
end

class Programmer
  def bake(food_name)
    "I don't know how to bake #{food_name} :("
  end
end

class Programmer
  include CanCook
end

Mario = Programmer.new
Mario.bake("tortillas") #=> I'm baking the tortillas!

What’s wrong with this?

Just as Gavin describes it in his post, this strategy is invasive. Your old method will be deleted and you will not going to be able to use it afterwards. This is the best solution so far, even though remove_method seems dirty. The good part is that your instances of Programmer will now know how to bake things automatically. Hooray!

No need to use module if using remove_method

class Programmer
  def bake(food_name)
    "I don't know how to bake #{food_name} :("
  end
end

class Programmer
  alias_method :_real_bake, :bake
  def bake(food_name)
    "I'm baking the #{food_name}!"
  end
end

Mario = Programmer.new
Mario.bake("tortillas") #=> I'm baking the tortillas!

What’s wrong with this?

This post describes modules overriding instance methods, that’s what’s wrong. :) It makes sense to not use the module, though. The original method is preserved and available for later usage. However, this is not that clean. Modules are used to describe behavior that can be shared between objects. This removes that flexibility.

Here’s the alternative:

module CanCook
  def override_bake(food_name)
    "I'm baking the #{food_name}!"
  end
end

class Programmer
  def bake(food_name)
    "I don't know how to bake #{food_name} :("
  end
end

class Programmer
  include CanCook
  alias_method :bake, :override_bake
end

Mario = Programmer.new
Mario.bake("tortillas") #=> I'm baking the tortillas!

I like this more since it still preserves the original, but we’re still using a module, even though the methods don’t share the name.

Use (prepend) library by John Mair

require "prepend"
module CanCook
  def bake(food_name)
    "I'm baking the #{food_name}!"
  end
end

class Programmer
  def bake(food_name)
    "I don't know how to bake #{food_name} :("
  end
end

class Programmer
  prepend CanCook
end

Mario = Programmer.new
Mario.bake("tortillas") #=> I'm baking the tortillas!

What’s wrong with this?

It’s depending on external library.

The ultimate solution of them all

These are all the solutions presented in that SO post, but we haven’t yet found the ultimate one. Does any of these make you jump around your room screaming how great this code is? I didn’t think so.

But behold! This is the solution by @rkh which pretty much encapsulates why I love his work.

module Prepending
  def append_features(base)
    prepend = self
    base.extend Module.new { define_method(:new) { |*args,&block| super(*args,&block).extend(prepend) }}
  end
end

module CanCook

  extend Prepending

  def bake(food_name)
    "I'm baking the #{food_name}!"
  end
end

class Programmer
  def bake(food_name)
    "I don't know how to bake #{food_name} :("
  end
end

class Programmer
  include CanCook
end

Mario = Programmer.new
Mario.bake("tortillas") #=> I'm baking the tortillas!

I’m going to describe this solution in detail, so if you’re not amazed, this post will not get any more interesting.

So where to begin?

Any external dependencies? No.
Are we getting invasive on original method? No.
Do we have to do something special with the instances we would like to have the method overridden? Not at all.
Is this code awesome? Hell yeah!

Isn’t this what you first think of when you wish to override instance method with a module?

Okay, enough with the praising, let’s start explaining! Our code is nicely organised, but the whole beauty lays in a module named Prepending. All logic needed to prepend instance methods is located there.

From ruby documentation:

append_features(p1)

When this module is included in another, Ruby calls append_features in this module, passing it the receiving module in mod.

Documentation is somewhat confusing. This method will get called even when the module is included in a class, since Class inherits from Module. In our code it happens when we include CanCook into Programmer on line 24.

Note that self will refer to CanCook, and base will refer to Programmer class.

    prepend = self

Save this module to a variable, so we can use it later.

base.extend Module.new { define_method(:new) { |*args,&block| super(*args,&block).extend(prepend) }}

Extend the Programmer class with anonymous module

This is somewhat more expressive:

module Prepending
  def append_features(base)
    prepend = self
    beauty = Module.new do
      define_method(:new) do |*args,&block|
        super(*args,&block).extend(prepend)
      end
    end
    base.extend beauty
  end
end

Why are we using anonymous module here?

By defining the module and the method in block, we stay in the same lexical closure, so we can access the local variables.

What is wrong with this line of code?

module Prepending
  def append_features(base)
    prepend = self
    beauty = Module.new do
      def new(*args,&block)
        super(*args,&block).extend(prepend)
      end
    end
    base.extend beauty
  end
end

prepend doesn’t exist in the context of the new method, since it’s a local variable. We have to define a method dynamically to make it available by preserving original context.

Okay, let’s explain the code inside this dynamically created method. It’s called new and it overrides a Programmer’s constructor, so when Programmer.new is called, this method will get called instead.

It calls the original constructor with super, which returns a new instance of Programmer and then extends it dynamically with itself (this module, or the module that extends this module). This enables overriding instance methods.

Update

Thank you all for discussing this post and sharing your opinions.

Ryan LeCompte has another, more easily understandable solution. Instead of using an anonymous module, we could simply use define_singleton_method.

module Prepending
  def append_features(base)
    prepend = self
    base.define_singleton_method(:new) do |*args, &block|
      super(*args, &block).extend(prepend)
    end
  end
end

module CanCook

  extend Prepending

  def bake(food_name)
    "I'm baking the #{food_name}!"
  end
end

class Programmer
  def bake(food_name)
    "I don't know how to bake #{food_name} :("
  end
end


class Programmer
  include CanCook
end

Mario = Programmer.new
Mario.bake("tortillas") #=> I'm baking the tortillas!

As Markus explains, we could have extended the instance directly in a constructor.

module CanCook
  def bake(food_name)
    "I'm baking the #{food_name}!"
  end
end

class Programmer
  def initialize
    self.extend CanCook
  end

  def bake(food_name)
    "I don't know how to bake #{food_name} :("
  end
end

Mario = Programmer.new
Mario.bake("tortillas") #=> I'm baking the tortillas!

Florian Hanke explains that this code doesn’t express its intent very well and I couldn’t agree more with him. I was very excited when I first saw Konstantin Haase’s technique of achieving this behavior (here is the original gist). I’ve written this post with the intent of describing that interesting technique. I didn’t analyse possible future usages.

You should also read an interesting post by Josh Cheek about dangers of using hooks.

Finally, thanks to Nikica for a suggestion about lexical context.

Articles • Hrvoje Šimić

Merry Christmas

I've just deleted five of my ideas

Second goodbye to LinkedIn

Shaving that yak

The prison of context

On evil being that which is positive

Schopenhauer, Emerson, and prompting yourself

Thoughts on coffee making

Into hibernation

Choose a note-taking app that best fosters self-dialogue

I regret not journaling sooner

Writing deadlines

Tired of social media

That which is familiar, becomes invisible

Good habits affect us, but we forget

Reflections on three months of note rafting

Putting the ego on the line

Thoughts on debugging

Writing before programming

Morning Pages are the wastewater

Thoughts on social media

The story of a ringing bell

Silencing others to hear yourself

Books for depth, articles for breadth

Use Zettelkasten to write articles

Writing is not a separate task from Zettelkasten

Zettelkasten makes writing more fun

Articles emerge from your notes

Stop thinking what others would like to read

Meetings vs documents

Speech is not editable

Meetings create artificial urgency

Documents allow easier collaboration

Documents are easier to reference

Documents are asynchronous

But, documents are less social

Dealing with bureaucracy

Reading and conversation

The problem with infomania

Writing might be like painting

The beauty of the conversation

Build aspirins for friends

Building multivitamins for myself

Building aspirins for non-tech friends

The problem with building aspirins for others

Writing a lot is not enough

The lesson of the pottery class

Do a hundred of something to become great at it

Writing a lot does not make you a great writer

Let the articles marinate instead of publishing them right away

The title lock-in

Developing a taste for writing

Why you should keep a learning journal

The advantage of being a programmer

The benefits of keeping a journal

The problem with Stack Overflow

Learning in public can sometimes be embarrassing

My experience with switching apps for personal knowledge management

Why bother?

The benefits of PKM

BASB in Notion

No structure in Roam

Zettelkasten in Roam

Switching to Zettlr

Switching to Vim

Switching to Obsidian

Switching to Bear

Readwise, or why I’m back in Roam

Thoughts on coming back to Roam after a long time

When magic works against you

1. It’s implicit

2. It’s a fake local

3. It’s easy to make mistakes

The importance of detachment

The overreaction paradox

Write for yourself

Beware of programming puzzles

Problems with puzzles

Importance of having a bigger goal