The survey only has three required questions and should take less than 30 seconds to fill out. If you have worked on an open source project, please help me with my research by filling it out.

It would also help greatly if you distributed the link to this post or to the survey form itself to your project mailing lists and encouraged other developers to fill it out as well.

When my research is complete, I’ll post the results on this web site. Thank you for your time.

The link to the survey is here.

One day I hit 290, which became something of a wake-up call for me. I really didn’t want to break the 300 barrier, but I had been steadily gaining weight for the past few years and I was well on my way to being over 300 pounds. Combined with my father’s increasing problems due to his diabetes, I had become worried enough about my future that I decided to do something about my weight in 2007.

I have tried a number of different things over the course of my life, though I never tried any fad diets like South Beach or Atkins. I tried limiting my food intake, I tried riding my bike to work to get exercise, but I remained steadily creeping toward 300 pounds and a future as a diabetic.

To make a long story very, very short, exactly one year later I weighed 200 pounds, having lost 90 pounds. No surgeries, no fad diets.

There were a number of things I did that I consider to have made the difference between an unsuccessful attempt at losing weight and a successful one. I’ve decided to share these things on the intarwebs, in hopes that they might motivate or help someone else struggling with their weight.

#1 See A Nutritionist

Talking to a professional nutritionist made a huge difference. I was able to tell her exactly what I ate during the day and exactly what kind of exercise I got regularly. I ran her through a typical day and a typical week, and she figured out exactly what my problem areas were. As it turned out, my main problem wasn’t sugar intake, but carbohydrate intake, and she gave me helpful guidance for how to control my carbs in my diet. She told me what foods I ate that I needed to stop eating, which foods I needed to cut back on, and which kinds of food I needed to start eating. She illustrated portion sizes for the foods I eat, and gave me a number of extremely helpful guides.

She didn’t put me on some crazy fad diet, or give me suggestions that I’d be unable to follow because I’d be miserable following them. She catered her advice to me specifically, which made it far more useful advice than what I could pick up on the internet in blog posts such as this one.

In the end, making adjustments to my diet and exercise routines based on her suggestions wound up making a critical difference in my ability to lose weight.

#2 Seriously, See A Nutritionist

I really can’t stress it enough. The combined impact of every single other item on this list didn’t even come close to the impact made by just talking to a nutritionist. The visit was covered on my insurance plan and it only took about an hour out of my life. Absolutely nothing I did over the course of the year helped me as much as talking to a nutritionist.

Do it.

#3 Set Goals and Rewards

My goal for the year was 90 pounds. I never, EVER thought I’d actually pull it off. 90 was my “boy would it be nice” goal. I set intermediate goals of 30 and 60 pounds. 30 I knew I could hit, 60 would take work, 90 was basically impossible.

At each goal, I gave myself a reward. This reward was something I didn’t allow myself to get without hitting the goal. At 30, I got a second monitor for my computer. At 60, an XBox. At 90, a Macbook. Each reward was larger than the last.

Focusing on just the thirty pound increments made my goals seem more doable, and whenever I wanted to bail on a workout early I could say “come on, 10 more pounds to the XBox” to keep myself going. Every time I wanted a piece of cake, I knew it moved me further away from my Macbook.

Manageable goals make a big difference in motivation, and I’d say that this item combined with seeing a nutritionist were the biggest difference makers without question.

#4 Timebox The Effort and Commit

When I first started, it was very helpful, just from a mentality standpoint, to set a limit for how long I was going to make this effort.

The idea of “I’m going to watch what I eat and work out for the rest of my life” was intimidating to me, to the point where it felt like I didn’t even want to bother. It was a miserable future in my mind, and it made me want to give up instantly.

In contrast, this time I said to myself “Okay, I’m going to watch what I eat and work out and commit to that for exactly one year, to the day. I’ll decide what to do after that at the end.” Time boxing the effort gave me a reason to try, and every time I wanted to give myself an excuse to get out of the gym or eat a giant pizza by myself, I’d just say “No, not now. You’re sticking with this for one year.”

It seems small, but it made a big difference. Feeling like there was a limit to the work kept me motivated to stick with the plan whenever I was tempted to deviate.

In the end, however, I feel so much better now than I did when I was 90 pounds heavier, and I actually ENJOY the gym as well as how I feel when I eat healthy. I don’t have the temptation to eat a big pizza any more because I know how I feel afterwards and how different that is from how I feel normally. Eating junk food makes me lethargic and tired, but I never knew that until I ate healthy and was able to really observe the difference. Even though my year is up, I haven’t fallen back into old habits; I still eat well and go to the gym, but now I’m happy to do so. However, it helped a great deal to to limit myself to a specific period of time from the outset.

#5 Track Progress, Adjust as Needed

During the year, I weighed myself every day, at the same time every day, wearing the same amount of clothing. I wrote down my weight, and I used the results to course correct when I needed to.

I found that my weight fluctuated quite a bit during the week, and there was nothing as frustrating as working my ass of at the gym and then weighing myself the next day and finding I had gained weight. In actuality, I hadn’t gained weight, but my weight fluctuated. Weight fluctuations are completely normal and depend on the time of day, the time of year, how hydraded or dehydrated you happen to be, when you last ate, and many other factors. You can’t let yourself get hung up on day to day weight changes.

Instead, what I did was kept track of my weight for the week. I had a spreadsheet (stored in Google docs) that had one week per row, 7 columns each. The only column I ever really looked at was the “Week Average” and I compared that to the previous week. If I had, overall, gained during the week, I needed to make a change. If I had lost weight, I was on the right track. This let me ignore daily fluctuations.

I entered my data every day, but I evaluated only at the start of the week. When I decided to change my plan, I committed to the change for one full week, even if it didn’t look like it was working as the week started out. For example, if I decided to have a different kind of breakfast, I would commit to that new breakfast for the full week, no matter what. At the end of the week, I’d decide if that did or didn’t work.

It also helps to buy a decent scale and weigh yourself at the exact same time every day. I always weighed myself in the morning, right before showering. The scale was in the bathroom, next to the shower.

I also tracked myself at the gym. I didn’t go running or bike riding for aerobic exercise - I used machines that allowed me to enter my age and weight, then told me how many calories I was burning. When I was first starting out, this was critical in figuring out what kind of changes I needed to make.

One thing I wish I had done was taken a picture of myself at 290. I never thought I’d actually be able to lose even 30 pounds, let alone 90. So I wasn’t willing to take a photo of myself at 290. When I hit 260, I wished I had taken a picture of myself 30 pounds heavier, because, having lived my life as a fat guy, it was really hard to actually see that I was losing weight because of my own perceptions. Only the scale told me I was losing weight. If I had a picture at 290 and one at 260, I would have seen the difference that others were seeing and mentioning. Of course, at 260 I never thought I’d hit 230, so I still didn’t take a picture. And, you guessed it, at 230 I never thought I’d hit 200 so I still didn’t take one. I wish I had a picture of myself 90 pounds heavier without a shirt on, but I don’t. Do it, or you’ll regret it.

#6 Don’t Make A Resolution, Start Right Now

Resolutions don’t work. Don’t make weight loss a “new years resolution.” And don’t say things like “alright, I’m going on my diet starting the first of this month.” Start next week.

Whenever I would pick a specific time to start, or do something like have “one last hurrah” at a buffet during the month prior to “getting serious,” I would fail. Any time I drew a line between my “old diet” and my “new diet” it didn’t work. I can’t really explain why, but for some reason this never worked out.

I’d miss a workout day and all of a sudden the “new diet” had been blown and I’d wind up skipping another day, and then another, until I wasn’t doing it anymore. Or I’d eat a slice of pizza and just give up on the whole thing. Creating a hard line between “old” and “new” made me feel like a failure if I screwed up during the “new” phase.

