Emily Stamey

Developer & Human. Finding my voice.

Category: speaking

Workshop: Delivering the Most Valuable Features

about 15 people standing around a table that shows the story board for the mock project created by one of the three teams.

The groups share their story boards and plans for future work

On Tuesday at PHP[tek] Workshop Day, I had the pleasure of delivering my first workshop to a group of about 15 people. The workshop is titled Delivering the Most Valuable Features, and we discussed how to use User Story Mapping as a communication and planning tool on our projects. I have learned a lot from this strategy and hope to use it in future work. The group was really fun to work with, and came up with great ideas for project work, and used those ideas to plan future work, tying it to the primary goals of the team. I’m looking forward to giving this workshop at Dutch PHP Conference in Amsterdam on June 29th.

Speaking at OSCON

Emily speaking at OSCON

Last week I traveled to Austin, Texas and the O’reilly Open Source Conference to share a talk called What’s Your Skateboard?  This is a talk I enjoy sharing.  It gives strategies for organizing and planning work.  I started out talking so quickly that I tripped over my tongue a bit.  I got it under control and conveyed the useful strategies to my audience.  In another week, I’ll be giving this in a workshop format at PHP[tek], and I’m really excited about that!  A 40 minute time slot, such as at OSCON, doesn’t leave attendees time to try it out.  The practice will become a lot more clear when attendees can get their hands on some post-it notes and organize work.

In June, I will be giving this talk again at We Rise, and I will give both the talk and the workshop at Dutch PHP.  After that things will settle back down for me with travel and speaking.

What Community Means to Me

Ever since I began attending conferences again, there have been several things bugging me.  Primarily it’s that so little has changed since I started college and later attended my first conference in 2001.  I ALWAYS bristled when a speaker would give a long list of their fellow speaker friends held up as community leaders.  There is no way to list every speaker in that list, so it seemed to focus on that person’s friends.  I knew the omitted speakers would feel left out, but I also thought about everyone else in the room who was definitely a member of the community who could feel left out in this type of talk.  It’s taken me a while to put my finger on this, so please bear with me as I tease this idea out.

When did I join the PHP community?

Well, I learned PHP in 1999.  I was a webmaster for a department on campus.  The IT lead, Kevin, said I needed to learn PHP because it was really cool!  It was, and in 2000 I took my first full-time job using PHP to do super cool things on the Internet.  I would say that I became a member of the PHP community when I first took the Webmonkey tutorial and began asking questions and building tools on the Internet.

At conferences, there is this idea that you weren’t a member of the community before you began attending conferences.  This fails to recognize the PHP conference community as a subset of the greater PHP community.  I believe this raises the stage higher than the audience and higher than the developers who use PHP daily.  I believe it puts space between the speaker and the audience.  I don’t like it!

Who is in the PHP community?

The conference community is a much smaller world.  You see a lot of the same people, and friendships form and you can see these people online in between conferences.  It’s fantastic!  And when speakers are traveling from to many conferences, they become even more familiar with each other.  The developer who can only attend a conference each year is less familiar.  This is a tight, supportive community, especially when you are known.  However, I firmly believe:

The PHP community is each one of us who use PHP or supports a PHP tool.  Because when we try to define community as anything less, we’re just forming cliques.

I learned a lot about PHP from 1999 to 2014.  PHP grew and changed A LOT in that time.  When I see the conference community represented as “The PHP Community” it very clearly omits my 15 years of experience.  It leaves out my peers on campus whose bosses don’t value continuing education for their developers.  Being in that space and relying on documentation alone to do your job and bring your skills up is HARD.  People in these legacy spaces are fighting an uphill battle to modernize their applications because the code quality is not valued by the people in charge.

Maybe, after all of this perseverance, they get to attend a conference.  They hear long lists of the new things they should be doing and judgements of how bad it was to do things the old way.  Then a motivating speaker defines community as these other people, and I just think it’s so backwards.

We are Community and So Can You!

I want to hear from the people who inherit these applications.  I want to hear how they’re overcoming challenges!  Because those projects are infinitely more useful to me than a talk about some new tool that isn’t even production stable yet.  I want to see the projects that succeeded and the ones that failed because there is so much learning there.  When we are speaking to people, we should be inspiring them to try something new.  We should be sharing tools they need, empowering them that they are valuable members of our community, and opening the floor to welcome them when they are finally ready to share that big project.

I feel very lucky that there were community members and speakers who encouraged me at conferences.  I know these talks mean to motivate people, and they also include a lot of history and support.  But it always bugs me when anyone labels the PHP Community as anything less than anyone who uses PHP. But I don’t always see that coming from the stage.  And the  stage has a louder voice.  I’d like to see that change a bit!

Bootstrapping Talk

I have been presenting ‘Pulling Up Your Legacy App By Its Bootstraps’ at conferences and user groups.  It’s been a treat for me because I am learning a lot by sharing what I have learned in this project, and it seems helpful to the audience.  I’m meeting people who are in similar work environments and when I get to the tools we used, I usually begin to receive questions.  This is what prompts the most questions after the talk, too.

The first few times I gave the talk, I received a lot of enthusiastic questions about migrations with Phinx.  Some of my audience had either not used a framework with migrations or didn’t know a tool was available outside of a framework, so they were eager to bring those into their projects.  I added code samples of change(), up(), and down() methods to my talk.

I have been improving my description of Dependency Injection and briefly answering the question “what is DDD” and “why did you need it”.  I believe I’ve better illustrated that point, but I feel like I haven’t answered those in the best possible part of my talk outline, and I’m trying to sort out where it may make more sense.

