The problem with dynamically typed languages is that they favor the developer who writes the code at the expense of the person who will maintain it. This is exactly the opposite of what we want.

A challenging space, but if anyone can do it it’s JetBrains. yaml, though? I hope the guys working on this project have read the Kobalt codebase and consulted @cbeust Also, Gradle is Kryptonite to JS devs

Don't worry about your code being fast until you have irrefutable proof from your profiler that it is slow.

Rough around the edges but added Wasm based Compose for Web client to the Chip-8 KMP sample (github.com/joreilly/chip-8) cc @bashorov Right now it's loading Space Invaders ROM by default but should work with others ones as well (was cool to see btw how straightforward it was to load that file using Compose resource() API) Think I need to make some changes to implementation of virtual game CPU/Clock (for project in general) but seems to work reasonably well.

My dear friend and incredible coder Bob "crazybob" Lee was stabbed to death last night in San Francisco. I just cannot comprehend this news. It is such a loss, we will miss his brilliance and kindness. I know I will.

Today is a great day to publish all your private projects containing code you haven't had time to polish. If you get made fun of, you can always claim it's an April's Fool.

Was inspired by this article to create a Wear OS client for github.com/joreilly/chip-8 #KMM sample! Not exactly perfectly suited to a device like this but it kind of works 😀 (repo is based on @cbeust's original chip-8 emulator project - github.com/cbeust/chip-8)

Chess engine update #6: linkedin.com/feed/update/urn…

Life is short. I'm fine with some yak shaving, but I want to pick my yaks. linkedin.com/feed/update/urn…

If your tasks spend most of their time waiting (e.g. I/O bound): use async. If they spend most of their time doing stuff (i.e. CPU bound), use thread pools. Discuss.

Chess engine report: linkedin.com/posts/cedricbeu…

Writing short, meaningful messages is surprisingly harder than dumping your brain into ten paragraphs. Once you dumped your brain, compress, shrink, get to the important part in as few words as you can.

Past a certain point, the difference between engineers (senior, principal, distinguished, ...) is no longer about tech but about soft skills. Teaching, communicating, influencing, documenting. Even empathy factors in. You can't lead if you don't understand whom you're leading.

The hardest part about teaching people what you know is remembering what it's like to not know what you today know. Most teachers fail this simple test.

What goes into "meat"? Well, that's a whole chapter book in itself. Are you writing to peers? Junior people? Senior executives? These are three different meats. Learn how to write different versions of what's in your brain. This is exceptionally difficult.

Structure. Written communication should follow the norm "Introduction. Meat. Conclusion". Write your text, but until you can fit it into this simple structure, refactor, refactor, refactor. And then finally send it.

You want an example? Sure! "i.e." is very different from "e.g.". Look that up! It takes two minutes to vastly improve your communication skills,

Want some examples? Sure. "e.g." is not short for "example". You don't say "for e.g.". You say "e.g.". I'll let you look up the exact meaning (based in Italian). Bottom line: if you're using a written form and you're not sure what it means, spend a few minutes and look it up.

"Who cares about the typos as long as they understand what I mean" means you are facing a concrete ceiling that will prevent you from getting that promotion to the next level.

Written communication is what differentiates a senior developer from a junior one. Grammar matters. Punctuation matters. Text structure matters. Short, concise communication to your peers (especially if above you) matters.

After writing a few emulators, I embarked on my next project: writing a chess engine. Early report: linkedin.com/feed/update/urn…