I was at ReactEurope and now I "get" React Hooks

Last week, I went to Paris to spend some time there with my family and to attend ReactEurope.

Based on the kind of mediocre design of their website I did not expect a lot of care to go into the organization of the conference. I expected a dull conference room in a hotel and some interesting talks.

I got some interesting talks and a dull, stuffy conference room in a dull, ugly area of Paris. The room was too small for so many people though. The air was terrible and people coughing and sneezing all around me. I was not capable of spending a lot of time in there.

Instead, I took some time to read through the React Hooks documentation. Let me just take a second to say how well written and how thought-out the documentation is. Really world-class. Unlike the ReactEurope conference.

I also started rewriting my Grit editor from Preact and htm to React with hooks. Just so to get familiar with them.

It is always hard to convey how features like that impact your development experience without trying it out. I have only rewritten a small part of it so far but I like it a lot.

The concept of custom hooks especially seems to have a lot of impact when it comes to simplifying your code.

Here is an example.

In order for Grit to work the user has to store the path to their Markdown files in the settings. I store the settings by using this ace package called electron-store by Sindre Sorhus (Shout out to him, what would I do without his stellar open source work?!).

This path needs to be shown in the UI via a state variable and it has to be synced back to the electron-store if it is changed.

So I created this custom hook called useElectronStore to read the path from electron-store and to set the filePath state variable from it and to set both, the state variable and electron-store, with the new value once it is changed.

And it makes getting and setting electron-store values incredibly easy. The API basically looks like this:

const [someValue, setSomeValue] = useElectronStore('someValue', '');

The 'someValue'-string is the path in electron-store and the second value is the default value for it.

I can now say that I “get” React Hooks because ReactEurope was not that great. Works for me.

Announcing Grit: a Markdown editor for blogging with a static site generator

Last year I decided to write more. I thought I’d try a hosted solution because I wanted to concentrate on the writing and not on the fiddling with the site.

Micro.blog was the most attractive solution to me but after using it for a while I realized that, as a developer, I am not capable of leaving the building of my blog to somebody else. There were too many things I wanted to tweak/change, bugs I couldn’t live with etc.

So I ended up sticking with my Hugo solution.

Unfortunately there are many little annoyances when blogging with a static site generator, due to the fact that your posts are a bunch of Markdown files in a folder with a specific file name and some frontmatter boilerplate in them.

Creating a blog post was always tedious. Too many little fiddly things to do before you could just start to write.

In order to remedy this I created a blog-cli that just scaffolds new blog posts for me. It works fine but I really wanted an editor that can do that for me.

That’s why I built Grit. It’s a little Electron app that lets you manage a folder full of Markdown posts and edit them as well.

It allows you to store the path to your Markdown files, filter through the files, create a new file, edit the file and publish via Git.

I used Preact and htm to write it because I was too lazy to set up a build step and I love writing code the browser can directly interpret. For the file editing part in Grit I am using CodeMirror which is a hell of a product, wow.

If you use Hugo, Jekyll, Gatsby or whatever other static site generator to build your blog and are looking for a little convenience there, give it a spin! See the current feature list on GitHub.

It’s an alpha version so there be dragons. But I am planning a bunch of improvements like: drag and drop images, configurable frontmatter and some enhancements around file-creation.

If you want, let me know what you think on Twitter.

Get off of Medium and publish a blog under your own domain

Nobody can wall that off behind a paywall.

Nobody can put a popup over your stuff and say “Don’t look at the content right now. It’s so much better if you login!”.

Nobody can build their brand off of your work. Nobody can make money off of your work, if you don’t want to.

Nobody can tell you “You can’t have your own domain on here.”

Your hoster will most likely not suddenly go: “Oops we just went out of business / were acquired, we’re deleting all your stuff but you can export it until tomorrow and fuck off, basically.”

And if they do, you can go and host that somewhere else.

You can still decide to re-distribute your content to places like Medium, dev.to, Micro.blog, Twitter, Instagram, Linkedin, Facebook and / or via a newsletter. It’s a good way to extend your readership.

You can have an RSS feed! That feed should always be under your domain!

Writing on the internet under other peoples / companies domain names is like giving away money.

Sure, sometimes it makes sense to guest-post on somebody else’s blog because it broadens your audience. That’s a good trade-off.

You should just always have a place that people can come back to that is yours.

Constraints Are Decisions You Don't Have to Make

