• GiveCamp provides real value to organizations that truly need help. 

The Seattle event alone succeeded in helping sixteen non-profit organizations in many different ways.  The projects involved varied dramatically, including website redesigns, SEO, reworking data management workflows, and even game development. 

Many non-profits have a strong need for good, quality technical help.  However, nearly every non-profit organization has an incredibly limited budget.  GiveCamp is a way to really give back, and provide incredibly valuable help to organizations that truly benefit.

My experience has shown many developers to be incredibly generous – this is a chance to dedicate your energy to helping others in a way that really takes advantage of your expertise.  Your time as a developer is incredibly valuable, and this puts something of incredible value directly into the hands of places its needed.

First, and foremost, GiveCamp is about providing technical help to non-profit organizations in need.

• GiveCamp can make you a better developer. 

This is a fantastic opportunity for us, as developers, to work with new people, in a new setting.  The incredibly short time frame (one weekend for a deliverable project) and intense motivation to succeed provides a huge opportunity for learning from peers. 

I’d personally like to thank off the developers with whom I worked – I learned something from each and every one of you.  I hope to see and work with all of you again someday.

• GiveCamp provides an opportunity for you to work outside of your comfort zone.

While it’s always nice to be an expert, it’s also valuable to work on a project where you have little or no direct experience.  My team focused on a complete reworking of our organizations message and a complete new website redesign and deployment using WordPress. 

While I’d used WordPress for my blog, and had some experience, this is completely unrelated to my professional work.  In fact, nobody on our team normally worked directly with the technologies involved – yet together we managed to succeed in delivering our goals. 

As developers, it’s easy to want to stay abreast of new technology surrounding our expertise, but its rare that we get a chance to sit down and work on something practical that is completely outside of our normal realm of work.  I’m a desktop developer by trade, and spent much of the weekend working with CSS and Photoshop.  Many of the projects organizations need don’t match perfectly with the skill set in the room – yet all of the software professionals rose to the occasion and delivered practical, usable applications.

• GiveCamp is a short term, known commitment.

While this seems obvious, I think it’s an important aspect to remember.  This is a huge part of what makes it successful – you can work, completely focused, on a project, then walk away completely when you’re done.  There is no expectation of continued involvement.  While many of the professionals I’ve talked to are willing to contribute some amount of their time beyond the camp, this is not expected.

The freedom this provides is immense.  In addition, the motivation this brings is incredibly valuable.  Every developer in the room was very focused on delivering in time – you have one shot to get it as good as possible, and leave it with the organization in a way that can be maintained by them.  This is a rare experience – and excellent practice at time management for everyone involved.

• GiveCamp provides a great way to meet and network with your peers.

Not only do you get to network with other software professionals in your area – you get to network with amazing people.  Every single person in the room is there to try to help people.  The balance of altruism, intelligence, and expertise in the room is something I’ve never before experienced.

During the presentations of what was accomplished, I felt blessed to participate.  I know many people in the room were incredibly touched by the level of dedication and accomplishment over the weekend.

• GiveCamp is fun.

At the end of the experience, I would have signed up again, even if it was a painful, tedious weekend – merely due to the amazing accomplishments achieved throughout the event.  However, the event is fun. 

Everybody I talked to, the entire weekend, was having a good time.  While there were many faces focused into a near grimace at times (including mine, I’ll admit), this was always in response to a particularly challenging problem or task.  The challenges just added to the overall enjoyment of the weekend – part of why I became a developer in the first place is my love for challenge and puzzles, and a short deadline using unfamiliar technology provided plenty of opportunity for puzzles.  As soon as people would stand up, it was another smile.

If you’re a developer, I’d recommend looking at GiveCamp more closely.  Watch for an event in your area.  If there isn’t one, consider building a team and organizing an event.  The experience is worth the commitment. 

I feel honored and proud to receive this award, and hope that I can continue to be a valuable member of the community in the future.  Thank you to everyone who nominated me!

Understanding Big-O notation is critical in making good decisions about algorithms or libraries used to implement routines.  However, there is often a lot of misunderstanding about what it means, and I frequently see this used as justifications for poor decisions.

First, let’s define Big-O notation.  Big-O notation describes the limiting factor of a function as the argument or domain size of the function approaches a specific value, typically infinity.  Big-O notation describes a growth rate, not a speed.  This is important – one very common misunderstanding about Big-O notation is that it describes how “fast” a function will be – and this is never true.  It describes how a function or algorithm will scale, but says absolutely nothing about speed.

