I almost didn’t apply.

My twitter friend Mary knew I was looking for my first Developer Relations job. She tagged me in a reply to a tweet she saw about a company who was looking for junior developer relations people.

I navigated over to the job post only for my heart to sink a little. The position was listed as located in London–a mere 5,500 miles from where I live. Gulp. That couldn’t be good. But before clicking away and forgetting about the position, I read a little about the company and team. It sounded awesome! Their product was something that I thought was genuinely useful to developers. I knew this could be a great role.

Instead of forgetting about it, I reached out to the person who had tweeted about the role. I asked her if the company would consider a remote US advocate. Yes they would.

So I applied. Even though it was Thanksgiving and my weekend was busy. Even though my kitchen flooded and I arguably had enough going on, dealing with contractors and insurance people. I applied and I am glad I did.

I start mid January.

---

 

More details to come. Suffice to say, I am excited.

I am also very thankful for every person who retweeted my job searching tweets, for everyone who connected me to a job post, for the advocates I have met in this year of conference speaking and gave me a glimpse into their work, for the organizers who selected my talk proposals, and for my manager who was very flexible with my schedule as I chased my goal.

Harry Potter, boy wizard, has an innate ability to communicate with snakes–to speak Parseltongue. At first he isn’t aware that it is a special skill–he isn’t even aware that he can do it! But he figures it out and at a few points in JK Rowling’s stories, Harry uses this ability to achieve his goals.

I have good news and bad news. Good news is that you almost certainly can talk to snakes, or at least Pythonistas! Also good news–you can use this skills to achieve your goals! Speaking at a tech conference is a great way to expand your network, add to your resume, and build professional skills.

The bad news is that it most likely won’t be something that you can do naturally, right away. However, with some planning and effort, speaking at your first Python conference is an achievable goal and probably more useful in the Muggle World than speaking Parseltongue.

 

I am going to share some of the things I learned from speaking at four Python-centric conferences in 2018 and getting acceptances at two Python-centric conferences already for 2019. Most of these thoughts will also be relevant for tech conference speaking in general.

This first post will cover how to get accepted as a speaker. An additional post will be coming within a month that will cover how to prepare and deliver your talk.

How Does this Work?

There are hundreds of tech conferences around the world and conference organizers are looking for content! Every event can be a little different, but in general, conference organizers will invite a few speakers that they know will have an interesting story or something important to say to their audience, but they will also have a number of speaking slots that they fill based on a “call for proposals” (cfp).

The organizers will advertise and spread the word about their cfp. They want people to apply, you just need to keep your ears up in the right places to hear about these opportunities.

When you hear about a conference that you are interested in, you will need to submit a proposal. Typically this happens through their website or a third party site specifically for cfps. When the cfp period closes, the organizers will review the proposals (oftentimes the first round is anonymous) and craft a schedule to suit their audience. They will send out acceptances first, then fill any empty slots in the schedule that might occur when people turn down slots. When the schedule is reasonable finalized, organizers send out rejections and announce the schedule to the public. (This process can vary a little, sometimes there are rolling acceptances, sometimes organizers will name alternates, etc).

Where can I hear about CFPs?
Here are a few options.

www.papercall.io
CallBackWomen
Mozilla Tech CFPs

Why Python?

OK, so the above applies to tech conferences in general, but why should someone consider applying to speak at Python conferences in particular?

There are LOTS of Opportunities

Pythonistas are all over the globe and their conferences are as well. There are events that range from fairly local, single track conferences that have a few dozen people to international, week long, multitrack conferences with thousands of Python users. When you want to try conference speaking, you don’t need to jump in to a very large conference right away. Many people get their start at a smaller conference, and if they like it shoot for speaking at a larger conference the next year.

You can find Python events here and here. Ocsasionally check back for updates!

Python is a Good First Language

You may have hear that Python is a good first language. It is very readable and it is comparatively easy to get something running. I think that this quality of the language is important when you consider python conference speaking. There are all sorts of Pythonistas, those who just got up and running last week to people who have been working in the industry and/or contributing to open source for decades.

A Python conference is going to want to appeal to the community. This means that organizers are going to craft their schedules so there is something to everyone! If you are nervous about speaking, just know that you don’t have to select the most technical topic.

Writing and delivering a talk in the context of a Python conference does not mean that you need to be an expert. You just have to have a handle on your subject and for your subject to be useful to some part of the community.

Python is Used for Awesome Things!

