Scenic City Summit 2017 In Review


This was Scenic City Summit’s second conference and I heard so many great things about it last year, that I was super pumped to be accepted to speak here. Looking over the speaker list, I was floored at the quality and topics they had selected. Not only was there some .NET, but there were tons of sessions on best practices, different back-end languages, different front-end languages, career, and soft-skills. For this to be a single day conference, I was impressed that they could fit so much awesome in such a short time period. For every time slot, I had at least three sessions I’d love to have seen. Huge shout-out to Scenic City for the awesome job on speaker selection!

Tame the Front End with Elm by Jeremy Fairbank

In this session, Jeremy introduced us to a functional front-end language called Elm. Elm is a language that compiles down to JavaScript, but it’s power lies its default architecture style “The Elm Architecture”, where by defining a Model, a View,  Messages, and an Update function, you could write sophisticated web applications.

Even thought I’ve used Elm in the past, I still learned a lot about the power of Elm and how by using functional concepts, you can easily reason about complicated

Not only was the content fantastic, but Jeremy’s presentation skills are amazing. His thoughtful choice of words, his examples, and his slides really helped get his points across and made it memorable. This session was amazing because not only did I learn some cool new things about Elm, but I learned how to be a better presenter.

Slides can be found at

Canary Deployments for Continuous Delivery by Chris Keathley

In this session, Chris showed us how his team was able to deliver value faster by leveraging Continuous Delivery practices. For example, leveraging automated tests to make sure that the code your deploying isn’t going to break or for your database scripts, make them additive (i.e. add columns and tables, never delete), so that if you need to roll back, it’s painless. As someone who’s currently helping a team set up their deployment pipeline, I was happy to hear that I was on the right track.

One thing I appreciated about this presentation is that Chris’ style is completely different from Jeremy’s, but no less effective. Whereas Jeremy’s approach is methodical and deliberate, Chris’ is more off-the-cuff and he was easily able to sculpt the talk to fit his audience which really helped to get his ideas across.

Guide for the Reluctant Leader by David Neal

For the closing keynote, David Neal told us his story about he struggled to stay as a developer as he kept being promoted to management. Not only did he tell great stories and his trademark drawings, but he gave us some tips and tricks for how we could survive moving into management. This keynote was hands down one of the best sessions I’ve ever seen. Seriously, if you missed this session, you really missed out!

Slides can be found at

Wrapping Up

This was my first time speaking at Scenic City Summit and I had a blast. I was a bit worried about the shorter sessions (45 minutes), however, the length was great and it allowed to have more sessions which really helped to build up a diverse set of topics. Not only were the sessions great, but I had fantastic conversations with both speakers and attendees that inspired me to continue doing better and to be awesome. I’m already looking forward to next year!



Detroit.Code() is another conference under the Amegala umbrella and I was pumped to be here. I spoke at Indy.Code() earlier this year and had a blast so I was already looking forward to going to another Amegala conference.


For the conference, we were going to be staying at the Detroit Marriott at the Renaissance Center in downtown Detroit. The hotel was very clean and quiet, my room was great, and I had a fantastic view of the Detroit River and Windsor, Ontario, Canada


For the venue, we’d be presenting at the Renaissance Center in Detroit. From an attendee perspective, this was great because going from my hotel room to the conference was as simple as an elevator ride. This was super convenient if I needed to go back to my room in case I forgot something or to get ready for the attendee party.


For the conference itself, the organizers tried two new ideas with what I think were mixed results. The first was to not have a speaker’s room. For those who aren’t aware, most conferences have a room just for the speakers where a speaker can make adjustments to their presentation, socialize with other speakers, and to relax. At first, I wasn’t sure how that was going to work out, but with the conference being so close to your room, it actually wasn’t that big of a deal. In addition, I found myself interacting more with the attendees since there wasn’t a dedicated room.

