Write/Speak/Code: the conference highlights

Last week I attended Write/Speak/Code for the first time. Now, I’ve attended a good amount of conferences. I find most of them pretty interesting, I always learn something, but I was blown away at how much I was able to take home from this conference. From the pedagogical approaches to the actual content to the awesome women I met, this is a conference to keep your eyes open for in the future.

I took a grand total of 20 PAGES OF NOTES, so this is going to be my attempt to recap what went on. I want to start by saying that I’ve never been to an all-female conference and honestly wasn’t sure what to expect. I have a lot of male friends and so it wasn’t really until I entered this industry that my “otherness” of being a women became a thing. I have to say that it was actually really awesome. It is so rare that you’re in an entire room with smart, technical women respecting one another. I think, as a result, this conference had a very different vibe and the interactions I had with everyone were just lovely.

The sessions were quite interesting. I decided to participate in the alumna track since I’ve already done a fair bit of conference speaking. The alumna track was focused on leadership development, self care, and personal realizations that can be put to use in personal and work settings.  Some of the highlights included K Wu’s session on ask vs. guess culture. I’d never heard these terms before. She did a great job describing both cultures and also giving tips for interacting with colleagues, managers, and direct reports who might come from the opposite culture as you. From there, we looked at leadership and conflict styles looking at the Hippocrates four temperaments as behavior preferences and different conflict styles and how we interact with our team as a collection of individuals who might have very similar or very different conflict styles. Examining our conflicts styles really made me think a lot about processes in tech and how some processes might give an advantage or disadvantage to folks with a specific conflict style.

One really interesting point was that over and over again, there was a clarification made in sessions to think about your responses, personality, and style in the context of how you are at WORK. This was interesting to me because women often are expected to act differently at work than in their personal lives and often many of us feel like we can’t bring our whole selves to work. I would be curious if men also feel this way and if there would have needed to be such an emphasis on “are we talking about our overall selves or our work selves in this scenario?”

There were a couple of interesting talks that had really tangible, actionable steps. For example, Annyce’s talk on creating videos and Neha’s talk on branding yourself were two of the best I’ve seen in those areas and really provided great, easy steps anyone could take and work towards in a thoughtful productive way.

There were also some tough sessions… one about self-care which really magnified the pressure many of us feel in the industry and put forth some coping solutions and some very real- talk about whistleblowing, being taken seriously in the industry, and how to give and receive advice.

There was a FASCINATING talk by Liz on algorithmic accountability and algorithm biases which taught me about how the ways in which a human develops an algorithm, especially a learning algorithm. can introduce biases. That’s definitely a topic I want to learn more about and found the examples incredibly interesting.

One major accomplishment for me was contributing to open source. I helped build a gem years ago to open source but have basically been scared of OSS ever since. I don’t have a ton of time and Ive heard some really scary stories about getting involved in projects. As part of write/speak/code though you actually get time to work on OSS. This is a big deal for me because I basically have no unspoken for time in my life. I looked over a bunch of projects and ended up working on the callback women rails app (a twitter handle that I rely on to find out about conferences and LOVE). It was a great experience and by the end of the day, I had a PR that was merged in. I’m hoping to keep up with the community and the project and contribute more in the future.

Finally, the last day was self-care day. It was great. There were really interesting talks about burnout, personal journeys, wellness, and salary negotiations. Overall, the conference was fantastic. You could tell the organizers put an incredible amount of thought and effort into the event. The speakers presenting thoughtful, intelligent, actionable presentations. The fellow participants were engaged, respectful, and kind. And, of course, the swag bag was awesome.

For a full least of speakers, the schedule and the slides, check out: https://2016.writespeakcode.com/pages/schedule

Pull Requests - It's all about the details

Let’s talk about pull requests. Most people I know operate through a PR system at work. The basic process goes like this:

1. Write code
2. Push up the branch and create a pull request
3. Put a few details in the description about what changes were made
4. Wait for comments
5. Improve code based on comments if needed
6. Ship it

The description portion of the Pull Request can be incredibly important though in making sure your code is reviewed effectively and getting better comments. This is something I’ve been focusing on personally recently and that we’ve been focusing on more as a team. Even though putting more thought and effort into crafting a pull request takes a little more time, it helps us QA much more effectively and allows us to have better context when reviewing each other’s code.

So here are some quick tips to crafting effective PRs.

First, start with user stories. This is something I only recently started doing but it basically acts as a summary of what is going on in english. As a ___, when I ___, I want to see ___.

Example:

As a developer,

When I go to the github repo’s readme

I want to see clear instructions to get set up

As a developer,

When I go to the github repo’s readme

I want the setup instructions to work

Second, what happened bullet points. This is just an overview of the biggest changes. It should potentially re-iterate some of your git commit history but not all of it. If you’re still working on creating a clear git commit history with small, specific commits, this section might be a little bigger. 

Third, screen shots. To take a screenshot of a specific portion of a screen, on a mac, you use SHIFT + CMD + 4. It’s often helpful to annotate that screenshot by placing arrows or text onto the image. An easy way to do this is to open the screenshot, open the toolbox, and place the arrow shape into the image and then save it. You can see where all these things are below.

Open Toolbox

Select Shape

Select arrow option

Fourth, record video or screencast. I’m not great at recording a demo video but screencasts can be really helpful. RecordIt was recommended to me and it’s been great so far. It’s really simple to understand, use, and post where necessary. 

Fifth, Add QA instructions as a checklist. At my company, developers do a pretty in depth QA of each other’s issues in addition to code review. Creating a QA checklist also helps you as a developer think through possible edge cases or flag critical paths that need a more in depth look. This QA checklist should be specific, include links and then what should be seen. It’s often easiest to make this as a checklist so that whoever is QA’ing can just check off the items as the QA. The example below is VERY simple, but hopefully it is easy to imagine what instructions for a more complex feature or bug fix might look like.

Example:

Go to www.allisonsherenmcmillan.blogspot.com and sign in as an admin

Go to the consulting tab

[ ] You should see bold headlines

Sign out of the admin role

Go to the consulting tab

[ ] You should still see the bold headlines

Sixth, add labels in Github. This is more in reference to the code review processSome of the labels we use include things like “Ready for improvement”, “Don’t merge or review”, etc. Sometimes if I don’t have time to complete the description for a PR, I’ll just temporarily slap a “Don’t merge or review” label on there until I can complete it.

Finally, open your PR and get excited for some great feedback. By spending more time on your PR description, you'll get better feedback and you'll be able to ship more confidently.