The company I work for is hiring several developers which marks my first significant hiring effort since being promoted to management. This had led to a few interesting observations* I would like to share that may benefit both those looking for a new job and those looking for the next star to add to their team.

Immigration Law: I had no idea how complex this area of law gets; it’s a maddening maze of rules and policies that are more effective at confusing those involved than providing a reasonable solution to a problem. If you run into this (and you will), you need somebody that has dealt with this and knows what to do. Getting both parties into legal hot water is far too easy.

Resumes: I’ve seen great resumes that made it clear that I needed to hire this person and resumes so cluttered and complex it took an hour just to get through it. Here’s a few things that stuck out to me:

• DRY is good for code, and for a resume. Clean and concise is always better; if you find yourself hitting Ctrl+C even once while working on a resume, you’re probably doing something wrong.
• Length is important, but shorter isn’t always better. Unlike many other fields where a single page resume is considered optimal, technical resumes need at least a second page. Going too short on a resume is a great way to blend into the crowd; a resume should stand out, and that takes space.
• How long is too long? Unless you’ve been doing this for a very long time, more than three pages is probably excessive. This isn’t always true, but think it through before using more than two pages.
• Use whitespace carefully. Don’t leave a page half empty or pack everything in so that it looks cluttered. As with any type of design, whitespace is a powerful tool that should be used wisely and never be left to chance.
• Use color sparingly. Many corporate printers are black and white only, so if you use color make sure it looks right when printed without it.
• Use bold even more sparingly. It’s sometimes useful to point out items of interest, but it quickly degrades the readability of a resume.

Many people seem to have a hard time with this, but a resume is a textual representation of yourself. It represents you as a person and your accomplishments as a professional. Any errors or signs of haste or carelessness say much about you as a person; if you are careless with such a significant representation of yourself what does it say about your attention to detail or work ethic?

Experience: For a person that has recently graduated, experience in the field is the single largest hindrance both when it comes to securing a position and to receiving a salary they are happy with. The best advice I can find for people in this position is to look to the open source community for help. There are many projects that are desperate for developers and it’s a great way to get familiar with working in a team, coordinating with people over a distributed area, and releasing code for public consumption. In lieu of paid work experience, open source is a great way to fill in a resume (and it can be quite profitable for some, if you play your cards right).

Salary: In some companies pay is a minor issue thanks to clearly structured systems such as that proposed by Joel Spolsky; for others is can be a source of pain, envy, and jealousy. This is a topic that I truly hate; it’s uncomfortable at best and quite painful at worst. While I can’t offer much advice, here are a few things to think about:

• Money is not an effective motivator. In an ideal environment it should just stay out-of-the-way and allow developers to live a comfortable life; in reality the role it plays is a bit different. More often than not, it’s a distraction that gets in the way and outweighs the factors that do motivate people.
• Companies follow a few different pay systems, and once set moving to different system is nearly impossible. Here are a few I’ve seen:
  • Clearly Structured: This system places developers on a scale, and developers at a given level receive the same salary (see Fog Creek).
  • Structured + Negotiated: This is the most common system I’ve seen; it mixes a structured level system with negotiated modifications that can apply a certain percentage increase from the normal base salary for that level or other benefits (extended vacation, etc).
  • Negotiated: Pay is based on negotiation skills and need; this can lead to odd situations such as where a junior developer can make more than a senior developer due to the need to fill a position quickly. This system requires strict secrecy when it comes to salary information to avoid nasty surprises, unlike the clearly structured system where salary information can be openly shared.
• Are large salary increases possible? Some companies have no issue with large increases in salary for a promotion (20%+) while in others exceeding 5% for any reason is a major challenge. If a developer is coming in on the low-end of the scale (i.e. due to lack of experience, such as a recent graduate), is there a real possibility of moving up? In my experience, people stay near the end they start at – those that start at the bottom will stay there until they move to a different company.

Interview Questions: If you are conducing an interview, make a list of questions and write them down. It’s quite embarrassing to suddenly realize that you are out of questions just a few minutes in (Need inspiration? Try this or this). Many people have said much about this, but the most important thing I can point out is just don’t wing it. Plan carefully, make sure you know what you’re going to do and when before the candidate shows up.

