Author Archives: Mark

About Mark

Ten years into my journey towards becoming a pro systems programmer, sharing what I learn along the way. Also on Twitter: @offlinemark.

If you're reading this, I'd love to meet you. Please email mark@offlinemark.com and introduce yourself!

How to build traction for your creative endeavor

Leave a reply
: _Micropost 🍪, Creativity

Core cycle:

  • Try hard at something (bonus if it’s hard)
  • Share it, enthusiastically, in public
  • Repeat every week*

Bonus: Find likeminded peers and become good friends with them.

*A week strikes a good balance between consistency and workload.

Plus:

  • If it’s not working, shake it up somehow
    • Try different content
    • Try a different format
    • Try a different venue
    • Intentionally try to improve at the craft
    • Imitate people 1-2 steps above you
    • Artistically steal for everything except the key area of creativity & innovation

This advice comes from a decade+ at failing to build traction for my endeavors, with small pockets of success here and there:

  • Then Tragedy Struck (instrumental metal) — Little traction
  • comfort (wave / trap music) — Medium/little traction
  • timestamps.me — Little traction
  • offlinemark (2012-2019) — Little traction (Twitter)
  • offlinemark (2019-2023) — Medium traction (Blog, Twitter)
  • offlinemark (2024+) — High traction (Youtube)

7 steps towards learning something

Leave a reply
: _Micropost 🍪, Software Development

Here’s my rough mental model around learning things in the world of computer programming:

  1. Never heard of it before
  2. Heard of it, but don’t know what it is
  3. Know what it is conceptually, but not how it works
  4. Know how it works, but never implemented it
  5. Have implemented it, but just for fun, not in production
  6. Implemented something in production
  7. Applied concept creatively in a novel fashion (mastery)

Find your own bugs

Leave a reply
: _Micropost 🍪, _Tech 💻, _Twitter Archive 🐤, Open Source, Software Development

Audio version: https://podcasters.spotify.com/offlinemark/episodes/Find-your-own-bugs-e2i15vc

Contributing to open source is a popular recommendation for junior developers, but what do you actually do?

Fixing bugs is a natural first step, and people might say to look a the bug tracker and find a simple bug to fix. However, my advice would be to find your own bugs.

In 2019, I had some free time and really wanted to contribute to the LLVM project in some way. Working on the actual compiler seemed scary, but LLDB, the debugger, seemed more approachable.

I went to the LLVM Dev Meeting, met some LLDB devs, and got super excited to contribute. I went home, found a random bug on the bug trackers, took a look for all of 30 minutes, then … gave up. Fixing some one else’s random string formatting bug simply wasn’t interesting enough to motivate me to contribute.

3 months later I was doing some C++ dev for fun. I was debugging my code and ran into a really, really strange crash in the debugger. It was so strange that I looked into it further and it turned out to be a bug in LLDB’s handling of the “return” command for returning back to the caller of the current function. The command didn’t correctly handle returning from assembly stubs that don’t follow the standard stack layout/ABI, and caused memory corruption in the debugged process which eventually led to a crash.

This was totally different. I had found a super juicy bug and dedicated a couple weeks to doing a root cause analysis and working with the LLDB devs to create a patch, which was accepted.

So if you want to contribute to open source, I would agree with the common advice to fix some bug, but would recommend finding your own — it will be way more rewarding, fulfilling, and a better story to tell.

—

https://twitter.com/offlinemark/status/1778483168611610940
https://twitter.com/offlinemark/status/1208491737099882496

Why I use 5 different git clients

Leave a reply
: _Micropost 🍪, Git, Software Development

What if I told you you didn’t have to use just one git client? I use 5, and here’s why:

  1. Command line – Sometimes it’s the simplest fastest way to do something.
  2. Lazygit – Ultra-fast workflow for many git tasks, especially rebasing, reordering, rewriting commits. Quickly doing fixup commits and amending into arbitrary commits feels magical. Custom patches are even more magical.
  3. Fork (Mac app) – Great branch GUI view. Nice drag and drop staging workflow.
  4. Sublime Merge – Good for code review, can easily switch between the diff and commit message just by scrolling, no clicks.
  5. Gitk – Great blame navigator.

One you try one of these GUIs, you’ll never go back to git add -p.

Toxic minimalism

Leave a reply
: _Micropost 🍪, Life

If you’ve ever had a painful move due to having too much stuff, you might have had the urge to become a minimalist to avoid an unpleasant experience like that again.

There’s a lot of good things about minimalism and the philosophy of needing less. In addition to being easier to move, it’s better for the environment, and less costly to have & maintain less things.