The last time I gave this talk, I received some comments that composer seemed awkward or was frustrating to use.  As I asked questions, I learned that the pain area was actually about wanting to exclude the vendor folder from their project’s repo.  I was able to share that we commit our composer.json and composer.lock files to the repo but ignore the vendor folder.  This seemed to solve that issue, but I am curious if there will be other composer questions in the future.

Now that I have been able to add more code and explanation of the tools we are using, I am reorganizing my outline and optimizing the talk based on the feedback I have received.  I really enjoy giving this talk and helping people.  I hope I’ll get to share it more.

Speaking at Peers Conference

In April, I presented for the first time at Peers Conference.  ‘Pulling Up Your Legacy App By Its Bootstraps!’ was my talk title.  I was super excited and honored and humbled by the experience.  It was a very different conference in the best possible ways!  Even now, I don’t think I have unpacked the many ways the experience has changed me.  I’m going to try to share them here.

Submitting

I had never been to Peers Conference before.  I submitted because several speakers whom I admire recommended the conference, and I finally had an abstract I felt good about submitting.  I had tried to figure out how to share the useful pieces of this legacy project that had dominated my work life.  But the project was HUGE and difficult to put into pieces.

Getting Accepted

Peers selects talks using a blind approval process.  I did not pay attention to this before submitting because I was new and using a shotgun submission approach to becoming a Conference Speaker.  What I mean is that I felt my odds were pretty low and didn’t expect to win this opportunity.  But I did!  Peers featured almost 50% women speaking in its sessions.  The Developer track was dominated by women (75%)!  The lone male speaker on the Dev track was Matt Stauffer (but this isn’t about him).  It’s about me.  😛

I found out I was chosen, not by a form email but a phone call.  We talked about the conference, its community, and about the abstract I had submitted about bootstrapping.  I received advice for how my talk would be most helpful to the community I would be meeting.  It was wonderful and helpful as a new speaker to get this advice and support!

Preparing the Talk

I was offered so much support for preparing this talk!  I organized my first draft and gave it as a google hangout to speakers I admire (Elizabeth Naramore and Beth Tucker Long), and they gave wonderful advice.  I presented again to my supportive user group TrianglePHP.  They asked so many questions throughout my talk, which helped guide me toward the interesting parts and highlighted areas I could explain better.  This was a couple of months before the conference.

I consolidated a lot of those questions and added more code samples into the presentation.  A week before Peers, I organized a small group of developers at work to come listen.  I was really selective of who I picked because I wanted them to know me and to be comfortable giving me helpful feedback.  Unfortunately, I had a really hard time with the order of my slides.  I was saying things ahead of the slides and skipping over some details.  It was really frustrating because my talk ended early, and I had a bit of work to fill in gaps.  Luckily, these people were patient and kind.  They gave me some great advice for some structure to my talk and feedback for filling out the talk. Mitch Amiano and Dustin Wheeler, my teammates on the project, were so helpful, too.  They gave great advice for details I could explain better and corrected some technical details.

I continued revising my slides for the entire week, refining the flow and improving my speaker notes, hoping to keep myself on the current slide’s content!  And I camped in the hotel room on Tuesday, feeling unsure and making my notes cleaner and easier to read.  I was so relieved to only have one talk to give because I couldn’t imagine preparing two.  But I did finally have my talk ready on Wednesday morning and practiced it several times after.

Presenting

Thursday, my presentation was after the keynote.  It was one I was excited to see, Gregg Pollack from Code School (a learning site with interactive tutorials).  He shared so many great experiences of his team’s growing and how they were able to put their team needs first and grow together.  I wasn’t sure if I would be too nervous to watch his talk, but my nerves weren’t too bad, and I enjoyed his presentation.

I had about 30 minutes before my own talk, so there was plenty of time to get settled!  The A/V guy was super helpful and adjusted the lights to keep them out of my eyes.  He got me set up on the podium and microphone.  I was a bit nervous, but not terribly so.  It was just enough that I felt like I needed the podium and to stay close to my notes.  I chose the fixed microphone, which I later regretted because as I felt more comfortable, I couldn’t move away from the podium.  Also, the microphone drooped a bit, and I was shrinking to stay in range.

As far as I could tell, the talk went well!  I had a pretty attentive audience, and they asked great questions at the end.  Some of them were consistent with what I’d been asked before.  I was glad to have the code samples to use to explain in more detail.

I felt GREAT after giving the presentation!!!  It wasn’t like feeling relief after a test or something I dreaded.  I felt accomplished!  I felt like I had something neat to share and people appreciated it.  I felt like I had contributed something to the conference community I had joined!  I immediately knew I wanted to do it again.

Achievement Unlocked!

Speaking at Peers was incredible!  I met people who were encouraging and supportive who made me feel so welcome.  I never once felt like I needed to spout a list of my tech trivia to prove I belonged there or linger on the outside of a group.  I attended knowing only 2 people that I knew would be there.  I re-met two people, one from [php]tek 2014, and another from our old Laravel group back home! I made so many other new (old) friends while there.  It was an amazing experience!

I’ll be getting the opportunity to speak again soon at Open Source Bridge in June!  And I had the pleasure of speaking to DaytonPHP over Google Hangouts.  I’m feeling pretty great about it!  I’m so grateful for the chances to share this legacy project and the lessons we learned.  I’m enjoying the brief breaks from work to revel in an accomplishment.  I’m exploring new ideas and things I want to teach and share.  It’s awesome!  I can’t wait to do it again!

Celebrating Accomplishments

Lately I’m thinking about my accomplishments this year in tech.  I feel much more a part of the greater development community than I ever have before.  I owe a lot of that to my Co-Organizing the TrianglePHP meetup group and my TA-ing with Girl Develop It.  I have also overcome some of my hesitation to contribute code in Open Source again.

Read More

Powered by WordPress & Theme by Anders Norén