A hundred years ago, lighting lamps was a great way to earn a living. You’d carry around a giant pole and go from lamp to lamp lighting them up. See the city while starting fires, I can see the appeal. Many others did too and created a rich set of traditions, practices, and quirks.

Things changed without advance warning though. We figured out how to make gas lamps light themselves and a profession was extinct. A dedicated few kept it alive through sheer force of will but by and large lamplighting was dead even before the advent of electricity.

Such is the danger of specialization, a horribly easy trap to fall into. It’s tempting to focus your energies on improving the process of using long sticks to ignite lamps. However, it’s career suicide to forget that your customers want light, not sticks.

Bringers of light will never go out of fashion, but the demand for people with sticks is always a time-limited affair¹. Be very careful about tying yourself to just one way to set things on fire.

-SP

People who practice various forms of agile software development often make distinctions between capital-A “Agile” as a set of defined practices and methodologies, and “agile” as a broader philosophy of how to approach software. Bill Pietri sums it up best:

It’s important to note that they weren’t saying that they had an exclusive lock on agility, or even what made software development agile. As with the naming of Grand Rapids, they were pointing at a particular spot in the landscape of ideas and naming it. The word agile has a variety of meanings, and there are a lot of aspects to software development to which you could apply those meanings. They weren’t trying to lay claim to agility as a whole, any more than Grand Rapids is claiming all the rapids in the world, especially the grand ones.

Yesterday, the organization called Obtiva by those who worked there was acquired by Groupon. Just as agile practitioners differentiate between “Agile” and “agile” though, a similar distinction must be made here. While it’s true that this chapter in the history of Obtiva ends, it’s equally true that lowercase-o “obtiva” will continue to exist beyond this organization and even the people who comprised it.

This obtiva is present each time we build software with an empathetic view towards those in need of it. When one developer invests in another at the cost of their personal time and productivity, this obtiva is at work. Engaging with the larger community when there’s no personal gain is totally obtiva.

While I will stop calling myself an Obtivian, I have been extremely fortunate to practice obtiva daily with my friends and colleagues for nearly two years, and I look forward to many more. This is an opportunity to create and find much more obtiva in the world, and I am certain I will continue to share in obtiva with friends both old and new.

It has always been and will always be a great time to be obtiva.

Thank you to everyone who made it possible for me to share in all things Obtiva. I especially appreciate Kevin Taylor, Kat Nelson-Reid, Dave Hoover, and Todd Webb for deciding to take a chance on me and my “top-secret plan” to join them. This company has been a second family to me in times both tremendous and terrible, and I will always value that.

-SP

We’re in need of a venue for this meeting - if you know of a place in the Loop that could help, please contact me

We’re all familiar with words like “process” and “patterns” - in this meeting, we’ll look at different ways to think about and apply those terms in ways you may not expect.

Groupon’s Blake Smith will begin by examining why design patterns lead to good designs at the small-scale program level, why they often get ignored at the macro large-scale system level, and the impacts of doing so on your applications.

Then we’ll switch gears and go through a group exercise on understanding why your employer, (yes, your employer) has the process it does and how that impacts you. As with the previous exercises, this could be a huge success or huge failure but should be entertaining either way.

As always, anyone of any experience level and any background is welcome to come and participate.

Food and socialization will begin at 6PM on Wednesday, July 20th, and we’ll the start the meeting a bit after that. Once we’re done, we’ll wander on down the street to socialize and intoxify.

If you’re interested, please RSVP here.

Both portions be interactive, so please come ready to participate.

To stay informed on what’s happening with ChiSC, please join the mailing list at http://groups.google.com/group/chisc

See you there! -SP

I interview a fair amount of software developers (although not as often as I used to, sadly), and so I have people ask me about a variety of issues related to finding programming gigs. What certifications, what schools, what questions to ask, and even what attire to wear.

I really thought interview attire was something of a solved problem, but apparently not.

