Monday, December 2, 2013

Thoughts On SCNA 2013

I had the opportunity to go to SCNA this year. It was a lot of fun and represented a lot of firsts for me:

  • First time going to SCNA.
  • First time going to Chicago (and trying the pizza there).
  • First time going to a conference outside of Utah.
  • First time being in a skyscraper over 20 floors (the event was on the 80th floor!).

I tend to lean towards introversion so conferences can be a bit draining for me but I'm glad I went. I was pulled completely out of my comfort zone which forces me to grow which is one tenant of software craftsmanship that I like.

I thought it would be interesting to put down my thoughts on my experience for anyone interested or at least so that I can reflect on them later.

Overall Themes


Within the software craftsmanship community, test-driven development is one of those things that's just expected. It's no longer new, hip or edgy, it's just what you do when you develop. You don't want to hit people over the head with it but it should be something that you are actively trying to improve on.


Naming is one of the hardest things in software development. If you've ever tried to work on code where a method name says one thing but the code ends up doing way more than was advertised, you know how important naming really is. My favorite thought was from Sarah Gray: "naming is an extension of thinking".

Dreyfus Model of Skill Acquisition (link)

The Dreyfus model of skill acquisition (or skill expertise) came up many times during the conference. You can follow the header link for more information but the major themes were to not get yourself stuck in the advanced beginner stage and also to strive for mastery to be able to rely more on intuition rather than active thinking.

I found these topics to be very interesting as I feel that I got stuck in the advanced beginner stage a lot in the past. Oh, I still get there occasionally but being aware of it helps me get unstuck before it becomes too much of a problem. The book I'm currently reading talks a lot about this and is worth reading if you want more information.

Striving for mastery is ultimately what software craftsmanship is about and it was nice to see people talk about why. Why do we strive for mastery? Is it so we can say we're better than others?

We tend to have a finite amount of deliberate thinking cycles which limit how many tasks we can juggle in our heads at any time. When we first learned to drive, we probably couldn't even listen to the radio because all of our concentration was on driving. With years of practice, we can even kind of zone out on a commute and wonder how we got home.

With enough practice, we can move deliberate, effortful tasks to the intuitive, automatic parts of our brain. This frees up deliberate cycles to work on more important tasks that require our attention. The important thing here is practice.

Favorite Talks

I enjoyed pretty much every session at SCNA. Some were nice because they reinforced what I already knew while others were simply entertaining. There were a few that stood out and made me think.

Ken Auer - Craftsmen Cannot Live on Stack Overflow and Github Alone

Software teams will usually have or work with a "subject matter expert". This person is usually very familiar with the business problem that the software is trying to solve. They may not know the technical details on how to solve the problem but they know if the problem has been solved or not. Ken pointed out that as software developers (or craftsmen), we should be subject matter experts as well; not of the business but of quality code. After all, who else will point out when code has become too smelly or will become a maintenance nightmare?

One harsh reality of software development (and Uncle Bob pointed this out recently) is a development team is limited by the expertise of the most skilled member. This is something I've always felt strongly about as while I don't mind helping less skilled developers improve, unless there's someone more skilled than I am on the team, I know I'm going to stagnate or worse, get stuck in the advanced beginner stage. This also got me thinking about pairing and how it can expedite the process of getting everyone on a team on the same expertise level.

Dave Thomas - Unknown Knowns

This session kind of broke my brain and I still don't fully understand what was being taught. What I did get out of the session was experts have tacit knowledge that is difficult to pass on to other people.

Tacit knowledge is knowledge that you can't necessarily write down for people to reference later. Because of that, it's important to teach what you have learned, rather than what you have been taught. For example, we teach unit testing but the reasons why we test are more interesting since there may be a better way to solve the problem testing solves, we just haven't found it yet. If we teach with passion, we can infuse some of that tacit knowledge into others.

Ron Jeffries & Chet Hendrickson - Nature of Software Development

Ron and Chet told an interesting story about how product owners say that they didn't want to be product owners anymore. It was too stressful being this magical person that just knew how everything was supposed to work, what needed to be done and to get everything ready for developers to "just do teh codez".

One product owner suggested that they wanted the whole team to be the product owner. We are all cast members putting on a show. Every part of the vision should be shared.


I would really like to go to this conference again. The way the sessions were laid out were great and the speakers were top-notch. I was able to meet or listen to some people that I greatly admire in the industry. I feel that the software craftsmanship movement is important to our industry and I'm glad there are a lot of people out there that feel the same way.

I would also like to give a shout-out to my employer for footing the bill as well. I always feel that it's my responsibility to keep myself trained but it's nice when your employer is willing to help out.