But watch out — it’s easy to go too far in the other direction and let the minimalism take on a toxic quality, where you don’t even acquire things that you really would find helpful, and would improve the quality of your life.

If you’re in that position, I’d just remind you that it’s ok to acquire a bunch of stuff, learn what is really valuable to you, then trim things down later. Sometimes to go narrow, you first need to go wide.

It’s worth writing, even if someone else covered the topic already

Leave a reply
: _Micropost 🍪, Creativity, Writing

It’s worth writing, even if someone else on the internet has covered the topic already, because:

  1. Writing helps you understand the topic better
  2. Your tone, communication style, or perspective might appeal more to some readers than the original source
  3. It helps build your public body of work, which makes you luckier

And writing is just an example — replace it with whatever form of self-expression you’d like.

Learning kernel development on hard mode

Leave a reply
: _Micropost 🍪, Streaming

When I started self-studying kernel development via MIT 6.828 (2018)’s open source materials (JOS OS), I thought I was making my life easier by not starting from scratch. Doing this allowed me to get going very quickly with a base skeleton for an OS, as well as a fully functioning build system and helper Makefile command for debugging with qemu.

That was great, but I’ve realized that there are also many ways I’m doing this on hard mode:

  • Doing it in only 2-3 hours a week
    • This is not really enough time to develop an OS, and is particularly hard for debugging, where it can be helpful to have significant context built up for longer sessions.
  • Live-streaming almost all of it
    • This can be very distracting and make me go at a slower pace than usual, since I try to engage with viewers and answer questons. On the other hand, explaining things helps solidify my understanding.
  • Working with a 6 year old code-base, but using a newer toolchain — which means fighting bitrot
    • There have been multiple cases where the codebase actually got in my way and produced very hard to debug bugs. Also, when I transition labs, it introduces a bunch of foreign code that I don’t understand. It can be difficult to tell if I truly have something broken, or if the new code is in an intermediate state that is meant to yield issues like crashes or assertion failures.

Don’t be afraid to reinvent yourself

2 Replies
: _Micropost 🍪, Blogging, Other, Streaming

In the past year I’ve effectively reinvented my public identity as a live-streamer. That wasn’t the goal initially, but it’s been one of the most fun journeys I’ve been on in a long time, and I’m glad I did it.

For many of the people discovering me now, that’s what they know me as, but what they don’t know is the 10+ years of public presence I had pre-streaming. Since 2012 or so, I’ve been on Twitter and blogging (to a lesser extent) as part of the tech & infosec scenes, sharing random projects I was working on, or things I learned about.

In 2019, I revamped my blog and wrote a few viral blog posts about Linux kernel internals. This was the start of reinventing myself as a blogger. Around that time I started posting a lot more on Twitter also.

And now in 2024, I’ve started streaming and funnily enough, that has had more traction for me than any other project I’ve had before. So I guess that makes me a streamer now — until the next self reinvention!

So, be careful of getting stuck in self identities that you’ve historically created, but don’t have intentional reasons to maintain. Don’t be afraid to try new things — even if they potentially reshape your entire identity.

Old tweets:

poet was a toy post exploitation RAT I developed for fun.

Removing dates from post URLs

Leave a reply
: _Micropost 🍪, _Twitter Archive 🐤, Blogging

Originally I used a YYYY/MM/DD/<slug> url scheme for my blog, which felt nice since it creates namespacing and one can also get some date context about a blog post simply from the URL.

However, I eventually removed all date context from the URLs entirely. Namespacing isn’t a real benefit in practice (name collisions are rare) and neither is date context. I also found it annoying that I couldn’t type post URLS from memory, which is occasionally useful. Plus shorter URLs is also often a plus.

To migrate to this new URL scheme without breaking links, I used the “Redirection” WordPress plugin. Yet another reason why I like WordPress.

This simple no-date naming scheme is also inspired by bloggers like Paul Graham, Patrick Collison, and Sam Altman.

Release it and move on to the next

1 Reply
: _Micropost 🍪, Creativity

A common artist pitfall is getting too stuck on a particular piece, which builds high expectations for it when it’s eventually released. It can be painful if that piece isn’t appreciated like you hoped it would be.

A remedy is to zoom out and maintain a global perspective over all the art you’ll release in your life. In the grand scheme, this one piece is hopefully a drop in the bucket of all the many other pieces you’ll make, some of which (hopefully) will be many times better than the one you’re stuck on. Staying stuck on one prevents you from moving forward to creating those amazing future works.

This advice doesn’t apply to every artist, but I think it does for many: Release it and move on to the next.