Showing posts with label writing. Show all posts
Showing posts with label writing. Show all posts

Thursday, December 1, 2016

Elite Worship

Yesterday I read an article called In a world..., which talked about the problem of elite worship in the iOS community. I'm an Android developer, but I see the same problems in our community as well.

Here is how I see it:

  • People who tweet, blog, speak and open source are considered elites
  • Elites are held above the rest of the community, making it unwelcome for others

Does being loud make you a better developer?

Or, flipping the question, are people who don't share their work inherently worse? No, of course not. Unfortunately, unseen work is just that: unseen. Without external evidence, there is no way to tell if a developer is good or not, so we assume they are average. Not better, not worse.

I, too, would like to believe that we live in a meritocracy where good work is automatically recognized. But how? How do people know what you are doing if you don't tell them?

This encourages people to run up a hill and yell on top of their voice. And the people who are comfortable doing that are rewarded, are seen as "better".

However, this is not automatically lead to elite worship. Yes, there will always be some people who are more visible in the community. But that does not mean it has to be a small group who are revered above all else.

What you can do

When you see good work, point it out

One problem of elite worship is that we ended up comparing ourselves with people with more Twitter followers, more mentions in the industry newsletter, more conference talks etc and feel defeated. We can counter that by pointing out the good work we see that is not enshrined on the internet.

Here is a concrete thing you can do: When you do a code review, don't just point out the things to fix. Remark on the good parts as well.

When something takes longer than expected, write it down

We need more voices in our community. Blogging is great, because there is no gatekeeper to decide who gets to publish and who doesn't. But there is still one hurdle: What to write about?

Pay attention to what you do day to day. If you spent more time figuring out how to do something than you thought you would, it is worth writing down.

Don't worry about looking stupid because others must know how to do it already. You don't have to push the boundaries of human knowledge. That's PhD theses, not blog posts.

Think of it as notes to your future self, a place to put codes and commands in monospace font so you can come back in 3 months to copy and paste them.

Just because some people share more doesn't mean there is no place for you to do it. Everyone has a different experience, and we want to hear from you.

Speak at local meetups

In the original article, the author laments that there is no diversity at conferences. Always the same faces, always the same topics. As a conference organizer, I can tell you that speaker selection is hard. There were so many people that very much deserved a speaking slot but didn't get one, because we had a very limited number. You can read more about how we try to have a balanced speaker roster at 360|AnDev.

That said, we don't have to let conferences be the only place where technical talks are given. There are numerous meetups happening all over the world on any given week. And they are always, always looking for speakers. Sure, it does not come with the prestige of conference speaking, but does that make them worthless?

If you think the local audience is too small to worth your time, record your talk and post it on the internet. I wrote a guide on how to record your screen and voice with QuickTime. Would love it if someone write one for Open Broadcaster Software (OBS)!

Give talks yourself, and encourage those around you to do it. That is how we get new voices. Don't let the conference speaking circuit dictate who gets to speak and who doesn't.

Sharing != Elite Worship

People are lazy. If we see the same name over and over, we think that person must know something. This is fundamentally what leads to elite worship. We can't change human nature, but we can spread the love. Point out each other's good work, encourage each other to make it visible. Make the elite circle so large that it is no longer elite.

Thursday, December 24, 2015

Learn to celebrate

Work hard and you shall be rewarded. I don't know where I got that idea, but that was how I operated for a long time. Turns out hard work does not count if nobody knows about it.

This is especially important during performance reviews. How do you let others know the good work you have been doing? To most of us, it is not natural to toot your own horn. But like most skills, it can be learned.

Step one: Reframe. Rather than viewing it as bragging, look at it as celebration. Celebrate your achievements, big and small.

Donuts

I really like how Lara Hogan does it. She gets herself a donut whenever something awesome happened in her career, and makes its significance known to those around her. Check out her Donut Manifesto!

The boring list

If donut is not your thing, you can do with the good ol' list. Send a weekly summary email to your team with a few bullet points of what you have done.