Instead, I got into it gradually. My first day at the gym wasn’t some hour-long thing, it was about 30 minutes. My first day of my new diet wasn’t carrot sticks and salads, I just cut back on some bad foods and tried some new ones. I experimented. I replaced my morning muffin with a morning yogurt. I added half an hour to my workday by going to the gym immediately after work (before going home) for a little while. Then I’d simply track how helpful these efforts were. Quite honestly, a small change was actually enough to lose some weight in the beginning, but eventually it wasn’t enough, and I had to add more gym time or cut back more in my diet. I started with baby steps and then course-corrected as time went on. This means I didn’t ever have a distinct “old life” and “new life” with a line drawn between them. I didn’t start “first thing next Monday”. I started immediately and changed the plan as I went along. Start tomorrow.

Another benefit of starting without making it a New Year’s resolution is quite simple: just after New Year’s, the gym sucks. The place gets packed with “New Year’s Resolutionists”. You have to fight for a machine that you want to use, and if you’re new to the gym, you feel like everyone is watching your fat ass jiggle around on the treadmill. The gym blows when it’s crowded, especially when you’re starting out. Starting out in January is a guaranteed way to abandon the gym. I started in October, so I was comfortable enough in the gym by January that I didn’t mind the sudden surge in attendance (in fact, I felt like they were n00bs). The resolutionists all give up by March, so after that it’s safe.

#7 No Fried Food, No Soda - Cold Turkey

There were two exceptions to the “slow start” mentioned above. Two big changes that were, in fact, immediate and drastic. I stopped drinking regular soda, and I stopped eating fried food. Completely.

In a restaurant, if my food came with fries, I’d ask to replace it with steamed Broccoli or something similar. I didn’t buy or drink any regular soda, ever, no exceptions. Diet soda was fine, however.

I didn’t listen to any of the crap about how diet soda is bad for me and causes cancer, or how Mexican coke with real sugar is better for me, blah blah blah. It’s all horseshit. Calories are calories, and diet soda doesn’t have any. Diet soda isn’t GOOD for me, but it did let me drink something with some flavor with my lunch. Quite honestly I’d have gone insane if I only drank water for the year, so I’m glad diet soda had my back. That said, I didn’t guzzle the stuff. Soda, because it’s carbonated, expands your stomach, so it makes you feel less full than you otherwise would. This encourages you to overeat. I also started ordering only water when I went out to eat, which had the bonus of saving me more money than I expected. I generally had water or diet iced tea (no carbonation) with dinner, and I allowed myself to drink a diet soda at lunch. I could get away with this because I always brought my lunch from home, so there was a limit to the amount of food I could eat at lunchtime, reducing the risk of overeating because of soda.

I’d occasionally steal a couple fries from my fiancee if she had some, but eventually I found that having two fries made it extremely difficult not to have a third fry, and a third made it very hard not to have a fourth, so I stopped doing that for the most part.

Diet soda and veggies instead of fried food, immediately. Starting right away. It helps.

#8 Get What You Need, But Don’t Let It Stop You

At the gym during the first week with my iPod nano. Holding it while I work out is a pain. “You know what,” I think to myself, “I really need an arm strap. I’ll get one tomorrow and then start working out.”

You have no idea what kind of excuses you will invent to get out of the gym until you start going. It’s staggering, the human brain’s ability to concoct reasons to get out of the gym. My foot is kind of hurting. I need a water bottle to really get started. My iPod battery is dead, I should charge it first. My gym shorts are too tight, I need new ones. The little plastic thing on my shoelace came off and now I can’t tie them as tightly. Seriously, you will think of every possible reason under the sun to get out of the gym. GO ANYWAY.

Even if the reason is completely valid, like the armstrap for my iPod, make yourself go anyway and live with the problem for the one time, then fix it tomorrow. The HABIT of going to the gym is almost as important as the actual going. If you skip a day that you planned on going, you break your habit. Once you build the habit of going to the gym, you find that you don’t have to convince yourself to go anymore, it’s just part of your day, like brushing your teeth. Building the habit is crucial, so don’t let little things derail you from developing the habit.

I now find that I actually feel shitty when I don’t go to the gym, it takes more effort for me to skip than to go. That’s because I built a habit out of it, the same way that if you skip brushing your teeth for a day your teeth feel all grimy and disgusting. Even if you need something before you can really get a lot out of a gym trip, go anyway and deal with the problem tomorrow.

#9 Drink More Water

Water is good for you. It increases your metabolism, and it helps you feel full. Very, very often when you think you are hungry, you’re actually thirsty, your brain just can’t tell the difference. If you find yourself craving food, go drink a glass of water and wait a few minutes. You very well may not actually have been hungry. Your brain sucks, deal with it.

When I go out to a restaurant, I order water, and I drink a ton of it. This ensures I don’t overeat at the restaurant (food in restaurants is usually served in a 3x or more portion. If you’re not taking home a box when you leave, you ate too much). I try to drink an entire glass of water before the waiter or waitress comes back to even take my order, and another before the bread arrives. If I’m not annoying the server, I’m not drinking enough water.

How much water should you drink? At the risk of being crass, your piss should be almost clear. If your urine is yellow, you need to drink more water. It’s that simple.

#10 Slow The Fuck Down

You eat too fast. Trust me, you do. Fat people eat way faster than skinny people. Huge bites, gone in seconds, then a plate full of more food.

I found it very helpful to fill my dinner plate with what I felt was the correct amount of food, then to eat the food on it as slowly as possible. If I was still hungry when I was done, I forced myself to wait 20 minutes. Only if I was still hungry after 20 minutes would I let myself have more food. It almost never happened. I only got a second plate if I broke the 20-minute rule (which I’d always regret)

It takes about 20 minutes for your stomach to tell your brain it’s full. That means, once you’re COMPLETELY FULL, it will be twenty minutes before your brain even has an idea that you should stop eating.

The slower you eat, the more time you give your brain to find out it should stop eating before you cram more food down your cramhole.

Take tiny bites. Your mouth doesn’t need to be full to enjoy the taste of your meal. The smaller the bite, the more food you’ll think is on your plate, and the less likely you will be to feel like you didn’t get enough food.

Chew. Turn it into mush before you swallow. You’re on a diet, so you have a much more limited number of bites. Taste those bites as long as you can before you swallow them. Once the food is out of your mouth, you can’t taste it anymore, and you need to stuff a whole new bite into your face to enjoy the taste of your food again. Leave the bite in longer, and you can enjoy your food longer without the need to shove more food into your gullet. Try to chew until there’s no flavor.

I still stuggle with this one, it’s a big adjustment, but it’s worth it.

#11 Don’t Kill Yourself

The worst thing you can do to completely derail your diet is to make yourself so miserable that you hate it.

If your company orders pizza for your group and you decide you eat your lame little salad while everyone else is eating pizza, you’re just going to sit there focusing on delicious pizza and how pissed off you are that you’re on this stupid diet. If you hate it, you’ll quit.

Indulge every so often. Have that slice of pizza. Steal a few fries from your spouse. Just order the cheeseburger if you’re going to be pissed off all night after ordering a bowl of soup. Just don’t make a habit of it. They’re indulgences for a reason, they should be the exception, not the norm.

If you love chocolate more than life itself, depriving yourself of it is going to end one way: with you shoving fistfuls of Hershey bars into your face while screaming “screw the diet!” The trick is not to deprive yourself, it’s to introduce moderation. Eat a kit-kat, but spend an extra 15 minutes at the gym to balance it out.

