DEV Community: Kahlil Lechelt

Run your day, don’t let the day run you

Kahlil Lechelt — Wed, 02 Mar 2022 09:27:04 +0000

When I transitioned from software engineering to engineering management I had a difficult time adjusting to the new job. As an engineer, I let the day run me. I did not proactively plan my day or my week. I worked on my sprint tasks when I had no meetings and joined meetings when I had to.

That is a common way of working as an engineer. You want to do your work and try to maximize your time to code and try to get into flow state. This can work out fine.

I continued with that basic framework as an engineering manager out of habit and it did not work.

By letting the day run me I was sitting in meetings almost all the time, never got into flow state and just reacted to things. I barely had time to do any proactive, strategic work and when I had some time I feverishly caught up on outstanding todos.

Picture of a 45 inch record of Flourgon’s number one hit “We run things”
The lyrics in We Run Things by Flourgon lead to the solution to my problem. Just turn it around.
In 1988 Jamaican artist Flourgon landed a number one hit with “We run things”. In the chorus he used the Jamaican proverb:

We run tings, tings nuh run we.

In the spirit of these wise words, the solution to the problem was for me to start to run my day. Doing so basically means to take control of your calendar and live by it.

Every day I switch my calendar into day-view and clean it up. I Reject any meetings I don’t have to participate in, resolve parallel meeting conflicts by rejecting or moving meetings that I can’t attend and schedule things I want to get done in the remaining free areas of the day.

Using your calendar and scheduling everything you want to do in there is a major productivity practice taught by many productivity experts. Ideally you work on one thing at a time and plan beforehand when to do it.

Taking control of your calendar has little value if you are letting Slack and email constantly distract you from what you are trying to do. Checking your messages is also work that should be scheduled.

My Slack notifications are always turned off. I schedule time to check Slack and answer messages. Sometimes I just quit Slack to make sure I am not distracted by attempts of the lizard brain to quickly switch over and see what is going on in there. The same setup goes for email.

The last ingredient needed to run your day is to keep a todo list. This is something I never needed as a software engineer. Every attempt of using a todo list ended in todos rotting away somewhere in different todo apps, never reviewed, never checked off.

As an engineering manager I find myself inundated with little tasks I need to do or little to big things I volunteer to do for my direct reports or my manager. In order to not forget 90% of these things I have to write them down. I use Things for that.

I use a global keyboard shortcut to capture every single thing I need to do in my Things Inbox. On a daily basis I do a review of the todos. Sort them into the right areas (typically just “Work”) and prioritize them.

When it comes to prioritization I learned that it really helps to focus in on the 1-3 tasks you really and truly want or need to get done today. Add them to your Today list and makes sure you definitely do them. Repeat every day.

To be honest I am quite bad at reviewing my todo list every day but when I fall off the wagon I just pick up from where I left off. I go through the list, check off everything that is already done, delete every todo I don’t need anymore and proceed to prioritizing the top 1-3 items.

When sorting todos I also use Things’ scheduling features for items I don’t need to think about now so that they are out of my face.

This technique really helps to deal with the emotionally overwhelming aspect of growing todo lists. And this is where we go full circle and come back to the calendar because the work items that you schedule for your meeting-free time should be the top priorities from your todo list.

So this is how you run your day.

To summarize, the first rule is to make your calendar the single source of truth for anything you do today and live by it. Second, one must turn off all notifications and any other distractions, schedule message checking and answering as per the first rule. And the third rule is to keep, review and prioritize a todo list, schedule top priorities as per rule one.

Volta

Kahlil Lechelt — Wed, 15 Jul 2020 00:00:00 +0000

This post is about Volta and why it should be the first thing you should install on your machine as a JavaScript developer. This is how the Getting Started guide describes Volta in different places:

Volta is a hassle-free way to manage your JavaScript command-line tools.

and

Volta solves the problem of global packages

and it can

Managing your [JavaScript] toolchain

