Conferences

Background

I was at CodePaLOUsa last year as an attendee and I had a pretty good time, but this was my first time as a speaker, so I wasn’t 100% sure what to expect. One thing that immediately caught my attention was that there wasn’t a room for speakers to get ready or to practice their talks. I didn’t know what to think of this at first, but overall, I actually like the idea. A trap that I’ve fallen into in the past is to spend too much time in the speaker room and not enough time hanging out with attendees so this was a great way to get me out of my comfort zone.

On that note, I was impressed with how Chad Green and crew have been able to have as many different venues as years (6 venues in 7 years) and yet the conference seems to run without a hitch year after year.

Day 1

Making the Unstable Stable – An Intro To Testing by Cameron Presley

Feedback

Overall, the reviews were pretty positive with 30/41 responding with 29 “great”,  1 “ok”, and 0 “awful” with a 73% overall participation rate. From the comments, here were the major trends.

  • Very engaging
  • Have me sold on starting testing sooner than later
  • Your talk was the best one all day!
  • Your energy is awesome!
  • Presented to programmers but also QA. I am QA and was able to follow along
  • Very helpful as I move into QA automated testing from strictly manual testing

Slides can be found at https://www.slideshare.net/CameronPresley/making-the-unstable-stable-an-intro-to-testing


Everything I Needed to Know About Debugging I Learned in Elementary Physics by Nate Taylor

In this session, Nate talked about his experiences learning physics in undergrad and how impossible it felt to solve the problem especially with other students looking at you. However, his professor had a system for administrating partial credit if the student in question did the following:

  • Create a labeled diagram
  • List what is known
  • List what is unknown
  • Write out a starting equation

For Nate, this turned the “impossible” task to “achievable”.  Not only did he show this technique by solving a couple of physics problems, but he then draw parallels to solving physics problems to how we troubleshoot problems with our applications by stepping through two different issues. What I really appreciated in this talk was that we started on a problem with a simple enough domain and the audience worked together using the technique to debug the solution.

Slides can be found at https://github.com/taylonr/romanNumerals/tree/develop


Not Just My Opinion by Martine Dowden

In this session, Martine talks about how do we actually validate a design. We’ve all heard from users that “they’ll know it when they see it”, but what does that actually mean? Her argument was that design has a single purpose (to visually communicate a message) and that a good design will never be noticed, it’ll be seamless. From there, Martine talked about the Gestalt principles of psychology and how they apply to design. To prove the point, she walked us through a sample music e-commerce store and by following these principles, we iterate to a better design.

One cool thing I loved about this presentation was at the end where she showed us popular websites and we walked through some of the good design decisions she made. Given this was near the end of the day, Martine brought a massive amount of energy with her and you could tell she was super interested in this topic and that transferred to the audience.


Getting Functional With Elixir by Nate Taylor

In this session, Nate discusses the basics of functional programming using Elixir as the motivation. Some thing that really stuck with me was his description of a functional language: declarative paradigm (what vs how), functions as first class citizens (functions have the power), and immutability (data doesn’t change).

After explaining these concepts, we dove into looking into the different constructs (pipe forward, pattern matching, return values, structs, and recursion). To wrap things up, he showed us Exercism.io, a site where you can level up your programming skills in various languages.

Overall, I thought Nate did a excellent job demystifying the jargon of functional programming and provided a  primer for the for the developer interested in learning more about functional programming.

Slides can be found at https://github.com/taylonr/get_functional_elixir


Day 2

How To Have Code Reviews Your Developers Actually Want by Cameron Presley

Feedback

This is the third time I’ve presented this session and based on some feedback I got from CodeStock 2017, I made some changes. First, I emphasized that the reason I don’t cover tools is because a lot of the pain points from doing code reviews come from the process used for reviews, not the tooling. Your developers are smart and can find the right tools for themselves, but no tool can fix a bad process. In addition, I focused more on speed and checking in with the audience more often.

Overall, the reviews were pretty positive with 36/45 responding with 35 “great”,  1 “ok”, and 0 “awful” with a 80% overall participation rate. From the comments, here were the major trends.

  • Helpful technical and professional information
  • Liked the “how are we doing” check ins.

Slides can be found at https://www.slideshare.net/CameronPresley/how-to-have-code-reviews-your-developers-actually-want


Care and Feeding of your new Junior Developer by Michael Hand

In this session, Mike showed us not only the reason we should be hiring junior developers, but also how to grow them into the developers we need. His approach was to have our juniors get better by teaching them soft skills (how to communicate and that everyone comes from different backgrounds).

To sharpen their technical skills, pair programming and code reviews can accelerate their learning. With that in mind, Mike defines experience as the combination of time and feedback and that it’s our responsibility that we’re providing Specific, Meaningful, Actionable, Relevant, and Timely (SMART) feedback. Otherwise, the developers will go where there is feedback. This was one of my favorite sessions of the conference and I took so many notes to take back with me.