In addition to Python being used by developers of diverse experience levels, Python is used to build a bunch of interesting things. This means that talks on all sorts of topics are relevant for Python conferences. Data Science? Yes! Bio-informatics? Yes! Academic research? Yes! Web development! Education! Science! Art! Machine learning!

If you are using Python to do something interesting, even if it seems niche, you can share that with the community. We like variety and there are lots of smaller communities within the general Python community. You will find your people. This quality is part of what makes Python conferences fun.

Inclusion

In my experience, Python conferences are good at finding a diverse crowd of speakers. Obviously, it isn’t perfect but I appreciate a few things that many of the conferences do to help encourage diversity on their lineup.

1. Anonymized CFP review. Most (all?) of the Python conferences that I spoke at this year had at least one round of CFP review be anonymized. Sometimes unblinding happens only at the very end to be sure that the resulting speaker line up is balanced.
2. Codes of conduct. A code of conduct is an explanation of the agreed upon behavior to which all organizers, speakers, volunteers, and attendees must adhere. If someone acts in a way contrary to the code, there should be methods in place to rectify the situation–usually a code of conduct phone number to call or making sure attendees can identify staff to report the problem. Codes of conduct (when well written and enforced) can go a long way in ensuring the safety and experience of all attendees, and actively work against systemic problems. There is room to grow, but the Python community takes Codes of Conduct seriously, and they help make Python conferences nice places to speak.

Picking Topics

So now you know how to hear about open CFPs and why you might like to speak at a Python conference. You still need to decide on a topic for your proposal. This can be an intimidating step, but there are a few things that you can do to make it more approachable.

Brainstorm

Grab a pen and notepad and set aside a half hour. Then write down every talk topic that occurs to you. No editing! There are no bad ideas at this stage. Topics can range from a problem you recently solved, to a tool that you are excited about, to team dynamics, how to hire people, and much more.

Once the half hour is up, put down your pen and go do something else. Return to the list the next day and evaluate all the topics, making notes or writing down questions you may have about any of the topics.

Pick 2-3 topics that you really like for further development.

Write the Talk YOU Would Want to Hear

When you are a conference speaker, you are also a conference attendee. You are the kind of person (whatever your current role in tech) that organizers want to reach. When you pick your topics, I recommend selecting the talks you would want to hear. The proposal will be easier to write, the talk will be easier to put together, and you will be a more engaging speaker. Win, win, win.

Crafting Your Proposals

Now that you have your topics, it is time to craft your proposals.

Things to Keep in Mind

1. Most conferences will let you submit more than one proposal. If you really want to speak and have the time to do so, submit multiple ideas. In my experience, it greatly increases your chances.
2. You can submit the same topic to multiple conferences. You don’t need to have a fresh topic every time.

Read the Problem Statement

Conferences should have a page of information on their website or on something like papercall.io that describes what they are looking for in a proposal. That page may describe conference ‘tracks’ (a group of talks with a similar theme or purpose) that they are putting together. You increase your likelihood of acceptance if your talk fits well into one of these tracks.

They might want to know how much time you intend to spend on each point. They may want to know if you have ever given a talk before. They may need to know if you need any additional a/v equipment. If they have a direct ask, be sure that you include an answer. That way, the reviewers can select your talk without worry!

Read the instructions, follow them, and increase your chances.

Detailed Outline

Most conferences will want a detailed outline of your proposed talk. (There might be other things they ask for like a description or an abstract, but the outline will be the majority of the work).

Create an outline of your talk, focusing on the big pieces first, and then adding supporting details after you have an understanding of the general direction of the talk. Be sure to give reviewers an idea of how your talk will benefit the listeners. You aren’t writing an essay, but the outline should be detailed enough that you probably could.

Put yourself in the shoes of a reviewer. They want to have a great conference! A well detailed submission, with a well developed outline, shows the reviewer that you have put a lot of thought into your talk. This tells them that you would likely do the same if included in the program. You are selling the idea of your talk, but also your preparedness and desire to give the talk.

Use the Resources Available to You

Finally, I encourage you to use the resources available to you. Conference organizers want you to do well. Your success is their success.

Resources available to you may include:

1. A proposal mentor. Sometimes this is organized officially by the conference–watch their twitter! Other times it can be less formal. Sometimes experienced speakers will offer help, especially to underrepresented people. Again, watch twitter for opportunities like this.
2. Sometimes submitting early means organizers will have the chance to reach out to you with questions or concerns. Depending on your answers and changes this can be the difference between acceptances or rejections.
3. Occasionally community groups will offer workshops for writing proposals. I went to such an event last year, and it helped a lot! Here is an example of such an event.

The End?