Or you can take it a notch up and add some prose around it. I have started doing that with my newsletter, sending out about once a month, and it has been a great way to look back and take stock my accomplishments.

Celebrate now

End of year is an excellent reason to celebrate. Here is my list: blog.sqisland.com/2015/12/my-2015.html

Your turn! Write a blog post for your 2015 accomplishments (do it on medium if you don't have a blog) and post a link in the comments. Let's celebrate!

Wednesday, August 5, 2015

Keeping up with side projects

I have so many side projects that I launched a newsletter to track them:

tinyletter.com/sqisland
I got some really nice responses:

Well indeed, how do I find the time?

Freelancing

I am a freelancer, and my workload fluctuates a lot. During the slow times I can devote my energy to longer projects like Pluralsight courses.

Work from home

Working from home means I don't commute. That saves me at least an hour day. Also, my clients are all in California, and I work remotely from my home in Colorado. This means I am one hour ahead of them. I start my day at 9am Mountain time, and have one hour to do my own things before they get into the office.

It is quite nice to give myself time first, before I get busy with client work.

Incorporate sharing into my workflow

Many of my blog posts come directly from client work. I encounter a problem, figure it out on client time, and then write my findings on my own time. I often need to isolate the problem into a separate project, which gets shared afterwards. Read more on my workflow.

Taking notes at events

A great way to amplify your efforts is to record everything. You probably go to meetups like me, but do you write about it? If not, you are just an attendee, not a part of the event.

When I go to events, I live tweet or sketchnote, and then share them. For instance, I went to this awesome Bluetooth Beacons talk, made notes on the spot, and posted it:

Looks like I did a lot, right? I was taking notes while the speaker was talking, so no extra time there. I then spend 10 minutes or so when I get home to scan it on my flatbed scanner and run "Colors → Auto → White Balance" on GIMP, but you don't need to. Just snap a photo on your phone.

Alternatively, tweet during the event, snap some photos, then write a trip report. Here is the formula I use.

Go swimming

Taking notes during events is one way I multitask. Another one is swimming. You see, when I am in the pool, I get to think. I can come up with an outline for a blog post, compose a talk proposal, and in general organize my thoughts. By the time I am back at my computer, I can write much more quickly.

Have a schedule

One trick to make sure you allocate time to your side project is to have a schedule. We publish Technically Speaking every Tuesday, which means that I need to find CFPs, links and videos by Monday. It's a mind trick, but having a real deadline makes it much easier to find time to get it done.

Have a conspirator

To maintain that schedule, it really helps to have another person on the project. You feel bad about not putting in the effort, and also, when you are busy the other person can pick up the slack. I work with Cate Huston on Technically Speaking, and Huyen Tue Dao on Android Dialogs. They keep me on schedule, and make it way more fun!

Summary

Here are the tricks I use:

  • Allocate time for side projects (for me it's 9am to 10am)
  • Use writing formulae
  • Multitask by taking notes at events and thinking while exercising
  • Have a schedule
  • Have a conspirator

Monday, May 18, 2015

Fancy titles considered harmful

Do you agonize over your title when you write a talk proposal? I know I do. I want something catchy and clever, I want the organizers to like it, and I want the attendees to come.

I have come to realize that obvious titles are often the best. I gave a talk at OSCON called Bust the Android Fragmentation Myth. Catchy isn't it? I was so proud of myself, coming up with that title.

However, after I gave the talk, an attendee came up to me and said, "I am so glad I came. I have always wanted to learn how to write apps that works for both phones and tablets, and I would have never guessed from the title that you would be covering that in this talk."

That made me wonder: How many people went to other talks because they couldn't tell the content of my talk from the title? A lot of people just glance at the conference schedule, and if the title is not obvious, they probably won't bother looking at the description. Besides, it's not easy to come up with clever titles, so nowadays I just stick with descriptive ones:

Yup, my talk will just be "Advanced Espresso", no clever coffee puns or anything :)

Saturday, May 2, 2015

Writing about speaking

I decided that I need to be more visible when I became an independent developer a few years ago. I came up with three ways to increase visibility:

  1. Blogging
  2. Public speaking
  3. Social media

Turns out they are not three separate things, but very intertwined. Blogging allows me to showcase my technical expertise, helping me get my first speaking opportunities. As I gained more experience I started blogging about speaking as well, which is a great way to establish yourself as a speaker who cares about giving good talks.

There are a few ways you can write about speaking:

Topic list

To get started, write about the topics that you would like to speak on. It gives you a chance to take inventory of your interests, and it signals to others that you want to speak so they can connect you with meetups and conferences.

Some examples:

War stories

We are all nervous about speaking, and it really helps to know other people have the same problems too. Share how you feel before, during and after you speak, and how you cope with your anxiety.

Some examples:

Conference report

Talk about what you saw at a conference. What talks did you see? Did you pick up any new speaking techniques? How did your talk go?

You can try my blogging formula for conference reports. Key points: Embed photos and tweets!

Transform your talk into written form

Whether it is a 5-minute lightning talk or 50-minute lecture, you have taken out a lot of material to form a good narrative and maintain a good pace (You have, right?). You can turn those additional material into blog posts.

Kate Heddleston did a phenomenal job with her diversity talk at Pycon. She wrote 5 blog posts expanding on the points she made on her talk, and posted them before the conference to garner interest.

Another way to expand your talk into a blog post annotated slides. Here are some examples:

Do it

There you go, I have written about speaking (actually, I have written about writing about speaking. I know, so meta). Your turn now. If you are an aspiring speaker, go write your topic list. And if you have given a few talks already, write a summary post of your journey. How did you start? What have you learned since then? What are your next goals?

This post is written to celebrate the sixmonthiversary of Technically Speaking. Subscribe for more public speaking tips.

Sunday, March 22, 2015

Write/Speak/Code: Write

The first day of Write/Speak/Code is dedicated to establishing credibility, then sharing expertise through writing.

Impostor Syndrome

After the introduction from Write/Speak/Code founder Rebecca Miller-Webster, the first order of business was to address the impostor syndrome. Neha Batra gave us a 6-step formula to fight it:

Own your expertise

Next we went through a bunch of exercises to come up with our expertise based on our knowledge and experience.

With that, we crafted a bio and brainstormed ideas to write or speak about.

Writing panel

I really like how Write/Speak/Code alternates between hands-on activities and lectures/panel. Next up is the writing panel, and I got to share my experience alongside Pam Selle, Debra Williams-Cauley, Julie Steele, and Corey Latislaw.

Writing sprint

We concluded Write day by writing a blog post. I just stepped off the writing panel, and realized that I forget to share my blogging formulas, so I ended up writing a blog post on how I write conference reports. Oh so very meta!

This is a part of the Write/Speak/Code series. Read more: Intro, Speak, Code.

Write/Speak/Code: Intro

When I heard about Write/Speak/Code, I know I want to be a part of it. My career has benefited tremendously from writing blog posts, speaking at conferences and sharing my code as open source, and I want to empower other women developers to do the same.

Make it happen

Once I decided that I want to help out at Write/Speak/Code, I need to figure out how to make it happen. I met Vanessa Hurst while we were both speaking at OSCON 2013, and she co-founded Write/Speak/Code, so I reached out to her. She put me in touch with the organizing committee, and while I was waiting for results from mentor nomination and selection, I decided to write a blog post in the spirit Write/Speak/Code and send that to the organizing committee. A few weeks later, they invited me to be on the writing panel and also be a speaker mentor. Yay!

I normally don't share stories like this, but I feel this is appropriate for Write/Speak/Code. If you want to speak at a conference, there are many ways to get in the door. Answering to an open CFP (Call For Proposals) is one way, but you can also reach out to the organizers directly. If you don't know them, get an introduction. Make it happen.

Write/Speak/Code

Write/Speak/Code is a 3-day conference, each day dedicated to Write, Speak and Code:

  1. Write
  2. Speak
  3. Code

Yup, the conference is so jam-packed with action that I need to write a separate blog post for each day! Click on each link above to read more.

Thursday, March 19, 2015

Blogging formula: Conference reports

I wrote about my formula for writing technical articles. I also have one for trip reports, to talk about conferences I attended. Having a fixed structure means I can plug in the content from the conference and publish the blog post a day or two after the conferences ended, while it is still fresh on people's minds.

Here is my formula, using Øredev as an example.

1. Introduction

I introduce the event many different ways:

  • Explain why I was there.
  • If I was speaking, talk a bit about the CFP process.
  • Pull out one interesting thing from the conference.

Here is what I said about Øredev:

When Cate and I was touring Copenhagen, we talked about how we got into public speaking. One thing led to another, and we decided to publish a newsletter together. We had a little bit of time on Monday before Øredev, so we put together our first issue in the hotel lobby!

2. Highlights

I point out things that I enjoyed. This is pretty easy because I tweet during the conference, so I just embed the tweets in my blog. I also search for the conference hashtag and include other people's tweets.

I also include photos from the events. Photos are great because they take so much space that you post looks rich even if you did not write many words. Same goes for embedded tweets.

Selected tweets from Øredev:

3. My talks

If I was speaking, I mention my talks, embedding or linking to slides and videos if available. Usually I keep this pretty short, assuming people can check out the slides or videos if they are interested.

My talks at Øredev:

4. Conclusion

Quick summary of my general impression, usually just a sentence or two. This is what I said about Øredev:

Tack så mycket, Øredev!

Exercise for the reader to figure out what it means :)

