Category Archives: _Micropost 🍪

Tiny, short thought. Less polished.

Software engineers must learn to write

1 Reply
: _Micropost 🍪, Career, Writing

There is an immense amount of written communication involved in a programming job:

  • Commit messages
  • Bug reports & debugging discussions
  • Design documents
  • User documentation
  • Project documentation, READMEs, internal dev documentation
  • Project announcements
  • Comments & in-code documentation
  • Making complex situations simple for stakeholders
  • Handling support tickets
  • Mailing list discussions

Software engineers must learn to write well in the same way that they should also learn how to stay organized — they avoid doing so to their own detriment.

How I create so much content

1 Reply
: _Micropost 🍪, Blogging, Creativity, Meta

Between my two personal projects, I create a lot of content.

offlinemark:

  • Blog – Writing
  • Twitter – Shorter writing, writing meant to be seen more widely
  • Youtube – Educational content, screencasts
  • Podcast – Stories & lessons from my life, more personal

comfort (my music production project):

  • Music
  • Youtube – Educational content, screencasts on music production
  • Twitter
  • Instagram
  • Podcast

I also have a travel blog that I don’t share publicly.

Some of these channels are more active than others, but I have three principles that help me do it all.

1 – Harvest, don’t generate

I try to harvest content from what I experience & learn in my life, rather than sit down, brainstorm, and generate content from nothing.

2 – Respect inspiration

I’m significantly more productive when I’m inspired, so I try to treat moments of inspiration with great respect and get to work when they come. Sometimes this means being awake at 5:18am writing (as I am now).

Rick Rubin talks about this exact concept in “The Creative Act”.

I try to avoid queueing things at all costs; if possible I just sit down and do it now.

3 – Have buckets for everything

Different kinds of ideas naturally have a medium in which they are best expressed. Insights or essays are best expressed in writing. Educational walkthroughs are best done via screencast. Stories are best told via audio.

I try to have “buckets” (media channels) ready to receive ideas in their best form the moment they strike. This helps you harvest as much of your creative potential as possible.

For a long time, I left content on the table by not having a podcast for offlinemark. I regularly had stories I thought of and wanted to share, but simply had no great place for them, so they weren’t shared. Now that I have the podcast, I notice that I fairly regularly have a thought that is suitable for that medium, and can capture it.

Bonus: 4 – Default to public, and iterate

Don’t get tied up polishing content before you publish it. Default to publishing whatever you have, and remember: You can always polish, expand, or re-release content later. Defaulting to in public maximizes the potential for it to be discovered.

Bonus (Dec 2023 ):

5 – Never let an idea slip

If you’re going to create a lot of content, step one is to not needlessly throw away good ideas when you have them. Ensure that you have some system or tools in place for quickly capturing ideas wherever you might have them. I heavily rely on “Hey Siri, remind me…” on my iPhone which lets me quickly record notes to process later. I use Omnifocus as my todo app which integrates with this. Omnifocus and most other todo apps have a “Quick Add” global keyboard shortcut which is useful if you’re already on your computer.

6 – Not all content needs to be long

Not all blog posts or content needs to be long and arduous to write. In fact, it’s better if it’s not.

7 – Minimize friction

My current blogging setup with WordPress feels very friction optimized — I just browse to my blog, click new post, write, and hit publish. No command lines. No writing in a separate app, then copying the post over. In-place construction if you will.

8 – One-shot it

Get in the habit of “one-shotting” content — forcing yourself to “finish” it in some way in the same session of work. It’s incredibly tempting to leave a piece in a half-finished state and say that you’ll come back later. But rarely does that ever happen and adding things to todo-lists/queues adds weight to your life that doesn’t feel good. Plus, forcing yourself to finish is a creative muscle in and of itself that can be exercised and improved at. I’ve noticed improvement with this for me for music making and writing.

I started a podcast

Leave a reply
: _Micropost 🍪, Meta

You can find it here: https://podcasters.spotify.com/pod/show/offlinemark/

It’s an experimental home for content which favors the audio medium — mostly non-technical stories & lessons from my life. I will have audio versions of some of the blog posts here.

I was thinking about the growing number of publishing channels I now have and what belongs where. Here’s what I have so far:

  • Twitter: More polished posts that I feel comfortable directly sharing with a larger audience.
  • Blog: Home base for everything.
  • Youtube: Technical topics where screencasting is most natural
  • Podcast: Stories, life & career lessons, more intimate or personal topics

