feedburner
Enter your email address:

Delivered by FeedBurner

0. Always remember the source of the rule.

Labels:

All through my life, especially my career, I have run into rules that make no sense.

Once I was given a 'beat down' by the IT department of a former employer for not following a specific rule. When I asked how I was to have known about the rule, they said it wasn't documented or published. I then asked if there is a list of other undocumented/secret rules I should know about. They didn't laugh.

Too many times a rule or guideline is drawn up and rolled out to the masses. Then time goes on, and if things are going well, the business changes. [Side note: If your company doesn't change, then get a new job, because that company won't be around for long.] After the change, the rule is still blindly followed, doesn't make any sense, and people are still following it.

Also, after this business change, the rule might need to be updated or removed entirely. If you don't remember the reason for the rule, then you won't know when it needs to be updated.

This following joke explains this better than I can. I have seen this come around about every two years, and it is always a good read.

The Origin Of Company Policy
Start with a cage containing five monkeys. Inside the cage, hang a banana on a string and place a set of stairs under it. Before long, a monkey will go to the stairs and start to climb towards the banana. As soon as he touches the stairs, spray all of the other monkeys with cold water. After a while, another monkey makes an attempt with the same result -- all the other monkeys are sprayed with cold water.

Pretty soon, when another monkey tries to climb the stairs, the other monkeys
will try to prevent it. Now, put away the cold water. Remove one monkey from the cage and
replace it with a new one. The new monkey sees the banana and wants to climb the stairs. To his surprise and horror, all of the other monkeys
attack him. After another attempt and attack, he knows that if he tries to climb the stairs, he will be assaulted.


Next, remove another of the original five monkeys and replace it with a new one. The newcomer goes to the stairs and is attacked. The previous
newcomer takes part in the punishment with enthusiasm! Likewise, replace a third original monkey with a new one, then a fourth, then the fifth.


Every time the newest monkey takes to the stairs, he is attacked. Most of the monkeys that are beating him have no idea why they were not
permitted to climb the stairs or why they are participating in the beating of the newest monkey.
After replacing all the original monkeys, none of the remaining monkeys have ever been sprayed with cold water. Nevertheless, no monkey ever again approaches the stairs to try for the banana. Why not? Because as far as they know that's the way it's always been done around here.


And that, my friends, is how company policy begins!

Rule 0: If you are going to make a rule, document the reason behind it, so that people will understand the rule, and know when it should be refactored or garbage collected.

Rules of Thumb for Consultants

Labels:

I love being a consultant. I love managing a consulting team. I can't think of something more fun to do. Over the years, I have learned a lot! I try to codify these lessons, so that our team can move farther and faster from all of our experiences.

I will start posting some of my 'rules of thumb' here. These are not scientific. NONE of them are 100% strict or prefect, which is why they aren't just called 'Rules'. There is always a lot of gray area in consulting, and communication and truth will guide you in the gray areas. But until you get the experience, and comfort with clients, these should help you through some situations.

Truth be told, most of these have come from me, or people I know, putting my foot in my mouth.

I am sure these have all been covered on other web sites and blogs. But, since blogs are about conversion, I thought I would put some down here, and see what people have to say.

What is a consultant? Well, that is a very ambiguous term, as much as the title architect is. There are two ways of looking at it.

There is the paperwork way, and the philosophical way. The legal way lays out like this:

0. You work for the same people that pay you. They tell you what do to on a daily/tactical basis. You do it. This makes you a 'native'.

1. You work for different people that pay you. But the people that you work for still tell you what to do on a tactical level each day. This makes you a contractor/staffer.

2. You work for different people that pay you. They give you strategic direction, and let you figure out the best way to do it, based on your training, processes, experience, and luck. This makes you a consultant. You don't necessarily work on site or off site. Your professional relationship with the client is much like a lawyer.

I am sure there are better definition out there, but I guess that is the basic.

The philosophical view grays this a little. You can be a native employee, yet still think and act like a consultant. I think this is key. No matter who you are working for, and how they are paying you, you should always think and act like a professional consultant. You will end up bringing a lot more to the table for your employer. Think of your internal customer as a client, and truly treating them like that can be a very powerful thing. It will lead to more success, and to more value and growth for your company. That's a good thing.

The worst is when a consultant ends up thinking and acting like an internal/native. This leads to stagnation, and negative value for the client. They could have gotten the same grunt work for a lot less money from a real native. And all you did was ruin your own reputation, as well as your company's.

I think 'how' you think, approach problems, and how you provide value is more important in the "Am I a consultant?" equation that merely how you are paid and who you work for.

CodeMash Registration

Labels:

The past 48 hours has seen a huge spike in registrations!

The Early Bird discount of $50 (from $149 to $99) just expired about half an hour ago. I guess there are a lot of procrastinators out there.

We have received word that the hotel still has some rooms left at the $88/night rate. So while the CodeMash registration fee is now $149, the hotel room is still a great value. We can't guarantee this hotel rate for long, because when they run out of rooms in our block, then you will have to get a normal room at the normal rate of around $150 or so (I don't know the real rate off the top of my head, but it is up there!).

 