I digress. When I’m asked one of those questions, I usually try to stress that it’s hard to hurt yourself when answering any of the above questions. Yeah, some schools are better than others, but that doesn’t matter too much for programmers, especially once they have a year or so of experience. Certifications usually don’t hurt or help too much unless it helps you meet a job’s requirements (although an XML Master Certification is resume poison).

However, there is one particular brand of resume that, regardless of talent, really irks me and makes it difficult to get on my good side, let alone get a recommendation from me. I hate, hate, HATE finding a “spray and pray” resume. This is the kind of resume that is two pages long for every year of experience and is absolutely crammed with a wide range of unrelated technical terms. It’s the kind of resume where someone has liberally sprayed the document with verbiage and prayed that some of it tricked someone into interviewing them.

It doesn’t work.

Telltale signs you’ve written a Spray and Pray Resume

• Under “Programming Languages,” you list every single programming language you have ever encountered.
• You list every job, ever.
• For each job, you list an insane number of different, unrelated responsibilities.
• You have the world’s most vague Objective Statement.
• You list at least one OS for which you don’t know how to navigate the file system from a command prompt.
• You list any UI framework for which you cannot instantly tell me the base class/method/approach for displaying a “Hello world” window.

What’s so bad about that, huh?

Many people would say these resumes looks desperate, and you generally want to avoid looking desperate in an interview. I don’t really care too much about that however, as Lord knows I have been desperate for work before and lucked out to find a job despite it.

A more significant problem with this kind of resume is that is just looks lazy. If you can’t make the time to trim your resume down to only those things the interviewer has a chance of caring about, then why should the interviewer make the time to talk to you? Just 2-3 minutes spent making a specific objective statement, removing irrelevant items (or moving them to a Hobbies/Interest section if you really, really want them on your resume) and tightening the resume up in general can work wonders.

Worse than looking lazy is looking dishonest. If you are confident enough in some skill that you put it on a resume, then you’d damn well better be at least at an intermediate level in it. If you haven’t touched that programming language since high school, leave it off your resume. Otherwise, as soon as you have to tell an interviewer you don’t know much about something on your resume, you bring everything into question. It reflects poorly upon you, and the interviewer will subsequently devote a fair amount of time fact-checking your resume rather than really engaging with you.

Even if you don’t look lazy (which you might), and even if you don’t seem dishonest (which you will), you’re still doing yourself a disservice. Why? Because your strengths will be lost in the “noise” you create with unrelated terms and bullet-points. I promise you, even if you are just graduating from school, you already have strengths that are worth showcasing on a resume. It’s many times more effective to have three bullet points that prominently highlight things you excel at than to hide those amongst umpteen other areas where you aren’t so hot. By paring down your resume and saying less, you can let your strengths shine that much more and seem stronger.

Almost all of those problems listed earlier can be solved by simply going over your resume, and asking yourself “Could I answer a simple question about this?” If the answer is no, leave it off your resume. Otherwise, you might just be sitting across from someone like me who ALWAYS picks one of the programming languages you put at the end of your list and asks you to compare and contrast it against a language from the front of your list.

Oh, and never list XML as a programming language. (Although if anyone ever says that they really meant XSLT and that XSLT is Turing complete, I’ll be suitably impressed to overlook the mistake. Throw in a “Duh” for good measure though)

So I know this guy who knew about this one event months in advance, and yet didn’t think to post a blog about it until roughly 24 hours before.

What a dolt, huh? Sucks to be him.

Anyway, in totally unrelated news, Codeapalooza is tomorrow! It promises a day full of totally free .NET goodness and interesting workshops. There’s a full slate of pretty interesting sessions.

In particular, there’s a tasty-looking treat on rich, reusable user controls with MVC that I’m looking forward to pretty intensely. If we’re going to adopt MVC at the office, feature-rich reusable controls will be a must. But there’s also some lovely XNA exotica, Silverlight salaciousness, a slew of Sharepoint stuff (gag, vomit, WHY HELLO MICROSOFT YES I LOVE SHAREPOINT OKAY THANK YOU) and much more miscellanea.

If you attend, I’ll be the guy in the Chicago Public Radio hat who asks a zillion questions. Hope to see you there. -Scott