Paid vacation

While it isn't really a vacation, I am really looking forward to this weekend when I will be going down to Chicago for the No Fluff Just Stuff software development conference. The silly name simply reflects the fact the the conference organizers put a lot of effort into packing the most useful and interesting information and speakers into the weekend as possible. I was introduced to this conference through my previous job, where all of the developers were encouraged to attend each year. I asked my new company if they would send me this year and they seemed happy to do so.

I really think that paying for this kind of training and career/skill development is an amazing benefit that a company can provide its employees. I always find that I learn something of value and I certainly get exposed to a lot of new ideas and technologies by attending this show. It seems like a pretty small price tag per person and the return on investment seems quite high. Not only do I come back with some new ideas and new motivation, but I also feel very thankful to the company for investing in my future.

I'm really looking forward to the conference. I will be meeting up with a few of my previous coworkers, so that will be a lot of fun spending time with them. It should be great!

A different breed

As I mentioned a few weeks ago, we're looking to hire a few people in our software R&D group and this week we've started interviewing some of the first responders. Being such a small group, our leader has taken the tack that all of us in the group should interview potential candidates since each new person will substantially change the dynamics of our little office here.

I'm no stranger to interviewing people for various positions including software developers, software QA engineers, and project management types. However, the type of positions we've posted seems to be drawing a wholly different breed of person to our doors than I have previously had experience with. I think part of it has to do with the nature of our company and our target markets. We're looking at potentially embedded systems, low-level algorithm development, and Quality process management (yes, with a big Q). It also has to do with the level of experience that we're looking for. Management has always said that they're looking for the "best" people that can come in right away and make an impact... this was one of the things that really excited me about this job. As a result, however, I'm interviewing people backgrounds far different than I am used to.

For starters, everyone I've interviewed so far has been over 40. They have all been working at (or consulting for) extremely large companies. They have all been working under what I would consider very heavy-weight development processes. This is quite a change from the types of people I've been used to interviewing, which were mainly recent college graduates with little to know professional work experience outside of school. I'm used to trying to drag information out of interviewees, trying to get them to show me that they're bright and talented and can do the job. With the people I'm interviewing now I kind of have to try and get them to stop talking about how much they can do.

But the one common thing I keep coming back to is the need for the interviewee to convince me that they want to do the job that we're offering them and that they are the right kind of person to work with us. "Kind", in this usage, is not a strict category that you can use to segregate people. Rather it is a blend of the necessary and desired qualities that make a person stand out as someone I would really want to work with. I have seen very talented people that have had the absolute wrong personality or attitude for the team they joined. I've seen extremely likable and fun people that fit in perfectly with a team but that cannot perform the work. That ideal blend is just as hard to come by in a 22 year old as it is in a 52 year old.

First release

After the confusion and uncertainty that ensued over the green blob I discussed last week, we decided that I should focus on getting an initial release created of the code I've been working on. By the end of the day yesterday I had it built and tested and sent out the installer and release notes to the team. It feels really good to have now actually delivered something. Even thought it's just an internal release, it feels good knowing that the things I've been working on are actually going to get used. Actually it feels great because every time I hear my boss telling someone what the software does now they get really excited about it. So that is cool!

Now we'll just wait and see what kind of bugs and things I've missed come out of this. That's the flip-side to the "Yay, someone is using my code!" excitement ... it's the "Oh man, someone is using my code and finding all sorts of things I need to change." sort of feeling. We'll see how it goes. :)

We're hiring

Another round of funding has come our way and, with it, a little more work. We're currently looking to hire three people in the software development group. It seems like for now that there's only enough Java work for me at the moment, so we're looking to hire in other areas.

Primarily we need a software QA person to help us get our products up to snuff by putting together some test plans and validating the existing software we have.

Additionally we really need what they're calling a "Systems engineer" position, which is basically a person that is good working with software development teams and IT staff that can help us whip up a solid system for packaging, distributing, and configuring our software and hardware systems.

Finally there is also a need for a skilled C++ programmer to work on some of the core, computational components used in our software.

If you are one of these people, or if you know one of these people, please take a look at the descriptions at our employment page.

You want a what, now?

I guess pretty much every programmer in the world goes through this experience in their lifetime when they are presented with a project that is so ill-defined, so nebulous that it twists your mind inside out as you try and fathom exactly what it is that you're being asked to do. You poke and prod at the amorphous blob that is your project hoping that, either by skill or by chance, you can coax it into revealing to you some of its actual features or some of its internal machinery. It's like looking out an icy window: you can tell that there's stuff out there, maybe you can even discern some of the colors and shapes, but the reality of what's outside may in no way correspond to what you thought you saw through the frozen glass.

As such, how do you begin? One approach would be to say, "Well, all I can see is a green blob so I'm just going to make some software that does green blob-like stuff. I can always change it later when I get a clearer picture of what's needed." This approach appeals to the part of me that doesn't want to waste my time on doing complex things that may very well be wrong. But there's a part of me that really doesn't like doing simple things that I know for a fact are going to be wrong. I know that I'm not really looking at a green blob ... it's probably really a stalk of broccoli, something with defined structure and intricate detail. But what happens if I go through all the work to deal with broccoli and it turns out that I was really looking at asparagus?