Eventually you’ll start looking at a slice of pizza not as a delicious, cheesy piece of bread, but as an extra 20 minutes on the treadmill. Then you won’t even want the damn thing (usually).

Yeah, that snickers bar sure LOOKS good, but the fact of the matter is that you’ll have eaten it in 30 seconds and you won’t even remember what it tastes like 10 minutes from now, but if you eat it you’ll have to spend an extra half hour at the gym working it off. Possibly an extra 6 hours the next day being all pissed off at yourself for eating it, blaming it for the fact that you gained weight yesterday in spite of working your butt off at the gym.

Your relationship toward these kinds of foods changes when you start living healthier, and you desire them less and less. But if you completely deprive yourself of them, you’ll want them more and more. Give in when you absolutely have to, just don’t make it a regular occurrence.

Conclusion

Losing weight is not that hard. Really, it’s not. It’s more about commitment than anything else. Make a plan, stick to it, and the pounds come off.

You don’t need a fad diet, you don’t need a special book, you don’t need to subscribe to some online service. If you burn more calories during a day than you eat, you lose weight, it’s that simple.

Stop telling yourself “I’ve tried everything and nothing works!” You know damn well you haven’t tried everything, stop kidding yourself.

Losing 90 pounds is, without a doubt, the most significant accomplishment I’ve ever made in my entire life so far. I can’t even describe in words how much better I feel now, how much more energy I have now, and how much happier I am. I feel comfortable in a suit. I can buckle my seatbelt in a car without feeling like the strap is making my bitch tits stick out. I can shop for clothes in a regular department store, and it doesn’t take me 5 hours. I can wear t-shirts instead of fat-guy Hawaiian shirts. I can dance or ride a bike without feeling like a fridge. The little things make a big difference.

I feel alive, confident, and energetic. My brain feels like it works better, and I enjoy how I feel when I’ve eaten well for the day. I enjoy my time at the gym, it gives me time to think about whatever I want or listen to an audiobook. 200-pound-me is so much happier than 290-pound-me that I can barely even understand how I was able to live my life before. Having someone I haven’t seen in a while say “holy shit, you look great!” makes my week.

It’s not that hard once you build habits, I promise. I did it. You can too.

His book “Clean Code” is, in many ways, an introduction to the concept of Software Craftsmanship and a guide for developers interested in becoming craftsmen. Clean Code is not about only writing correct code, it’s about writing code that is designed well, code that reads well, and code that expresses the intent of the author.

The book is essentially divided into two parts. The first part contains Bob’s suggestions for writing and maintaining clean code. This includes suggestions on everything ranging from how to properly comment code and how to properly name variables to how to separate your classes and how to construct testable concurrent code. The second part of the book uses the principles in the first part to guide the reader through a few exercises in which existing code is cleaned.

The first part of the book is fantastic. I can’t recommend it highly enough for a professional software developer that wishes to elevate him or herself to a higher standard. This guide is excellent, and gave me lots of things to think about while reading it. I could almost feel myself becoming a better programmer as I internalized Martin’s advice, and the code I’ve been writing has been noticeably better since I began following his suggestions.

In the second part of the book, Martin essentially guides us through three projects: a command line argument parser he wrote, a section of the JUnit source code, and a section of source code from SerialDate. Of these, the most detailed guide is Martin’s illustration of refactoring the command line argument parser.

These sections all suffered from a fundamental flaw: they were inside a book.

These sections all required reading large amounts of source code. Not just scanning it, but really reading and understanding the code, so that the reader can understand the changes Martin makes to the code. Reading and understanding code is something I do every day as a professional, but I never have to do it from paper.

When I read code, I’m interacting with something, not just reading. I can scroll up and down. If I see a method being used and I wonder how it’s written, I can click on it and jump right to the implementation. My IDE shows me symbols in my gutterbar when methods are overridden. I can press a keystroke to pull up a list of just the methods in a source file. I can right click on a method and find its usages immediately. The source code I am reading is something I can push and pull, gaining an understanding of it through interaction.

When source code is printed in a book, you get none of this. To make matters worse, Martin’s code samples have absolutely no syntax highlighting applied to them. When I read source code, certain parts are rendered in specific ways that make it easier to pull the information into my brain. Strings and literals are formatted differently, comments are dimmer so I can focus on code, and so on. Code samples in “Clean Code” are just characters, with occasionally bolding used to draw attention to parts that were changed. It’s amazing how much syntax highlighting helps make code more comprehensible, even at a completely subconscious level.

A book is, quite simply, not an appropriate medium for a guided code walkthrough. I’d have preferred the content of these sections as perhaps a lecture, with Martin’s text done in audio and his code kept on the screen. This would at least prevent me from having to flip back and forth constantly. I didn’t get as much out of these sections as I would have liked to, simply because it was so difficult to digest the information it contained in such an awkward, unnatural medium. At the very least, the code samples should have been printed in color, with syntax highlighting.

I can tell that his advice was good and that the refactorings he applied to the code samples in the book made the code far better, but mostly because I’ve observed these efforts in real life and observed how much they improve code. If I were to encounter Martin’s “before” and “after” code in a project I was working on, I undoubtedly would find the “after” code far, far cleaner and more enjoyable to work with. However, since the book format made it so difficult to understand EITHER code sample, it didn’t seem like Martin’s efforts offered much improvement, even though I know they did.

Despite this frustration, the book is an excellent read, and I’m quite certain it has contributed a great deal to helping me improve as a professional. I can’t recommend it enough, especially for Java developers. I just think that most readers will find the final few chapters intensely frustrating - I recommend downloading the code and viewing it in your favorite code editor so that you can comprehend the source code the way you would any other source code.

Overall Rating: 4/5 Stars

But this comes with a downside. I have almost 200 subscriptions in my Google Reader account. Many of these subscriptions are to sites, such as Reddit or Digg, that themselves, aggregate other sites. I have divided my Google Reader subscriptions along various categorical tags (such as politics, development, movies, etc) as well as priority tags (Must Read, Should Read, Can Read, Can Ignore, and Should Ignore) but even that isn’t quite enough to manage the firehose of information coming my way via RSS.

I have utilized Yahoo Pipes to manage this deluge of information and I thought I’d take some time to share how. This article will serve both as a basic tutorial for using Yahoo Pipes to manage your RSS feeds as well as a place to show some specific examples I use to control my feeds that you can use as well if you subscribe to the same sites I do.

Yahoo Pipes

Yahoo Pipes, if you’ve never used it, is simultaneously both intimidating and insulting the first time you use it. You drag components around on a screen and connect them together with little paths. It feels like you’re programming in Visio or something. Yet, even though you feel like a child dragging components around, you find yourself simultaneously overwhelmed by the number of components that exist in the system. Yahoo Pipes is tough to get used to.

Pipes allow you to essentially define a source of data as a starting point, then run it through a series of operators and output something else when done. But it’s more than just a regular expression being run on a page - it works best with sources that consist of a list of SOMETHINGs, and the operators tend to perform their transformations on every item in the list.

The source we’ll be using in this article is the RSS feed source. Everything we do will be done to take an RSS feed with too much data, then run it through a series of filters and transformations to re-output the same feed, but with only the items we care about.

Once you have a pipe that outputs a transformed list, you can get an RSS url to the output of the Pipe itself, then subscribe to that with your feed reader in place of the original feed.

For example, let’s say that I find far too many posts in the RSS feed for Digg.com/technology. Let’s say, for me, I only care about the items that relate specifically to Apple, because I’m a digg user and I love Apple to death like all good Digg users. Rather than subscribe to the RSS feed for Digg/Technology in my Google Reader, I’ll create a pipe that uses that feed as a source, filters out all of the posts that do not relate to Apple, and then subscribe to the RSS feed of my pipe. I can even rename the subscription “Digg/Technology” in Google Reader, hiding the fact that it’s even going through Yahoo Pipes.

