Somebody Has to Say It

This is #10 on Chris Brogan’s list of 100 Blog Topics I Hope YOU Write.

It’s quite astounding how many people fail to think before they speak. I’m not referring to the occasional social slip up, but to people who can be relied on to say the wrong thing. Examples of this include handing out unsolicited advice and criticism to strangers. Or stating the obvious when everyone else in the conversation was deliberately trying not to (this is usually done by the last person to catch on to what the conversation is really about).

A piece of advice: before you say anything, pause for just a second, and think about whether you should be saying something, and whether what you’re about to say is appropriate!

Work Published At Last

I’ve been working pretty hard for the last few days to complete another revision of a program I built, and finally released it to the client last night. I first wrote the program using Java, until I encountered too many obstacles to allow me to complete it in time for a self-imposed deadline. I then rewrote the application from scratch using C#. Surprisingly, the 15K line program in Java was rewritten in C# in only 2K lines, and it took about a week.

The resulting code was not pretty, or efficient, but it worked. Since then (from the start of 2009) the client has been using it, and filing bug reports and change requests, which I have been chipping away at as quickly as I can.

Two weeks ago, with the number of bugs falling, I decided to clean up the program. Data access was spread all over the place, and needed to be consolidated, and field validation was minimal or non-existent. Mappings from the database to the screens was almost impossible to follow, as I used arrays and lists of values, and you had to follow the queries to figure out which array index corresponded to which field on the screen.

Once I started, I was committed to getting certain segments of the program cleaned up before I could publish the application again. Of course, that’s when another change request and bug came in, both relatively high priority. On the plus side, the bug was something that would be fixed during the clean-up process anyhow (an issue with saving certain characters, which would disappear once I rebuilt the data tier of the program). The change request, too, was a relatively simple change. The problem, however, is that the current state of the program was slightly unstable.

I have not yet heard back from the client as to whether they have noticed any differences in the application, and whether any new issues have cropped up. What I haven’t told them is that while I was refactoring the program, I located 4 bugs that they had not found, with certain fields from the database being mapped incorrectly to the screen, and that these issues were quickly fixed. Considering they’ve been using this program for over 2 months and haven’t noticed makes me wonder if they’ve even looked at that section of the program yet.

Subcontracting: A Middleman's Perspective

As a technical consultant, I have worked with several contracts over the course of a few years. In all these cases, I was working directly for the client. However, during a discussion with one of my networking groups last night, we talked about the issues of subcontracting, and the problems they solve and create.

A client, who I’ll call Small Business, needs a custom inventory management system, which links to their website for processing orders. Not being technical, he hires a Consultant who is an expert in inventory management systems, but has no experience with building websites. The Consultant takes the entire job, requiring him to provide both the software and the website. The Consultant puts out an ad and recruits E-Commerce Developer to build the site.

From the perspective of Small Business, he has managed to contain all his technical needs within a single contract, and can keep his maintenance costs down by retaining a single contract instead of two. From the Consultant’s perspective, he has landed a large contract of which he is only doing a portion of the work, and retaining a finder’s fee for the remainder, plus a maintenance contract. The E-Commerce Developer was unable to get the contract on his own, and so is happy for the work, and does not need to deal with the client for payment.

It looks like everyone wins.

However, there are problems with this model. The Consultant, not being a web developer, cannot provide accurate estimates of the costs of that component, leading to possible cost overruns. As well, by acting as a middleman for the Small Business and E-Commerce Developer, the chance of miscommunication has been increased. This is compounded by the fact that any communication between E-Commerce Developer and Small Business must go through Consultant, which means it is slow and inefficient.

The model that we came up with during last night’s meeting aimed to remove these obstacles.

A small group of individual contractors would band together and move into a small office. Each person would have their own office, with some shared resources (meeting rooms, kitchen). The office would share phone lines with an internal automated switchboard and internet access. As well, technical resources would be shared within the group, including access to legal documents, tax advice, graphic design, and a developer pool. Each partner would contribute a fixed sum per month for the upkeep of the office, plus some extra for renovations and unexpected expenses. (An office can be rented for less than $4000 per month including utilities, which, in a group of 10 partners, is only $400 per month for an office with meeting rooms and shared resources.)

The developer pool is what would make this system work. Partners in the group are people who are looking to establish clients and to bid on projects. Each is technically proficient, but they bid against one another for projects, or join together to bid for projects. When a project is deemed too large for an individual, they turn to the developer pool to get the work done. The developer is brought in on the project, and communicates directly with the client for requirements and specifications.

Developers in the pool are people who are looking for occassional work, but do not desire the overhead of dealing with clients and searching for projects. By being in the pool, they can see which projects are available for work (indicating that one of the partners has won a contract and requires particular skills) and which they would like to work on. They will then be able to deal directly with the client once approved by the partner, using standard rates from within the group and paid by the partner (not the client).

We are still in the planning stages, and nothing has been cast in stone yet. But the model is in place, and we are looking to tweak it over the next few months. If you have any ideas or suggestions, please let me know. I’d love to hear from you.

Working From Home… Again

