Forem: Jacob Jerrell

Why are you using QWERTY?

Jacob Jerrell — Tue, 25 Nov 2025 13:36:51 +0000

Putting all arguments of ergonomics aside, just take a look at the top row of your keyboard and notice how all of the letters for the word "TYPEWRITER" are up there. That's how dated your keyboard layout is. One part solution to a long gone problem and one part sales gimmick.

Somewhere around one-hundred years before the Epoch Date, typists became quite efficient simply using two rows of keys from A-N and O-Z. So efficient, in fact, that they would commonly cause jams with frequently used pairs. In the 1870's, Remington entered the scene and began gradually developing the layout used by a majority of us today.

Now, you can hardly shop for a desk without finding some mention of ergonomics. So we buy the desk -- a glorified piece of wood -- and place a keyboard with an archaic layout on it. QWERTY isn't for humans, it's a workaround for mechanical bars which are far removed from the mechanical keyboards of today.

We're long overdue for reconsidering the dominant keyboard layout of today. We could easily forgive the first 60 years of the 1900's if we wanted to. But there really is no excuse. By 1893, the Blickensderfer typewriter was unveiled to the public with the keys "DHIATENSOR" positioned on the home-row. QWERTY was still an option, but consumers were made to sign a statement acknowledging that they were purchasing an inferior product.

The most commonly known alternative to QWERTY, "Dvorak" was introduced as early as 1932 and patented by 1936. Still yet, nearly 100 years later, nothing has really put a dent in QWERTY's market dominance.

Alternatives

Ranked by adoption numbers, Dvorak still has the majority of the minority due. This popularity is largely owed to old-school.

Next up would be the Colemak layout which was introduced in 2006 and is supported "out of the box" by almost every major operating system. Compared with QWERTY, 17 keys have changed locations. Cut/copy/paste (x/c/v) maintain the same positions, as do the comma and period keys. The colon is shifted up to the top row so that your home row is fully populated by alpha keys.

Barely escaping the realm of niche layouts, we have Workman being introduced in 2010. It's supported out of the box in Linux/X11 and is easily installed on other common OS's.

Beyond those, you'll find hobbyist keyboard layouts such as: Norman, Asset, and Engram. Finally, you'll descend into absolute niche layouts such as the Neo layout.

Transitioning

This is the "gotcha". Your transition must be deliberate and practiced. Your typing speed will reduce temporarily and in all honesty, it won't be comfortable. The first time you're forced to use QWERTY again, it won't quite be like riding a bike--for a while, at least.

You can't simply pluck the keys out of most laptops and rearrange them for visual reference. If you already primarily use a mechanical keyboard, your life will be simpler. If your mechanical keyboard can truly be programmed, even better.

My Experience

I began transitioning around 2018 while I was in a startup-themed "Skunkworks" organization. I was working long hours and typing A LOT on a laptop keyboard. I really began to question my T-Rex pose and attributed it directly to the constant pain I was feeling in my wrists and fingers.

By this time, I had been using QWERTY for more than 20 years and thanks to an IT teacher's persistence, I had been using it "appropriately" for about 13 of those years. Frankly, I disagree with forcing students to "home" on QWERTY... "floating" is definitely going to lead to less injury. I digress, I hold no resentment to the teacher who forced me to "home" because now I rarely leave it.

It was hard to ignore the popularity of split keyboards, Microsoft and Logitech both had popular ones on the market. But I was acutely aware of the fact that, despite being trained, my left index finger still reaches for the "Y" key--present tense because I'm using my laptop with a QWERTY layout in the moments of typing this paragraph and notice that the left index even reaches for the "h" key about half of the time.

Long story short(er), I can't solder. So I decided on the Ergodox EZ by ZSA; it's a split keyboard, columnar instead of staggered, and programmable. The last part was important because I had decided the Workman layout was for me and I didn't want to worry about whether the computer I was plugging into could support it or not; all of the logic is at the hardware layer. The QMK Firmware also offered to solve a handful (hah) of other problems: home-row modifiers, layering, macros, Hyper/Meh modifiers, and quite a lot more than I've even scraped the surface of.

Timelines

While waiting for my order to arrive, I spent evenings using The Typing Cat, which allows you to "emulate" alternative layouts. My fingers rebelled against me for a week or more.

Within a month, I could barely use QWERTY and my typing speed with Workman was about 25-35 WPM--abysmal, in my opinion. I could do fine while coding, but I'd just about get up and walk across the office before trying to engage in a conversation over Teams or Slack.

After the first month, I became quite comfortable with my choices. The new keyboard was fantastic, my thumbs were in charge of Enter, Tab, Space, Backspace, and layer changing. All modifiers were on the home row (mostly) and my left pinkie retained the traditional Shift-key location.

For some period of time, texting was mildly uncomfortable. But to this day, I haven't found a suitable keyboard app on Android or iOS which is worth the trouble for having Workman available there.

Within the second or third month, I had to visit a client site and my only option was to use their keyboards. It surely seemed like the expert they knew a year before must have had a seizure--It's not a laughing matter but I don't know how else to describe it.

Finally, around three to four months, I just needed to look at the keyboard I was using, take a deep breath, and I could use either layout comfortably. By now, it's all muscle memory; QWERTY works just fine for recliner typing and nicely reminds me why I switched.

At the end of the day, my keyboard layouts resemble the layering theories shown in the Neo layout. But the home layer is Workman.

Your Experience

Whether you turn this into a hobby as I have or simply reconfigure your OS to use an alternative layout, you absolutely should invest the time in yourself. I probably don't know you and it won't benefit me at all if you change layouts. But it will help you a lot.

If pure statistics are your driving factor, I encourage you to explore the website describing the Workman layout. It does a great job of highlighting the scores of the four main layouts I talked about here.

I know of people who have learned multiple and can likely switch between at least three different layouts, but I recommend researching first, deciding on one, and sticking with it until you're good and comfortable with it.

If you find yourself down the QMK rabbit hole, it used to be a lot easier to find inspiration. But due to the number of PRs and total size of the firmware repository, they've adopted a "user space" approach. Take a look a Drashna's Userspace for a very advanced users setup. Follow the firmware documentation if you want to start building your own

Lambda's in Kotlin

Jacob Jerrell — Mon, 24 Nov 2025 19:18:19 +0000

Once you understand them, they seem so simple and you wonder how you ever had a problem with them. Early in my career, I definitely spent countless nights studying and trying to wrap my head around lambda's in Swift; terrified to tell anyone that I struggled to understand them.

Years later, I've come to find that it's a very common place for even seasoned engineers to get stuck on, especially if their early experiences were with a non-functional language. I'm here to hopefully dispel some of the confusion surrounding them.

In short, they're just functions that you can pass around. They can be used for configuration, dependency injection, and when using Jetpack Compose, they're highly recommended for use in State Hoisting.

For Java Engineers

Perhaps most recognizable for Java engineers are callbacks implemented as SAM interfaces. A few recognizable examples standout as still being widely used within Kotlin today:

Runnable: void run()
Callable<V>: V call()
Comparator<T>: int compare(T o1, T o2)
Consumer<T>: void accept(T t)
Predicate<T>: boolean test(T t)
Function<T, R>: R apply(T t)
Supplier<T>: T get()

Simply put, they're interfaces annotated with @FunctionalInterface. They have a single function and look like this:

@FunctionalInterface
public interface ConfigurableAction {
    void execute(View view, String data);
}

A custom MaterialButton in Java using the interface would be written this way:

public class ConfigurableButton extends MaterialButton {

    private ConfigurableAction action;
    private String data = "";

    public ConfigurableButton(Context context) {
        this(context, null);
    }

    public ConfigurableButton(Context context, AttributeSet attrs) {
        this(context, attrs, 0);
    }

    public ConfigurableButton(Context context, AttributeSet attrs, int defStyleAttr) {
        super(context, attrs, defStyleAttr);

        setOnClickListener(new OnClickListener() {
            @Override
            public void onClick(View v) {
                if (action != null) {
                    action.execute(ConfigurableButton.this, data);
                }
            }
        });
    }

    public void configure(String data, ConfigurableAction action) {
        this.data = data;
        this.action = action;
    }
}

An early Java implementation would have you configuring the button as an anonymous class; using the new ConfigurableAction() and override approach:

button.configure("user_123", new ConfigurableAction() {
    @Override
    public void execute(View view, String data) {
        Toast.makeText(this, "Data: " + data, Toast.LENGTH_SHORT).show();
    }
});

If you're using Java 8+, the IDE would likely suggest that you implement it as a lambda; which really just means you remove new ConfigurableAction() , the function override, and bring the parameters from the execute function up to the where new ConfigurableAction() was previously:

button.configure("user_123", (view, data) -> {
    Toast.makeText(this, "Data: " + data, Toast.LENGTH_SHORT).show();
});

In Kotlin, with the interface being the last parameter of the function, we can make it look a little nicer:

button.configure("user_123") { view, data ->
    Toast.makeText(this, "Data: $data", Toast.LENGTH_SHORT).show()
}

The previous three snippets are equivalent. The second snippet is nearly perfectly valid Kotlin code:

button.configure("user_123", { view, data ->
    Toast.makeText(context, "Data: " + data, Toast.LENGTH_SHORT).show()
})

The third snippet is the result of taking the IDE's suggestion for moving the lambda argument of the most recent example out of the parenthesis.

For Jetpack Compose Engineers

Life gets a whole lot easier in a lot of ways with Kotlin. Jetpack Compose is just the chef's kiss. The same interface and button from the Java example implemented in Kotlin and as a Composable is simply this:

fun interface KConfigurableAction {
    fun execute(data: String)
}

@Composable
fun ConfigurableButton(
    modifier: Modifier = Modifier,
    data: String,
    action: KConfigurableAction
) {
    Button(
        modifier = modifier,
        onClick = { action.execute(data) }
    ) {
        Text("Click me!")
    }
}

A view implementing the above button would do it this way:

@Composable
fun ButtonView() {
    val context = LocalContext.current
    ConfigurableButton(
        data = "Foo"
    ) { data ->
        Toast.makeText(context, "Data: " + data, Toast.LENGTH_SHORT).show()
    }
}

But wait. We don't actually need the fun interface (Kotlin's way of dropping the need for an annotation for a common use case) at all and it's probably just going to be confusing and seem like a waste of keystrokes (it is) for the majority of engineers who've had the pleasure of working with Kotlin for a decent amount of time. So we would simply implement ConfigurableButton with a lambda in the signature and never consider an interface for this scenario:

@Composable
fun ConfigurableButton(
    modifier: Modifier = Modifier,
    data: String,
    action: (data: String) -> Unit
) {
    Button(
        modifier = modifier,
        onClick = { action(data) }
    ) {
        Text("Click me!")
    }
}

With the above implementation, ButtonView doesn't change at all; it perfectly understands that it has a matching signature.
Since the base Button's onClick parameter in Compose doesn't expect an argument and you may not always need one, another sample button could be created like:

@Composable
fun ConfigurableButtonToo(
    modifier: Modifier = Modifier,
    action: () -> Unit
) {
    Button(
        modifier = modifier,
        onClick = action
    ) {
        Text("Click me!")
    }
}

Notice how action is just passed directly to the onClick parameter without any curly braces at all. This would still be perfectly valid though: onClick = { action() }, it's just another waste of keystrokes.

To close out this section, we can simply say that if two lambda's have the same signature you can just pass one into the other without using curly braces or parentheses at all. If they have different signatures, you'll need to expand the receiver with curly braces and populate the parameters.

Advanced Usages

One thing that really strikes you as odd the first time you see it is that you can directly reference a function, perhaps from a ViewModel, and use it as a value for the lambda. Consider the following example where the ViewModel has a function with a signature matching Button's onClick parameter:

class ButtonViewModel : ViewModel() {
    var data: String by mutableStateOf("")
        private set

    fun onSetData() {
        data = "Primary button clicked!"
    }
}

@Composable
fun ButtonView() {
    val viewModel: ButtonViewModel = viewModel()
    Button(
        onClick = viewModel::onSetData
    ) {
        Text("Primary button")
    }
}

Notice the double colon's which say "go to this class and use this function as the lambda." Not being aware of this capability, you would be inclined to just open curly braces and call the ViewModel's function "appropriately", which is still perfectly valid and the IDE won't make a suggestion at all (currently, at least):

@Composable
fun ButtonView() {
    val viewModel: ButtonViewModel = viewModel()
    Button(
        onClick = { viewModel.onSetData() }
    ) {
        Text("Primary button")
    }
}

But once again, why use so many keystrokes and reach for those symbols while the colon is resting under your pinkie finger? Unless you've moved away from QWERTY (as you should) and your layout has the colon elsewhere… which I'm sure is still more convenient than curly braces and parentheses.

In Conclusion

I hope you enjoyed reading and learned a thing or two. If you have questions, comments, or a request for understanding a more complex use case, please feel free to let me know!