Basic Example: Simple Filter

Let’s start with a simple filter. I like to read ScrewAttack.com, so naturally I wanted to subscribe to their RSS feed. But unfortunately for me, they post new videos every day and I’m only interested in some of them. They have many categories of videos, but the only ones I really like are “Hard News,” “Jose’s Puntos,” and “Trailer Dump”. In particular, I hate their “SideScrollers” feature because I don’t listen to podcasts.

So head on over to ScrewAttack and copy the RSS feed URL to your clipboard: http://screwattack.com/rss.xml

Then go to Yahoo Pipes and create a new Pipe (you may need to make a Yahoo account). Open the “Sources” menu on the left and drag the “Fetch Feed” element into your work area. Paste the ScrewAttack RSS feed into the box. You can now click on the titlebar of the source and see the output in the lower portion of the screen.

Now, open the Operators list and drag “Filter” into your work area. Click on the circle at the bottom of the Fetch Feed box and drag the line to the circle on the top of the Filter box, connecting the two.

Change “Block” to “Permit” and change “all” to “any”. Underneath “Rules” click the arrow next to the leftmost box and select “item.category.content”. This makes the filter look at the item/category/content field of the RSS xml. Leave the dropdown at “Contains” and type in “Hard News” into the box on the right. Click “Refresh” in the output preview at the bottom and you’ll see that the recent Hard News posts (and only those) show up.

Now click the plus icon next to “Rules” to create another rule. Select the same thing for the left drop down (for the category) but put “Trailers” in the right. Do it again for “Jose”. Click refresh again and you’ll see the interesting stuff on the site only. You can obviously customize this however you wish if you care about different categories.

Last, drag the circle at the bottom of the “Filter” box to the circle at the top of the “Output” box. Your pipe is now done. Click output and see a preview of what your pipe outputs.

Save your pipe in the upper right corner. A flare will pop up at the top telling you it’s been saved. Click ‘Run Pipe’ and you will be brought to the Yahoo Pipes interface for a running pipe. Click “Get an RSS” and you have your new RSS feed URL. Feel free to change the name of your pipe if you wish at any time, the RSS feed URL never changes.

Please note that this RSS feed is PUBLIC (it has to be if you want to subscribe to it through something like Google Reader), but not LISTED. If you publish your feed it will show up in the searchable feeds database on yahoo. But don’t make pipes out of private data.

The later examples will be less more complex and less detailed. Play around with Yahoo Pipes to see what you can do if you are not already familiar.

Reddit Filter: Only Talked-About Posts

One of the reasons I generally prefer Reddit to Digg is that I find the conversation on Reddit to be a bit more intelligent. The top comment is usually some snarky one liner, and the second comment is usually some joke or reference to a meme, but after that there’s usually some interesting conversation.

As a result, the way I’d like to limit my Reddit RSS feeds is by only selecting the the posts that reach a certain threshold of comments. This number is different for the different subreddits I read (less popular subreddits need fewer comments to be considered talked-about than, say, the front page).

Let’s construct a filter for the programming subreddit (or “proggit”) using the RSS feed http://www.reddit.com/r/programming/.rss

If we create a feed source and look through the structure of the object that Pipes has to work with, we can see that in the “Description” element is a link to comments, and it contains the number of them.

What we’re going to do is construct a regular expression that pulls that information out, and only permits posts with more than 20 comments.

Create a “Loop” element and connect the output of the feed to the input of the loop. The loop allows you to perform an operation on every item in the feed and save the result to a new element in the feed (or overwrite an existing one). This allows you to add information to the feed that it didn’t have, which you can then use in subsequent filters.

Drag the “String Regex” element into the inside of the loop and tell it to replace the regex .*?(\d*) comments?.* with $1. Since the number of comments is the capturing group, it is essentially just extracting the number of comments. Tell the loop to assign the the result to “item.comments”.

Now your feed has a “comments” element that contains the number of comments on the post. Pipe the output of the loop to a new “Filter” element and tell it to permit only items that have item.comments greater than 20. Connect that to your output and voila, you’ve got a version of the programming reddit RSS feed that only shows the items with more than 20 comments.

If a post that was filtered out because it had, say, 5 comments, were to become more popular and get 21 comments, it would start showing up in the feed (and therefore in your reader).

You can make this pipe even more useful by introducing User Inputs. User inputs let you send parameters to the feed, which can then be used by the pipe. For our case, it would be handy to provide the url of the subreddit as a parameter, as well as the number of comments for the inclusion threshold.

Drag a new user input URL element into the work area. Give it the name “redditurl” and the prompt “URL to Reddit RSS Feed”. Paste the programming reddit RSS feed into the “debug” field. This allows you to test out that your feed is still working correctly, but when you re-use the pipe it won’t use the value in the field. Pipe the output of that input into the small box to the right of the field in the “Fetch Feed” box. Your pipe should still be working as normal if you check the output, but if you paste a different reddit rss feed URL into the debug box and click refresh, you’ll have a new set of filtered data.

If you run the pipe, you’ll now see that you are prompted to input the feed URL before you can run the pipe. If you paste the feed in here and run the pipe, you can grab the RSS feed for just that subreddit. If you paste a different RSS feed URL into the box, you will get the filtered feed for a different reddit.

You can do the same thing with a “number input” to control the comment count threshold. You could also use the “Sort” operator to sort by the number of comments, moving the more popular items to the top.

If you don’t want to bother going through all this work, you can feel free to simply use my published version of this pipe here.

Digg Filter

Very much like Reddit, Digg is a link aggregation site that allows users to vote links up or down. However, for me, the Digg comments aren’t as valuable as Reddit comments, so I’m more interested in links based on the number of Diggs they receive, rather than the number of comments they have.

Handily, the Digg RSS feeds actually include the number of Diggs that items have received in the XML, so we can key off that to build a new pipe. The element can be found at item.digg:diggCount, so all you need is a filter that permits entries with a high enough diggCount. In the example below, I’ve also included a sorting mechanism.

As with the Reddit filter, you may feel free to just use the pipe that I’ve published here.

DZone Filters

DZone is like Reddit and Digg, but geared specifically toward software developers. Just like Reddit and Digg, you can key off of certain elements in the RSS feed XML to determine how popular an item is and filter accordingly.

DZone is slightly more complicated, however, because there are actually two different kinds of sites on DZone. First, there are different Zone’s, such as Agile Zone, where you can key off the number of times a post has been read. Then there are the links collections, such as Agile Links which is more like Digg/Reddit and you can key off the number of votes.

The first type is relatively simple, so I won’t even cover it (it works just like the Digg filter, but keying off the number of reads embedded in the feed). You can use mine here.

The Links feeds are more interesting. Even though the site displays the “net vote”, the XML only contains the number of up votes and the number of down votes. That means you need to do the subtraction in your pipe to get the actual net vote count.

We’re going to do the subtraction in a loop and assign the results to a new element, then filter by that.

As usual, you can just use mine here if you wish.

Conclusion

Digg, Reddit, DZone, and feeds in which I only care about a subset of the entries make up a major chunk of my RSS subscriptions. Replacing those subscriptions with hand-tuned versions of feeds coming out of these pipes allowed me do a great deal toward managing the firehose.

Yahoo Pipes can do a lot more than I’ve covered in this post, and I encourage you to experiment with it. If you make a particularly interesting (and generic, reusable) pipe, feel free to post about it here in the comments.

The Political Brain

