Sunday, February 2, 2014

Adventures In Losing Weight

Adventure
I know a lot of developers that struggle with obesity and the problems that go with it (I even have a mild case of peripheral neuropathy to show for mine). Between sitting at a desk all day at work (sometimes at night as well) and living an American lifestyle, it's easy to gain weight. Losing weight (or at least talking about it) is a time-honored tradition in my family (blame my mother's side) so it makes sense that I make at least one post about it.

In my annual physical about 3 years ago (they're free for any insurance, you should go), I noticed that the scales had me at 330 lbs. I couldn't believe that I had gotten that big. I have always been big but this was just nuts. I would get winded playing with my kids or going up several stairs and it bothered me. I don't need to be super fit but I need to be able to function in life at a level I feel is normal.

After educating myself a bit and finding diets that work for me, I've managed to get down to about 265 and have kept it there for over a year. I'm eating mostly normal now and plan on losing more once summer rolls around (something about winter just kills my motivation).

A disclaimer before I get into what I did:
  • I'm a software developer, not a dietitian. This is just advice from some guy.
  • This is what worked for me. Everyone is different when it comes to diets.
  • Talk to a doctor to before you start any diets or extreme exercise routines.

The best diet is the one you can stay on. There are however, some constants out there that you can't ignore and are important to understand.

Educate Yourself


There are a lot of websites and books to read about weight loss but the one that spoke to me the most was the Hacker's Diet. Click that link. The book is free and it's written by and for engineers trying to lose weight. It explains how there really aren't any shortcuts to losing weight but on the other hand, it really comes down to the first pro-tip in dieting:
Pro-tip #1: Eat less calories than you burn.
The other big thing I got out of this book that it seems a lot of people don't understand:
Pro-tip #2: Losing weight is 80% diet, 20% exercise.
Exercising is good. You will live longer by exercising but what's easier, running a mile or skipping on a cookie? I love cookies as much as the next guy but I hate running more. You choose.

Dieting


So now that we know we need to cut down on what we eat, how do we do that? There are many diets out there but once again, the best diet is the one you can stick to. I have tried a few diets and have learned something from every one. Here are the ones I have tried:

Weight Watchers - I think Weight Watchers is the most like eating normal than any other diet. They favor healthy foods over sweets and their point system is easier to do than just straight up calories. But if you don't have the money for it, you may want to look elsewhere. I think I lost about 15 or so pounds on this.
Pro-tip #3: Tracking what you eat is a powerful tool.
Ideal Protein - Wow, you thought Weight Watchers was expensive? If you can find someone to give you special prices on the food, the pricing isn't that bad. There are even forums out there that can help you put the diet together for very little money. This is a very, very effective and fast acting diet but it's too restrictive to live on. If you plan on doing this, make sure you have something planned for when you go off of it. I think I lost about 30 pounds on this.
Pro-tip #4: Only eating what you plan to eat guarantees results.
Paleo - I'm not sure who started this but the best resource I've found for explaining it is at Nerd Fitness. I have never fully bought into doing 100% strict Paleo but I have found it to be the easiest diet to live on if you're willing to plan your meals and give up on some comfort foods you may be used to. I think I lost about 10 pounds on this.
Pro-tip #5: Protein keeps you full much longer than carbohydrates.
I'm currently doing a modified Paleo diet of sorts. I'm losing as fast as I was on Ideal Protein but I don't gain while following it. Some other tips that I found for all diets include:
Pro-tip #6: You're not hungry, you're thirsty. Drink lots of fluids so that you know for sure.
Pro-tip #7: Don't stay up late so you don't feel the need for that "4th meal".
Pro-tip #8: Never drink your calories. Water is best but diet soda still has zero calories. 

Tools & Gadgets


To help with dieting, I've found some tools to be very useful which brings me to another pro-tip:
Pro-tip #9: Measure all the things!
If you don't measure it, you can't know if you're improving. Here are some things that have helped me:

  • Scales - Doesn't matter which kind you buy, weigh yourself at least once a week. I weight myself daily which can be depressing if you don't have something like...
  • Libra Weight Manager - I know there are similar apps on the Apple app store, just search for Hacker Diet. This gives you trending lines so that even when your weight fluctuates, it gives you a good idea of if you're losing or gaining.
  • MyFitnessPal - Good website, good apps, good integration with other tools and social integration. Use this if you want to track what you're eating, exercise or weight loss goals.
  • Fitbit - Gamify getting off your ass! This helps encourage me to go to the further bathroom at work or to park further away just so I can get that extra few steps. I rarely come close to the recommended 10k steps a day but it still helps give you visibility to what you're doing in a given day. I love the social element too so if you have one, add me as a friend!
  • Get Up And Code - Not so much a tool but a great (free) resource for getting fit in the context of being a programmer. I've learned a few things (and have had a few beliefs challenged) listening to this podcast.

Still Adventuring


I feel so much better than when I was pushing 330 lbs but I'm not done yet. I would like to get my waistline much smaller and I would like to be stronger as well. I feel pretty confident that I know what I need to know to lose weight but I'm still learning how to effectively exercise. Maybe once I have a better grasp on that I'll write another post.
Pro-tip #10: Don't diet alone.
I couldn't have gotten this far without the help from my wife and some friends like @codeforth. I've also gotten some great support and advice from the guys on the Be Healthy Yammer group (ask for an invite if you're interested).

I'm always up for a conversation about weight loss so feel free to comment on the post, send me a tweet or email if you have any questions. Good luck on your own adventure!

Photo Credit, David Niblack, Imagebase.net

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



TDD


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


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.

Conclusion


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 Ancestry.com 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 my.exchange 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