Interview Dress Code: I’ve been amazed at what I’ve seen people wear, everything from high-end suits to jeans. What’s appropriate? It really depends on the environment; a large corporation will expect an Armani suit where a startup is happier seeing jeans and an American Apparel t-shirt. When in doubt, I would go with a suit personally – but depending on the company that could cost you the job just as quickly as showing up in jeans.

Interviews Go Both Ways: An interview shouldn’t be a one-way affair; the candidate should be interviewing the company as much as you are interviewing them. They should be asking questions about the environment, expectations, tools and resources provided as much as you are asking them about prior experience and knowledge. If a candidate doesn’t seem to care about the company or what the working conditions are like – think carefully before hiring them.

Other Thoughts: I’ll not go into what I look for when it comes to personality or other personal traits as that would require far more than a blog post to cover. I’m also going to avoid things such as hobbies and the like; while they can tell you much about a person they can also lead to other complications. Any question in an interview can quickly lead to a land-mine and in the legal quagmire that is HR law and policies, trouble is easy to find. When in doubt, just don’t ask.

* This is based on my experience over the years; not necessarily the experiences in this round of hiring or the opinions or policies of my employer. In general, nothing in this refers to policies, preferences, or procedures of my employer. <Standard Disclaimer />

While performing some testing on a Windows 7 Professional workstation running a VL build from MSDN found that a feature I needed was missing – the new Multi-Monitor RDP support. After a little research I found that only the Ultimate and Enterprise editions support this feature; which thanks to Windows 7′s Anytime Upgrade feature I assumed this would be no issue.

But, it was an issue.

It turns out that the build of Windows 7 I was using was missing WindowsAnytimeUpgradeUI.exe and the other related files needed to make the Anytime Upgrade work – and copying the files from another box doesn’t work. It seems this build simply can’t be upgraded in this fashion. So I tried a few other tricks, hoping to find something that would work:

• Reactivate Windows with an Ultimate key; fails with an error indicating that a Professional key is required.
• Run Ultimate edition installer from Windows; fails with this error indicating that you can’t perform edition upgrades.

So being stubborn and determined not to re-install Windows to make this feature work, I started looking for other options. Thanks to a hack for upgrading the RC builds to Final, I found what I needed.

I edited the EditionID and ProductName to reflect Ultimate instead of Professional, rebooted, and then ran the Ultimate installer from within Windows. This time the installer ran without issue and after an hour and a couple reboots it was done. This in-place upgrade/repair procedure allows you to jump to a different edition with fairly little pain. A couple of Windows settings needed to be corrected (primarily display related) and Visual Studio 2010 had to be re-installed, though otherwise everything worked just as it did before.

This is the only method for upgrading these Windows 7 builds that I’ve found, the only other option is to re-install Windows from scratch.

Setting up the Android SDK on Windows 7 64bit, with a 64bit JDK / JRE is a bit less straightforward than one would expect, thankfully though the solution is quite simple. There are two settings that need to be adjusted to make this work – otherwise you’ll get an error indicating that Java can’t be found.

Step 1: Modify your PATH to include the bin folder of the JRE. Mine looks like this:

C:\Program Files\Java\jre6\bin

Step 2: Set the ANDROID_SWT variable (you’ll probably need to add it) to the \tools\lib\x86_64 folder of the Android SDK. Mine looks like this:

C:\Android\SDK\tools\lib\x86_64

With these two changes, everything seems to work as expected. Why this is required on 64bit but not 32bit I’m not sure, but this does seem to solve the problem.

Do you use MD5 or SHA1 to store passwords? Think they are secure? Think again.

While generic hashing algorithms are certainly better than storing passwords in plain text, it’s still not as secure as it should be. Users place great trust in us to ensure that their credentials will be secure and treated with the utmost respect; it’s our responsibility to live up to these expectations.

