And now for something completely different

One of the interesting things about working at a start-up company (indeed, one of the things that got me excited about moving to this new job) is that there is a lot of work to be done and people need to be able to step up and take on a variety of projects which require different skill sets. Now that may work on the customer-focused software has wound down I'm picking up a new project working on some internal workflow software for manging the way we create optical maps and do identification of those maps.

This is a completely different part of the system than what I've been working on, involves a completely different set of code and, in fact, involves a completely different programming language. After languishing and collecting dust for over 5 years I'm brushing off my Perl programming knowledge and starting to put it to use. So far I've been working on understanding the code that is already there (thankfully the man who wrote it was very conscientious about clean, understandable code) and getting an idea of how things are laid out. That being said, it's still Perl! For those that don't have programming experience with Perl, it's often said that it's a "write once, read never" language ... meaning that you just write something to get a job done and then you never go back and look at the code again. It's not the prettiest programming language. Here's a short example:

for (my $i=0; $i<=$#vals; $i+=2)
{
my ($c, $flag) = ( $vals[$i], $vals[$i+1] );
$flag = ($flag eq "n") ? 0 : 1;
push @rle, $flag for ( 1 .. $c);
}

Yeah... isn't that nice and easy on the eyes?

Yesterday I had my first meeting with some of the scientists in the company who will be using the software that I'll be creating and got some very good ideas about things that it should do and how it should look and behave. It was very nice to be talking to users (even if they're my coworkers) and seeing how the software I'm going to write is going to make a huge difference in the way they do their work. I'm excited to have something new and interesting to work on and I'm glad that it's going to be something useful.

Ship It!

The last month at work has been a non-stop push of implementing features, testing, and fixing bugs. We spent hours and hours testing the software that I've been working on and I think we really polished it up nicely and have something that's going to make customers happy. We've actually had a couple of customers using a beta release of my application and so far the feedback has been quite positive, which makes me happy.

Today the last official document was signed off and the software I've been working on for the last 8 months has now gone gold for the first release to customers! I'm very excited, relieved, and apprehensive all at the same time. It's exciting to know that people are going to use the software that I created and put all of my work into. I banged my head against the desk trying to solve some very hairy and insidious problems, spent hours discussing how features should work and how to make the program as useful as possible, and delved deep into performance profiling and benchmarking to try and eek out as much speed improvement as possible. It was a lot of work and I'm thrilled that we came this far and that things are looking this good.

But all of that is followed on with a niggling doubts and worries that I've missed something that's going to be a big problem once people start actually using the software. One thing is true about writing software: you can plan all you want for how you think customers are going to use your software, but you can never be certain that you've got it just right. I worry that there are hidden bugs that we didn't find that are going to crop up and cause big problems or make us look bad. I'm concerned that the technology choices I made might not be the right ones .. maybe we didn't fully understand how people are going to use the application and it just won't scale well.

But after I calm down for a little bit I remind myself that I'm surrounded by a group of people that are working hard to make sure that we don't send out something that's going to be a flop. After all the hours of testing and of talking to customers and other users I think that it's going to be a success.

But I will still worry a little bit.

Help Wanted

Things are moving along very quickly here at work and we've hit our first big milestone. It kind of feels like we're just over the top of the first big climb on a roller coaster... things are about to start getting wild! There is a lot of software work to be done and it looks like we have a number of openings in software development that we're hoping to fill soon.

In general, we're looking for bright, self-motivated, and effective people that can come on board and happily pick up some new projects and jump right into making some software. In particular we're looking for Java and C++ programmers for a variety of projects including production database management, image processing, and algorithm development to name a few.

The job postings are not yet up on the website, but they should be posted some time this week. If you know a person interested in a new opportunity with a cool and fun company please direct them either to myself or to the hiring manager Erik.

Here comes the science, Part 3

Before I went on hiatus it was just about time to talk about the software that I've been working on and how it pertains to the process of working with optical genome maps and actually doing something interesting with them.