Drew Westen’s book, “The Political Brain,” is illuminating and engaging. The author is an expert in the human mind, and has devoted his book to relating his understanding of the brain to the world of politics.

Westen talks about what people really look at when they evaluate politicians and candidates. He backs up his assertions with many studies and experiments, clearly laying out exactly how the human mind works when it attempts to “decide” who to vote for.

I learned a great amount about the human mind reading the book. When I look back and evaluate campaigns or candidates, I can now see exactly where they went wrong (or right) and what they could have done differently. I understand how my fellow voters think, and I’ve even gained a great deal of insight into how I think (though I didn’t realize it).

Unfortunately, Westen’s book is really two books. The first book is a rational, scientific analysis of the brain, a breakdown of various campaigns in America throughout history, and a discussion of what candidates need to do in order to effectively communicate their personalities and politics to the voting populace.

The second book is a biased diatribe against Republicans and an overly emotional plea with democrats to follow Drew’s advice.

The first of these two books is phenomenal: scientific, accurate, and rational. The second of these two books is garbage: emotional, biased, and relentlessly irritating. To make matters worse, these two books are overlayed on top of each other inside of “The Political Brain,” the content of the book suddenly switching between these two sub-books at random in a jarring, frustrating way.

It’s a shame to see a scientific man fall victim to his own emotions and biases. I’m not saying Westen’s personal political views are WRONG, but I am saying they have absolutely no place in a book that really ought to be scientific and fair-minded.

The plus side is that the switches from scientific book to political rant are so extremely obvious and transparent that you never have to worry about internalizing as scientific fact something that is really political opinion. The facts are backed up by studies, and the opinions backed up by emotional pleas. While jarring, the differences are so stark that it makes it somewhat easy to read the political nonsense with one skeptical eyebrow raised and simultaneously read the scientific information with an open, spongelike mind ready to absorb new information.

Like I said, the factual portion of the book is absolutely riveting - well worth a read for anyone interested in politics, cognitive science, or psychology. The opinion portion of the book is frustrating and tiresome, and the reader is forced to wade through it to get to the good stuff.

I wish I could say this is simply a matter of me having different political opinions than Westen, but the fact is that I agree with most of his opinions. I agree with many of his characterizations of the modern day Republican and Democratic parties, and I believe in a lot of the same values he espouses in the book. But the fact remains, even as I read opinions I agreed with I found it obnoxious I was reading opinions at all, embedded in an otherwise factual and intelligent book.

I recommend the book, but I also feel compelled to warn anyone reading it, particularly people of political persuasions that differ from Westen’s, they are going to have a tough time getting through many parts of the book without hurling it across the room. Keep at it, it’s worth it.

Rating: 3/5.

My current job is the first one where I’ve ever pair-programmed. I actually recall interviewing for it, and I was asked if I had pair-programmed before. I said sure, occasionally I would pull another developer over to my desk to help me and we’d sit together to figure it out. This apparently was a decent enough answer to the question that I got the job, but now that I’ve been pair-programming nearly full-time for five months, I’ve determined that what I was doing before was definitely not real pair-programming.

When I first heard I’d be pairing at the new job, I was a bit apprehensive and skeptical. Do I really have to sit next to some fat developer all day, 40 hours a week? When am I going to check my RSS feeds? What if the other developer is gassy or hasn’t showered? How am I going to listen to my totally awesome Death Metal if I can’t wear headphones? Will the other developer be constantly judging and correcting my code? Will pairing prevent me from hitting “the zone” where I’m just belting code out so fast that my fingers can’t keep up with my brain?

Over the last five months, I’ve found answers to all of these questions: “no,” “often,” “that’s rough,” “easily,” “sort of,” and “YES, but that’s a good thing.”

The Mechanics Of Pairing

The way pair programming works in practice is quite a bit different than I imagined it. I envisioned a day where I couldn’t escape the company of some other developer, constantly having eyes looking over my shoulder. I’m not a terribly social person, so the idea of interacting with a single human being all day was not my idea of a good time.

In reality, you don’t sit down at a desk with another person and work all day with them. You pair up for tasks.

So, once all of the stories for the iteration have had concrete tasks assigned to them, people pair up to do them. So a dev and I might pick a specific task and work on it together. Two other devs pick another task. My pairing partner and I sit at a big 30 inch monitor and work on the task (just that task) together. Generally when you pair one person is the “driver” and one is the “navigator” so one person is implementing code and the other is thinking of design implications, refactoring opportunities, or the “next step” for the task. If you get stuck or pause or just want to switch, you pass the keyboard to the other person and switch roles.

When doing Test-Driven Development, one of the things we do is called “ping-pong pairing”. So the other developer will write a test, then make it compile but fail. Then he passes the keyboard to me. I implement the feature just enough to make the test pass, then I write another failing test and pass it back.

When the task is done and code is checked in, the pair breaks up. Generally tasks only have 2 hour estimates (sometimes less) so you’re only pairing for the two hours. Then you pair up with someone else to work on another task. If a task is taking longer than expected, or the pair “goes dark” (meaning they aren’t talking) then you shuffle the pairings.

Between these tasks, you might go have lunch, or take a break from coding to watch a video on youtube at your desk, or check your RSS reader for a few minutes, or go take a walk, or go downstairs and play some ping pong or foosball. We take breaks often because getting away from the code for a few minutes helps keep a fresh perspective when you come back to the task. Physical activities like walking or playing ping pong help with blood circulation, which helps your brain.

It’s also nice to have an odd number of developers, which we do. This way, one person is working without pairing. Usually this person will work on a defect instead of a story, or they’ll work on a story where everyone understands what needs to be done for that part of the code. If you don’t feel like pairing or you need a break, you volunteer to be the odd man out for a task. When I first started pairing, I frequently volunteered to be the odd man out and work alone. Today, having been pairing for a few months, generally I try my hardest to avoid being the odd man out.

In an 8 hour day, I’m probably pairing somewhere between 4 and 6 hours noncontiguously. It’s important to have a good setup for it - big monitors, comfortable chairs, no corner desks (so that the devs can be side by side at the flat desk with the monitor between them).

Effectiveness

I see pairing work so well every day that I consider my career prior to my current job to have consisted mostly of wasting time. When I think back to all the code I’ve written for a job, I’m annoyed at how much less efficient I was then since I wasn’t pairing, and how much better my code and my products would have been if I had paired on them full time.

When you have a second person working with you, you find that you try harder to code well. You’re far, far less likely to be willing to apply duct tape to a problem, because someone else is working with you and he or she is more likely to object to the duct tape. If two people approve a hack and implement it, it’s almost certainly because it’s the right approach given the time constraints. If one person sitting alone decides to pursue a hack, it’s more likely to be a situation where there is a better approach.

Two people attacking a design problem together is easier than one person doing it. Your partner will think of things you don’t, and vice versa. In a non-pairing environment, you can always call someone to a whiteboard to help you work through a design issue, but when you do that you’re only calling for help when you know you need it. The times when you need help and don’t know it go unaddressed - and yet despite the fact that you need help, I guarantee that you’re coding SOMETHING and checking it in. It’s almost certain to be shitty code. The amount of time you spend trying to figure out “what’s going on here” or “why isn’t this working the way I expect” is severely reduced. I’m talking hours of debugging that literally turn into seconds.