When programming, Big-O notation can be used to describe many different things.  Most frequently it is describing the algorithm in terms of instruction count or speed, but can also be used to describe memory or resource usage.  It’s important to know what is being described when making decisions based off this information, and seeing that an algorithm is “O(N)” isn’t enough information, in and of itself, to know what that means.

When and why is this useful?  It becomes very important to understand this when we start dealing with collections, especially if the collection is large or of an unknown scale.  For example, say you’re going to do some basic image processing, and you have the choice between a couple of different algorithms.  If each algorithm’s limiting behavior is based off the total image size, and the algorithm’s operation count is described in Big-O notation, the total number of operations will vary dramatically as your image size changes.  For example, let’s say we have the choice of 3 algorithms described by three different, but common Big-O notations:

• Algorithm A: Linear – O(N)
• Algorithm B: Logarithmic – O(log N)   
• Algorithm C: Quadratic – O(N^2)

[I am, for here, assuming Log in base 10, but for Big-O, it could be any logarithmic base and still be O(log N)]

Note the huge discrepancy in terms of instruction count!  Algorithm C is a quadratic algorithm, meaning that its instruction count increases by the square of the number of elements (pixels, in this case).

Now, given the information above, it seems like you would naturally always choose Algorithm B – it scales much, much better.  Often, this is true, and this is a good way to choose between algorithms, but we don’t have enough information to make an educated decision at this point.

Remember above – I mentioned that Big-O describes a growth rate, and not a speed.  In addition, it describes an upper bound for the growth rate, not necessarily the average case scenario.  For example, it may be that algorithm C is the fastest algorithm for processing a single pixel – perhaps by a factor of thousands.  Let’s look at these algorithms, and assign the number of actual microseconds each pixel takes to process on average, and look at the same chart as above:

• Algorithm A: 0.1 seconds
• Algorithm B: 10 seconds
• Algorithm C: 50 microseconds

This shows off a basic misconception of Big-O notation.  It’s not about speed.  Granted, if you’re planning to deal with megapixel imagery, you’d probably still choose the algorithm above with the best Big-O notation.  However, there are two things that may trip you up here when you’re developing this algorithm.

1. If you developed the three algorithms above looking only at a small image, you’d probably have picked algorithm C, hands down, because the per-pixel routine is so dramatically faster.
2. If you developed the three algorithms above with a large image, you’d have given up on algorithm C quickly, because of it’s poor scalability.

However, both of those are not necessarily good things.

In case 1: The reason this is bad is obvious.  Later, when you fed the routine a large image, you’d be in trouble (especially if you didn’t realize that it was quadratic at the time).

In case 2: If this routine was always going to be used on very small images, Algorithm C is a superior choice, even though it has the worst Big-O description.  This is because it’s single element speed is so much better. 

Also, Big-O only describes the upper bound (which is very important), but the average case of an O(N^2) function may actually be closer to N Log N (quicksort is this way).  It may be that, when we actually look at real execution times in a profiler with real data, the algorithm performs, on average, in N log (N), in which case the “real” runtime may be more like:

All of a sudden, our O(N^2) algorithm is looking very, very good – much better than any of our other algorithms!

What can we take from this?  There are a couple of important points:

• Big-O Notation can provide critical information about the scalability of an algorithm.  Coupled with information about the algorithm itself, this can help us decide which of multiple algorithms will be the “best” choice.
• Big-O Notation does not provide information about speed.  Factors in the algorithm itself, including total number of instructions required, are not included as part of this notation.
• Knowing the Big-O notation for a method, or doing your own analysis of the algorithm, is not a substitute for profiling.  “Bad” routines in terms of their Big-O notation can outperform “good” routines, in certain situations.

Now, personally, I am not a “web guy.”  I do nearly all of my development on the desktop, and most of my experience with web development has been using the LAMP stack, mostly via PHP.  I do try to keep current on what’s out there, and play with a few technologies as they become commonplace, but my day to day programming is still C++ and C# on the desktop.

That being said, I was pleasantly surprised with ASP.NET MVC.  The routing mechanism that’s core to the framework is very elegant.  It does seem obvious to me that Microsoft is borrowing ideas from the Ruby on Rails folks with this – it’s a pretty far departure from the previous means of developing using ASP.NET.

In particular, I love the separation of concerns and the testability.  I definitely think it’s worth checking out…