How to be happy

Leave a reply
: _Essay 📝, _Micropost 🍪, Favorite, Life

Note to self:

  1. Remember: You are already enough just as you are, right here, right now. You don’t need to achieve or do anything. 1
  2. Remember: The only competition in life — if you must think of it that way — is to know yourself as fully as possible, and act with maximum authenticity towards that truth.
  3. Remember: All things considered, you have it good — so many around the world would kill to switch places and inherit every single one of your problems.

It will never be easier than right now

Leave a reply
: _Micropost 🍪, Productivity

This is a mindset I use to help with procrastination. It first came to me in my senior year on university when I needed to do lab reports. At that point, I had been doing lab reports for 8 years — ever since the start of high school. And throughout that whole time, they were always excruciating.

But I realized that they were excruciating partly because I always waited until the days before the deadline to do them, which was about a week after the actual lab. By that point, the details of the lab were much fuzzier, making the lab report way harder.

It occurred to me that even though all I wanted to do after the lab is forget everything about it and push it off to the side, that exact moment — right after the lab — would be the easiest moment to ever do the report. As more time passes, it will strictly get harder as I begin to lose the context of the lab.

So I sucked it up and started to immediately go to the library right after the lab and simply do the report right then. It worked very well and I only wished I had started the habit years earlier.

I try to remember this lesson and apply it to my life now. If there are situations where I need to do something, and no additional information will arrive that will influence how the job gets done, I try to do it as quickly as possible to take advantage of the context fresh in my brain.

TIL: Debugging microcontrollers may require hardware breakpoints

Leave a reply
: _Micropost 🍪, _Tech 💻, Assembly

I was debugging a microcontroller recently and was surprised to see that I was limited to 4 breakpoints. That surprised me because I’m usually only used to seeing that kind of limitation when using watchpoints, not breakpoints. (See my youtube video for more on this).

But it makes sense after all — code running on this microcontroller is different than in a process in an OS’s userspace because the code will probably be flashed into some kind of ROM (Read Only Memory) (or EEPROM). Since the code is unwritable at a hardware level, the typical method of inserting software breakpoint instructions isn’t possible. So the alternative is to use the microprocessor’s support for hardware debugging, which occupies hardware resources and is thus finite.

What cured my writer’s/publisher’s block

Leave a reply
: _Micropost 🍪, Blogging, Creativity, Writing

I’ve managed to make writing fun again and have been publishing a lot on my blog lately.

It’s due to three reasons:

1 – Having explicit content categories creates the freedom to post things that aren’t highly effort intensive deep dives.

By introducing explicit post categories (i.e. Micropost, Lab Notes, Essay, Deep Dive, etc) I feel much more free to post without the expectation that every post needs to be a time consuming, deeply researched technical post (which are the kind of posts that are popular).

I don’t have time for those lately, but that doesn’t mean I can’t write or post anything! Explicitly tagging something as a micropost or lab notes takes a lot of the pressure off, and makes me much more willing to write and publish.

2 – I stopped sharing on Twitter.

The curse of growing an audience is that posting to that audience has increasing weight as the audience grows, which creates stress and friction about posting. What if I post something that people don’t like and I lose a bunch of followers? What if I’m straight up wrong? What if I want to share something but don’t have time to fully polish it and people judge me? What if I post too often?

It’s also distracting to share on Twitter, and very difficult to not monitor notifications afterwards.

Furthermore, writing on Twitter was actually difficult in that it took extra energy to abide by the character limits, or fit things into threads otherwise. Writing freeform of my own blog is easier in this regard.

Not posting on Twitter removes a nontrivial amount of friction and stress that used to prevent me from sharing.

3 – Using WordPress (i.e. not a static site generator) removes a ton of friction.

The fact that I can click buttons in a web interface, write and post as easily as sending a tweet makes all the difference.

It’s so nice being able to change the website without coding. For instance, I just added a “Popular posts” feature in the sidebar in the last 5 minutes. Turns out Jetpack already has the feature included and I just had to enable it. I don’t even want to imagine what it would have taken to implement that by hand or with a static site generator.

Though not as fast a static site, the blog loads fast enough and I’m more than happy to take the performance hit.

