This month I realized that this blog is easier to keep up with if I just document my projects. I released episodes 4, 5, 6, and 7 of my podcast about writing. I also wrote articles about how I am self-hosting it, using S3 for the media, and how I get simple stats.

I also wrote an article about Bicycle, an open-source library I am working on with a couple of friends, and I’ve been writing articles about WatchKit on App-o-Mat. And this post itself is an example of just documenting my projects.

Most of the articles I write for this space are about software development and processes.

• In Defense of Tech Debt encourages you to just think of tech debt as a cost which might be acceptable.
• But, I think Tech Debt Happens to You most of the time because of dependencies.
• And then in Timing Your Tech Debt Payments, I compare payments to servicing interest and paying down principal and offer a best time to do the latter.
• In It’s Bad, Now What?, I talk about pre-planning actions for when monitoring shows problems
• In Assume the Failure, I recommend framing all risks as your own failures, not external ones, so that you can personally mitigate them.
• In Mitigating the Mitigations, I show how you can’t wait until a risk materializes to do your mitigation plan. It might be something you need to do somewhat in parallel.

And, I wrote some articles on gaining expertise

• In Observing Experts, I wrote about how I learned how to seek out experts to emulate, which I learned from reading Peak.
• Peak is also the source of deliberate practice. I offered ideas for Deliberate Practice for Knowledge Workers.
• And, for programmers, Deliberate Practice by Cloning.

I have been thinking about the great works in software and software writing as I think about where I want to spend my time. I think there’s an interesting cycle of making -> tool making -> making with the tool, where the result is content in a new medium.

Caveat: This works for me, and I am talking about it in the hope that it can help others. It’s not for everyone.

Over the course of my life I have become a lot better at managing anxiety. I once joked that all I had to do was realize that there’s no logical reason to feel anxious and then wait twenty-five years to see that I was right. That pretty much sums up how I’ve managed it.

Recently, though, I’ve come to see anxiety as as asset.

In my career, I would say that I generally get big things done by being on top of them. By worrying about them. I think about mitigations, like you’re supposed to, but even mitigating the mitigations. It’s probably a bit much, but it works for me. I think of this as being conscientious.

And that’s the reframing that’s helped. My feelings of anxiousness are a flip-side to conscientiousness. They come together. So, to the extent that I am happy about my approach to work, I have to accept that I will often feel unfounded anxiety.

I have come to be thankful for it. When I feel it coming on in an unwelcome way, I tell myself that this part of me is helpful at other times, and it can assuage it.

Since I mostly use Twitter to listen to young, underrepresented programmers, I get to hear about things I normally would not. One recurring theme is the role of mentors, and at some point I saw people talking about how they needed sponsors instead. Here’s an example from Nancy Wang in Forbes:

Part of a solution could be via mentorships and sponsors. The difference is critical: mentors can help make introductions and give valuable advice, and sponsors often go one step (or many steps) further, leveraging their own reputation and personal capital to advocate for your success.

I am trying to apply this when people ask for advice. It’s hard.

It’s easy to just say a bunch of stuff. Talk about yourself, tell a story, recommend a book, etc. If you are successful, it’s easy to think it’s because of the things you did and if someone else did them, they would also be successful. But it’s not that simple, because mixed in with our efforts were luck and helping hands. A lot of what we think is good advice doesn’t apply at the very start, where we need someone to just take a chance on us.

When I look back for sponsors in my own life, I remember that my aunt got me a job filing paper invoices in her office and that’s where I learned Lotus 123 and did my first professional programming in high school. At 13 my mom got me a computer at Radio Shack when we went there to return a defective electric typewriter (they were the same price). A few months before that, my wood shop teacher transferred me to computer “shop”. They didn’t give advice—they used their “personal capital” to put me in a position to grow.

Moms, aunts, and teachers will probably always help out a teenager. They are part of our lives, know us well, and probably feel a vested interest in our success. But, as aspiring sponsors, we can do that too. Our goal should be to get to know the people we are trying to help. To become invested in their success.

So, now when someone approaches me for help, my default is to think about how I can get into a position to sponsor them. To do that, I need to know them and what they can do. For programming students, I hire them to help me with my personal projects and consulting. I always pay for this work.

It’s not a lot, but my goal is to get to know them well enough to recommend them without reservation.

Update July 2023: This post was written in 2021. Since then, I have changed my views on Twitter and deleted all of the data in my account. I haven’t edited this post, but I would see it as more of a way to use Mastodon or other social media, not Twitter specifically.

I don’t tweet much, so my Twitter experience is highly dependent on how I manage who I follow, block, and mute. I realized a few years ago that by tightly controlling this, I could make Twitter into any experience I wanted.

I decided that the best way to use it for me was to give me access to voices I wouldn’t normally hear from. So (aside from people I know in real life), I almost exclusively follow programmers from groups that are underrepresented in tech.

In my feed, since they are way overrepresented, I am constantly exposed to the world as they experience it, and it helps me develop empathy. I can feel my attitudes and default reaction changing in ways it never would have if I only interacted with people I know.

Another important part of how I use it is that I mostly listen. If the topic is tech and I can answer a question or add value, I do. But I don’t chime in on topics where I should be learning, and where my instincts are probably not great.

I can also add value by amplifying their great work. Again, by making my default overwhelmingly underrepresented programmers, it’s just more likely I will be exposed to their work instead of it getting buried in my feed.

This month I talked about how The Practice helped me understand what I am trying to do by blogging and motivated me to blog every day. I shared some tips to how I am doing that.

1. Start the day by writing morning pages, then write a shitty first draft.
2. Keep a long list of topics.
3. Bank blog posts.
4. Edit by using the editing sweep method.
5. Write a lot of posts to become a better writer.
6. Generate topics with these tips. For example: Mining your tweets or writing while reading.
7. Use media depravation to make space in your brain for your own ideas.

I offered some tips for technical job seekers.

1. Write a job statement
2. Build your network by being useful to people
3. Don’t be afraid of rejection.
4. Make your resumé specific to the job.
5. Prepare for interviews like they were a performance.

Last month, I wrote mostly about how we can apply game design to books and apps. By this, I mean making the book or app literally a game (like Pokémon Go), not slapping on badges to gamify an app. Speaking of Pokémon Go, I have ideas for how AR will turn mundane apps into games.

I also covered parts of my daily and weekly routine, and how I use habit totems to keep myself on track.

I wrote a little about programming. I think tutorials should be vaguer because they would force learners to write programs, not read them. If they were, they would be better preparation for coding interviews. I updated my 2011 advice on GitHub profiles. I covered two approaches to app icon design, icon-first and icon-last.

In February, I plan to talk more about my practice of daily coding, writing, and sketching.