If you hold a full-time job during the day, and moonlight with small projects, then you will likely be familiar with this scenario. Your day job is a source of steady income, and the side projects give you something extra, but are not reliable. When you have a project, you try to complete it as quickly and efficiently as possible, since it occupies your spare time (of which you don’t have much to spare).

For the sake of this article, assume that a normal working day is 9 to 5, and it will take you an hour and a half to get home and each dinner, which puts you to 6:30. Now you need to spend some time with your family and relax a little (try going without this for more than a couple of days and you will see why this is needed), perhaps an hour, to 7:30. Now you might be able to start working, at the earliest.

In order to work efficiently, you need blocks of time in which to work. This block must be large enough that you can spend some time “getting into the zone”, work for a while, and then spend some time closing up your work. For me, when programming, this tends to be about a 2 hour block. Longer than this and I start getting distracted when I should be in the zone, so a break is needed every 2 hours.

When planning work, you need to consider this. The size of your block, which depends on how long you can stay focused, will vary, but it can be figured out (just clock yourself a few times). If a project is estimated for 5 hours, that means 3 two-hour work sessions. The next question is how many work sessions can you do.

Considering that you are likely tired from being at work all day, it’s probably not a good idea to schedule more than 2 work sessions per evening, and that should be the exception. Using the numbers I showed above, that would translate to finishing work at 11:30, plus the time spent during the break, which should be at least 30 minutes, which brings us to 12:00. A third work session would bring us to 2:30. Then 5:00. You then grab a couple of hours of sleep, drink huge amounts of coffee and head to your day job, and the cycle repeats.

Instead, try the following. There are 5 workdays per week, so pick 2 as being nights off. Of your 2 weekend days, pick one as a day off. This helps you ensure that you relax properly at least once a week, and get a proper amount of sleep at least 2 worknights.

On the 3 worknights that you plan on working, plan for 1 working session for 1 evening, 2 working sessions for the second evening, and, if the project needs it, 3 working sessions for the third evening. On the weekend, work out how many hours you have available, and fill them. By doing this, you help ensure that you can plan for projects (that is, you know in advance how much time you have available to work) and can keep time open so that you don’t burn out too quickly.

One of the other things you may want to consider for the weekend is your client meetings (if you can). Count a meeting as a working session when planning your time. A weekend day may look like (4 working at home sessions and 1 client meeting):

  • 10:00 – 12:00 working at home
  • 12:00 – 12:30 lunch
  • 12:30 – 2:00 meet with client A
  • 2:30 – 4:30 working at home
  • 5:00 – 6:30 relax and dinner
  • 6:30 – 8:30 working at home
  • 9:00 – 11:00 working at home

What kind of schedule do you use? How do you keep yourself from buring out? Let me know, I’m always interested in hearing how other people balance their Work-Work-Life schedules.

Cover Letters

As per a comment on an ealier post, I missed one section of the application process – your cover letter. This is perhaps the most significant part of your application, and yet, it often recieves the least attention. A well-written cover letter can make the difference between getting a job and not even reaching the interview room. I will attempt to answer here the question: what makes one cover letter better than the next?

Most applications consist of two parts: a resume or CV which outlines your professional experience, and a cover letter, which outlines you, as related to the position in question. For the resume, there are standard components: work experience, education, certifications, and so on. For the cover letter, the guidelines are less clear. Beyond the formatting, which, of course, should be in the same style as your resume, and the spelling and grammer, which should be correct, there are few rules about what goes into a cover letter.

  1. Customize: A cover letter should be drafted for each and every application you make. Even if the titles of the position are the same, or you are applying for two different positions at the same company, the cover letter for each application should be unique. Of course, some of the content will overlap, but each should be written on its own.
  2. Concise: A cover letter does not have to be a long treatise on your life story, and in fact, should not exceed a single page. Recruiters don’t want to sift through huge amounts of data to get at the real information, and they don’t have time to read through every essay that crosses their path. If your letter is relatively brief, it has a higher chance of being read to completion.
  3. Informative: Use the cover letter as a way to show that you have researched the position you are applying for. Talk about some of your skills that would make you an ideal candidate. Highlight relevant experience you have that would be of benefit to the position.
  4. Make a Sale: Talk about how the company would benefit by hiring you, not about how you will benefit from being hired. Convince them that they have a need for you, not the other way around.
  5. Interest: What gave you the incentive to apply for the position? Did you come across a posting on a job board? Did a friend recommend the company? Did you read about them in the paper?

Pros and Process – A Delicate Balance

I was reading a question on a forum the other day about the benefits of having highly skilled people work for you relative to having a clear and detailed process for how work is done. The answer, of course, is that neither will work without the other, and the challenge is to find the right balance between the two.

At my office, process is part of the daily grind. I have been working there for over 2 years, and I have come across scenarios where process was more important than expertise. (Note that I do not discuss the alternative, since it is easy to understand why having quality people is important, and for more information on that topic, read my post Saving Money on an IT Solution.)