The first time I landed on the page I had problems really understanding what the Volta’s value was just by reading the descriptions. Somewhere in the docs they are talking about the “JavaScript toolchain”. I never used that term before. What does it mean?

What is the “problem of global packages”?

The definition of “JavaScript toolchain”

In order to understand which problem Volta solves, let’s define what they mean by “JavaScript toolchain”.

The JavaScript toolchain that Volta manages for you consists of all the tooling that you need in order to run and install JavaScript packages as well as globally installed command-line tools.

You can categorize these tools into three categories:

The runtime, that would be Node.js
JavaScript package managers, that would be npm and Yarn
JavaScript CLI tools, that would be any globally installed npm package binaries

The problem of global packages

The problems of global packages are slightly different for the three categories mentioned above.

Node

The problem with a global JavaScript runtime is that you have to switch the runtime globally per project if you need different Node versions for different projects.

This can be done via a script whenever you enter the directory via command-line but the switch can be slow and any global packages you installed for one version are now not available anymore or might break because they depend on a specific version to work.

Package managers

A certain Node version comes with a certain npm version. Yarn global installs might require a certain Node version or just possibly not work with a certain version of Node.

Some projects might need different versions of package managers because they might rely on features that are differ between the version.

Global npm packages

For globally installed npm packages or JavaScript CLI tools as you might call them, the problem can be either of two things:

It is installed for the currently active Node version. That means it is not available when you switch to a different version.
Or it just uses whichever Node version is currently active which creates reliability issues because it might not be compatible for this version. In some cases it even needs to be recompiled.

Volta solves all of this and gets out of your way. Let me tell you how.

How Volta manages Node

Volta allows you to install Node via the Volta CLI.volta install node installs the latest LTS version of Node. You can also install a specific version with volta install node@10.15.3 for instance.

Whenever you run a Node program it will use the latest version you installed. If you need to use a specific version of Node for a project you can pin the currently active Node version to the project’s package.json with volta pin node or a different Node version with volta pin node@10 for instance.

From this point on all Node programs and locally installed npm packages that are being executed in this project are run on that pinned Node version and nothing else.

The pinning is nothing else besides an entry in the package.json. This means you can easily change the Node version by hand at any time if you want.

When you share this project via GitHub any other team member that has Volta installed on their machine will also automatically use the pinned Node version in that project. Volta will just go ahead and install it if you don’t have that specific version installed yet.

This is huge for teams. As long as Volta is installed everywhere it just takes care of using the right version per project and gets out of your way.

Many times I have experienced onboarding team members running into problems or experiencing inconsistencies because they were using a different Node version in a project.

How Volta manages package managers

Package managers can be installed and pinned per project with Volta.

On first install of a package manager Volta installs the latest stable Node version with it and binds the two so that the package manager works forever.

Via volta pin you can pin the package manager and desired version to a JavaScript project.

How Volta manages JavaScript CLI tools

Volta allows you to install any JavaScript CLI tool and will make sure it works forever once installed. If you want to install Sindre Sorhus’ tremendous Trash CLI tool you can do that by typing volta install trash-cli to use it.

Volta installs the latest LTS Node version with the tool if that version of Node was not installed yet and will always run the tool on that version of Node forever. No matter which version of Node you are using in your current project.

When you use a different Node version manager or install your Node versions globally yourself you can never be sure if all your CLI tools are working.

How it all works together

Once Node and package manager are pinned for a project and Volta is used by all devs on your team and your CI/CD automation, all weird bugs and weird behavior caused by incompatible Node and package manager versions are completely eliminated.

This tool unlocks extra stability levels for the JavaScript dev and essentially makes the toolchain much reliable.

Meaning: if your setup worked once it will definitely work again later. No matter what you globally install for other projects.

It’s one of the first things I install on a fresh system. I highly recommend you have a good look at Volta.

And on top of everything it is wicked fast because it’s written in Rust and Rust compiles down to a native binary.

