I've found being able to read assembly more useful than writing it.

For those writing in compiled languages like C/C++ and particularly with an interest in performance it's been very helpful just to be able to read compiler output and see what it's generating. Takes the guesswork out of it, removing the uncertainty by simply being able to see what the compiler is actually doing. You can just write code and see the result, who knew!. It's actually helped my understanding of C++ in seeing the bigger picture.

Of course it's also much easier to learn just to read a little disassembly than actually write the stuff. I'm sure I'm not alone in that for me Compiler Explorer (https://godbolt.org) was my gateway into this. You can get quite far even if just knowing the basics (I'm no expert).

The software security community has a subsection that focuses on the security of compiled binaries, where understanding assembly has many uses. These uses include binary reverse engineering and proof-of-concept exploit development to demonstrate the severity of a vulnerability.

If these do sound interesting to you, I'd recommend looking into capture the flag (CTF) competitions, and trying reverse engineering or binary exploitation (pwn) challenges. PicoCTF [1] is an entry-level platform that hosts challenges and has references to learning resources - I believe there's a sequence on assembly in the learning resources.

Aside, I also find it useful to know assembly when debugging C/C++ code, as others have suggested.

[1] https://play.picoctf.org

Assembly is one of those things where setting your ambitions higher than is usually advised can be wise.

You could try writing a game (perhaps using Raylib) or a pixel art editor. Or maybe a little web application for your Homelab.

Simple C libraries (Raylib, libcurl, early win32 APIs) tend to be dead simple to use from assembly.

Most asm tutorials are either bare metal / OS or “we will talk directly to the kernel”, but there’s no reason you can’t interface with higher level libraries and make real apps and games. It’s simpler than it sounds because a whole lot of your code will just be moving things around between registers and memory in order to make function calls and bookkeep your program state.

Yeah I think the only things that really need assembly these days are vector/SIMD (e.g. writing a video codec), really low level stuff for interacting with hardware (writing an OS) or if you're actually working on CPUs (how I learnt).

It's kind of useful for understanding compiler output on godbolt, and occasionally for debugging code without debug info.

But I successfully wrote a ton of C++ for decades without knowing assembly. It's not really necessary.

In embedded systems using MCUs with very little memory (AVR comes to mind) assembly might be preferred over high level languages (very generously counting C as HLL here). It might even be fun (for truly launch-and-forget projects -- don't even think about maintaining such code) to forgo structured programming and get creative with control flow and self-modifying code.

As a systems engineer it's good to know _some_ x86-64 assembly as sooner or later you're facing a stack trace / register dump and will have to try to make sense of it. Personally, I would take it only further, if you're interested in building compilers.

As an odd twist to the whole assembly vs. HLL dichotomy, sbcl is used by some as assembly playground: https://pvk.ca/Blog/2014/03/15/sbcl-the-ultimate-assembly-co...

FFmpeg uses assembly and they use it so extensively that they put up their own assembly tutorial: https://github.com/FFmpeg/asm-lessons

Maybe there is something to do there (I haven't checked).

TIS-100 is a fun little game where you have a sort of pseudo-assembly and solve puzzles with it. I find it can help scratch that itch.

Microcontroller and LEDs. And maybe buttons. Keep it to 8-bit and chances are you'll be able to navigate the ISA comfortably pretty quickly.