So, food-related metaphors aside, I'm at this frustrating point of not knowing quite enough about what I need to know, yet still feeling like I need to make some sort of step forward. I keep talking with other people to get their ideas and it's all still very blurry and green blob-like in their minds too. For those of my old coworkers that make it this far into my ramblings, it sounds like I'm going to be basically implementing metadata, but with a few extra twists. Metadata was, in my mind, easily one of the few most complicated areas of the code that I worked with. Maybe it had to do with the way the code was written, or maybe it was just that it was a complex, hard-to-understand beast of a problem. Either way, I'm going to get my chance to try and replicate it and, hopefully, understand it better this time around.

Welcome to the machine

If you've ever worked in a company where "quality" was a word spoken with a capital "Q" than this might not seem that foreign to you, but I've been a little amused by the efforts going on at setting up our Quality control systems here at work. Working in the bio-tech field and, hopefully one day, creating systems that will be used to diagnose patients and affect their treatment subject you to the need to worry about certification, primarily by the FDA. In order to meet the requirements your company needs to have tip-top shape documentation about how the Quality of your product has been maintained throughout the development process.

We have a full-time employee whose job it is to define and maintain that documentation and it's only just started to actually affect me. The approach we're taking is using the GMP (Good Management Practice) which is espoused by the FDA. So far, it seems that all of that is just coming in the form of SOPs (or Standard Operation Procedures) which travel around in little blue folders and can only be photocopied once, and blah, blah blah. At the moment, I don't see that it's going to be much of a burden at all in our group. Mostly all of the work is focusing on the lab-based work and the actual engineering group who are responsible for building the device prototypes.

However I did get to sign three documents last week as part of the Quality process, which just made me have to laugh. The first was a "signature list", which was just that ... a list of all the signatures of all the people in the company. Oh, and by the way, atop each of these forms is a Training Form, which each person must sign to say that they have been trained on that particular SOP. So I got to sign the signature list and the training form to say that I signed the signature list. But it gets better!! The next one was the SOP about that Training Form itself. Yes, I signed the Training Form to say that I had been trained on the Training Form! I joked that she just did that for us computer geeks who find that kind of recursion appealing.

As laughable as it is to me, I suppose it's good that someone is looking out for these sorts of things. The last thing you'd want is to get this great technology built and tested only to find out that no one will use it until you can get certified and that you don't have the work done to meet certification. I'm just glad it's not my job!!

I hear (and I don't think they were joking) that SOPs for taking out the trash and refilling the water coolers will be coming soon....

All hands on deck

I think that one of the most powerful management tools that exists for getting people motivated, focused, and on-task is the "All hands meeting". Now, I agree right off the bat that there are good all hands meetings and there are bad ones. However, I really think that there are very positive things that can come out of bringing your people together as a team and sharing information with each other. It's incredibly important that everyone has a common sense of the direction they are going in and an idea of what lies ahead of them. An all hands meeting is the perfect time to instill a sense of purpose, of urgency, of importance, and of pride in each of your team members. Getting people from different groups together in one room is a unifying experience and can be a great way to galvanize a team and send them off in a positive direction.

Here are the core things that I think you have to have in order to pull off a successful meeting:

• Have a moderator
Every meeting needs someone to make sure that it stays on track and that the things that need to be discussed get covered. This can either be the person that's delivering the address or someone that introduces and gives the floor over to others, but you have to have a custodian that looks out for the health of the meeting.


• Have an agenda
The number one killer of meetings is the aimless leader who doesn't have a clear idea of what is going to be discussed in the meeting. Disconnected ramblings and flip-flopping between topics can confuse your attendees and fumbling around trying to remember what else you wanted to talk about only frustrates them.


• Be direct
If you've got something to say then say it. People demand honesty and forthrightness from their leaders, even if it makes them upset or uncomfortable. Don't tip-toe around issues and come right out and say what needs saying. Nor is this the time for verbose and flowery language, quirky little jokes, or funny (to you) side stories. Don't water down your message with meaningless words.


• Be concise
Keep topics short and sweet and avoid tangents and other rambling. Say enough to fully explain the concept you're trying to present, but keep out extraneous anecdotes or non-essential information. Let your team ask for more detailed information or background if they want it. These people are giving you their time and you must be considerate with it.


• Tie it all together
After all of the items on the agenda have been covered, take just a moment to bring together the various topics that have been discussed and try to distill it all down into a single, easily digestible message. This is the message that you want your people to walk away with when the meeting is over. You don't want to repeat everything you've said before but, instead, try to summarize the important points into a little nugget that they can keep in their heads for the near future.


• Take questions
Always allow your team to ask questions about the information that has been presented in the meeting or other relevant topics. It may be a good idea to ask people to hold questions until the end to make sure that all topics have been covered. Make sure there is time allotted for people to get more information, but the moderator should keep an eye out for questions or answers that take too long and cause things to drag on.