I am an engineering manager now

Kahlil Lechelt — Thu, 23 Jan 2020 13:29:08 +0000

Last year my manager quit. I was offered his position and since December or so, I am an engineering manager.

It is strange to move from a well-defined role into such a hazily-defined one.

A few things have changed. I don’t code anymore at work and the relationship to my team has changed. Especially to those who now report to me.

I want to be the best possible manager to them that I can be, so I am busy learning.

My friend Henning Glatter-Götz recommended the Managing Up podcast to me. I have listened to a bunch of episodes so far and it has been very helpful already.

If you are an engineering manager or are interested in becoming one, I highly recommend you check out Managing Up.

So far, my favorite episodes are:

Episode 5: One on Ones: The Basics

I loved hearing about how they approach their one-on-ones and about their different techniques on how to ask questions. It was also really great to learn how commonplace one-on-ones are in engineering organizations.One thing that surprised me was that it seems to be common to have weekly one-on-one meetings. We do it bi-weekly at LogMeIn. I think that it’s a good frequency if the one-on-ones are not skipped.

Episode 26: Creating Self-Managing Teams

This episode really exposed the experience the co-hosts of the show have. They are very open about mistakes they have made in the past and discuss how you might achieve “managing yourself out of a job”. This is a phrase that I have been thinking about a lot myself and I feel that should definitely be an engineering managers goal.

Build a Slack slash command app with Zeit’s Now

Kahlil Lechelt — Mon, 08 Jul 2019 07:29:08 +0000

First of all: Now is so flipping great it’s not even funny. Basically it is this:

You write your app, type now and it's deployed. You get back the URL under which it is deployed and that’s that. Every other deployment results in a new deployment under a new URL.

The latest deployment is always aliased to a URL that doesn’t change and that’s the address to your app or API.

If you hook up Github, your branches get deployed automatically as immutable deployments. The alias of those deployments contains the branch name. Every push results in a new deployment.

Now is a perfect fit if you want to create a slash command app for Slack.

Slash commands are super simple. When you send off a message like /mycommand yey all the command does is sending a post request over to a URL with your command and then prints out the response to you in Slack.

I used Micro (also made by our buddies at Zeit) to set up the API. Micro is a small no-config Node tool that allows you to create a microservice in no time. Write the function that takes the request and start the microservice with the micro command and you're good to go.

Now comes with initialization templates that have configurations for different tools, frameworks, static site generators, etc. One of them is called node-micro which configures Micro for Now. In order to use it, type now init and then choose node-micro.

It works out of the box. If you start the now dev and curl localhost:3000 you get the hello world message as a response.

You can deploy that by just typing now on the terminal or by hooking up now with your GitHub repository.

Next, configure your Slack slash command. Give it a name and a slash command and the endpoint URL. In our case it would be the alias that was generated. The alias always points to the latest deployment.

When you use that slash command it will post back that hello world message back into your Slack chat as a response.

Now you are ready to take over the world with your Slack slash command!

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

Kahlil Lechelt — Fri, 07 Jun 2019 09:33:30 +0000

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

Kahlil Lechelt — Tue, 07 May 2019 09:30:59 +0000

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 schaffolds 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 let’s 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

Kahlil Lechelt — Tue, 02 Apr 2019 06:08:50 +0000

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.

How to Force Your Brain to Be Creative

Kahlil Lechelt — Fri, 08 Mar 2019 12:13:02 +0000

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.

If you want to be productive and inventive, set constraints.

Like a time limit or a specific set of tools.

The Ultimate Recipe to Attract an Audience on the Internet

Kahlil Lechelt — Fri, 01 Mar 2019 14:38:03 +0000

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

Kahlil Lechelt — Thu, 21 Feb 2019 21:57:12 +0000

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

Kahlil Lechelt — Wed, 06 Feb 2019 13:28:19 +0000

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

Kahlil Lechelt — Tue, 22 Jan 2019 10:43:02 +0000

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: