Hiring based off years of experience

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/hiring_based_off_years_of_experience.htm]

I often see a job openings that require "X years of experience". While this makes sense as a general rule, there are a lot of exceptions. The problem is that you're hiring a developer to design and ultimately write code, and the computer doesn't care how old you are. Instead, it cares about what you type into the keyboard, i.e. do you know how to program? The question is how does a developer know how to program? Recruiters look at "years of experience" because they hope it will equate to "knowledge of programming", but there are many reasons where the correlation breaks down:

1. A younger dev may have worked 50-60 hr weeks. An older may have only worked 40 hr weeks (so the younger actually has more experience).
2. A younger dev may continually work on new features. An older dev may just do redundant work (so the younger actually knows more).
3. A younger dev may continually solve hard, new problems. An older dev may just copy and paste code (so the younger has better problem solving skills).
4. A younger dev may have a huge background in related technologies. An older dev may have slightly more "experience" in the specific requested technology - but nothing else (i.e. 5 years Java + 6 months C# is better than just 1 year C#).
5. A younger dev may have started programming when they where just 10. An older dev may have just started after college (so the younger actually has more experience).
6. A younger dev may just be smarter, and can pick up new concepts quicker. An older dev may be slower and while he knows the current concepts, can't pick up new ones (which is huge because the technology keeps changing, so you continually need to learn new techs).
7. A younger dev may be motivated (perhaps seen through extra-curriculars like open-source projects and articles). An older dev may be apathetic.

Of course "years of experience" matters - certainly you want senior devs and architects to be experienced veterans. But "years of experience" is only one factor to determine how qualified someone is, and it's a weak factor if two candidates are only a few years apart. Assessment tests, writing code on a whiteboard, checking for extra-curriculars, in-person interviews filled with conceptually questions, even certifications, etc... can all tell you much more about their skill level than "number of years".

On a a related note, it reminds me of back in 2002 when recruiters would say "This position requires 3 years of ASP.Net experience", and I explained to them that ASP.Net hadn't been around that long. "Years of experience" is a nice generalization, or minimum bar, but ultimately we're all trying to hire motivated and talented people - regardless of their years of experience.

Refactoring Your MSBuild Scripts

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/refactoring_your_msbuild_scripts.htm]

I had the opportunity to publish an article for .Net Developer’s Journal: Refactoring Your MSBuild Scripts.

MSBuild is Microsoft’s new build engine. It is intended to replace NAnt, and in a way, DOS. It is an extensible Xml-formatted list of build commands. You can read the official MSDN documentation for MSBuild here: http://msdn2.microsoft.com/en-us/library/ms171452.aspx

There are already several basic tutorials for MSBuild, I wanted to write an article that was a little more advanced, and explain how to write better scripts.

Also, check out Sayed Ibrahim Hashimi's MSBuild blog: http://www.sedodream.com. He's written an entire book on using MSBuild.

Dealing with pressure-hacks

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/dealing_with_pressurehacks.htm]

Life is tough, and sometimes that forces us to make tough decisions. For developers under time and money pressure, that means occasionally writing code hacks that you’re not proud of.

I’ve met some developers who think that the only reason that hacks exist is because other people are dumb. Certainly many hacks are caused by ignorance, but many are also caused by unrealistic time, money, or features constraints that pressure someone into writing bad code. The critics seem to think that if only the world were as smart as them, then all code would be perfect – just like theirs (sarcasm). Ironically, these critics never seems to have had to dealt with the pressure themselves – they can tell you how you’re supposed to do it, or how their last company (that’s 10 times bigger) did it, or what the “Best Practices” are, but they don’t actually implement it themselves.

The best way I can think of to handle pressure-imposed-hacks is to:

1. Acknowledge that it is not ideal, and identify the problems.
2. Ask if others have a better idea (that can be implemented under the same pressue).
3. Document your hack, ideally in the source code or wherever else it matters.

The first step brings everyone to the same page. The second gets others’ feedback – maybe they know a helpful trick that will make everyone work. The third reaffirms to your fellow developers that while you’re aware that this isn’t ideal and you’re not trying to hide it, the code needs to be completed and this gets it done. These steps require humility and confidence from the coder: they admit what they don’t know something, but they can be confident that their approach at least solves the problem. Ultimately the company stays in business not by the critic who points fingers at everyone, but by the developer who makes the project work – even if it has an occasional hack.

Open question to readers - what do you think about hacks due to excessive pressure? Any interesting stories?

Giving good feedback

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/giving_good_feedback.htm]