Pairing also helps a great deal with collective code ownership. I don’t feel like there are any realms of the code that “belong” to any team member. You don’t have a situation where one person is the “expert” on a part of the codebase, since that person worked with someone else when they wrote it, and everyone likely shuffled around while it was developed. EVERYONE has seen that part of the codebase before, which means EVERYONE feels comfortable refactoring or extending it. This enables the team to perform improvements to any part of the code whenever they are working, which leads to technical debt being paid off very quickly. I often find myself shocked at how good the quality of the code is that we write and that we’ve written before. The product is ENORMOUS in code size, easily the biggest I’ve ever worked on, but there are very few areas of code that I would consider bad at all, and all of those are the earliest parts of the code that were written (and were written without pairing or TDD).

Pairing fosters a collective unity that I haven’t seen anywhere else. There are obviously issues and challenges, and there’s no denying that you’re producing fewer lines of code per day since only half your team is coding at any one point. I don’t consider that a bad thing, though (if you have two solutions that equally solve a problem, the solution with fewer lines of code is the superior one) because the QUALITY of the code that IS produced is so, so, so much higher.

Challenges

There are definitely some challenges to pairing. Pairing at a corner desk absolutely does not work at all. The developers need to be side by side, the same distance from the monitor (which needs to be large). All instances in my career that I thought were “pair-programming” were not, because we were at corner desks. The person further away was, as a result, not as actively involved in the code (moving chairs is harder than moving a keyboard over a few inches). This isn’t pairing, it’s programming with someone watching over your shoulder. It feels like you’re being watched, not like you’re working with a peer. It sucks. I’m so glad that this is NOT what real Pair Programming turned out to be.

We have a team area with individual desks surrounding the area, but with “pairing stations” in the middle of the room. I find myself at my desk so infrequently (by choice) that my friends on IRC complain I never say anything on the channel. A good pairing environment is crucial.

Hygiene can be a serious problem. If one person smells, it’s rough to sit with them. I find myself going back to my desk often and the code suffers for it. If you’re pairing, take a shower, and hold your farts for your next bathroom trip. Just do it, you filthy pig.

The biggest challenge for me personally was essentially mourning for the death of “Programmer Man”. Programmer Man is how I think of myself when I’ve got my headphones in, speed metal blaring in my ears, and I’m coding like a motherfucker. My fingers can’t keep up with my brain. I’m In The Zone. For most of my career, this image is what I’ve considered to be the zenith. When I come home and was in Programmer Man Mode most of the day, I feel like I’ve had a good day.

Pair Programming undeniably killed Programmer Man. This was a tough adjustment, since I’ve considered that mode to be my favorite for so long. I now see, however, that Programmer Man was, without me knowing it, Technical Debt Man.

When you’re coding like a motherfucker, you’re often writing bad code. You’re more likely to be outputting hundred-line methods. You’re sometimes willing to skip writing tests (tests slow down Programmer Man). You’re not pausing as much to think about design implications or ways that the code could be refactored. You may not have time to fix the code you’re working WITH; Programmer Man is too busy working on his own code to give a crap about some other guy’s code. Programmer Man’s code is almost certain to be more brittle and more poorly designed than if someone were sitting with him, making him slow down and THINK more often. Programmer Man’s code may not have been BAD, but it was generally worse than if he had a partner.

Programmer Man was too busy coding to do as much serious thinking, and the quality of the code suffered for it. And in the situations where you can be headphones-on, heads-down but still write tests and think about design, modularity, and quality, it’s almost certain that two heads would have been better than one. If you’re coding at a reasonable pace, pair programming will not slow you down. Conversely, if you code so quickly that pair programming slows you down a lot, you were making mistakes before. You need pairing more than anyone.

Programmer Man is dead, but I don’t miss him. Not anymore. My standards for what is “good code” have greatly increased and quite frankly I’m not sure ANY of Programmer Man’s code ever met that standard. Today, nearly all of my code does, and I have pairing to thank for it.

And the headphones situation is easy to solve as well - at work we pick a musical theme at the start of the day, then use Pandora to provide music consistent with that theme all day. I get my “Killswitch Engage” theme and my “Slayer” theme days because I graciously put up with another developer’s “Angels and Airwaves” theme and “The Cranberries” theme.

Final Thoughts

When I leave my job (which I don’t see happening any time soon) if the next company doesn’t do pair programming, it’s going to be a tough adjustment to me. It would be like walking into a new company and finding out that nobody uses version control - everyone just copies their changes to a shared directory at the end of the day. Sure you get the job done, but god damn you’re being inefficient about it. When people hiss at pairing because they can’t listen to headphones or don’t want to sit next to a fat guy, it sounds to my ears EXACTLY like someone complaining about SVN being too complicated.

I’m not going to advocate pairing, because anyone who reads this post and says “hey, maybe we’ll give it a shot” and then forces their team to do it will find that it doesn’t work. For pairing to work, everyone has to WANT to pair. That means they all at least need to be curious enough about it to give it a genuine shot - attempting pairing with the attitude of illustrating it doesn’t work will certainly show that it doesn’t work. If you’re holding onto Programmer Man, you’re doomed.

But if you’re willing to give it a genuine effort, push through the challenges and difficulties, read a book or two about how to pair, or maybe even hire a mentor to come to your company and help you pair for a few weeks, I think you’ll be pleasantly surprised by how effective it is.

“The Art of Agile Development” by James Shore and Shane Warden is a book that is primarily focused on explaining Agile to people who want to adopt Agile software development practices for their team. The bulk of book is divided into sections based on a categorization on agile practices. There is a chapter on practices that help with thinking, one for collaborating, one for releasing, one for planning, and one for developing. In each of these chapters, there are sections devoted to a specific practice, such as “pair programming”. The sections describe how to do the specific practice, what benefits it offers, what challenges you might face when adopting the practice, and so on. Usually it also has some frequently asked questions about the practice (with answers, of course) and some suggestions for alternatives if you have a reason to not adopt the practice.

First and foremost, I need to mention my biggest criticism of the book. It has one of the most misleading titles I have ever seen. This is *NOT* a book on Agile. It is a book on XP, one of a few different flavors of Agile. The correct title for this book is “The Art of Agile Development using XP.” This is worth mentioning for a few reasons. First of all, XP’s practices are pretty hardcore. XP’s engineering practices are all extremely useful, but most of the time when a company or team resists Agile, it’s because they are resisting a typically XP practice, such as Test-Driven Development or Pair Programming. Personally, I’m a big fan of XP’s practices, but the fact of the matter is that any team that wishes to become Agile will likely find the most resistance if they try to adopt XP, so it seems misleading to sell the book as an introduction to Agile when it is, in fact, an introduction to XP.

That said, this is an excellent book on XP. All of XP’s practices are covered in just the right amount of detail - giving you enough information that you can adopt the practice, but requiring that you do additional research about the ones that interest or challenge you the most. This allows the book to be a pretty quick read in general, which is beneficial for a team wishing to adopt XP practices soon. This level of detail does have one disadvantage, though: by staying largely in the realm of hypotheticals and ideals, I often found myself thinking that the authors were being naive and idealistic about how easy some practices were to adopt. This made me somewhat more skeptical of the book than I would have been if more detail had been offered, but ultimately I felt the level of detail was right; I did my own research online about some of the things that challenged me.

One of the most annoying aspects of the book are the “examples” that are sometimes provided. Usually these examples provide a sample conversation between stakeholders as they illustrate the effectiveness of an XP practice. These little micro-plays are so exaggerated that it often felt like reading the script to a bad company training video. After a few, I found myself skipping them.

I learned an awful lot about XP practices, particularly Pair Programming, estimation techniques, and incremental design. I felt that a number of these topics were better covered in other books, but “The Art of Agile Development” seems like it is meant to be an introduction to XP. In fact, every section generally provided a list of books that covered the section topic in more detail, so I think the book is meant to tease you by design.

I recommend this book for a team that wishes to adopt XP as quickly as possible, but I cannot reiterate enough that this should be the first, not the last, XP book you buy if you wish to become an effective XP team.

