The FAIL Monster Loves Excuses

March 31, 2009 By 2 Comments

Do you remember watching the FAIL Monster on Sesame Street? Never heard of the FAIL Monster? Weird, I’m pretty sure he was Cookie Monster’s cousin or something. He would pop-up and sing a little song about your failures and then at the end he would go crazy and NOM NOM NOM all of your excuses. The really strange thing is that when I grew up, I still saw the FAIL Monster, except he was all over, eating up everyone’s excuses, not just mine. When was the last time the FAIL Monster paid you a visit?

The FAIL Monster Is Your Worst Best Friend

When you first meet him you’re trying to figure out what this asshole is doing hanging out right after you really screwed up. You realize that he’s no good, but as time goes on, you start enjoying his company. He loves showing up because he knows there will be excuses aplenty.

Here are some situations when you might see him:

  • You’ve messed up and can’t take responsibility
  • The project is off track and it’s not at all your fault
  • If only < outside agent > would have completed < task > on time
  • You start using Fat Bastard’s circular logic to explain away your problems
  • “I don’t have < resource > to do < what is right >
  • You don’t write tests

Put the FAIL Monster on a Diet

Here is a quick guide to help you trim down your personal FAIL Monster:

  1. Quit making so many goddamned excuses!

Stop making excuses for your lack of understanding, your irresponsibility, your lack of prospects and your shit attitude. Take the time to push yourself, learn a new skill, read a book, meet people, take a leadership role, achieve greatness and succeed.

You can make excuses for everything, the only thing they’re good for is feeding your own FAILURE.

Filed Under: Ideas, Riffs Tagged With: , , ,

Adaptive, Iterative and Agile Development is Fantastic

June 14, 2008 By Leave a Comment

The ability to work in short bursts of agility leads to amazing results. The ability to quickly adapt to changing needs brings satisfaction. The ability to combine all of these with Ruby on Rails makes for a happy developer. Adaptive, iterative and agile development with ruby on rails is fantastic!

Some Monkey Guy

Some Monkey Guy

What I Want Right Now

When I “launched” this blog a few weeks ago I had the ability to create categories and write posts. That’s it. No comments, no tags (still don’t have those) no permalinks, no photos no nothing. Just a really simple system of posting in various categories. This was fine for a while, but I wanted more. So, as time permitted I slowly added new features. Here’s a rough timeline with some made-up version numbers

1.0 - posts and categories
1.1 - user accounts
1.2 - polished admin interface
1.3 - permalinks
1.5 - comments
1.6 - admin comments
1.7 - new comment notifications
1.8 - photos

Together these would have taken a while, but as separate pieces they were simple digestible easy to complete tasks, perfect for my workflow.

Ship It, LDO

I would have loved to have all of these things and more when I launched originally but it wasn’t in my time budget so I had to break it up this way. I just needed to get something up and running, so I went with the most basic of basics. Turns out, I found some things that I could do with out right away (tags, search, ratings) and found some things that I wanted (permalinks, comments, photos). Everything bubbled up according to it’s importance and so far everything feels just right. When it doubt, just ship it. Like duh, obviously.

Rails Tie-In

If you haven’t realized quite yet, Ruby on Rails makes this agile/iterative approach super easy. Between migrations, built-in helpers and BDD I was able to add all of this new functionality piece by piece knowing that I wasn’t going to break anything I already had. Plus it didn’t take very long (learning curve not withstanding).

In a world dictated by client requests and boss-based to-do’s I don’t often get the chance to work like this, but for now I’m cherishing every moment.

Filed Under: Development, Ruby On Rails Tagged With: , ,

Learning Best Practices, Idioms and New Languages

June 5, 2008 By Leave a Comment

A few days ago I was listening to an episode of the StackOverflow Podcast and Jeff Atwood said something interesting about how he did a lot of reading as a kid but didn’t do much discussing about said reading with other people. The problem being that he had a lot of words that he wasn’t sure how to pronounce outside of how he had originally determined they should be pronounced. I was thinking about how this translates to code constructs and programming styles and how it’s easy to get stuck in your newb ways.

How Do You Say That?

I’m sure we’ve all experienced what Jeff was talking about, you’re reading something and you come across the name of a person or a place and you’re not really sure how to pronounce it but for the sake of moving through the material your brain comes up with something and you continue to use that each consecutive time it comes up in the material.

