A timeless process anti-pattern is when customers create a feature request and completely neglect to frame it in the phrase of a problem, rather they fill in what they perceive to be the solution. I simply call these – solution requests.

So what does the anatomy of a solution request really look like? Let’s first look what a good user story might look like:

As a paid customer, I can export my daily budget numbers to a spreadsheet.

Simple and small little user story. It doesn’t exactly explain why the problem exists, but some user stories are only meant to facilitate communication so the developer can understand the problem better.

Now here is a “solution” request:

As a paid customer, I can export my daily budget numbers to a spreadsheet. This will be accomplished by putting a button on the accounts page. This spreadsheet will be in CSV format with column A being the Total number, and D32 being the sum of all numbers.

This user story sucks, and rightfully so for a number of reasons:

Implementation Expectations

Who is it that makes feature requests? CEOs, paying customers, managers…in short, people from the top.

Solution requests are a Usability Engineers nightmare. Expectations to accomplish the feature (with the proposed solution) leaves very little maneuvering room if you are not willing to fight for it. Who knows usability habits better – a designer or the secretary?

Lack of Problem Understanding

Most user stories and feature requests are purposefully left vague as to engage the developer in conversation about the problem domain and possible solutions. When a feature request already has a solution, developers never have the chance to learn the problem domain that they are developing for.

It is necessary for quality solutions that the developer eventually becomes a domain expert in the problems that the software is trying to solve.

Solution, Party of 1

Assuming you have ignored my last two bullet points and have implemented the solution request. Probability is you have a solution that only solves one persons needs.

Without understanding the true problem, nor giving thought to how other people might benefit from the feature, you have created a feature that will probably be consumed by only one person (if that).

Allowing your clients and customers to create solution requests is just another weak link in the process chain that will allow for them to overrun and manipulate your design, process, and sometimes success of a project. Nip this anti-pattern in the butt by almost sounding Alex Trebek-ish,

Can you please phrase that in a problem?

This is Part #3 of the 3 Days To Building A Perfect Resume series.

Last week we talked about how to sell yourself and the best way to present your skills section. Now is the time to put it all together in one single and easy to use template. Ready? Here we go…

Highlight Your Strengths Early

Managers and HR people have just as busy days as you or I. Simply put, when managers are weeding through resumes they are scanning them quickly looking for the good ones and trashing the rest. As a result, don’t make any resume reader hunt for your strengths – provide them clearly at the very top.

As you can see above, I have highlighted at the top 3 big things:

• My name (which is extra helpful that is not an everyday name)
• MCSD Logo (color, image, and brand name recognition make it stand out)
• Summary of qualifications list

If you look at how people consume computer screens using the F pattern; hopefully, this resume header will grab the attention of a potential reader. First the name pops out…then the image…now back down to the list of qualifications. If we can get the reader engaged up to this point, I guarantee they will continue to read the rest of your resume (which is much better than getting it thrown in the trash).

Additionally, I really like this format as it considerably condensed my resume. I was able to remove the sections Education and Certifications while expanding on the section Summary.

Skip The ‘Goal’ Section

One thing I use to be guilty of is placing the “Goal” section at the top of my resume. You know, the ones that look like this:

Goal: To become a programmer at Smith, Smith, and Smith Lawyer Firm

The reasoning for doing this is to “personalize” the resume and have people believe that you have taken a special minute of your time to apply for their company. I hate this for a couple of reasons:

1. Takes up valuable space
2. Provides no informational worth about your skills
3. Wastes the readers time
4. Increases possibility of putting the wrong company name (I have seen it and done it)

The absence this section will not cause you to lose a job, but looking like a suck-up might. Ditch this section and give yourself some more space.

Brutally Summarize Your Professional Experience

Unless you are straight out of college and scrapping for content to put on your resume, you probably have enough professional history to fill a small novel. Yet, we are forced to put in on less than a single page in bullet point format. That’s cool, but it isn’t going to happen unless you trim out some of the fat.

Be brutal. List out your professional experience, read it, cut it in half. Read it again, and cut that half in half. You can not (and should not) list every war story in this section. Your resume is the pamphlet of your career and not the novel itself.

Personally, I recently had to trim off my very first job/internship as I didn’t have the additional room. It stung, but it had to be done.

Dig Deep

You probably know more than you think, and have done more than you are letting on. For example, I have an entire section dedicated to Publications. What else could you put on your resume? Here are some additional ideas:

• Author of blogs/journal articles/books
• Local/National User Groups
• Nonprofit/OSS experience
• Non-technical domain experience applicable to the hiring company

Prioritize them and fill out your resume with them. It will only help if it is not complete BS or fluff.

Hint That There’s Even More

Never include your references with your resume, unless specifically asked to do so as a requirement of submission. This is because you want them to know that there is more and to start a conversation by asking for it.

If you take a look at my resume below, I end my resume with this:

* Extended resume (previous to 2000) and references are available upon request

If they made it to the bottom of my resume, they want more, and what a better way than to give them a reason to call you and start a conversation. Extended resume? How much does this guy know? I wonder who is references are?

Optimize For Your Audience

A great reader comment on Part #1 – Sell Yourself With Business Benefits reminded me to make note of this:

It’s a good idea to try and figure out who is likely to be reading your resume… if it’s me, you can skip the management fluff completely. What I really want to know is what matters to the candidate. –Barry Dahlberg

Personally, I created a resume that is somewhere in the middle (because I am lazy). It speaks in both geek and benefits and is hopefully good enough to start a conversation with both parties. If you feel it to be necessary create separate resumes for the separate interviews and bring them with you. It is highly probable that each interviewer will bring a copy of your “generic” resume, but you can give them a more targeted one when you are face-to-face.

And that’s it! There is nothing hard about creating a gosh-darn good resume, and in fact I am about to make it easier. You can easily download both my personal resume and the template I use so you can have a good example to work off of. Good luck out there!

Download Example Resume and Template

This is Part #2 of the 3 Days To Building A Perfect Resume series.

Probably the funniest part of most developers’ resume is the “Skills” area. I almost chuckle out loud when I see a resume that appears as such:

Skills
I use the following languages and tools:

This is bad news as it implies is that you are highly competent in everything you listed, which [I am sorry] is not the case. People can be good at many languages, people can be great at a few languages, but nobody can be great at a ton of tools and languages at the same time.

Tools and languages are like foreign languages – if you don’t use it, you lose it. As a result, it is much more honest to separate out your experience into buckets that are defined by current familiarity. For example, the following is much more honest and accurate:

Skills
Highly competent in the following:

Familiarity or past competence in the following:

Familiarity from formal and self education:

This is much better as it represents a better picture of exactly what you are good at right now. In short, don’t mislead people into thinking you know more than you actually do. The last thing you want is to have your interviewer get the impression that the wool is being pulled over their eyes.

BONUS TIP: Another big reason for doing this is for technical interviews. It allows you many exits to escape the questions you don’t know and opportunities to flex the knowledge you do.

Let’s hypothetically say that you are applying for a Java job, but it falls under the bucket of “past competence” for you (you couldn’t code your way out of a Java paper bag anymore). If an interviewer asks, “How would you do X?” they are obviously looking for the answer in Java; however, you now have an ace up your sleeve and can respond as such:

As you can see, I haven’t coded in Java for awhile but I am certain I could pick it up really quick. However, I know how to solve this using .NET in about 10 simple lines of code – could I show you that?

Not being able to answer a question in a category you declared competence will surely be a big negative mark on your scorecard. On the other hand, taking this approach you will appear more humble, honest, and not stupid (and God knows I need not look more stupid).

-Good Luck