Tuesday, November 12, 2013

Updated Podcasts

Updated my podcast list today. If you're into podcasts, have a look. If I'm missing out on some amazing podcasts, please let me know.

Tuesday, June 18, 2013

Don't Ask, Tell

I just read Michael Feathers' post Avoid Null Checks by Replacing Finders with Tellers and it really made me think about how I write code.

Nulls Be Ugly

I am going to concur with Michael, null checking looks ugly. I hate null checking so much that often I will change a null check like in his example to a one or two liner return just so the ugly is minimized:

So what he suggests is rather than ask the object for state, pass a message to the object that it can handle. I've been reading/hearing about the whole message passing idea in OOP languages lately (especially in Ruby) and although I understand the concept, it's nice to have it illustrated in the post in a useful way.

Not Hip At All

So there's a little bit of a love-fest going on in the post with Ruby. Or is it a hate-fest with Java? Either way, I looked at both versions and thought, this probably wouldn't look bad in C#.

Poor C# isn't even close to as hip as Ruby nor does it share the kind of heritage that Java has with 'nix OSs but it has had lambdas for several years now and the syntax is quite good. When I started replicating the code in question, I came up with this:

I'd say that it's as readable as the Ruby counterpart:

Going Deeper

Being pleased with myself, I decided to replicate what a common data source implementation would look like and came to Michael's sad conclusion that we usually ask for the null check pattern so much that most base/system code is infected with it:

This can be mitigated a bit by calling something that returned an IEnumerable or IList:

It might not be as fancy a solution as in Ruby but it'll have to do for now.

There are a lot of interesting comments on Michael's post so if you're interested in more about this pattern, I suggest seeing what others have to say about it. One interesting comment mentions including a way to actually have an "else" clause in case the Person object didn't exist. I imagine you could do that with a second lambda but there may be a more intelligent way.

My whole C# solution is posted on GitHub for those that are interested. Thanks for reading.

Wednesday, June 5, 2013

Yay RabbitMQ Part 1

RabbitMQ Logo
One thing I've been working with a lot lately is RabbitMQ. It was a bit confusing to work with at first but I think a lot of that was primarily because there was already a code base in place that was using it. Now that I've had a chance to understand the why's and hows, I thought I'd share some of my experiences with it.

Why Queues Or RabbitMQ?

Any kind of process that doesn't need a UI response is an excellent candidate for a queue. There are many blog posts out there about queue architecture and RabbitMQ but here are the more popular ones:

  • Send an email
  • Log actions to a database/Hadoop cluster
  • Fire events that other services can react to
  • Queue up reports to run

There are other other queuing systems out there like MSMQ, ZeroMQ, ActiveMQ, etc. but RabbitMQ seems to be the fastest with durable message support. RabbitMQ also has some great library support out there for many different languages including my current language of choice, .Net.

How Does It Work?

Setting up a cluster is beyond the scope of this post but I'll just mention that it can run on Windows or Linux as it ultimately runs on top of Erlang. This makes for an easier install, simple administration and great options (you can even cluster Windows and Linux boxes together... though I wouldn't recommend it). One other note is to make sure you have the admin plugin installed as this is a major selling point for RabbitMQ as it not only looks good, it's highly functional.

Email And Exchanges (no, not that Exchange)

The best thing I've seen RabbitMQ compared to is an email system. What do you need to send an email? Well, you need an email address for one thing. And usually you'll have a subject with the message. Once you have those things, you can send an email to someone.

To send a message through a RabbitMQ cluster, you need an exchange and a routing key. An exchange is like an email account in that it has a unique name on the cluster and its job is to receive messages. A routing key is much like the subject on the message, it's there to tell more about the message.

Queues, Queues, Queues

You can send an email to an address but unless there's a client pulling the messages, the email account just gets full of unread email. In order to read those emails, you connect an email client to the account and start reading messages.

With RabbitMQ the email client is much like a queue. When you create a queue, you tell it what exchange to listen to and then start pulling messages off.

So what about the email subject and the routing key? Here's where the abstraction starts to leak a little bit but bear with me.

When you first connect an email client to an email account, everything comes through the inbox. If you get a lot of messages that are similar, you usually want to create rules to place the messages in a specific folder or tag. If your senders are nice enough, you can filter on the subject line. This doesn't happen often but let's just assume that they're super nice.

Routing keys are like those really reliable subject lines. When you create a queue, you define what exchange and routing key to subscribe to. If you want all the messages (like the inbox), you can use a single routing key and everything sent to the exchange will go to the one queue. If you create a queue with a specific routing key, only messages sent through the exchange with that routing key will get sent to the queue. You can even use wildcards with topic queues to do some fancier routing.