With the simplicity and speed of these general purpose algorithms, it’s possible to generate hashes looking for collisions (or even the original value) extremely quickly. It’s this speed that introduces the fatal flaw; with a database dump containing MD5 hashed passwords, with a fairly small investment most could be recovered within a very small amount of time (mere days for a large database).

Many people are moving to bcrypt as a solution. In Coda Hale’s “How To Safely Store A Password” he covers this topic in more detail, complete with useful stats and links to implementations in languages from C# to Ruby (even Erlang is represented).

If you are looking for ways to better protect your user’s data, take a closer look at your password storage.

When you move on to your next challenge how will those that inherit your code think of you? Noble or notorious, innovator or insane? This is a question that all developers should ask themselves frequently; though too few ever do. You should always write with the assumption that someday a new developer will take over your code, and they will question every decision and assumption you’ve made. When this happens, what will they think of you?

Perhaps I’m more aware of this because I maintain an internally developed shared library that my company uses in every application; but regardless of the scope of the project you should always assume that someday you will hand the project off. Many developers think little about what happens to their code after it passes on to another; what other developers will have to deal with, or how their efforts will be perceived.

When I’m training a new developer there are a few points I try to reinforce as much as possible:

1. Code is only good if other developers can work on it without extensive training. If it takes days or weeks of introduction to get a new developer up to speed, then you’ve done something wrong¹.
2. Clever solutions are no better than an ugly hack if it’s not clear what you are doing. If the code isn’t clear then it’s not maintainable, if it’s not maintainable then it’s junk.
3. Assume you’ll be hit by a bus. Always write code with the assumption that you won’t have the opportunity to cleanly pass the code off to a new maintainer. Never assume that you’ll have time to come back and clean things up later.
4. Always perform design reviews, no matter the size of the project². Once you have a design in mind, talk it through with a at least two other developers. Just because you think it’s clean and clear doesn’t mean that others will see it that way as well.
5. Be consistent, always. I’ve seen more projects ruined by people doing things “their way” than anything else. Match style and design when working on an existing project. Be careful when adding new techniques, technologies, or methodologies to an existing project; unless you are willing to update the entire code-base, you can easily create a minefield without realizing it.

If you want your work to be seen positively after you move on, start thinking about your heirs today. The opinion they have of you will be almost entirely based on what they see in your code – not the stories or memories left behind.

¹ – There are always exceptions; these are generalized guidelines, not hard and fast rules.
² – This includes “throw away” projects, many projects that are intended to have a short life end up living far longer than intended. This is the most likely place that your heirs will find code that makes them question the quality of your work.

I’ve been a fan of bbPress for quite some time; I’ve even contributed code to the project. For those that aren’t familiar with it, bbPress is an open-source forum system written in PHP. It’s fast, lightweight, easy to install and even easier to use. It also scales, quite well.

bbPress was originally written to power the support forums WordPress.org, which get quite a bit of traffic. Later, it was released as a separate project. While it doesn’t have nearly the feature set found in more popular systems such as vBulletin or phpBB; it makes up for it in simplicity. It’s designed to be conversation-centered, where the clear focus is on what people are saying, not the bells and whistles provided by the software.

I’ve used it for a couple sites and couldn’t be more pleased; though now I fear the end may be near.

Automattic, the company behind WordPress.com (and ListPress.com) has committed to supporting the project; though primarily in context to its role in the WordPress world. bbPress as a separate product has so much potential, though it seems Automattic has little interest in this; instead the interest seems to be in making bbPress just another add-on for WordPress.

At one point there was a lot of excitement and interest surrounding bbPress, though for a project like this to succeed you need input from the community, you need an open and fast paced development process. Unfortunately for bbPress, it had no such process. There were people who had the skill, time, and interest to lead the project and make it a success; but they were pushed away and the project was allowed to stagnate.

Today, there is some activity going on, and I’m glad to see that it won’t fade away completely; though I see little chance that it will live up to what it could have been. I have a lot of respect for Matt and Automattic; they’re very successful and build great products; but they could have done so much more.

bbPress will go on I’m sure; though I believe only as a shadow of what it could have been. Though maybe Matt will prove me wrong, I certainly hope so.