A few weeks ago, I took my aunt to a medical appointment. While I was waiting, I found a place to get a coffee, and I read a book.
I read two copies of the book at once. Actually, two of my three copies... maybe I'd better explain.
A year or so ago, I picked up an ebook of The Staff Engineer's Path, by Tanya Reilly. Looked like a good book, but I was in the middle of reading something else, so I set it aside.
I picked it up again recently, because hey, if I'm going to be writing a book on career growth for developers, I should read someone else's book about a similar topic.
I quickly realized that I didn't have the focus to read the ebook. I spend a lot of my day looking at screens. Continuing to focus on screens in order to read a book... it just wasn't happening.
So I got the audio book, which allowed me to listen on my morning walks into town. Much better!
However, as I was digging into the first chapter, I started to worry. Had the book I was going to write... already been written? This first chapter was covering so many points I intended to cover in my book!
I know, I know. I've been lectured on this topic already. "There's nothing new under the sun," people say. For any book, there's bound to be other books covering the same material. You have to trust that your voice, your unique writing style, and your particular perspective will be adding to the conversation.
But this was making me nervous.
One thing I knew for sure: I was going to use Reilly's book as a reference. I got myself a third copy of The Staff Engineer's Path, this time a paper copy, so I could highlight key items and take notes in the margins.
Hence, three copies.
So, while I waited for my aunt's appointment to end, I listened to the audio book while reading (and marking) the paper copy.
I love this combination of audio and visual, especially in a high-distraction environment. If my mind starts to wander or something nearby catches my attention, it feels like I have twice the chance of keeping my focus. For example, I can stop looking at the page but keep "reading" as the audio continues in my ears.
And the more I read, the more I see that our books are sufficiently different. It's a relief. That said, The Staff Engineer's Path is excellent, and I'll definitely be mentioning it as a useful resource in my book.
I started to consider sending Reilly a message to introduce myself, once I was done reading at least one of the three copies...
LeadDev
As it turns out, Tanya Reilly and I are likely to cross paths sooner or later.
On a tip from a contact (hi!), I'll be attending the LeadDevStaffPlus conference in October. Usually I find out about a cool conference somewhere in between "when it sells out" and "when attendees post about how incredible it was," but this year I caught wind of it earlier. I even applied to speak!
Signing up for the conference got me on a mailing list, which led me to sign up to attend a webinar, which led me to the LeadDev Slack. And on a whim, I checked to see if Tanya Reilly might also be part of this Slack community. Wow, I thought, she is!
Yeah, about that. Apparently I hadn't noticed the back cover of her book, which says: "She's an organizer and host of the LeadDev StaffPlus conference." Oh, and she's also the first speaker listed on the conference page for October.
In other words, wondering if Tanya Reilly is in the LeadDev community is a little like wondering if Big Bird hangs out on Sesame Street.
Okay, I decided I was definitely going to reach out and introduce myself when I was done with her book.
That was you??
Then I get to chapter seven of the book. In a section called "Don't delegate through neglect," she describes a talk she gave a few years earlier:
The talk was about the leadership and administrative tasks that aren't on anyone's job ladder but are needed to make a team successful: all the unblocking, onboarding, reminders, mentoring, and scheduling.
Oh, I think, as I listen to the audio book. That's the concept of "glue" work. So glad someone once sent me an article that gave that kind of work a name.
"I called this kind of work 'glue work'," she says.
Wait, what?
Yep. The "article" I'd read several years ago about glue work was actually her blog post. See: noidea.dog/glue for the full article. (Such a great name for a blog.)
At this point, I stopped the audio book and messaged her on Slack. I now had several reasons for reaching out. I had to.
Books, books, books
Looking at Reilly's blog, I noticed the "Rands Leadership Slack," and I signed up for that too. In the process of signing up for that, I noticed that Rands has written The Software Developer's Career Handbook, so now I have another book to add to my must-read-before-I-publish list.
Also on that list:
I just finished The Five Dysfunctions of a Team, by Patrick Lencioni, which reminds me that I should reread Agile Conversations by Douglas Squirrel and Jeffrey Fredrick.
Are there other books I should read before I write my own about leveling up in software development?
Drop me a note
I would love to hear from you. Hit reply and let me know what's on your mind.
Know someone else who would enjoy this? They can subscribe here: https://www.beyondwritingcode.com/contact/
Thanks for reading!
A note about the em dash
I keep seeing comments on LinkedIn like: "you can tell it's AI if it uses the em dash, because nobody uses the em dash LOL."
But then others chimed in: "Hey, some of us do use the em dash." (Along with the usual response of "that's exactly the sort of thing an AI would say.")
I've been writing since I was a kid. I started taking writing classes outside of school in sixth grade. I'm a former English major. I've written hundreds of documents in a professional setting.
So, naturally, I had to look up what an em dash is.
From the AI Overview provided to me by DuckDuckGo:
An em dash is the longest of the three common dash types: hyphens, en dashes, and em dashes.
It's so named because it's the width of a capital "M" in a typeface.
Now that I know what the em dash is, and I've read up a bit on how to use it, I want to use it more.
By the way, the above quote about the em dash is my first—and so far only—use of AI in this newsletter. Exactly the sort of thing an AI would say.