Building a database
As I mentioned in previous posts the most interesting thing you can do with an optical map is to compare it to other maps of similar genomes for the purposes of looking at similarities and differences. But in order to do that you need a repository of maps and way of categorizing and searching that repository to find what you're looking for. We didn't have anything like that at the time I started so it was the first thing I worked on and we now have a nicely categorized, searchable database of over 40,000 genome maps.

Making maps in software
Creating optical maps is currently a time-consuming process and we'd need a lot of people to make 40,000 maps by hand. The vast majority of those maps that we have in the database are what are called "in-silico" maps, which is a cutesy way of saying that they were made in software. When you think about what mapping is, you're taking little bits and pieces of DNA and cutting it up with an enzyme and then measuring the fragments that get created. We don't necessarily know what the actual DNA sequence of that genome is and it's actually irrelevant for the purposes of creating optical maps (which can be very helpful, which I'll describe later). However there are plenty of people out there who are working hard at sequencing the genomes of all sorts of organisms. We can take those sequences (the literal nucleotide sequence, e.g. ATCGGACT) and simulate the process of applying a restriction enzyme to cut that sequence into fragments to create in-silico maps. Luckily someone out there already wrote libraries for doing these sorts of things so it was pretty easy to use that code to populate our database.

Comparing maps
Really the critical functionality of the software I'm working on is the ability to compare maps to each other. In a nutshell we compare maps by looking at the series of fragments in each map and use some complicated math that I'll likely never understand to figure out whether or not they're "close enough" to each other to confidently say that they probably represent the same underlying DNA structure. While it's very likely that the actual DNA sequences are different in some respects, those differences are small enough that they don't show up at the map level. And we can reasonably assume that these are regions of similarity between the genomes. Using maps these similarities and differences are very easy to visualize.. here's an example of a couple of similar strains of P.aeruginosa:


The purple parts are regions of similarity while the white parts represent regions that do not appear to be similar at all. It's immediately obvious where these particular strains differ and where they appear to have common structure.

Extracting meaning
All of these leads up to my final point which is how you can use this software for comparing maps to extract meaning. As we know, the DNA structure of organisms dictates what they look like and what they are capable of in the physical world. In our particular realm we're mainly looking at bacteria.. specifically bacteria that make people sick. There are a lot of species of bacteria that make people sick and, within those species, there are several sub-species or strains that act differently. Some are particularly nasty, some are immune to certain antibiotic medications, and some are just run-of-the-mill . Since these strains are all of the same species they (frequently, but not always) end up sharing a lot of similar DNA. So by comparing maps of the different strains you can fairly easily see places where the DNA structure differs and that can really help you isolate the region of the genome that is cause a particular strain to be especially nasty.

I guess that's about it for now .. this is getting pretty long. I may revisit this topic a little later as more code gets written and I start in on more new things. Right now I'm kind of in the middle of a round of bug-fixing and polish and that' s just not that interesting!! Bye for now.

Brushing the dust off

It's embarrassing to say it, but it's been almost 3 months since my last blog post. I've had a few people comment on this and my wife actually asked if she should remove my blog from her RSS aggregator... ouch!! Well my only comment is that I took a while off when our daughter, Sylvia, was born in early February and I got out of the habit. But I'm back in the saddle now and looking at getting back to moving forward.

Here comes the science, Part 2

This time around I'm going to dive down into a little more detail about what actually goes on in the process of making this optical maps of DNA samples. At a theoretical level, the process is fairly straight forward and sounds pretty basic. However, as I'm learning while working here, real life does not think very highly of our nice, simple, straight-forward theories. So the process has to be very robust, especially on the software side, which makes me very glad that I work with a lot of really smart people.

Making DNA lay down straight
The whole linchpin of this process is being able to measure the length of the strands of DNA (more accurately, the lengths of DNA fragments but we'll get to that shortly). In order for length to have any meaning, we need to have the subjects we're measuring be as close to a straight line as possible. In order to do that we use a glass surface (you remember those microscope slides you used in high school) and a cover slip that has microscopically small channels carved into it. The DNA is placed, in solution, onto this surface and, using a magical process I know nothing about, the DNA is stretched out along those channels which serve as guides for straightening out the molecules.

Cutting it up into fragments
In order to create meaningful maps that can be used to identify and compare organisms we need to break up the DNA molecules into fragments. It's these fragments that we measure to create that nice-looking barcode map. In order to create those maps you use what is called a "restriction enzyme", which are enzymes that actually cut DNA. A particular restriction enzyme always cuts in the same place, at a particular occurrence of base pairs in the DNA strand. For example, the enzyme BamHI cuts at restriction sites of GGATCC. As an aside, most restriction enzymes cut at sites that are palindromic.. there's no obvious reason that I know of why that is, but it sure is a neat coincidence. Due to the genetic makeup of different organisms, different enzymes will cut different numbers of fragments for each organism. Part of our process is picking an enzyme that will cut the "right number" of fragments, that is, enough to make a meaningful map. Too few fragments or too many fragments often make the maps indistinguishable from each other.

Measuring those fragments
As part of the preparation of the DNA, a stain is applied that will cause the fragments to light up or "fluoresce" when exposed to a laser. The glass slip containing the DNA solution is placed on a fluorescent microscope that has a camera attached to it and an automated software system moves the camera up and down the length of those channels and takes pictures through the microscope. Here's an example of what it looks like. Remember this is one tiny fraction of a single image from the microscope. You can see several broken strands of DNA. The colored one is one that has been picked out by the software as clean enough to be measured and recorded.


Hundreds of such images are acquired and finally fed through some image processing software that finds the nicest looking DNA molecules and it finds the fragments and measures their length in some unit of measure that is smaller than anything I can image. Finally those fragment lengths are recorded in order and they can be visually represented by that barcode-like display I showed last time. Here's an artists interpretation of how that looks:


Assembling the pieces
Here's where the real world comes in and whacks you in the head. DNA will almost never stay fully in tact throughout the process I just described. And even if it did, there are usually a lot of molecules and they tend to overlap each other or they don't straighten out exactly right (or sometimes at all). So what you end up with is lots and lots of small maps that represent just a chunk of the entire strand of DNA. And here is where some intense computing power is brought to bear on the problem as we take all of those smaller maps and try and determine how and where the overlap each other. It's kind of analogous to trying to put a piece of paper back together after it has been through a shredder. When this process is finally done (and everything worked out okay) you end up with a "consensus map", which is the amalgamation of all of those smaller map chunks.


Once you've got that consensus map, then the doors open to a wide range of things you can do with it and that's where the software that I'm working on comes into play. But I'll save that stuff for the third and final installment of this series. Thanks for reading!

Here comes the science, Part 1

I've been wanting for some time to make a post or two to try and explain the basics of the science that is the core of our company. The techniques described here are in the public domain so there's nothing secret here. I've been working here long enough that I now feel pretty confident that I understand the process at a fairly high level.. just the right amount to be able to describe it to someone else that might find it interesting. For part 1 here, I will just describe the basic premise and will cover more actual detail in later posts. I've really enjoyed learning this stuff and I hope that other people find it interesting too.

The "Op" stands for Optical
The company's name, OpGen, is based on the fact that the core scientific process behind the business is called "optical mapping" which is, in short, a technique for taking physical samples of DNA and creating a visual representation of it such that unique organisms can be easily differentiated from each other and similarities between other organisms can be easily spotted. The whole concept is that you can break up DNA into many fragments and then put those fragments together in a line and you get what we call a "map". What's useful about this is that similar organisms will consistently and repeatedly break up in the same way such that their maps are very similar. As you'll see later, these maps almost look like barcodes and you can actually think of them as such, or as a "fingerprint" which uniquely identifies an organism. Here's an example of what one might look like:


What's it for?
The most interesting applications for optical mapping that I am aware of are in the area of what we call "comparative genomics" (other people might call it something else). Basically, it's the practice of looking at a number of similar or related organisms and analyzing what's different about them. For instance, say you have maps of two isolates of the same species of bacteria that cause infections in humans. Furthermore, say that one of those isolates is known to be extremely nasty and hard to treat, while the other is easily killed off with a round of antibiotics. By comparing the maps of these two bugs, you can actually see where the two are genetically different. Those parts that are different most likely indicate where the nastiness of the bacteria is regulated and can point the way for researchers to know where to look when trying to figure out how to combat that strain.

Coming soon...
In future posts I'll tell you more detail about how we actually create those maps and talk about the software I'm working on and how it pertains to these maps.

Captain on the bridge

This week marks the first working week for our newly hired CEO. The board of directors and our executives spent quite some time looking for the right candidate, with an appropriate level of experience in the biotechnology field, and I think they've found a good one. I've just met him the once, but he seemed like a very personable person and even had some good technical questions to ask me. It remains to be seen what kind of direction he is going to be taking us in. I've always held the belief that the CEO really sets the "mood" of the company .. shaping the way that people relate with each other and the ways the things get done.

To start us off, we've got an all company meeting tomorrow... at the bowling alley! Sounds like a good way to get started. I hope I can still keep it out of the gutter. It's been a while since I last bowled. But in, seriousness, I like the fact that one of his first actions is to create an informal, fun environment for allowing us to get to know him and vice versa. That indicates to me that this is not your nose-to-the-grindstone, slave-driver type of person, but rather someone that acknowledges that employees need to have good relationships with each other in order to be productive.

I personally believe that good team chemistry (a combination of trust, respect, friendly competition, openness, and the ability to have fun) is of utmost importance when you need people to perform at their best. You can have an environment where people dislike, distrust, or disrespect each other and still get work done, but those people won't be as motivated or productive as people that feel at home when they're at work.

I'm working on developing that level of comfort with the people I immediately work with and I'm excited to see that our executives are actively working to encourage it, too.

I knew this would happen

One thing that I've learned about myself over the years is that I have a difficult time staying committed to projects. I often get pretty interested in a particular idea or project and start in on it all gung-ho and within a time period as short as a week or up to a couple of months my energy will fizzle out until the thing finally drops off my radar as if it never existed.

I intend not to let that happen with my blogging efforts because I find that it really helps me when I can put my thoughts down into words and, shocking to me as it's been, I've actually heard people read and comment on what I've written. However, there has definitely been a downturn in the number of posts over the last month. Now I agree there's nothing more boring than someone blogging about their blogging, but I will say that I can see why the change in my posting habits has occurred.

I don't think it's due to a loss of interest, but rather a change in the way I perceive my situation. I've been at my new job for close to 3 months now and I think things are becoming routine and familiar. There isn't quite as much going on that really gives me an idea of something interesting to think/write about. And I'm not a person to just talk about trivial things just to hear my own voice. So that just means that topics I think are worthy of writing about are coming in longer intervals.

So, if you're reading this, thanks! I'm not giving up on the blog, but simply acknowledging that it's going to be going at a slower pace than it has in the past.

And that will be the last blog post about my blog posts. :)

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.

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!

Flow

The programmer, like the poet, works only slightly removed from pure thought-stuff. He builds his castles in the air, from air, creating by exertion of the imagination. Few media of creation are so flexible, so easy to polish and rework, so readily capable of realizing grand conceptual structures.

-Frederick P. Brooks, "No Silver Bullet"

I love that quote. Brooks is an outstanding writer and a great source of a lot of good quotes about programmers and software development and they're just as true today as when he wrote them. Despite all of the unbelievable changes in hardware, the proliferation of programming languages and software frameworks, and decades of evolving and adapting our approaches to making software we are still find a lot in common with programmers of 40 years ago.

".. slightly removed from pure thought-stuff" ... Dealing with such a delicate and fleeting substance requires a good deal of concentration, persistence, and awareness. When building these castles of air you often find yourself juggling bricks and mortar, moving pieces and materials around until they fit just right. Suffering any interruptions during this process can cause you to drop what you're doing and struggle to pick it back up again. Worse yet you can drop things into a configuration where it seems that everything is stable yet, hidden from view, a flaw is left waiting for the day when it brings things crashing down.

Most programmers know about the idea of flow. If they don't know it by that name, their eyes will light up with recognition as you go into explaining that state of mind where you become so in tune with the task at hand that your thoughts speed up and become perfectly clear, code flies from your fingers and, when you finally come out of it, you realize that time has passed at a seemingly impossible rate.

This was something that, for the past year, at my old job I very rarely experienced. Most days I was dealing with a number of little projects or small tasks or bug fixes simultaneously. There were interruptions as customer sites would experience problems or there was a meeting to attend or another developer wanted to ask a question. I pretty much stopped entering into the flow state altogether.

But for the last two days I've been spending a lot of time flowing as I gather understanding about this project I'm working on and come up with ideas of what is needed and how to implement it. I have people to go to when I need clarification or help fleshing out an idea, but I have a free reign to write the code and pretty much no distractions to keep me from it. It's an amazing feeling and I can honestly say I haven't had this much fun at work in some time. I know it can't possibly last forever, but I'm so pleased to be back in a position where I can write code and create some of my own castles in the air again.

Can't turn the brain off

After lying in bed and trying to go to sleep for a while I realized that my mind is just full of thoughts and that perhaps a blog post might be the best sleep pill I can take right now. Chances are that I have some sort of personality disorder that causes me to be thinking about work while I'm trying to go to sleep ... or perhaps it's just that I'm pretty excited about actually getting in and starting to really contribute to my new team. As mentioned in previous entries, I spent a good chunk of last week trying to learn a bunch of new stuff without appearing to be a complete dullard. But today I got to actually start showing people that I can actually do some things and, I'm happy to say, I got some pretty positive feedback.

I think I'm really excited because I'm beginning to see where I can really start making a difference in the way that software is created at OpGen. Most of the codebase that they have is pretty much considered to be a working protoype, with just about everything written in Perl/Tk. Perl/Tk is NOT what I would choose to implement a large-scale product that you're hoping to ship to a customers site. There are one or two projects lying around that are written in Java, but it's hardly the Java that I recognize. Clearly it was prototype code, written by somebody that grew up programming in something other than an object-oriented programming language.

Dealing with these sub-optimal (in my mind) software codebases isn't incredibly fun, but it's not really all that hard either. However the really fun part is that I am getting to start on a fresh, new Java project with the intent that I will be building up a Java framework that will eventually replace all (or most of) the existing prototype code that has been written to date. That will be a long haul, for certain, but I'm excited about getting started at pretty much ground zero and making technology, framework, and design choices. I've pretty much been told that I am going to be "The Java Guy" and that I can (within reason) run things the way I want. That is pretty exciting to me!

I'm really pleased to see how some of things that I've learned from my previous job can really be used at OpGen to make a real positive impact in productivity and ease-of-development. I have to laugh a little when I say this, but first just using an IDE. I'm not entirely sure how the Java code that exists got developed, but rumor has it that it was created only using vi and ant. To me, that's kind of like building a doghouse using only 19th century tools. Sure you can do it, and there's some amount of geek credibility to be earned there, but wouldn't you rather use a cordless drill and a chop saw? Beyond just simple stuff like that, I'm very excited about the possibilities of using Hibernate (these guys have never heard of an ORM tool) for simplifying their database access routines and JavaSpaces for some robust, distributed processing. It's pretty exciting seeing that you've actually learned some neat tricks that you can apply in other situations.

I'm very happy about the way this week is starting off and I'm hoping to demo some software tomorrow and get going on my database access framework and start working on getting some stuff really cooking. I don't know if this is going to help me sleep or if I'm just more amped up now than when I started.