Slides can be found at https://github.com/stirtrek/2017MayStirTrek/blob/master/Talks/MikeHand-CareAndFeedingOfYourNewJuniorDev.pdf


Establishing a SOLID Foundation – An Intro to Software Design by Cameron Presley

Feedback

This is the first time I’ve presented this session since I’ve started gathering feedback and I was curious to see what the audience thought. Overall, the reviews were pretty positive with 37/50 responding with 34 “great”,  3 “ok”, and 0 “awful” with a 74% overall participation rate. From the comments, here were the major trends.

  • Super helpful, but I didn’t have time to really read and understand the examples, much less write the “fix” for the problem
  • Because of my weak understanding of interfaces, I got lost with dependency inversion
  • Great speakers make topics fun to learn about!

Given the feedback, I might need to scale down the complexity of the code samples and it might be worth spending some time on interfaces as preparation for Dependency Inversion.

Slides can be found at https://www.slideshare.net/CameronPresley/establishing-a-solid-foundation-an-intro-to-software-design-76802444


Going into the wild by Lisa Redemann

In this session, Lisa (QA Manager for UPS) discusses the challenges of gathering requirements for a product in the field by telling a story of when UPS replaced paper charts/maps with an iPad for their pilots. First, Lisa described what the problems were with the application/roll out (lack of conditional/non-functional requirements and little understanding of user issues). Then, she described her scientific approach (observe users using the device and app in a day) while establishing the scope of the observations (only the core use of the device).

Something that was pretty cool was how she was able to be in the cockpit of the plane, watching how the pilots were interacting with the device during a flight. At the end, she talked about some of the hurdles of finding the right crew to observe (honest and constructive) and some of their assumptions that didn’t pan out. For example, they thought that the device would be docked often, but that wasn’t the case. They also thought that the daytime/nighttime toggling feature would be used, but it was hugely important.

Wrapping Up

This was my first time speaking at CodePaLOUsa and as a speaker, I had a great time. Not only were there fantastic sessions, but I had multiple conversations with attendees about the cool sessions they had seen and what they had picked up from them. It was definitely humbling to have attendees who saw one of my earlier sessions come to my other sessions based solely on how awesome of a job I did before. I will definitely be applying back to speak for next year!

Conferences

Background

This was my second year speaking at Music City Code and I was already looking forward to it. So many great speakers on so many great topics, there were many times that I had to make a tough choice of which session to go to. The big thing I appreciate about Music City is that it’s such a low pressure environment to present. Everyone is super friendly, asks great questions, and overall are just awesome to be around.

As Music City enters its third year, Gaines and Mary Kergosien have made some changes that drastically improved the experience.

First off, a change in venue. Up to this point, the conference was held at Lipscomb University, but this year it was held at Vanderbilt University. I’m totally in favor in the change of venue if for no other reason, the campus is gorgeous (so much greenery so close to downtown).

Second, due to the change in venue, they were able to have speakers stay at the dorms in lieu of a hotel room (if they wanted). I didn’t know what to think of the idea at first, but after the first day, I was totally sold. Not only were we hanging out during the day, but we had a convenient place to hang out in the evening so it really provided an immersive experience.

Last, but not least, Music City introduced a feedback system for their speakers. As attendees came into the room, they were handed three cards (red, yellow, and green) where they could leave their feedback and turn the cards in at the end of the session (for more information, take a look at a similar system I used for CodeStock this year)

Day 1

F# Type Providers by Chris Gardener

In this session, Chris demonstrated how to use three different type providers by live coding an application. For those unfamiliar with type providers, a type provider typically analyzes a data source (at compile time) so an object can be created at design time for use.

As part of the demo, he worked with the AppSettings type provider (which analyzes your App Settings file), the JSON type provider (great for working with Web APIs), and the SqlDataConnection type provider (similar to LINQ-to-SQL). Throughout the demo, Chris demonstrated how the various type providers worked, the ease of use, and how they’ll behave under certain conditions (for example, when fields may/may not have a value)

Overall, this was my first time seeing Chris speak and he definitely had an aura of energy about him. What I really enjoyed about this session is that since he was live coding it, he could really demonstrate how quickly he could go from nothing to something.

Slides and code can be found here

Functional Programming Panel

In this panel, four members of the functional community (Reid Evans, Jeremy Fairbank, Tim Pote, and Chris Keathley) answered questions related to functional programming like what is immutability, why should I care, and what are some of the benefits. One of the big takeaways I had from this session is that functional programming is still just a tool and it can’t save you from yourself. You can still write bad code in functional.

FSGD and The Art Of Delivering Value by David Neal

In this session, David tells the story of a time where LeanKit (his employer) shipped a feature, but it took an insanely long time to get it out the door. From there, his company iterated on fixing the problem and came up with FSGD (pronounced Fizz Good). FSGD is an mnemonic for Frequent Small Good Decoupled and by following these principals, LeanKit is able to deliver more value to their customers in a shorter time frame.