Makes Sense, Now What?

One exchange and two queues with different routing keys.
So here's what I've covered conceptually in the image above. The my.queue queue is pulling messages from the exchange that have a routing key of my.key. The my.other.queue queue is pulling messages from the same exchange, but only messages with a my.other.key routing key.

It took me a while to understand this overview of how everything works so hopefully you won't have to go through the confusion that I went through. With this knowledge in place, you're ready to learn how to actually code against a cluster. Since I'm not crazy about super long posts, I'm going to leave that to another time which is hopefully in the not-too-distant future. Thanks for reading and if there's anything you'd like me to cover, please leave a comment.

Thursday, April 18, 2013

Running On Empty

Empty Cup
A friend of mine told me about an experience with their child psychologist the other day. It was mostly about dealing with teenager issues but one thing they mentioned that I found interesting was how every child has a sort of "love cup".

The idea is that every time the parent plays with, compliments or encourages the child as he/she grows up, another drop is added to the love cup. Any time that the parent ignores, tears down or hurts the child, drops are removed. If the parent removes too much from the love cup, the child will respond in unfortunate ways such as rebellion, anger or poor self esteem. If the cup goes beyond empty (negative), the child may become self-destructive which would require a lot of drops added to the cup to even get to empty.

It's an interesting theory which I've found to be true not only with observing children of friends and family but my own children as well. With every drop added, the more I see children respond positively to their parents as well as being happier overall.

Hearing about this idea of a "love cup" made me think about how I should spend more time with my children but it also made me think of how applicable this is at work. I would still consider it a "love cup" at work (because you love your job right?) but it probably sounds better as a "trust" or "satisfaction"cup.

Satisfaction Cup

I know that when I start with a new employer, the sheer excitement of starting somewhere new fills my cup most of the way. New people, new environment, new challenges and new code bases always seem to do it for me and most developers I know.

Once the honeymoon period of a new job is over, things start taking drops from the cup:

  • Management issues
  • Nasty legacy code
  • Team issues
  • Interoffice team issues
  • Not enough to do/boredom

It's funny, the things that add to the cup are the exact opposites of what takes from the cup. I've seen good managers turn teams around. I've also seen strong teams wade happily through some of the nastiest legacy code simply because they enjoy hanging out together. As long as the cup is being filled faster than it's being emptied, a job can be satisfying.

But what happens when the cup goes into the negative? That's usually when one starts becoming toxic and although it may be possible to turn things around, I've found it's usually a sign that it's time to start looking for other employment.

Know Your Cup

If you find your cup draining faster than it's being filled, let someone that can fix the problem know. It's sad when someone is struggling and those that can fix the problem don't know about it. Actively look for ways to stop the hurting and if your cup fall into the negative and you notice yourself becoming toxic, take the time to decide if it's best to leave before burning too many bridges.

It's an interesting theory and I'm curious as to what others think of it. Does it resonate with you? Am I way off? What fills your cup? What empties it? Let me know in the comments.

Image © Parrus | Dreamstime Stock Photos & Stock Free Images

Friday, March 8, 2013

Maximize Your Commute With Podcasts

I have a commute. It's not a long commute, but long enough (20 minutes-ish). Although I enjoy listening to music while driving, I've found that my time is better spent listening to something educational or interesting through podcasts.

How Do I Listen To Podcasts?

With the advent of smartphones, subscribing and listening to podcasts is super easy. I've never had an iPhone but I've seen that there's a podcast app in the App Store that should be sufficient (correct me if I'm wrong). For Android, Google used to make a nifty little app called Listen but has been discontinued. The app I'm a big fan of right now is the Car Cast Player app. It's made for listening to podcasts in the car and it does it well. There are other podcast players in the Google Play store but this is the best free one I've found.

The way you subscribe to a podcast is much like subscribing to an RSS feed. Most podcast players will have a way to either search for podcasts or link up to one through a feed URL. For example, if you wanted to subscribe to Hanselminutes, I would first go to the site and find a subscribe link. Sometimes you can just hover over the link to find the feed URL that you can enter into your podcast player. What I like to do is to actually subscribe to the feed into Google Reader so that I can read the show notes later. This also makes it easy to refer to the subscription link later and verify that your podcast player is pulling podcasts correctly.

So What Do You Listen To?

I created a nifty page that I'll try to keep up to date here. But here's the short list version relevant to right now:

If you're not a programmer, find something you're interested in. There are a TON of podcasts covering whatever subject you may be interested in. So go forth and maximize your commute! Listen to some podcasts!

[Updated 3/12/2014]
I've moved my podcast list to a static page that I try to keep updated: Podcasts Wot I Listen To