So, act now!

http://www.codemash.org/

Qualities of a good dev team member

Labels: ,

Part of my job is to build an awesome application development team. A team involves a lot of different skill sets of course. This includes the developer, but also the architect, PM, BA, QA, DBA, etc.

There are certain qualities that we look for when we are trying to find a new person to add to the team. These qualities are in addition to the certain skills and attitudes a specific position might require. I think all of these are things that you learn as you are young, and may be complimented by a certain amount of inborn talent.

The following three qualities are the baseline to get started. These are qualities that can be hard to see in a person in interviews. We usually go through 3-5 rounds of interviews, which culminate in an 'audition' in front of the team. More on this later.

So, what are these wonderful, Zen like qualities?

0. Learn Quickly, and Unlearn Quicker

I used to say 'Everything you know today will be worthless in two years.' I was corrected by a team member recently who pointed out that isn't really true. Problem solving skills, learning skills, etc. may improve, but they don't go out of use. I agree. So, technical knowledge you have today, will be worthless in two years. But how you get that technical knowledge will last a lifetime.

As time marches on, it is important to know when to move on from something that you do "KNOW", and move on to the next thing. For example, it used to be that Client/Server was the end all be all. The last architecture you will ever need. Then came n-tier. Then came SOA. So, don't just learn the next platform, but be ready to leave behind outdated concepts and ideas.