We have an on-call procedure for supporting applications even when no one is in the office. On occassion, a system will fail, causing the person who is on call to be notified. We have a clear process for what to do in the event of such a notification, which is detailed to the level of what to do for each and every system that we support. The reason for this is simple. Calls can come in the middle of the night, while the support person is sleeping. Rather than have them try to make decisions while they are half asleep, we detail the process, the choices that need to be made, and the information needed to make those decisions. Following this process has helped reduce the severity of the failures to minor bumps without impacting our customers as a result.

However, process can, and often does, go to the other extreme. A reader of the Daily Worse Than Failure will be able to think of several examples. In this situation, the issues behind the process can often be attributed to having non-technical people write the process. A lack of understanding of how a technology works (and more specifically, the technology requiring the process) often results in compensating for the lack by insisting on more documentation, more signatures, more approvals.

A good process is written by the people who will ultimately be following it. It needs acceptance from its users based on understanding of why the process is there. When the process is put into place, and management says “Follow the process” but there was no input from those who are meant to be using the process, resentment about the process, and often a flat refusal to use it will often ensue.

Basic Interview Skills

This article, like my previous one on the topic of resumes, is not meant to target any particular group. It is intended to be relevant to people across the board, whether applying for school, a job, a volunteer position, or any other situation in which an interview is being conducted. These are not rules, they are guidelines, but read the explanation for each before you decide whether it applies to your situation.

First, before the interview, make sure you are prepared for the following:

  1. Dress Appropriately: The type of interview and the level of the position will dictate what this is. Generally, it is considered appropriate to dress a step above what an employee at the same position would wear. In all cases, make sure the clothes are clean, and are not overly flamboyant. Unless you are applying for a fashion position, the clothes should complement you, not vice versa.
  2. Prepare Questions: Most interviews will give you the opportunity to ask questions of the interviewer. Don’t try to ask one off-the-cuff, unless it is to follow up on something said earlier in the interview. Instead, use the question to show you’ve done some research into the position you are applying for.
  3. Study: Yes, the interview is like an exam of your life. For some positions, you may be able to find out the kinds of questions asked. For others, look up standard interview questions (a quick Google search will turn up thousands of results). Think about the answers you want to give. Say them out loud in front of a mirror or a friend so that you won’t hesitate in the interview.

During the interview, keep the following facts in mind:

  1. You are one applicant (of many): You are trying to set yourself above the other applicants, but do it on your own merit, not on the fact that everyone else is bad.
  2. Don’t burn bridges: Be careful when talking about people and jobs from your past. Focus on the positive, and try to avoid negative statements. For example, when asked why you want to leave your current position, don’t say that you hate your current boss. Instead, say something like “I’m looking for a position where I am encouraged to explore new fields, and where management actively supports professional development.”
  3. You are not a peer (yet): You are applying for a position, and the interviewer does have the upper hand. No matter how casual the interview may seem, keep in mind that the initial decision as to whether you work there is up to the interviewer. Even if the interviewer is a friend or past associate, keep it professional at all times.
  4. You don’t have the offer yet: This is not the time to start negotiating. Wait until you have the offer before you make requests. Never make a demand, as it reflects poorly on you.
  5. Keep on topic: A question may have resulted in an answer that included your pet, but return to the topic of the interview, not your pet.
  6. Be courteous: No matter how well or badly you think the interview went, thank the interviewer for his or her time. Always be polite, even if he or she is rude, or if you know that you won’t take the offer. It will make you look better, and they may refer you to someone else who will have a better offer for you.
  7. Follow up: If there is the slightest chance that you would want the offer, follow up within a few days thanking the interviewer for their time (yes, a second time). You can include a question with your follow up, or an offer to provide additional information if needed. You can use this note to include your references if you have not already provided them.

Get Your Resume Read

I have been reviewing resumes for various people, under various guises (for friends and siblings, or at work looking at applicants). Not to mention my own resume, which I keep up to date on a regular basis. I have been struck by cerain similarities in all the resumes I have looked at.

  1. Spelling and grammar: With the availability of spell-check and grammar check, there is no excuse for either of these types of errors. You don’t need an English major to fix a spelling mistake, as your word processor will do it for you.
  2. Style and formatting: There are hundreds of templates available for building resumes. Find one that you like, and use it. When you try to build your own, chances are, the formatting won’t display correctly for everyone, and will make it hard to read.
  3. Opening statement: The first section of your resume should be a one paragraph statement that highlights who you are. This is not a cover letter, and you don’t need to tailor this paragraph for each application you make. It gives the person reading your resume a quick way to see what you think of yourself, which parts of the resume you are most proud of. You can include references to specific pieces or types of work you have done and liked. You can include what makes you different than the next applicant with an identical background. Make use of this section.
  4. Cover letters: This part of your application should be tailored for each position you apply for. Keep it relatively short, no more than a page. Talk a little bit about yourself, talk about the company (you did do some research and know what they do, right?), and how you can help them. Use this letter to convince the reader that you can help them solve a problem they may not have known they had. As well, include a little bit about your goals here, so that the reader knows what career aspirations you have.

Your resume should be designed to get you an interview, no more, no less. It does not get you a job, but without a good resume, you won’t get the interview either. The interview you can worry about later (and I will write about that in a little while). Use your resume to get you into the room with the prospective employer.