It’s also awesome that I can quickly edit posts to fix typos, even from my phone with the WordPress app. I do this very often.

(bonus reason: It’s also due to the realization that posts don’t have to be long, can be written in one sitting, and don’t have to be absolutely perfect!)

How to not feel dumb around “smart” programmers

Leave a reply
: _Micropost 🍪, Career

When going to programming meetups, conferences, or starting a new job, it can be extremely easy to feel dumb around other engineers there. Sometimes these engineers truly are geniuses, but many times they’re not as “smart” as your immediate imposter syndrome is leading you to believe.

My advice, especially for beginners, is to remember that these people are probably talking about a domain they are extremely familiar with, and have spent probably 1000x the time with than you. You probably have stumbled upon to a topic that they are specifically knowledgeable about, which gives the impression that they’re ultra smart (and you’re ultra dumb, for not knowing anything about it).

The key is to remember that this impressive depth of knowledge is likely limited in breadth. If you were talking about your domain, you’d might know a lot more than them.

It’s also easy to feel dumb when watching a conference talk. My trick here is to remember that the reason this person can speak so confidently about such a technical topic is because, again, they’ve spent 1000x more time on it than you have. They’re had their face pressed directly against this problem for a long time, which is why they know all this and can talk about it.

This comes from my experience:

  • Entering the programming world (feeling dumb at hacker club in college)
  • Enter the infosec world (feeling dumb at infosec conferences)
  • Going to conferences not directly in my expertise (i.e. the LLVM Dev Mtg)
  • Entering the audio programming world (feeling dumb at audio conferences)
  • Feeling dumb in many, many conference talks

Distance between application programming and standard library programming

Leave a reply
: _Micropost 🍪, _Tech 💻

This is a rough, potentially half-baked thought:

This might an interesting metric to compare programming languages: distance between application programming and standard library programming.

In general, standard library programming is more difficult than average application programming for any programming language. Or at the very least “different” in some way — language features used, programming style required, etc. That difference might vary depending on the language.

Mainly, I’m thinking about C++, where standard library programming requires expertise in C++ template meta-programming (TMP) (i.e. to implement std::variant), which is effectively an entirely different programming language, existing in the C++ type system. While many application developers may also be competent in TMP, there are many that aren’t (including myself). It’s possible to be a very productive C++ programmer, and STL user, without being an expert at implementing generic libraries using TMP.

Given this, my impression that C++ has a relatively high distance between application programming and stdlib programming.

Python of course also has some distance here. I’m not qualified to speak on it, but I can imagine it also involved more obscure language feature that do not occur often in normal app development. I would guess that this distance is less than C++.

Lastly, C is an interesting language to consider because it offers such a spartan feature set that there aren’t particularly that many more language features available to be used. (I’m probably wrong here and there are obscure things I’m not aware of, including symbol versioning for compatibility). But in general, my assumption would be that C has a some limited distance, given it’s restrained feature set.

Ultimately, this metric is probably impossible to quantify and may have limited value, but is something I find intriguing anyway if it were to exist.

“What could go wrong” considered harmful

Leave a reply
: _Essay 📝, _Micropost 🍪

The retort “What could go wrong” is one of my big pet peeves.

It’s often used in response to a failure of a complex system or operation. Sometimes the system had clearly poor design, making it warranted. But more often these comments reek of hindsight bias and carry an arrogance — as if the speaker could have easily avoided the failure if they were the one in charge.

It’s possible to construct that kind of retort for almost anything if you try hard enough:

  • “Flying massive metal tubes around in the sky filled with hundreds of people, what could go wrong?”
  • “Cementing metal wires into the mouths of children, what could go wrong?”
  • “Shooting lasers into peoples’ eyes, what would go wrong?”

But if you did so, you’d actually be wrong a lot — because there are many complex systems that function correctly for most users, most of the time. They function because many people have poured blood, sweat, and human ingenuity into them to make them reliable. And it’s often not intuitive that they can work.

Even if sometimes people are truly negligent and deserve it, I don’t find the phrase of net benefit to the culture. I consider it harmful because it ups the consequences of failure — a necessity for innovation — in exchange for cheap virtue signaling from bystanders who often have no experience in the domain.

So rather than assuming incompetence, let’s all be a bit more charitable. The world is complex and less intuitive than it looks.