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.

Testing from the ground up

Anyone who writes software knows that it's easy to write code rapidly and get something working right away, but the difficult thing is maintaining that code over time as the requirements for what it does and how it does it change. This is where bugs creep into a system and it's up to the programmer and the testing staff to find and remove those bugs. But coders have a tool that they can use called unit testing which allows them to build a testing framework around their code. These unit tests are also code (which makes it a little more fun to write) and is intended to focus on a logical unit of functionality and exercise it in such a way that you feel confident that it's doing what it's supposed to do. As the code changes you always have that suite of tests to run to make sure that it's still doing what it was supposed to do, regardless of how the implementation changes.

At my previous job we spent a fair amount of energy trying to make unit testing a part of our culture, encouraging developers to add unit tests for code when they fix bugs or when they are adding something new. What I found was that it's often pretty difficult or painful to add unit tests to a code base that was built without the idea that it would be tested that way. You would often have to jump through great hoops to try and test something quite simple. This often led to a fair amount of frustration and people would just avoid unit testing at all. One of my past coworkers started a new project of his own and decided to try building unit tests along with the code as it was written. This experience seemed to completely change his mind about the value of unit testing after seeing how valuable it was in creating a project from scratch.

It turns out that, if you have testing in your mind as you develop your software, it naturally gets written in a testable way. And having those tests telling you that everything is okay is incredibly valuable at times. At my current job I am encouraged to build unit tests along with the code that I write and have found that it has been extremely helpful in finding bugs that I would have otherwise missed until a much later date. It's actually pretty easy to write unit tests while you're creating the code, even before you actually write the code. This practice has actually helped fix most of my bugs. By writing a test that shows how the code should work first you then can write the code the way you think it should work and find out if you got it right.

Troop surge

The world of venture capital funded companies is a pretty bizarre one. I've never been in a company like it before, having previously worked with more established companies. With the arrival of the initial round of capital funding it's like someone fired off the starting gun and yelled "Go!!" My coworker that's been here for years, through ups and downs in the past, tells me that the company's roster tripled in the month of September! As I'm sure you can imagine, that creates quite a drain on the folks that have been here for a while as they train up all of the new people. The good news is that most of the new people are in the lab group, working on the nailing down the procedures for preparing DNA samples just right so that we can process them with the best accuracy. We had one more person start in the software group, bringing a background in genomics to bear in helping to interface between the lab group and the software group. She's going to help us design the best system interface and organizational structure that we can for presenting and storing data.

I would say the feeling in the air around here is similar to what I imagine it might have been like to be in the galley of an old maritime ship. Everyone is getting to know each other, getting used to the tempo, and getting in synch with everyone else in order to really drive the ship in the right direction and with haste. The starting gun has definitely fired and we're off!