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.

There are three things that I try to do nearly every day: code, write, and sketch. Of the three, I struggle most with sketching.

It’s also the case that of the three, my sketching is the least developed. I am a professional programmer, and I have had some success writing professionally, but my sketching is (to be the most charitable) “advanced beginner”.

It’s also the case that I have spent orders of magnitude more time coding and writing than sketching.

This year, with my theme to Hone, I am committed to just making as many bad sketches as I can. Honing is sharpening by repetition.

So, I remembered a lesson from a sketching class I took a few years ago—warming up with blind sketches.

In a blind sketch, you look only at the subject and not at the paper at all. You may even decide not to lift the pen. You try to get a sense of the canvas with just your hand. Part of what you are developing is the skill of drawing what you see (the shapes and values in the space), and not symbols of what you see.

I use a big pen (1.0 mm) to make sure that ink makes it on the paper (since I am not looking, sometimes my thinner pens don’t always make marks) and to further lower the bar on the expected outcome.

These sketches are “easy to do” in the sense that I can do them at any time. I just draw what’s in front of me. Here are some pens:

I do a few of these and then I might move onto a longer sketch. But, even if all I do is some blind sketches, I’m ok with that.