Well, of course not. If you weren’t accepted, I encourage you to resubmit to another conference. Events can be very competitive–a rejection doesn’t mean that your idea is bad or that it won’t be accepted elsewhere.

If you were accepted, this is just the beginning. Now you have to write and deliver your talk! This also doesn’t need to be scary, and I will be publishing another post soon addressing these issues.

I hope this was helpful. If you have any questions, feel free to send me a tweet www.twitter.com/hayleydenb

Engineering Ethics

There is a discussion happening within tech communities on the subject of engineering ethics. It is a multifaceted, nuanced, interesting topic. For the purposes of this post, it is reasonable to define engineering ethics as developers accepting responsibility for the code they write and the impact that their code has on others.

Before I wrote software, I was a licensed civil engineer and worked in a structural engineering firm. I have spent a lot of time thinking about how software developers can conduct themselves ethically, because my previous career was one that had a defined ethical structure. The result of my musing was a conference talk on engineering ethics.

But What About Open Source?

When you give a conference talk, people tend to track you down afterward and continue the conversation that your talk started. I received a lot of feedback on my talk, and was gratified that people were interested in engaging in the issue. Far and away the most common question I received from people was, “But what about Open Source?”

That is a really great question.

Open Source Software (OSS) is software that is shared. It means that anyone is able to view, use, modify, and distribute the code. If engineering ethics is about being responsible for the code you write, what happens when you are using code that you did not write? Do you need to assume responsibility for all of that code? What happens when you volunteer your time and talents to an Open Source project? Is the standard different because you are donating your time? How can we responsibly (read: ethically, deliberately, safely) use Open Source Software?

Benefits of Open Source Software

So since the use of OSS software raises these questions, a new user to OSS might wonder why we embrace it at all. There are numerous benefits to OSS, making it well worth it to wrestle with these questions.

Don’t Reinvent the Wheel

When code is shared, we don’t need to repeatedly solve the same problem. We stand on the shoulders of giants–people who have worked hard to build something truly useful. As much as developers like to work in green field projects, using, maintaining, and extending known solutions just makes sense. Starting at the very beginning just sounds disheartening and tedious.

Don’t Spend Money to Reinvent the Wheel

Starting at the very beginning also sounds expensive. Time has a cost and development time is pricey. Our industry is competitive. Open Source Software allows developers to get to the meat of their product faster. OSS is part of being economically competitive and is therefore likely to be part of the industry for a very long time.

Collaboration, Community, and Creativity

Open Source has value beyond these practical considerations. Open Source Software has shaped how developers interact with each other and how we view our work.

OSS is collaborative. We build together what one person could not build alone. Ideas can be debated and refined. People can pitch in where they will be most useful or where they want to gain more experience. We build something together that is greater than the sum of its parts.

When done well, OSS can bring together people from around the globe, from various backgrounds and groups. Communities spring up among people who maintain and contribute to an Open Source project and among those who use the project. There are numerous friendships, business partnerships, mentorships, teams, clubs, and more that are a direct result of our Open Source ecosystem. Technology can have a tendency to isolate, so I am very thankful that there are things within our industry that bring people together to share ideas and to work alongside one another.

Open Source can be a creative endeavor within itself. People are building something new and interesting or improving on an existing project in innovative ways. It is also the foundation of creative work for many people, whether it is a just for fun project (I love those) or a more substantial creative endeavor that can be part of someone’s livelihood. Being able to build creatively is deeply satisfying for many and I am grateful that Open Source exists as a tool within this realm.

Challenges Inherent in Open Source Software

OSS has many benefits (more than just those discussed above) but it is important to understand its limitations and challenges in order to use OSS in a responsible and ethical way.

I don’t pretend to know what all of the challenges are–I would love additional perspectives from everyone from users, to first time contributors, to seasoned maintainers. I am going to mention a few Open Source challenges that are relevant to understanding how we can responsibly use OSS and are broadly true about the majority of projects.

Volunteers are Amazing, and Can Opt Out Whenever they Like

Contributor. Maintainer. Board Member for a specific project. You are wonderful and the community is so appreciative of your work. Thank you for the time and expertise that you have contributed to Open Source.

The community has many reasons to thank the people who make our favorite projects possible. We are very grateful, but I hope we are able to check ourselves whenever we begin to feel that we are entitled to your time or contributions. Burnout is real. Making space for new endeavors–whether technical, personal, familial, or simply rest–is 1000% valid.