Since I realized that constraints can produce more creative outcomes I‘ve been fascinated by it.

I think I first learned about it when the iPhone became popular and the form factor and usage patterns produced beautifully designed apps and then website and web app designs that were optimized for mobile.

I read up on it a little and there seems to be a pretty logical explanation for this.

In an environment of abundance the brain is not being challenged. The brain likes to be efficient as possible. If there is an abundance of resources it’s going to be harder to be creative because your brain has no incentive to really get into gear.

In a situation where you are confronted with resource scarcity of some kind, your brain has no choice to start turning up in order to find out how to work around the scarcity.

This results in more creative, out-of-the-box thinking.

I think there is a second element that plays a part in this as well: reduced cognitive load.

Resource scarcity could also be interpreted as: some decisions were already made for you. The fewer decisions you have to make, the more brain capacity is available to you to solve the problem at hand.

The Ultimate Recipe to Attract an Audience on the Internet

My awesome co-worker Emma Wedekind wrote this post about how she got 27K followers on Twitter.

It’s a great post with lots of good advice to grow high quality followers.

I was able to watch the whole ride and it was quite something. There is one thing I noticed about how she used Twitter that I think had significant influence in why she blew up.

She editorializes her Twitter account. She deliberately tweets content that might be valuable to the developer community. And she responds to tweets a lot.

She also keeps a very friendly, welcoming and helpful tone.

Be kind and provide value frequently and consistently over long stretches of time is basically the ultimate recipe for attracting and growing an audience on the internet. We’ve all seen this work many times.

It has happened many times over on YouTube, Twitter and of course many blogs.

The thing is, the hardest part is not to come up with the topics or to do the writing itself. The hardest part is to keep it going in a specific rhythm over long stretches of time.

It takes a lot of discipline to keep that up, it’s hard work. But if you can do it, it will pay off.

My hat goes off to Emma for doing it.

If you want an audience too, follow the ultimate recipe and you most likely will not blow up like Emma did, but you will for sure attract an audience that cares about what you have to say.

TFW You Realize What Technical Debt Actually Means

A few weeks ago I set out to write a blog post about technical debt and the complexities of getting rid of it, or some of it, when you work for a company.

I wanted to see what others had written about it and of course I landed on Martin Fowler’s article about technical debt. When I started reading it I realized that up to that point I didn’t really know what tech debt was.

It seams that while being confronted with the eternal vastness of software engineering, this is what my brain does: when I hear a term for the first time and I can deduce its approximate meaning from context, I store it as a known term. Even though I don’t know exactly what it is.

What I deduced it to be was: “Legacy code, that makes it hard to maintain your code or to add features.”

And every time I heard or used the term “technical debt” there was a tiny little voice in the back of my head going: “Why is it “debt”!? I don’t get it.”

Anyways good ol’ Martin cleaned up that part of my brain and made it crystal clear for me:

Technical Debt is a wonderful metaphor developed by Ward Cunningham to help us think about this problem. In this metaphor, doing things the quick and dirty way sets us up with a technical debt, which is similar to a financial debt.

Like a financial debt, the technical debt incurs interest payments, which come in the form of the extra effort that we have to do in future development because of the quick and dirty design choice.

We can choose to continue paying the interest, or we can pay down the principal by refactoring the quick and dirty design into the better design. Although it costs to pay down the principal, we gain by reduced interest payments in the future.

It’s a metaphor! It is actually a term that was invented in order to explain consequences of sloppy coding to people in suits!

Fowler goes on to write:

The metaphor also explains why it may be sensible to do the quick and dirty approach. Just as a business incurs some debt to take advantage of a market opportunity developers may incur technical debt to hit an important deadline.

The all too common problem is that development organizations let their debt get out of control and spend most of their future development effort paying crippling interest payments.

Thank. You. Technical debt can lead to crippling interest payments. These can slow down your development teams so badly that you can’t compete anymore.

The term “technical debt” carries all the information you need in order to make the argument to company leadership why getting rid of it or keeping it at bay may be a wise business decision.

Who knew?! 😂

Nested Loops Bow-Out

As you may know, I am a member of the JavaScript band Nested Loops. We performed on the last three opening performces of JSConf.eu.

We will not be performing at JSConf.eu this year.

It was a great honor and privilege for us to be able to do that and we are thankful for the opportunity.

We produced original music for the conference and performed it in a browser. If you want, you can re-live of our performances on YouTube. And you can listen to our story on the Changelog podcast here.