Just recently Google started pushing new firmware to the phone with a bunch of new features. My phone suddenly popped up a screen asking if I wanted to install the update, but I was in the middle of something so I said “Update Later.” The screen vanished, and when I finished what I was doing I was unable to find a way to make the phone check for updates and try again.

Here is how to do it if you do the same thing I did.

1. First, have AnyCut installed if you don’t already
2. Next, Create a new shortcut on your phone’s desktop. Select “AnyCut” and then select “Activity”
3. Select “Device Info” as your activity. I can’t find any other way to get to this activity on the phone
4. Press the new shortcut icon you have created.
5. Scroll to the bottom and find the “Check for Updates” button. Click it. You may have to a few times for it to succeed.
6. Once the “checkin” has succeeded, exit back to your home screen and you will be prompted to install the update.

That’s it!

This means that it’s more important than usual for a software engineer to be “marketable”. Engineers need to make sure they stay current on technologies that are widely used in their field. This is a somewhat daunting task considering just how many technologies there are out there. Luckily, there are resources to help narrow this down.

What follows is an investigation into what technologies/products/frameworks/languages/tools are showing up in job postings for Java developers using Indeed.com. This sort of thing can be very handy if you’re looking to improve your skillset and would like to focus on improvements that make you more likely to land a new job if you were to need to.

Obviously, one of the most prominent traits of good Software Engineers is a natural curiosity and motivation to learn. Most engineers I know (including myself) have a list of technologies and tools they’d like to check out. This article is merely meant to help engineers prioritize their list to whatever extent they are being motivated by career aspirations or security. In other words, you may not see “Haskell” on this list, but that does not mean I am somehow arguing that Haskell isn’t worth learning. I am merely saying, to whatever extent your career is a priority, perhaps a different tool or language may be more of a priority for you than Haskell.

I also want to reiterate that this analysis is for Java Developers. Why Java? Because the stress of this article is on career, not academia or intellectual pursuits, and Java and .NET are still the industry leaders.

So if you’re a Java developer, you want to learn something new, and you want to help protect your career from economic instability, take a look at each of the sections below and, if you aren’t familiar with either the “most popular” or “fastest growing” technologies, add them to your list.

And if you feel that I’ve missed an important technology, please leave a comment and I’ll update the post.

Persistence Frameworks

Most applications need to save data to a database. Most large applications rely on frameworks to help with this process. For this category, I’ve searched for toplink, hibernate, ibatis, jdo, spring dao, and ‘jdbc’ itself.

Java Persistence Frameworks

The big winner here is clearly Hibernate. There seems to be a still-present (and possibly rising) number of job posts that mention JDBC in the listing, but that may well be in conjuction with other technologies.

Databases

To see which database technology is the most popular for Java developers, I’ve searched for mysql, postgresql, sql server, oracle, sybase, and db2

Databases

Oracle returns the most hits here, though it’s difficult to know if that’s always the database platform in every case. Microsoft’s SQL Server is a big winner here as well. As far as open source tools go, MySQL is where the jobs seem to be.

Web Frameworks

Writing web applications without a web framework is pretty grueling. Most companies recognize this and use web frameworks to lessen the pain. Here I’m looking at spring mvc, struts, javaserver faces, tapestry, wicket, and webwork.

Java Web Frameworks

The big winners here are Struts and, to a much lesser extent, Spring MVC. Struts seems like something of an old standard, while SpringMVC is the up-and-coming technology.

Web Technologies

For developing on the web, you’re going to want to be familiar with various technologies, even as a Java developer. For this, I’ve searched for html, css, ajax, javascript, google web toolkit, flash, and flex. Note that I’ve added “java” to each query to ensure that these skills are important for Java developers.

Web Technologies

HTML and Javascript are the big winners here, no surprises. Ajax seems to have passed CSS as of 2007, which is interesting. Flash and Flex seem to both be on a steady but slow rise.

App Servers

In a perfect world, Java developers would never need to know anything about the server in which they are deploying an application since they’d all follow the same standards. In reality, however, the popular application servers offer many different features and companies that don’t mind running the risk of vendor lock-in code their applications to those features. As a result, knowing the ins and outs of application servers can be important.

Here I’ve looked for websphere, jboss, apache geronimo, weblogic, tomcat, jetty, and glassfish.

Application Servers

The big winners here are WebSphere and WebLogic. Tomcat and JBoss, however, seem to be on a clear slow growth.

Environment Tools

Many companies believe that hiring a developer who is already familiar with the development environment they use will allow their new hire to hit the ground running. This means that sometimes job posts will mention IDEs, version control systems, and build tools.

For this comparison, I’ve searched for ant, maven, git, subversion, cvs, eclipse, netbeans, and intelliJ.

Environment Tools

Eclipse is a big winner here, as is Ant. In the version control war, CVS came out the winner, but the growth rate of Subversion seems to indicate it will eventually overtake CVS. In a related observation: holy crap people still use CVS?

Other Languages

Good developers branch out of their comfort zone to pick the right tool for the job, and good companies know this. So what should a Java developer know other than Java?

For this, I looked for ruby, python, scala, erlang, c, c++, php, groovy, and perl.

Other Languages

There’s no way around it, the best way to bolster your Java career is by expanding into C/C++/C#, though it’s possible these numbers may be partially attributed to job posts that look for candidates familiar with EITHER Java or C++.

Additionally, I was surprised to see Perl so high on the list. PHP, Python, and Ruby all seem to be on the rise as well, so learning those may put you ahead of the curve.

Overall

So far, we’ve seen a large number of technologies that are worth learning if you want to strengthen your career as a Java developer. Unfortunately, our time is limited and our wallet finite, so it may be handy to see which of the above popular choices are more popular than the others.

I’ve taken the top couple of search terms from all of the charts above and combined them into a single search to get a handle on relative importance. I’ve also added spring, ejb, and junit to the list. Why? Because, had I created a category for each of them they would have completely dwarfed the rest of the items in the category anyway.

The search terms are ejb, junit, spring, perl, eclipse, ant, websphere, javascript, ajax, struts, springmvc, and hibernate. I’ve removed C/C++/C# from the comparison because it dwarfs everything else.

Overall Comparison

Javascript and Perl (I’m still surprised by this) are the big winners overall. This indicates that the two strongest skills for a Java developer to have are, somewhat ironically, to know how to program in something other than Java.

Let’s remove everything that isn’t Java-specific from the chart, searching only for ejb, junit, spring, eclipse, ant, struts, springmvc, and hibernate.

Java Specific Overall

So the best Java technologies for Java developers to know are Hibernate, Spring, and Struts. Following that, companies seem to value skills with EJBs, Eclipse, Ant, and JUnit, with SpringMVC gaining popularity.

I suppose that all of this data means the ‘quintessential’ industry application is a Struts-based web application built using Spring, Hibernate, and EJB technology with an Oracle (MySQL if using an open source stack) database, written using Eclipse, built using Ant, tested with JUnit, and deployed in WebSphere (JBoss if using an open source stack).

Designing and implementing a web application using Struts, Spring, Hibernate, EJBs, MySQL, Eclipse, Ant, JUnit, and JBoss seems like a pretty solid way for a Java developer to make sure he or she has the skills that are in highest demand, and doing so would cost no money whatsoever.

I refer to this question as the “Career In A Bottle Question”

The Career In A Bottle Question

Very often this question is actually given prior to an interview, as something you submit to a company after passing an initial phone screening but before they bring you in. The question takes a form similar to the following:

Write a program that will [anything]. Please write it as though it were going into production.