Users of OSS need to keep this in mind. The use of Open Source Software may seem fairly similar to commercial software, at least in your day to day work. But it is fundamentally different in that it is not reasonable to have expectations about when new features or versions will be ready or that issues, bugs, or vulnerabilities will be addressed immediately. We are not owed anything by volunteers.

Transparency has Pros and Cons

Another issue with Open Source is that it is well, open.

Don’t get me wrong. This is a strength of Open Source. Issues can be caught by the community. If you are using the software you can dig into it so you are sure of what it is doing. You can make changes that you deem necessary.

It also means that bad actors can examine the code in order to exploit it.

What These Challenges Mean for Users

So how do these challenges impact our work?

I see them as an opportunity to understand the industry better and to think about what I can do to deliver the very best product that I can. I see these challenges as an opportunity to create a recovery and mitigation plan for when things go wrong, either with my code or with my dependencies. Both working within this these challenges and using the many benefits of Open Source have the capacity to make me a stronger developer.

I want to discuss a few ways that different groups and individuals can take these opportunities as well.

It Takes a Village

Together we can all ensure a bright future for Open Source Software. I have suggested a few things that different groups can do to help foster responsible use of Open Source Software.

Maintainers

Thank you for everything you do! Your work has contributed to so much promise and possibility to the world. You do not owe us anything, but if you want to contribute to the discussion and make your project easier to use in a responsible way, please consider the following steps.

Be Sure to Select the Best License for Your Project’s Needs

For a project to be Open Source, it needs a license. There are a number of options and and they have different implications for how the software can be used and reused. I am hoping to write more about different kinds of licenses in a future post, but this is a very good resource.

Be Transparent About Security Measures

Maintainers and contributors to OSS can come from many different backgrounds, which may or may not include security literacy. This shouldn’t disqualify anyone from contributing, but it is reasonable to include documentation on what measures have and have not been implemented. If this is included, users can better access how they want to use the software.

Have an Exit Plan

At some point it may be time for you to move on. You may no longer have an interest in maintaining the repository, or want to invest your time elsewhere. If possible,  draft an end of life plan for the project, or hand over the maintenance of the repository to someone you (and ideally the community) trust.

Companies

If you use Open Source Software at your business, invest in its future and do what you can to use it responsibly.

Contribute

Contribute financially and/or contribute developer time to help the projects you use continue forward. Especially if you have developers who have specialized skill sets (ie. security), their ‘on the clock’ contributions to the project will be worth it to your company and to the community.

Document and Plan

Keep close track of the OSS projects that you use and the dependencies that those projects use. Build time in your roadmaps for your developers to keep up to date with their project versions or refactor when a particular tool is no longer supported. Those kind of things are not “nice to haves”, they are essential to a healthy project.

Use Available Tools

You don’t have to do everything yourself. There are solutions for helping you identify problems in your code or in your dependencies. You can learn more here and here.  

Responsibly Report

If you find a problem in one of your Open Source dependencies, do the right thing by the community. Write a patch, notify the maintainers of the project, and work with them to make sure the fix goes out in a way that will minimize potential damage to others in the community. There are groups in this space that are willing to help you do this right. 

Individuals

Educate yourself on OSS. Github has a number of Open Source guides that can give you a good introduction. Keep track of your dependencies. Consider a security tool (many are free for Open Source and other public repos). Write tests, monitor your apps, keep up to date. Advocate for a more deliberate Open Source plan at your workplace.

Communities

Tech communities come in many different forms. They can be based on language or tools, geography, overlapping identity, educational background, or on some combination of all of these things. For instance, I am part of an online community for women and other gender minorities in tech who graduated from a specific bootcamp and largely work with Python.

These communities have the chance to set the tone. If you are a leader in a tech community, consider including discussions on things like engineering ethics, security, and open source software into your community life. This could take the form of an event, a dedicated slack channel, or just starting a conversation. If you are organizing a conference, consider soliciting and accepting talks about these issues. We can make the space to have these important discussions.

Ethical Open Source

Engineering ethics involves taking responsibility for your code and the impact it has on others. Although it might seem difficult to integrate OSS into this framework, stakeholders can take steps to be sure that Open Source can be used responsibly.

I want to express my thanks to everyone (whether they are writing Open Source or working on private projects) who considers the impact of the code that they write. I believe that kind of consideration and thoughtfulness will be important as the industry moves forward and tech is further incorporated into our lives.

Resources

I have found the GitHub Guides to be really interesting and informative on different aspects of Open Source Software.

This video on Who Owns Open Source Security was also very good.

This is my talk on engineering ethics, which was mentioned in this blog post.

I needed a sample project.