Saturday, January 24, 2015

Moar technical articles!

You need to write more technical articles.

Yes, you.

I could guilt you into doing it. I could tell you that you have benefited from other people's sharing so much that it is time for you to give back.

But instead I will tell you what is in it for you: Job security.

Your real résumé

The classic first step to get a job is to prepare a résumé. It could lead you to an interview if you keyword-stuff it the right way. But nowadays employers are turning to the internet to cross check if you are who you claim. A repertoire of technical articles is a solid way to show that you know your stuff, and more importantly, you can communicate.

But what do I write?

I knew you would say that. While I have no guaranteed formula that works for everyone, I can share how I make writing technical articles a part of my normal workflow.

  1. Experiment on a clean slate
    Whenever I need to incorporate an unfamiliar technology into my work, I do not do it directly in my main project. Instead, I create a brand new project and implement the minimal setup to understand how it works.

  2. Build it up step by step
    Once I get the minimal setup working, I add extra logic to get to what I need. But instead of overwriting the minimal setup, I make a copy so that I can explain the steps later. For example in Android apps I make my MainActivity a list of activities, each corresponding to a step.
  3. Integrate into the main project
    When the sample project has all the functionalities I need, I put it into my main project. It may interact with my existing code in unexpected ways, so I tweak until it works.
  4. Write the article
    After the coding is done I write the article. This is the structure I use:
    1. A back story of what I was trying to do
    2. Outline the steps I took with code snippets and screenshots
    3. Explain the problems I encountered along the way, and how I solved them
    4. Link to source code on github
  5. Push the sample project to github
    I don't publish my source code until the article is written because sometimes I thought of a better way of doing things while explaining my method in writing. Once I am happy with the article, I push my repository to github, publish the article, then add a link from the README of the github repository back to the article.
  6. Share on social network
    After everything is published, I post a link to Twitter and Google+ with a screenshot as the teaser.

End result

Here is a sample article: Partial SlidingPaneLayout

And how I shared it:

Good for you, good for others

I stumbled upon this workflow by accident. I used to stick the new technology straight into my main project, failed to make it work, and unable to pinpoint why. With a brand new project I can focus on the new stuff, work out all the kinks before I introduce the extra complexity of my main project.

Once I figured out how it works, I could have just thrown away the sample project. But what a waste! Instead I push it to github, and suddenly I am an open source contributor. Sweet!

Writing the article is a bit of extra work, but so very worth it. It gives me credibility. It lets people know that I know my tech, and I know how to explain it. Icing on the cake? It helps other people too!