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 />

• Microsoft Expression Blend 3 + SketchFlow RC
• Microsoft® Silverlight™ 3 SDK
• Microsoft® Silverlight™ 3 Tools for Visual Studio 2008 SP1
• Deep Zoom Composer

Though the tools needed for development seem to be public, I’ve yet to see the end-user run-time; though I imagine we’ll see that in the release anticipated for tomorrow.

Time to have some fun.

Update: Client run-time is now available.

While building something as simple as avatar support takes a relatively small amount of time, when working against a tight deadline or a tight budget every minute counts. In the world of an ISV (especially a young one) the balance of user satisfaction and development time is critical. Using a service such as Gravatar is a great way to give the users what they want with minimal impact to the timeline.

With a super-simple implementation we were able to get it running within a few minutes – compare that to at least a few hours to build a custom system. Plus, reduced server load as we aren’t hosting the images and a cleaner, simpler interface as it’s one less option the user has to look through.

Hardware is Cheap, Programmers are Expensive

I point this out because this is something I’ve been fighting recently. It’s easier for management to tell the development team to fix a performance issue than to request money for the new hardware that’s needed.

In the long run it would be much cheaper to just throw more hardware at it – though that requires higher level approval. Whereas assigning a couple developers doesn’t require going nearly as high.

For the third week in a row I find myself at work at the wee hours of the morning preparing for a project launch. Though today more than ever I find myself asking questions; what takes priority, the needs of a company, or the needs of a relationship? What’s more important, the health of a project, or my own health? Should I be working to make this project a success, or sleeping to stay healthy?

Normally these questions are simple and obvious – yet so often we choose our projects over ourselves, our companies over our loved ones. Why? Is it the drive for success, the challenge of doing the impossible? Maybe it’s the money? Why do developers so often sacrifice so much?

This isn’t a guide to better managing time, or a treatise on setting priorities; no, it’s a developer’s lament. So much is given for a company that does little but ask for more; yet more we always give. We know there are things far more important, but yet so much rides on our efforts, so many people counting on us; how could we dare let them down? Though I appreciate my paycheck, it doesn’t drive me to do more – it’s the people, the challenge, the fact only I can make this happen.

Sometimes though, I wish I could bring myself to accept failure; maybe then the pressure wouldn’t be so great. Maybe then, I could sleep at night.

But this is what we do, we make the miracles; we do the impossible. Every day we face another challenge, every day we find another solution. Now if we could just find a solution for all this time lost from what matters most.

• Software Branding
• Confirmations
• Warnings
• Toolbars
• Sound
• Icons

These guidelines are crucial to ensure the most consistent user experience possible. Though many don’t, this is a document that all developers should read. I firmly believe that consistency is the most important single factor in design, and following an established style such as this is a great way to ensure that a UI is as consistent as possible.

If you’d like some background reading, the XP version is still available.

Scott Hanselman provides a great review; check it out for the details on what’s new.

Unreasonable clients, managers that just don’t understand; there are so many reasons, so many triggers. While reciting this mantra often invokes laughter from those nearby, some thought should be given anytime it’s used. More often than not, used as a joke, but a joke masking true problems.

Some issues are unavoidable, some no amount a planning or preparation will help with; for those I can offer no advice. For those, even a perfect environment won’t help. It’s the others I care about, those issues that shouldn’t be, the deadlines that should never have been set, and those whose sole cause is lack of planning or forethought. Those are the ones that tire me; those are the ones I hate.

When I run into one of these situations, it makes me wish this was closer to reality than a dream of how we want things to be. However, why shouldn’t it be reality? Why do we allow this to happen time and time again?

Wait, read that last sentence again. Why do we allow, why do we allow? Yes, as developers we allow this to happen, and often encourage it. Late nights, working weekends, 90-hour weeks. Those could all be prevented, and could be reduced significantly should we stand up. If we do not take a stand, we encourage those that push us too far by doing just what they ask. Why should they stop if they can get a single developer to do the work of two?

A Solution?

So, what are we to do? Taking a page from Rob, here is my modest proposal. A few simple rules for both developers and managers to keep in mind. While rules such as these can never be enforced, keeping these things in mind could make life more pleasant for everybody.

Managers…

• shall keep requests for after hours work to a minimum. While there are “crunch times” on occasion, these should be minimal.
• shall seek input from at least one developer before estimating a project. An estimate should not be created without consulting those that will be working on it, as they should have the most realistic idea of how long it will take to implement.
• shall not ask developers to implement a hack or kludgey solution to meet an unreasonable deadline or request; especially if it will compromise stability or maintainability.
• shall understand that developers are often passionate about their work, and the quality of the software they produce. Asking a professional to implement a solution based on a bad design, or inferior technologies will often be viewed as an insult, especially when this is done to meet an unreasonable goal.
• shall shield developers from unnecessary distractions and meetings. Distractions can destroy productivity.
• shall not ask developers to do the job of a Support technician. Tasks such as installing or configuring third-party software should not be given to a developer.
• shall filter all requests and put policies in place to ensure that requests do not go directly to a developer.
• shall give developers the freedom and opportunity to test different development methodologies when the schedule allows.

Developers…

• shall make every reasonable effort to complete a task, including working long hours (so long as the hours and frequency are reasonable).
• shall not complain about boring or undesirable tasks.
• shall alert management when an issue arises that may impact a deadline, as soon as possible.
• shall build the best software they are able to.
• shall provide accurate estimates when asked.
• shall be available as much as possible should an emergency arise.
• shall not over-build, or over architect just for the sake of doing so.
• shall try to understand the pressures and forces at play when communicating with management.
• shall make an effort to improve development methods and processes.

If you agree with this last, take it to your manager and talk about it; if not, build your own and talk about it. Either way, the idea is to talk about the issues and try to find ways to get everybody on the same page. If we make no effort to improve things, then we are just as much a part of the problem as anyone else.

If you don’t like things, complain; but complaining to a friend or co-worker won’t help, you need to let management know that there are problems and that you have some ideas to fix them.

I’ve not had time to test this yet, but it sure looks like it has promise. I’ll be playing with this one soon, I’ve got a couple new projects this might be perfect for.