And that could only mean one thing–I was going to build something related to running. I can’t explain this impulse except by saying that I am easily motivated by these sorts of projects.

So I would like to introduce you to My Marathon Buddy, an app that aims to make your run a little more positive. It does the following things:

1. You can fill out this form to get an initial text from me.
2. The number you received this initial text from is my Twilio number.
3. When you are out for a run and need a boost of motivation, you can send a text to my Twilio number and you will receive a random encouraging text back.
4. If you want to contribute to the motivation, you can add encouraging texts here.
5. I gave myself mad power. I can actually post short updates about my training to the website by sending texts! I have not given you this power, but you can see the updates at the bottom of this page.

This project is written in Python 3.7 and uses Django 2.1. The core functionality is built with Twilio’s Python SDK and utilizes their API. It utilizes a MySQL database and is hosted on pythonanywhere.

More features/minor improvements will roll out soon and I will be writing about them here. In the meantime, please feel free to poke around the site a bit.

 

It is the middle of October, and I have just finished up giving my intimidatingly named talk We are 3000 Years Behind, Let’s Talk About Engineering Ethics. Djangocon 2018 is the fifth conference where I have given this particular talk since July. My local python user group was also kind enough to let me practice on them in September.

I am as surprised as anyone to find myself criss crossing the US this summer and fall telling people about how my old job had specific ethical rules and maybe developers should think about some too. It was an idea that I had on a whim, but it really resonated with conference organizers while they were setting up their talk schedules and eventually with conference goers too.

Here are a few things I learned by giving the same talk 6 times over three months.

Practice Really Matters

This isn’t surprising, but I didn’t appreciate how true it is. Practice really matters.

I have relied on my experiences in front of crowds (shout out to Good Company Player’s Junior Company, with whom I performed hundreds of times as a kid) to let me coast through my talks. I wasn’t very nervous in front of crowds, and I know that kind of calm is elusive to many. The first few times I gave the talks, I hadn’t practiced much because I didn’t need to in order to calm anxiety.

But practice does more than provide you with the required confidence to not faint on stage.

Practicing….

• Helps you edit
• Makes sure you won’t be severely undertime or overtime
• Helps your talk sound more natural
• Reduces surprises

And practice absolutely decreases anxiety, even if you aren’t super prone to that problem.

Listen to Yourself

This may sound weird but you might want to make sure you don’t sound weird.

I gave my ethics talk at the end of July and sometime in August I had to watch a video of the talk to okay it being posted on youtube. So I watched myself give my talk.

And I was mortified! I did this clicking thing with my tongue and once I heard it, I will never be able to unhear it until the day I die. This clicking sound is exactly the sort of thing that makes listening to your own voice an uncomfortable experience. I am convinced that I was judging myself more harshly than any of my attendees (at least none of them mentioned it in their speaker feedback). Regardless, it was still something that I am glad I found out about after my first time giving the talk so I could stop and not make that mistake again.

After this experience, I picked up the habit of recording myself giving my talk and then listening to the recording on repeat during my weekly long run. Doing so doesn’t strike me as a particularly normal thing to do, but it was effective.

To summarize, listen to available recordings of your talks and make your own recordings and listen to those as well. You will find ample opportunities to improve your performance and your content.

Get Some Feedback

After your talk, it is very likely that people will come up and ask you questions or have stories to tell you related to your talk. It is almost always a good idea (unless someone is being weirdly aggressive or something) to have these conversations. You may learn something relevant to your talk, you may gain insight into how the talk has been perceived, you may learn that certain points could use more clarity, you might get a kind compliment , or meet a new professional contact or friend.

There can be awkwardness to these kind of interactions and you don’t need to incorporate all feedback you get, but I have found that I usually come away from these discussions with ideas of how to improve my talk.

Use What You Have Learned for Your Next Proposal

All good talks must come to an end and eventually you will probably want to retire your talk from your repertoire. If you are a frequent conference speaker, this will probably mean that you will want a new talk proposal to send around to conferences with open cfps.

Use your experience from giving your talk multiple times when you are crafting that next proposal. I am currently asking myself the following.

• What kinds of content did people respond well to?
•  What kinds of conferences fit your presentation style and your personal preferences? Single track? Multi track? Language agnostic? Community conferences?
• Is there a way to build upon the topic you have already spoken on, or should you try something entirely new?

Thank You

My whirlwind experience of traveling the country and giving this weird little ethics talk six times wouldn’t have been possible without the conference organizers who believed in the idea and some of whom found money in their budgets to help me with travel. I appreciate it immensely.