Skip to main content

Nebraska Code Camp 2014

I attended the Nebraska Code Camp this weekend and wanted to share some thoughts on the sessions I was able to sit in on.

Iris Classon started the day with her keynote speech and I really enjoyed the keynote.  The speech was not technical, but instead focused on her life story and her passion for technology and developing software.  She is a very good speaker and was entertaining with her story telling.  I was energized and motivated after hearing her talk and really excited to learn more throughout the day to increase my passion for becoming a better developer.

The first session of the day I listened to was Cory House, Becoming an Outlier: Rebooting the Developer Mind.  Cory is a fantastic speaker, he was always entertaining while also providing great information in his talks.  This session will soon be a course on pluralsight.  I will be watching that course when it becomes available.  This session followed up very nicely with Iris' keynote, it further emphasized that following your passion will keep you happy.  Cory also brought up an interesting idea that as you become better at something your passion for it grows as well. The main point I took away from this session was to streamline things out of my life that do not add value to my passion. If I want to become a better developer, then I need to devote more time to developing and to find more time I need to sacrifice other things that do not help me become a better developer.

Next was SOLID Design Patterns for Mere Mortals with Philip Japikse. Again Philip was a great speaker.  For the most part I think I ended up going to session with great speakers and that really helped the conference be a success for me. This course covered a high level overview of design patterns. I have heard about most of these before, but haven't implemented them so getting to see some uses of them was valuable.  Philip purposefully chose silly and abstract uses of these patterns as so that people would learn the concept without trying to copy and paste, or as Philip described - clipboard inheritance.  This worked for me in some of the examples, but in others I found it difficult to figure out where I could apply that pattern in real code. I definitely need to continue learning these patterns so that I can apply them where needed.

After lunch I went to another Cory House presentation, Pragmatic Software Architecture: Curing the Architecture Astronaut.  This discussion focused largely on the pragmatic idea from the title. There is a "Best Practice" approach to developing software and we all strive for that ideal, but in some situations it isn't always needed or appropriate to force development to follow those "Best Practices." There are business reasons to add technical debt or to use a faster or more simplistic approach when writing code. I have been guilty of wanting to make sure the code I produce is the best it can be and forcing those "Best Practices" in situations that didn't need it. I need to remember to step back and look at the greater picture before making a decision on which approach to take to make sure it is the best for that particular situation.

Next up was the major disappointment of the conference for me. TDD Mastery - Writing Meaningful Tests with Jason Norris. I have no idea what happened here. Jason rushed through his slides in about 5 minutes, just reading the slides providing no addition comments. Then the last 2 slides were information about other sessions going on at that time. He then left and went to watch a panel in the gym. This was a big letdown and waste of my time, I would have preferred that he just canceled his session so that I could have made it to another one I wanted to attend before it started. On Jason's first slide he talked about his company, Farm Credit Services of America, and how it was the best place to work in Omaha. Well based on this "talk" I was left with a very bad impression of him and his company.

Maintainable Unit Tests - that's an oxymoron right? by Andy Bayer followed up the last session by actually covering the previous topic and his own information.  Andy provided a lot of good knowledge, I think maybe he was a bit nervous with his presentation, but overall I thought he did a great job and enjoyed the talk. One key point I took away from this session was the idea of keeping Mocks or Fakes in a centralized location. If your application has 1 repository, why would you then want to create a Fake repository in each of your tests? Treat your tests the same as other code, use SOLID principles and DRY to keep your tests maintainable.

Lastly was, Why Agile? The Economics, Psychology, and Science of Agile's Success with Matthew Renze. Focusing on the reasons why Agile is better than Waterfall I think this talk would be great to get in front of management at a business that has not adapted Agile philosophies. It seems to me that the hardest part of getting to an Agile environment is the initial buy-in from management and presenting them with facts and charts about how Agile would be an improvement over their current approach would help them get on board. One of the biggest points I took away was a chart that showed the relative cost of finding and fixing a defect in software at different points of the life cycle, with the cost for finding it in production 150x that of finding it in the initial stages. This alone should be reason enough to push an organization towards at least doing automated testing to try and keep as few bugs out of production as possible. Another valuable idea I brought away was that it should be ok to fail small and fail smart, meaning that if you do a little experiment that doesn't work out, you have at least learned something and not cost the company very much. Where if you make a large experiment you can have an epic fail which will cost you and the company dearly. You should focus on small, fast, and simple. Add over time as you know that the direction is worthwhile, don't assume you know what is right up front and risk being wrong in the end after too many resources have been committed.

All-in-all, I was very happy with the conference and look forward to using the knowledge I received to make myself better.


Popular posts from this blog

Converting a Large AngularJS Application to TypeScript Part 1

I work on a project that uses AngularJS heavily. Recently we wondered if using a preprocesser like CoffeeScript or TypeScript for our JavaScript would be beneficial. If our team is going to switch languages, we would need to be able to convert existing code over without much pain and we would have to find enough value in switching that it would be worth the conversion. I had read an article that stated that because TypeScript is a SuperSet of JavaScript, you could convert a plain JavaScript file to TypeScript by changing the extension to .ts and not much else would need to change. I wanted to test out this claim, so I took a file that I was familiar with, an Angular Controller, and tried to convert it to TypeScript to see how much effort it would take and then try to figure out where we would benefit from using TypeScript. This is what the controller JavaScript file looked like to start out with: ( function () { 'use strict' ; angular .module( 'app'

Interns: Taking off the training wheels

My intern team has been working for several weeks now on our new website. We have already completed one deployment to production and are finalizing our second one. We started with a plan to release often adding small bits of functionality as we go and so far that plan has been working really well. We already feel like we have accomplished a lot because we have completed many of our project's requirements and should easily be able to complete the rest giving us time to do even more than just the original requirements. One of the things I have had some difficulty balancing has been how much to lead the interns and how much to let them figure out on their own. In deciding what our team process should be and how we should allocate our time, I think it was important for me to do more leading. I saw some deficiencies in how we were currently working and brought up some ideas for how we could address them. We had moved into spending all our time just working through stories and did not

My idea for Hearthstone to add more deck slots

Recently someone asked the Blizzard developers for more slots for decks in the game Hearthstone. The response was that they are talking about it and looking into it, but no decision has been made yet. One of the concerns over adding deck slots is that it could complicate the UI for Hearthstone and make it more difficult for new players to understand. I have what I think would be a good solution to add more deck slots without increasing the learning curve for the game much if at all. First I would take a look at the current selection screen for starting to play a game. It defaults to showing the decks that are custom built by the player if they have any custom decks, and there is an option to page over to the basic decks. This basic deck screen is perfect for how I would change this process. Instead of having 2 pages of decks, 1 for basic and 1 for custom, you would just see the select a Hero screen. Then once you selected the Hero you wanted, you would see all of the decks that