Dot Net Thoughts

November 18, 2007

An Interview Question (and a Thanksgiving note)

Filed under: Management — dotnetthoughts @ 7:21 pm
Tags: , ,

Interviewing potential hires is always tough. Determining whether or not somebody is good for your team from a technical and personality standpoint based on a two page resume and an hour interview is a nearly impossible job. I’ve made a number of hiring decisions over the years. Some of them worked out quite well; others, not so much.

I used to have a stack of “tricky” interview questions that I used to ask. In my VB6 days, I would ask applicants to explain binary compatibility to me. I was amazed by the number individuals who didn’t have any idea about such a fundamental concept in COM development. (In the interest of full disclosure, I would only give myself partial marks the first time somebody asked me that question. I told the interviewer that you could add a method to a COM contract. VB6 allowed you to get away with this through a horrible concept called interface forwarding, but it violates just about every COM rule known to man.)

Over the years, though, I’ve come to realize that tricky questions don’t mean anything. The percentage of the .Net Framework that the average developer will use in a typical day is tiny. If a competent developer doesn’t know exactly how to do something, there are plenty of resources on the web for them to research exactly what they need to know. Over the past couple of months, I’ve watched a team of developers with little or no experience in WPF and WCF start to build some pretty serious enterprise level applications using these new technologies.

I’m not saying that experience shouldn’t come into play when deciding to hire somebody, but I am saying that we need to know exactly why we are hire for experience. If a decent developer with a moderate amount of experience can pick up any new coding techniques they need fairly simply, what is the real difference between a junior and a senior level developer?

As near as I can tell, the difference comes down to how they would answer the question “What does a developer do in a day?”

I recently talked with a fairly senior developer at another company. He typically works from home, and hates the thought of having to ever go into the office. “I never like to go in, because when I’m in the office no coding ever gets done. It is nothing more than meetings with other team members to talk about the project.” While I think all developers feel this frustration occasionally, his aversion to going into the office is constant.

Even though he has a senior title, I have a hard time accepting him as a senior developer. (This may be a bit unfair, as I don’t know exactly what standards he is being held to by his management.) I’ve found that the extremely good developers focus less on the code, and focus more on the team. They work to bring the weakest developers in the team up to be more in line with the stronger developers. They push the strong developers to continually improve and to keep expanding their horizons. They work with management on long term planning to ensure the long-term success of the project. They do it all, and still have a love for the code and the langues and the bits and the bytes.

Leadership skills aren’t all that easy to come by. For developers to truly learn these skills, they have to see them modeled effectively. (I also believe that experience in seeing these skills modeled ineffectively can be extremely helpful in understanding the difference.) Reading books on methodologies, researching leadership on the internet, even getting an MBA, are all helpful activities when looking to learn about leadership, but it doesn’t go far enough. It takes mentorship and modeling from existing leaders to truly build and grow a successful organization. When a self-managing development team begins to work effectively, it is a beautiful sight to see.

I’ve been very blessed over the past couple of years to work with some extremely talented and effective leaders, and I just wanted to say a huge thank you this Thanksgiving for all of your time and guidance. I have learned so much from you and look forward to working with you over the next year.

Happy Turkey day, all!

 Mike

Advertisements

October 6, 2007

My experience with paired programming

Filed under: Management — dotnetthoughts @ 7:08 am
Tags: , , ,

I’ve spent the better part of the morning trying to get my first WCF code sample to work. I got it to work eventually, but it took quite a bit more time than I was expecting. Instead of writing new code this week, I thought I’d record some of my recent experiences with paired programming.

Paired programming is simply placing two developers at a single workstation to write code. The thought process is that two heads approaching the same problem will have different experiences and perspectives on how to tackle it. While one person is writing code, the other is supposed to be thinking about the unit test and how the code might break. The philosophy recommends switching developers at the keyboard several times during the day. Research indicates that the total time to develop a system using the paired technique is relatively close to the same amount of time required for developers working individually. Code quality, however, improves greatly.

I’ve recently been working on a project with some pretty complex algorithmic calculations. I’ve been pairing with an architect for about four months, and I’ve come up with these thoughts for anybody considering pairing.

  1. Make sure you have a good personality match. The paired developers are going to be spending a lot of time in a small space together. My partner and I get along extremely well together, but there are still days where we want to throw each other out the window. If there are personality conflicts between the developers, they will probably be magnified significantly. Learn the strengths and weaknesses of your partner, and play to each others strengths as much as possible.
  2. Be flexible with the philosophy. True paired programming requires that both developers be there for each and every line of code that is written. Some teams may find that to be critical to their development process. We’ve fallen into a pattern of coding difficult sections paired, and easier secitons individually.
  3. It’s not called trio programming for a reason. Early on in the project, we had a third team member working on the same code we were working on. When any two of us were working together, it was a very clean, efficient day. When all three of us were in the room together, the additional voice added just enough chaos that our productivity fell significantly.
  4. Be prepared to defend your point of view. Typically, when my paired developer and I both have a conflict over the right way to do something, we will debate back and forth for awhile. It often turns out that both of our initial thoughts were wrong and we end up with a far superior way of solving the problem. Both team members must be willing to give and take on what the final code looks like. If one personality dominates, I think a lot of the benefit would be lost.
  5. Team programming is a good way to build team cohesion and consistency.When starting my last project, an entirely new team was brought on. We spent the entire first month, “team developing” our first module of code. This brought all of our coding standards in line with each other, and helped develop relationships very quickly.
  6. Try to keep ability levels similar. Mentoring is often talked about as one of the advantages of paired programming, and two developers can learn a lot from each other. I would advise caution when pairing two programmers together where one is significantly more senior than the other. The risk is that the junior programmer be overwhelmed or intimidated by the senior programmer, while the senior is frustrated with the development speed and thought process.
  7. Understand the effects of scheduling. If you are a shop that adheres 100% to the philosophy that both programmers need to be present for work to get done, you will have to have a plan for how to deal with sick days, vacations, doctor’s appointments, etc. This is one of the big reasons I recommend flexibility with the philosophy.
  8. Finally, keep a sense of humor. The world can start looking a little strange after being trapped in a room with the same person for hours on end. Enjoy the friendship and the development.

That’s all for today. Code safe!

 MW

Create a free website or blog at WordPress.com.