I have no idea if we will ever perform again at JSConf.eu or any other event.

If you want to talk to us about performing at your JavaScript conference or any other event, or if you needs some original music just drop me an email or DM me on Twitter.

How to Use Async Functions

This article by Dr. Axel Rauschmayer was exactly what I needed to wrap my head around how to use async functions without confusion.

Because I was just using them intuitively so far and because of their synchronous style I got confused about when to try-catch. I also attempted to call an async function without await in front of it while using await in its body, fully expecting it will be executed synchronously.

It’s important to remember that the foundation of async functions is Promises.

The most interesting parts of Axel’s article to me, were these:

• Async functions are started synchronously, settled asynchronously
• Parallelism
• Immediately Invoked Async Function Expressions

blog-cli: A CLI for Blogging with Static Site Generators

My blog is built with Hugo. Every blog I ever had was built with a static site generator or a file based CMS. I love static site generators, they make content management simple, they are secure and it’s fun to build websites with them.

For me, they have one problem: creating a blog post is annoying. Typically the file for the post needs to have the date in it and the slug and then you need to put in the Front Matter for the post. It is all just very tedious and annoying.

That’s why I made blog-cli. It creates the Markdown file for me at the right location with the correct file name, inserts the basic Front Matter and opens the file in my favorite Markdown editor. This means I go from post idea to writing in 1 second.

This should work for most static site generators. At least for simple setups.

Here is how it works.

First you have to install blog-cli. You need Node.js and npm for that.

npm install --global @kahlil/blog-cli

Then you need to tell blog-cli where you want it to put your posts.

blog --path ~/my-blog/posts

Then you need to tell blog-cli about your favorite Markdown Editor.

blog --editor 'ia writer'

Now you are all set and you can create a new post and open it in your editor by simple specifying a slug.

blog my-new-cool-post

This will create a new file with the filename: 2019-01-17-my-new-cool-post.md in the directory you specified, ~/my-blog/posts in this case.

The Front Matter that is inserted looks something like this:

---
draft: true
date: 2019-01-18T10:03:48.620Z
title: ""
---

Now, if you are part of the cool kids club then you probably keep your files in a Git repository, commit new blog posts and push them to Github at which point it gets deployed to Netlify.

It turns out that blog-cli can help you with that as well!

blog --publish

Will automatically commit all changes with the message ‘new post’ and execute a git push.

Nifty, right?! If you are static-site-generator-blogging as well I hope blog-cli can help you.

If you have any ideas to improve it please send an issue or a PR on GitHub.

Blogging is Back

I’m excited about blogs this year. It really feels like blogs and RSS feeds are back. I am especially happy to see some developers getting serious about it.

Dan Abramov started the year off with a barrage of really good posts of which some already went viral. People even started to translate them into different languages. Wow.

Yoshua Wuyts started the year with a new blog as well. With a sick dark theme, too.

CSS Tricks relaunched their blog with an amazing dark theme design. Not a new blog obviously but man did they make a splash with this. Their post about how they came up with the design is really impressive.

Just a few days ago I stumbled over remove.bg. You can upload any picture with a face on it and it will give you back the same picture with the background removed and made transparent. It’s quite astonishing. How do they do this?!

This Next.js MDX Blog Kit sure looks interesting!

Salary Negotiations for JavaScript Developers (and Anybody Else)

Salary negotiations at the start of a job always feel somewhat like a war to me.

Each party is trying to get on higher ground to get the tactical advantage over the other.

Typically one of those parties comes to that fight ill-prepared. Generally that’s the prospective employee.

It’s weird that your first interaction with your future employer is them basically trying to get the best of you. Companies should just pay fair market by default but they don’t. They try to get you as cheap as they can.

I learned a few things about salary negotiations from a friend, from experience and from this twitter thread that led me to this amazing 7k word Kalzumeus article on the topic.

Here are the three most important things I learned.

1. Never give a number

If they want to know what you want to make, they want to gain leverage over you in order to lower your ask, don’t tell them.

Rather tell them:

First and foremost I am interested if we are a mutual fit. I am happy to talk about the financials later on in the process.

If they keep asking say this.

Money is not that important to me right now, I would like to find out if we are a mutual fit first. I do expect to be paid a salary that is fair market.

If they want to know what you currently make, they want to gain leverage over you to see if they can low-ball you, don’t tell them.

Rather tell them:

I don’t feel comfortable talking about the internals of my current working arrangement out of respect to my current employer.

Or just be blunt and say:

I don’t see how my current salary factors into these discussions. Let’s find out if we are a mutual fit first.”

The goal is to get them to make an offer first. That offer will be in the middle range of what they can offer you and you can negotiate up from there.

2. Always be negotiating

Always negotiate. Not necessarily because you need the money but because it represents your value at the company. It is a matter of respect and it influences how you are perceived at the company.

3. Start negotiating when you receive an offer

Since you are not giving them a number, they will make an offer. Here is where you start negotiating. At this point it is highly unlikely that they would reject you for negotiating. They simply invested too much into you already. Take your time, maybe say you have to talk it over with your spouse, or that you need to read through it in peace.

Then you could say that the offer is “interesting” but not quite there to get this done. Ask if there is flexibility on that number. They might make you another offer that is higher and that they can’t go any higher. This is where you can tell them that this offer will work if they can throw in a few more vacation days or something like stock options etc. As @patio11 puts it in his article:

You Have A Multi-Dimensional Preference Set. Use It.

This kind of tactic should get you to the high end of what is possible to get for your position. This will make you feel good and strengthen your position in the company from the get go.

To be honest, I think it is a flaw in the system and really uncomfortable that one of your first interactions with your new employer is of this nature.

There are rare cases in which it’s done differently. Basecamp for instance pays everybody the same competitive salary based on job title and current market situation. You should read their article about it, it’s such a refreshing take on this matter.

If you want to get deeper into this I highly recommend you read @patio11’s article that I mentioned a few times already. He links to more resources as well.

Happy negotiating!

Just Fucking Ship Taught Me How to Ship Blog Posts

Just Fucking Ship by the most excellent Amy Hoy is a great book. It’s about how to bootstrap and ship any (side-)project.

The most valuable part of the book for me personally was how she describes outlining a blog post.

I always thought outlining a post was to come up with some high-level headlines. That never really helped though, because they were too high-level and I was still busy working on the structure of the blog post on the fly while filling in the gaps between the headlines.

No, what I learned from Amy is that you have to write down each and every thought that you want to put into that post. Write them down, fuck structure, fuck grammar, fuck spelling.

Put it all on (virtual) paper. Now that you did that you can look at it and move your points around, give the whole thing some structure, delete some, add some.

Once you are happy with that, you go ahead and write the blog post. At this point its super easy because all you need to do is write it out, you are not structuring it while you write it anymore.

This makes so much sense because it completely separates writing a blog post into two smaller isolated steps:

1. Determine content & structure
2. Write it

Take this here blog post for example. When I first started writing it I started with a big introduction about the book and Amy and bla and immediately I got bored of my own words.

That made me stop and think again: what is it really I want to convey with this post?

1. Just Fucking Ship is great
2. Here is why it was great for me

So I deleted everything and just wrote Just Fucking Ship is a great book and went on writing about my greatest take-away from it.

I feel like it makes this post much more meaty and interesting for somebody to read. It definitely is much more fun to write.

For closing I would like to add that there are also many more surprising tips in that book to help you finally start and also actually ship your side project.

But instead of telling you what they are I would rather you go and support Amy Hoy and get yourself the book! It’s a really quick read and it is worth it.

Vimming in the Squasher: How to Squash Your Commits with VIM

Whenever I use git rebase -i to squash commits, Git opens the squasher (that’s how I just named the text view for the interactive rebase) in VIM.

My knowledge of vimming is not very great so I used to just type i and then inch around with the arrow keys and delete character by character in order to delete the word “pick” a bunch of times and then type “squash” a bunch of time.

Of course that was incredibly annoying, so I finally looked up how to vim in the squasher and it is glorious. So here is how you do it:

First, move to the line with the first commit you want to squash, which is typically the second one.

Then, enter into something called visual block mode (WTF?! What does that even mean?) by hitting ctrl + V. Something magical happens: when you move the curser it blocks out every character you move over with white and if you move down it will cover as many characters you covered in the line above. It looks like blocks. So I guess that’s where the “visual block” comes in 😅.

Select all the rows you wish to squash while visually blocking out the word “pick”.

Now, more magic: hit C and type the word “squash”, after that hit esc and see the word “squash” applied in all places that were “visually blocked out”.

If you only could exit VIM at this point, you would actually successfully squash all these commits. A boy can dream, right?