This was hands down my favorite session of day one for sure. Between David’s speaking style, his custom illustrations, and the natural flow of the story, this session was real a winner for me.

Slides can be found here

Day 2

How To Have Code Reviews Your Developers Actually Want

This is the second time I’ve presented this session and based on some feedback I got from CodeStock 2017, I made some changes. First, I emphasized that the reason I don’t cover tools is because a lot of the pain points from doing code reviews come from the process used for reviews, not the tooling. Your developers are smart and can find the right tools for themselves, but no tool can fix a bad process.

Feedback

Overall, the reviews were pretty positive with 20/21 responding with 17 “great”, 3 “ok”, 0 “awful” with a 95% participation rate. From the comments, it looked like I did a great job, but some felt that content was too entry level and that my presentation itself was heavy on slides.

Slides can be found here

I’ll Get Back to You: Task, Await, and Asynchronous Methods in C# by Jeremy Clark

In this session, Jeremy walked through the evolution of asynchronous programming, first with the  Asynchronous Programming Model, then the Event Asynchronous Pattern, and then the Task Asynchronous Pattern.

After giving a brief history, Jeremy dove deep into asynchronous programming by demonstrating the differences using Tasks vs async/await by using a utility application. What was really useful about this presentation was all of the common “gotchas” that can happen when working with Tasks and how to solve the problem. As someone who’s starting to get more into Tasks, this was a great intro to the concept.

Slides and code can be found here

Software Quality Panel

In this panel, Phil Japikse, Jesse Phelps, Peter Ritchie, and David Neal fielded questions about how to maintain quality in your software, do standards matter, what can I do when no one at my job wants to write tests, follow standards, or perform code reviews.

Something that Phil said that really resonated with me was “What are the goals for your standards?”. There’s a lot of wisdom here because developers in general want to do the right thing, but it’s hard to sell them on standards if there’s not a clear reason why they should be followed.

How Functional Programming Made Me A Better Developer

This is the third time I’ve presented this session and based on some feedback I got from CodeStock 2017, I made more of a conscious effort to slow down and work on my pacing. One thing I did that I thought helped was that I introduced more pauses and checked in with the audience a bit more.

Feedback

Overall, the reviews were pretty positive with 32/33 responding with 31 “great”, 1 “ok”, 0 “awful” with a 97% participation rate. From the comments, it sounds like the audience resonated with my experiences learning functional programming, how it changed my programming style and inspired others to look into functional programming. Sweet!

Slides can be found here

Wrapping Up

Overall, I had a blast at Music City Code this year and I’m already looking forward to next year. Gaines and Mary, keep doing what you’re doing, you’ve got something special going on in Nashville.

Conferences

Background

As I start my second year as a conference speaker, I was lucky enough to be selected as speaker for CodeStock’s 10 year anniversary. It’s been a pretty crazy ride to see how much the conference has grown from when I first attended in 2013 to now.

CodeStock was the first technical conference I ever attended, so to be able to go from an attendee to a speaker in time for the 10th year was  humbling to say the very least.

For this conference, I decided to try something new. Over the past year, I’ve learned that it’s almost impossible to get feedback about your presentation from your attendees once the session ends. However, when I spoke at Indy.Code(), the gang at Amegala implemented a pretty effective system for gathering feedback. So I decided to carry out a similar setup and it only costed me about $10.

Ready? Here’s all you need.

  • Red index cards
  • Orange index cards
  • Green index cards
  • Paper bag

The idea is that as attendees are leaving the session, they write down their comments on the appropriate card and toss it in the bag. If they thought I did a great job, a green card goes in. If they thought I did an “ok” job, they could write their comments on the orange card, or if I did a really bad job, they could leave me a red card.

Audience Review

How To Have Code Reviews Your Developers Actually Want

Feedback

Overall, the reviews were pretty positive with 25 “great”, 5 “ok”, and 0 “awful” with an 85% overall participation rate. From the comments, here were the major trends.

  • Excellent job on how the information was presented
  • Lot of good content, but spoke a bit too quickly at times
  • Didn’t spend any time on tooling, and there were some questions about what tools to use for the review

For this session, it seems that I need to work on pacing the content and maybe add a section for tooling.

Slides: https://www.slideshare.net/CameronPresley/how-to-have-code-reviews-your-developers-want

How Functional Programming Made Me A Better Developer

Feedback

Once again, the reviews were pretty positive with 12 “great”, 1 “ok”, 0 “awful” with an 70% overall participation rate. From the comments, here were the major trends

  • Content was good and delivery was smooth
  • You were clear and understandable to someone with only a fumbling understanding of C#

Slides: https://www.slideshare.net/CameronPresley/how-functional-programing-made-me-a-better-developer

 

Audience Superlatives

  • This talk and the code review session were the best sessions I’ve attended so far this year!
  • Very entertaining; good information. I feel like I learned something
  • Handled questions well, very engaging most of the time, and good jokes
  • Nicely done! Concise, Specific, Doable, Actionable. I wish you could do this at my company