How do we figure this out in an interview? Ask them about some of the latest and greatest. See what they think of Atlas, or WCF, or anything. Have they played with it, learned it? What was the last thing they learned? How do they like to learn? What was the last book you read? Our interviews tend to be conversations, not SAT style interrogations. It is about the discussion, and about your gut feeling as an interviewer. [OK, there is ONE interview that is a quiz, and that is the technical interview. We want to know what your chops are. Where do you lie on a range of skill levels, and across several parameters. People have cried. It's a long story.]

1. Problem Solving

Our jobs are about problem solving. We solve problems. Our clients have problems, and we provide solutions; solutions that solve those problems. Usually within a bizarre set of technical, business, and financial constraints.

Problem solving goes directly to how to solve that business problem, the best business process, how to get that code to work, why is the trigger not firing, how do I map that XML document?

Problem solving skills are some of the hardest skills to learn.

How do we find this in a person? Ask them about difficult problems they have faced, and how did they solve them, or try to solve them? Get them to talk about their problems, and solutions. What process did they use? Did they work with the team? Did they do their own research first? If they talk about how they haven't had problems to solve, then show them the door. Don't waste your time.

2. Passion, preferably for what you do

Passionate people are infectious. They put more effort into what they are doing, they build team energy, and they become a force multiplier on their team.

We look for people who show passion for technology. There are plenty of good candidates that are good developers, but will never be on the team, because they aren't passionate. It is fine to be a nine-to-fiver. Those are fine people. Really, they are. I just choose to work with people that stand up and applaud when the BizTalk team annouces you can now zoom in the orchestration designer, or people who take a long van trip to the VS2005 launch, or people who take time outside of work to learn about things you don't have to learn for your job.

The best way to find this is to be part of the community. If I can get to know you at user groups, then it is a lot easier to get through the interview process. If I see you at code camps, CodeMash, conferences, Usenet, etc., then I know you are engaged in what you do. Perhaps you blog. Perhaps you just voraciously read blogs. I want to see engagement. HINT: I Google you before I ever call you for an interview.

 

These aren't the only things we look for, but I feel they are the most important three.

Auditions? Yes, auditions, but you don't have to sing. We generally go through several interviews before the audition.

0. Recruiter screen - Are you an axe murderer? Do you have the required skill sets and attitudes? Team culture match?

1. Technical screen - You say you have nine years of .NET experience. Sure. Prove it. You don't have to score a 95%. We try to see where you are from one to ten across several aspects of your role.

2. Personal Interview- The candidate will meet with me, or someone on my leadership team. We spend a lot of time listening to the candidate, trying to figure out the above three aspects, as well as their general attitude, and direction. What are their career goals?

I heartily believe that a person has a career vector, and a company has a vector. The vector represents where they are going, how they are getting there, and what their other goals are. If these two vectors aren't close, or don't converge, then neither the employee nor the company will be happy. It's ok. They are not a bad person, they just have to know it might not be a great match. We also spend a lot of time talking and showing how our business and team works. We want you to feel like you KNOW what you are getting into. That there is a strong ownership culture. That you WANT what we have. That you know what your day is going to be like. What your role will entail. We aren't talking about a ridiculously vague position description (which all end with 'and other duties as assigned'). We are talking about what life in a day of a team member is like. I don't want the candidate to feel like what they thought they were getting, and what the job really is are two different things.

3. Then the audition. A time is set. The candidate picks a topic of their choosing. Must be technology related. Doesn't have to be related to the project, or even their role or primary skill set. Preferable something they have learned recently, and something we don't know inside and out already.

The audition serves several purposes. You can ask people about the pillars of OOP all day long, and what generics are, but until you see them flying around visual studio, you really won't know if they know what they are doing.

Also, you get some free training/exposure for your team on something new. You get a sense for how that person can communicate in a group, and transfer their ideas and complex technical concepts.

At the beginning of the audition, I will introduce the candidate, and hand out their resume. I then leave the room and get a water. I let the team interact without my presence being an influence. There is 30 minutes of slides/code (we're agile, so we prefer code), and 30 minutes of Q&A on any topic. The Q&A is in both directions, so I expect a good candidate to come prepared with questions they want to ask the team.

Vista has stolen my 'free time'

Labels:

There was a time when I had a lot more free time. I had time to go check the mail. The real mail I mean. To go get a drink. Perhaps to quickly read a blog post or two. Skim a tv show. Hug the kids. Lots of small activities I could fit into my day.

Vista has ruined that.

Damn you Microsoft!

Now, the laptop boots quicker, hibernates/sleeps quicker (with one button or icon Mr. too many icons guy), runs quicker, loads quicker, searches quicker. I even upgraded my display driver from a standard Vista one to an ATI driver (I have a long hatred for ATI drivers, they always seemed to have problems, not like the nVidia drivers) without rebooting. What happened?

It used to be :

1. download new driver

2. uninstall old diver.

3. reboot.

4. install new driver.

5. reboot.

6. waste 20 minutes reconfiguring the new driver to the settings I like.

New Way:

1. Click 'update'. It was an optional update for the new ATI driver.

2. Wait a few minutes while it is download, and checkpoint created and installed.

3. Screen flickered a bit.

4. Done. Same resolution, same settings. no reboots.

I didn't have any time to go do anything else. I will never get that time back.

Granted, once I have to start using the Dell drivers, instead of the ATI manufacturer drivers, I am sure it won't be as smooth. Dell seems to have a need to require me to use the Dell version of the drivers, instead of the ATI version. I don't know if there is a technical reason, but the ATI ones seem to work fine. The reason I don't like having to use the Dell drivers is because they update them. Ever.

Another interesting thing is that an entry for a software install (a driver is software after all) into the performance and reliability monitor. This tool tracks app crashes, installs, etc and creates a time graph to show you your 'health' rating over time. Cool tool. I am surprised to not see the driver update listed there.

Information Architecture in Vista

Labels: ,

I have been running Vista for a while now. Not once have I had a real crash. A few applications have crashed here and there, and that is going to happen on any OS/platform. Applications have problems at times. It's no big deal.

Each release of Vista during the RC/beta process was better and better. It was faster, and more cohesive. I really love the search in the control panel. Ever since Windows 3.1, I could never find the right icon for what I needed to do. The control panel was always the worst designed aspect of the system. Just a giant switchboard interface, with no real guidance, or rhyme or reason. It lacked any sense of Information Architecture. It was a firehose of options.

Windows XP tried to fix that, with the groupings, and what not, but I always clicked it back to 'classic view' when I setup my profile because I had become comfortable with the dysfunctional menu, and didn't like the menu aimed for 'everyday' people.

Vista has even more items in the control panel. They improved the 'everyday' person (joe lunchpail) interface by improving the groupings, so that isn't too bad. They helped the experience, but not expert user, by promoting common used features to the grouping level. But the best thing is the search bar on the control panel window. I just type in what I am looking for, and it comes up.

This is a perfect example of a tiered information architecture. Architects think too much about the backed, and they leave users out. Thats fine, it will get better, as architects start to focus on the whole application, and not just the gears behind the curtain. Those architects that do pay attention to UX and IA will produce better applications, which will help their users kick ass, which is what architecture and development is all about.

So what is this tiered IA?

Tiered IA means that 70% of the screen/window is for novice/new users, 20% is dedicated to experienced/return users, and 10% to 'expert' users. In this case, a novice can plumb through the well labeled categories to find what they want. To protect against going down blind alleys, or ambiguous groupings, an item may be found in several areas.

For regular or return users, the common functions have been promoted to the category list.

For those experts that know what they are looking for (and expert here means someone who is very familiar with a system, not someone with a MCSD.) they can just go directly to that.

A side effect in this case is that the expert search bar is very useful to the other categories of users as well.

This tiered approach is used on a lot of B2C web sites that really need to cater to a wide audience. The bulk of the main landing page is about what the site does (perhaps explains what eBay does, or who the bank is). Then a portion is for regular users; they can get some information (most active auctions, today's rates, etc.). That last group is served usually by very dense and abbreviated information. A small login cluster is the most common example of this.

I don't plan on turning on classic mode in my Control Panel. I plan on searching every time.

Win a Zune!

Labels:

So, want to win a Zune?

Register for CodeMash here : www.codemash.org

Put the blog badge on your blog, and blog about CodeMash. Then send an email with your blog link to contest@codemash.org.

Don't have a blog? Just start one. There are plenty of places to start one.

What? You're still reading? Go do it. Now, while you are thinking of it.