It’s the second sentence that does a candidate in. Why? Because there is no right way to answer the question.

More specifically, there is a right way to a single interviewer, but you have a 50/50 chance.

Allow me to elaborate by making this concrete. Imagine the question is as follows:

Write a program that calculates what phase the moon is in for a given date (the input) as though your code were going to be used in production.

If I, as an interview candidate, were to see a question like this, my mind would go through the following thought process:

Well, that’s actually a really simple algorithm. Read a date from commandline, do a little calculation, print out the phase. But wait, they said they want it to be like production code. So I should probably design it in a more object-oriented modular manner than just some procedural script. And when I write production code, I unit test it, so I should write some unit tests. And with all that code, I’m going to need a build file… Jesus, this seems like overkill for a 10 line script.

It’s the last sentence that destroys me, and many other capable programmers. On the one hand, production code needs tests, it needs a build, it needs to be well designed, and it needs to work. On the other hand, the problem I was given is a 10-liner, and it seems like overengineering to do anything more.

If I write the simple script version, will the interviewer think that I write one-off production code without tests?

If I write the full system, will the interviewer think that I overengineer everything I write and anyone who maintains my code will have to deal with an overly complex system?

I have no way to know.

I have no idea what the interviewer’s expectations are, so I have to guess. I have, essentially, a 50/50 shot at guessing correctly. To make matters worse, my answer will likely go through a number of different interviewers, and I have a 50/50 shot at having guessed correctly with each of them. Assuming that a single “no” from one of the interviewers means I don’t get a job offer, having 2 interviewers gives me a 25% chance of success. Three interviewers gives me a 12.5% chance. A team of 6 or 7 interviewers (extremely common in up-and-coming companies) gives me virtually no chance at all.

Generally the conversation about the interviewee’s qualifications goes like this:

Interviewer 1: I really liked his answer to this question. He has a good design, good unit test coverage, and a fast build.
Interviewer 2: Yeah but he wrote this future-proof ten-class system for a simple math function. Why did he write code for requirements he wasn’t given? I don’t want to hire someone that’s going to spend 2 weeks writing something that should take a day.
Interviewer 1: Yeah, I guess I can see that. He did write an awful lot of code.
Interviewer 2: Let’s keep looking.

You can’t possibly have written something to please both of these interviewers without hitting the magical, arbitrary middle-ground exactly between the two of them. If there was a third interviewer, you’d have virtually no chance.

What’s Going On Here?

Fundamentally, the reason this question is bad is that there is a mismatch between two of the constraints. On the one hand, the interviewer is told to code as though it were something he were assigned at work, but at the same time a programmer would never get such a simplistic task.

Interviews are tricky, because you can’t tell your candidate to reinvent your product for you in the interview. Questions need to be simplified to make the interview process manageable, but once something becomes simplified it leaves the realm of something you’d actually have to write in production. As a result, there is no way to word a question like this without making it conflict with itself.

Essentially, this question breaks down because it’s testing too many of the candidate’s skills simultaneously. What the interviewer wants to know here is:

1. How are the candidate’s algorithmic skills?
2. How are the candidate’s design skills?
3. How are the candidate’s testing skills?
4. How are the candidate’s Java/Ruby/C#/Whatever skills?

Occasionally, these questions are worded in a way to also test a candidates familiarity with a framework as well, such as an additional constraint of “Use Spring” or something of that nature.

The problem is that you can’t get the answer to all of these questions while keeping the questions manageable in scope and size. Good design skills mean a high degree of modularity and encapsulation, but testing modular code means writing more tests than is appropriate for an interview. Good algorithm skills mean writing simple procedures that perform a task, but simple procedures do not lend themselves to the scope that give insight into a candidate’s design skills or language knowledge.

How To Change The Question

If you’re a company looking to hire, don’t ask the Career In A Bottle question or you’ll wind up passing on a number of highly qualified candidates. The only people who will get in are the ones who just so happen to hit the magic compromise between the ideal responses of all of your team members. It turns what should be a game of skill into a game of luck.

Instead, figure out what you’re trying to ascertain, and ask direct, focused questions centering around those topics.

If you want to know a candidate’s algorithm skills, ask a question fitting this template: “Write a method that takes a [something] and determines [something else]. Use any language you wish.” By saying that you only want a method, you are removing any concerns the candidate might have about your expectations regarding class design and testing. By saying the candidate can pick any language, you are making sure they aren’t wasting mental power on remembering language specifics or APIs. The answer you want from the candidate should be whiteboarded pseudocode, easy to read and functionally correct. If you need to say something like “pretend that there’s no something-or-other method,” feel free.

If you want to know a candidate’s design skills, describe the requirements of a large-scale system and ask that they draw UML describing the classes in the system, how they interact, what extends what, what’s an interface, etc. The question should sound similar to “Sketch the design a system that [something].” By saying sketch, you’re making it clear that you don’t want any code. You want method names, class names, and so forth. The candidate should give you boxes, arrows, and method signatures on a whiteboard, though I wouldn’t be too strict about the adherence to the UML standard unless it’s important to your company.

If you want to know a candidate’s testing skills, then YOU should be the one drawing boxes and arrows on a whiteboard. Sketch out a system with classes and methods and ask how the candidate would test your system. Ask about how he or should would strive for complete test coverage on a unit test. Ask about functional tests and integration tests that test multiple aspects of the design. The candidate should answer this question with, in my opinion, words only. Descriptions and methodologies, without writing anything down.

If you want to know a candidate’s language skills, then and only then should you give an assignment. Pre-interview assignments aren’t good at determining anything other than a candidates ability to write code in a specific language and work with the API for that language. Asking language and API questions during an in-person interview is pointless since it tests a skill that developers don’t need unless your company’s internet connection dies and all of your books catch fire suddenly. The best way to give a programming assignment is for YOU to actually provide some code. Provide an interface and a test or a program that uses an implementation of that interface. Ask the candidate to provide the implementation. This way, the candidate can actually compile and run the code to make sure it does what it should (an ability he or she would have in real life). It also gives you control over what you want to make sure the candidate is familiar with. If it’s important to you that the candidate be familiar with the java collections library, write an interface that passes various collections around.

Weeding Out

The biggest objection someone may have to my suggestions above is probably that the purpose of the assignment is to weed out candidates before everyone has to take time out of their day to interview someone in person.

I believe that you can actually convert the information you wish to gather from a programming assignment into information you can easily gather with a phone screening. The algorithm question can simply have the complexity of the question decreased to a point where you could describe the algorithm with words alone, over the phone. The same goes for the design and test questions - you can make the system under discussion less complex and the questions and answers can be transmitted through speech alone. And you can still do language/API/framework familiarity testing by giving a programming assignment following the specifications described above.

In my experience, following these suggestions may make the interview process take slightly longer than you may like, but the end result is that you severely decrease the number of false negatives. Those qualified candidates that you aren’t hiring because of bad questions are getting jobs elsewhere, and it may be your competition.

Don’t throw good programmers away because you’re too impatient to ask narrowly-scoped questions.

Don’t ask the “Career In A Bottle” question.

Update: Some people have pointed out that you can simply ask the interviewer what he or she is expecting from you. While this is usually a decent workaround, I’ve often seen the attitude taken that figuring out what “production ready” means is part of the question. One particular horror story I’m aware of from a friend has him asking the interviewer ‘Do you want me to include tests?’ and having him respond ‘Do you not normally test your production code?’

If you were to insist on asking a question like this, adding additional information to the description such as “I’m expecting unit tests and a build file” makes it far more palatable.

I still feel that the question is fundamentally flawed because it attempts to ask too many questions simultaneously, and would be better split into a few more narrowly-focused questions.