It’s only the next day when you’re talking about the text with a friend that you hear their alternate pronunciation of the word. Sometimes neither or you are sure what the correct pronunciation is, but you now spend the rest of the conversation saying each pronunciation, so as not to be rude, when referring to the word in question.

Learning PHP

A lot of programmers start out learning PHP. It’s easy to learn, make something, lots of resources etc. etc. However, I think that you tend to do a lot of the “brain deciding how to do this previously unknown thing” decision making while you’re learning. There was a post on The Daily WTF today about somebody who basically re-implemented the functionality of $_GET using their own hacked together POS method. It’s good for a laugh sure, but it’s not that unreasonable when you think about it.

Imagine you’re learning PHP and you’re like most geeks, introverted, you want to accomplish this goal of learning a new language, but you’re not planning on spending any time discussing it with other people. This is especially likely if you’re not learning in a work environment with other people. Since you don’t know a lot of the idioms, best practices and commonly used syntax you end up figuring things out and deciding that’s just how it’s done. I only use PHP in this example because of its wide use and forgiveness when not sticking to accepted practices (are there any?).

You find ways to do things and you stick with them, for good or bad, until you find out a different way.

Quit Being an Introvert

Do yourself a favor and get over keeping to yourself, you’ll be a better programmer and you might learn something about social interaction.

  • Join mailing lists (*and participate*)
  • Join forums (*and participate*)
  • Attend local in-person live events
  • Find some AIM/YM/MSN/Gtalk buddies who you can bounce ideas off of
  • Seek the advice of the more experienced
Filed Under: Development, Ruby On Rails Tagged With: , ,

Reinventing Wheels

May 18, 2008 By Leave a Comment

It’s been about two weeks since I started writing the ruby on rails app for this blog. I recently took a look at some of the established RoR blogging engines and this feels more like a somewhat circular rock. Even though this app is lacking a lot of the regular features of a blog, I’m extremely happy with how it turned out.

Build to Learn

One of the things that I realized early in my programming career was that reading about how to do something was nice, but I never felt like I really understood it. However, when I started actually building something everything started falling in place. I think this is a pretty standard realization for a lot of developers and it’s always something I keep in mind when learning a new technology. Enter Ruby on Rails. Even though I read a ton of stuff, watched lots of videos, subscribed to podcasts and purchased expensive books, I didn’t realize how much I was missing until I set out to plan, build and deploy this application.

Referencing the Reference Books

By a huge margin the best ruby on rails book I found was The Rails Way (non affiliate link btw). There was just something about it’s straight forward nature, clever writing and almost-but-not-quite reference book feel that made it so easy to use. There was a great post on the Signal v Noise blog the other day about years of irrelevance where David spoke about how it took him some time to get up to speed with ruby’s syntax, idioms and just how things worked. I think I’ve finally reached that point with rails, the more and more I used the The Rails Way the less and less I needed it. Combine this awesome book with building this app and I think I made it through the learning curve faster than I would have following tutorials or watching videos.

What I Learned

Here’s just a short list of things I learned while building this app. I plan to expand this particular concept into a series of posts.

  • Using RSpec for BDD Testing
  • RESTful controllers
  • Ruby syntax and idioms
  • Customizing and extending Rails
  • Deployment with Capistrano
  • Git

Sadly I had spent some time already reading about all of these, but never understood how far off I actually was.

When NOT to Reinvent

While I’m hailing the virtues of building your own stuff from scratch it’s important to know when “rolling your own” is a bad idea. First, if you’re doing work for a client chances are you’re going to increase your profitability by finding a solution that’s been built and tested and proven to work, do you really want to build your own Authorize.net processor when you can use Active Merchant instead? Secondly, if you don’t have the time and patience to work on your project with the understanding that you’re trying to learn as you go, you run the risk to slapping together something that’s a hodgepodge of bad code and shortcuts, which will be more trouble down the road.

App Delivers; Would do Again

Like I said earlier, while I don’t have everything I’d like in this app, I’ve learned more doing this than I would have reading about how to do this so I’m happy. I know everything about this app and can add to and improve it as time goes on. Perhaps most importantly I have the satisfaction of having built something that’s now facing the world which is one of the more underrated accomplishments in software development.

Filed Under: Development, Ruby On Rails Tagged With: , ,