For the second idea, Amegala changed how they gathered feedback for the sessions. Instead of using index cards similar to Indy.Code() or what I’ve done in the past, they actually included a section for feedback in the website with the idea that you would login to the website, click on the session and leave feedback.

This is a cool idea because speakers can get immediate feedback without waiting on the organizers to gather the data, format, and send it out. However, some of the attendees weren’t aware they could leave feedback in this form and since they have to log in to the website, there was an added barrier to leave feedback.

Day 0

Up and Running with Angular by Justin James

I typically don’t attend workshops at conferences, but I’ve been learning more about Angular lately and I heard that Justin was a great presenter, so I was looking forward to this workshop.

This was a full day workshop that started you from nothing and you built up a To-Do application using Angular. But before you step away, this isn’t your average To-Do, this application handled data persistence using 3rd party APIs, a way to log in with a username/password, deploying, different ways of doing forms and more.

In addition, this workshop has some of the best documentation I’ve ever seen (take a look for yourself: Clear steps, example code, ability to copy snippets instead of hand-typing and what the completed code should look like at the end of every section.

I was only able to catch the first half of the workshop, but this was so well done. It took the pressure off from having to keep up with everyone and allowed me to go at my own pace and ask questions if I got stuck. Seriously, if you get the chance, go to this workshop.

Day 1

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


Overall, I had six people attend the session and zero left feedback in the official channel. However, I was able to catch up with one of the attendees (Sam) and we were able to chat more about how to work with static classes with dependency injection.

Presentation and resources can be found here

Liven Up with Logic Apps by Gabrielle Crevecoeur

In this session, Gabby presented on Logic Applications, what are they and how to create one. I knew absolutely nothing about this topic, but it turned out that Logic Applications are a Microsoft version of IFTTT (IF This Then That) hosted in Azure.

Logic applications work by defining two different pieces, actions (what to do) and triggers  (when to start). For example, a trigger may be Whenever a SharePoint page is updated and the action may be Send an email to Cameron with what changed.

To show, she created a Logic app that would send an email to her if there a tweet was sent containing #GoGabby and the tweet was recognized to be positive by leveraging Azure Cognitive Services. It seemed very straightforward to create the application and to wire the pieces together.

Something interesting about Logic Apps is that there isn’t much programming, it’s more like selecting pieces having them fit together to perform the steps you want. As Gabby said, it’s closer to putting puzzle pieces together than writing code.

Overall, I thought Gabby did a good job with demonstrating what Logic apps can do and how to set them up.

How Functional Programming Made Me a Better Developer by Cameron Presley

Overall, the reviews were pretty positive with 5/20 responding with 4 “great”, 1 “ok”, and 0 “awful”. Attendees who left feedback mentioned the following:

Loved his style, you could tell he was comfortable and the information presented was highly informative.

It was really cool and great to me from OO background.

Great show of how functional programming can be helpful to making developers better at writing code. I learned that I should make classes smaller, more fail safe, always return an object of some sort, and how to use functional programming to drive my skill.

Slides and resources can be found here

What is DevOps by Curtis Cockerham

In this presentation, Curtis cleared some of the confusion around “what is DevOps”. For example, DevOps is not using the cloud. DevOps is also not a team or a position, DevOps is about communication and making sure that everyone is aware of what’s going on. DevOps is the opposite of “throwing it over the wall”. For example, if a developer choose a particular technology, it’s letting the infrastructure team know about the technology during development, not right before pushing it to production.

Throughout the presentation, Curtis refers to two books The Phoenix Project and The DevOps Handbook. I’ve read both of these books before and it was reassuring to hear that his take on the books was close to what I was thinking. In addition, he was able to clarify a few concepts that I can now leverage for the DevOps’ process at work now.

Overall, I thoroughly enjoyed his presentation style and content. For it being the last slot of the day, he brought some much-needed energy into the room to cap off Day 1.

Day 2

Design Patterns: Not Just For Architects by Jeremy Clark

In this presentation, Jeremy covers what are design patterns, where the inspiration of a pattern comes from, and how even though we aren’t conscious of them, we’re using some of these design patterns in our day-to-day work. The problem we run into is when we unconsciously use a design pattern because that means we didn’t consider the weaknesses of said pattern.

To demonstrate, Jeremy covers four different patterns (Observer, Proxy, Chain of Responsibility, and Iterator) and how through typical work, we seethese patterns. For example, when we register a handler for a button’s onclick event, that’s using the Observer pattern. When we wrap an external resource (like a SOAP service) and treat it like it’s a local resource, that’s using the Proxy pattern. When we add multiple catch blocks for exceptions, that’s an example of the Chain of Responsibility pattern. Finally, anytime we’ve used a foreach loop, that’s an example of the Iterator pattern.

I’ve seen some of Jeremy’s sessions before so I know he’s a great presenter, but what I particularly enjoyed about this session is that he removed some of the ivory tower mysteriousness of design patterns and made them very approachable for a developer.

Slides and resources can be found at

A feature-based approach to software development by Ryan Lanciaux

In this presentation, Ryan covers some of the advantages of following a feature-first approach to software development. To start with, the idea of grouping files by concept (like models in one folder and views in another folder) might make sense for a small application, but as time goes on and the application grows, each of these folders will have dozens of files and it’s hard to find anything.

Instead, what if we had feature folders? The idea is that everything related to the feature (models, views, controllers, services) lives in the same place and therefore, it’s a bit easier to find what you’re looking for. In addition, this promotes the idea of vertical slicing of an application instead of the more traditional horizontal (layers) approach.

One advantage of using feature folders is that toggling features on/off (i.e. feature toggles) is really simple because you either include the feature folder or not. As someone who’s looking into taking on a more DevOps approach to software development, the ability to easily include/exclude features is nice!

Overall, Ryan’s presentation covered some great points about feature folders and how to migrate your current application to use feature folders

Creating a Solid Web Application Architecture using Angular (2+) and ASP.NET Core Web API by Richard Taylor

In this presentation, Richard covers on how to develop a solid application using Angular for the front-end and ASP.NET core for the backend while respecting major architecture concerns. In Richard’s opinion, an application needs to respect Scalability (the ability to grow horizontally), Extensibility (switch one layer out with another), Separation of Concerns (UI shouldn’t know about the business rules), Security, and Availability.

Most of the presentation was demonstrating a speaker registration application built with these concerns in mind so it was interesting to see how someone else approached solving a problem with the above constraints in mind.

Overall, I thought Richard did an excellent job outlining the architectural concerns of building an application and how to leverage Angular with ASP.NET Core. In addition, he was able to handle a lot of questions from the audience about certain design decisions and how they made sense given his concerns.

Source Code can be found at

It’s Dangerous to Go Alone, Take This! by Curtis Cockerham

In this presentation, Curtis discusses the importance of having a mentor and how having a mentor can supercharge both your career and life and that by mentoring, you’re helping someone become a better person.

What I really enjoyed about his presentation is that he covers the kinds of mentors you’ll encounter and the strengths of one over another. For example, a career mentor is great for you learning on the job and getting better, but they’ll typically not do a great job in your life outside of work. On the other hand, a life mentor can really help make sure that your relationships outside of work are going well.

Overall, this was my favorite session of the conference. Not only was Curtis able to make a strong argument for the benefits of having/being a mentor, but he was able to entertain and connect well with the audience. If you get the chance to see Curtis give this presentation, go to it!

Slides can be found at here

Wrapping Up

For the first ever Detroit.Code(), I thought the conference was well put together. There were hardly any issues with the space, the workshops and sessions were fantastic and the attendees were great. I appreciate the hard work the Amegala group put in to make this event as successful as it was. I’m already looking forward to see how Detroit.Code() will grow in the future.



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


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

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

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, 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

Day 2

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


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

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

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


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

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!



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.


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.


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.



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


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.


How Functional Programming Made Me A Better Developer


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#



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