Software is complicated, and we therefore must often get feedback from other people. Some people do not know how to give good feedback; they:

1. Blindly stamp it with approval - maybe they're shy, don't want to offend, or just don't know how to give feedback.
2. Point to useless details that don’t really help - maybe they don't understand how to improve it, but still feel compelled to say something.
3. Give completely impractical advice - maybe they don't know what's going on, or didn't want that feature in the first place.
4. Use it as an ego booster and try to rip the other person apart - maybe they're just a jerk. (Or, another theory: many socially awkward nerds go into software development. Perhaps they're just desperate for affirmation, and want to dim your candle to make theirs look brighter).

Feedback should be constructive and practical - it's goal should be to make something better. Here are some ideas how:

1. Do you understand what the thing is that you're evaluating? If not, save everyone time and admit that ("I'm sorry, I'm not really sure what this is supposed to do, so I can't really comment on it."). You can always learn more about it such that you can have an opinion later.
2. Point to something positive. The developer invested time and effort in what they're showing, so affirm something ("this took a lot of effort", "I like how it functionally works", "that's a nice algorithm").
3. See what you can practically improve (an algorithm, refactor it, better performance, etc...). Start with the most important improvements first, limit your suggestions to what they can handle, and make it practical.
4. If they did something poorly, and it's a touchy subject, try comparing it so something else good that they did. Compare these two feedbacks: (A) "Your first module had great performance, any way to make this second one perform well too? Perhaps we can run the profiler on it?" and (B) "This second module performs too slowly. Fix it."

Giving good feedback doesn't just help the recipient, it helps you too. You can help influence things for the better, others will respect you more, and it can be more mentally challenging (and therefore grow you as a developer).

Strings in .Net 2.0

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/strings_in_net_20.htm]

Jeff Atwood at Coding Horror summarizes a lot of interesting points about strings. I especially like the new .Net 2.0 "String.IsNullOrEmpty" method.

A junior dev code-reviewing a senior dev

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/a_junior_dev_codereviewing_a_senior_dev.htm]

We all know that Code Reviews are a good thing, especially for a senior dev to review a junior dev's code. But it is also beneficial to have the junior developer code-review the senior dev's work:

• The junior dev see what good code looks like
• The junior dev may still catch something - even senior devs make mistakes.
• It sets a good role model - if even senior devs are having people review their code, then certainly junior devs should be too.
• It offers humility to the senior dev - If you only review other people's code, and no one ever reviews yours, it becomes one-sided, and is easy to get into an ivory-tower mentality of only criticizing other code without accepting criticism of your own.
• It prepares the junior dev to possible take over easier parts of the senior dev's code, freeing up the senior dev for other important tasks.

Certification: Pro vs. Con.

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/certification_pro_vs_con.htm]

In the consulting world, I saw a constant pressure for devs to get Microsoft Certification. This has benefits:

• A certification implies at least minimal knowledge, commitment to the technology, and initiative to take some tedious exam.
• They're great for younger developers trying to get their foot into the door, or consultants who want to bolster a resume.
• They're good to ensure at least a general, broad knowledge
• They tell you what Microsoft and the Industry thinks is important to know.
• They're good when competing with another candidate for a job, to match their credentials. I.e. if they have certification but you don't, then it's an edge. But if you also have certifications, then it nullifies that advantage.

Many managers would point out that a certification is better than nothing, and distinguishes you from your peers. While this has some merit, I think certifications (at least the MS ones) can be overrated. Speaking as someone who has several MS certifications, I think that they have several limits:

Tests only broad and shallow knowledge, not the ability to think: A MS certification essentially requires broad, but shallow, knowledge in an area. That is important, but it has many limits. Developers need the ability to think and solve very complicated problems. Certifications don't really test in-depth problem solving.

There are other good things: Sure, a certification is better than nothing, but most developers aren't doing nothing - they're doing other constructive things:

• Reading up on other technologies
• Practicing technologies that are too complicated to have certifications for.
• Open source projects
• Extra features at work
• Their own personal pet projects
• Writing articles
• Mentoring other junior devs

These activities all can help make someone a better developer.

They can be cheated: Somewhere out there, there's got to be a black market for exam answers. Microsoft recognizes this is a problem, and wants to enforce exam security and integrity. Of course, the exams are straight-forward enough that if you need to cheat on them, you have bigger problems.

At Paylocity, any developer we hire needs to write code on a whiteboard. This quickly lets us see more of someone's thought process than a multi-choice certification exam. Certifications are good, and of course they have benefits, but they're not a silver bullet for everything.