I’ve finally decided that I’m going to take an active role in getting myself out of this almost year-long development-less funk that I’ve been in. I’ve been pouring over information and ideas, trying to come up with something that I could spend my time on and make a personal project of. I actually came up with a few. They’re all Omega Vortex projects from back when we were trying to bootstrap a software company by consulting. The projects never got enough attention because of the consulting and we started to enter the really nasty area of the recession, so the consulting projects also started drying up, leaving us without enough income to allow us to move forward …

Fast forward a couple months where we were wrapping up our last consulting gig as I was taking a job at Highwinds as a Systems Engineer. Presumably to Engineer some cool tools and systems to help make our collective jobs easier. If only I knew then what I was really getting myself into. Honestly, I’m glad I didn’t. I probably wouldn’t have been so eager to take the job. Not too long after I started, our more senior engineer and overall badass Systems Ninja (hi, Matt!) got an offer he couldn’t refuse and decided to move on to higher places. It was about that time that my world turned upside-down.

With almost zero previous experience as a Linux SysAdmin, I started a journey that would lead me to a great wealth of knowledge, a much greater understanding of how our systems worked and interacted with each other, as well as roughly no amount of time to spend on any of my development projects. We went through several ups and downs as I came up to speed, learning everything I could about running our Linux systems and how all of our software worked, the way the whole deal was architected, and everything I needed to know to keep it all running. It’s a constant learning experience and I’m still picking up stuff as I go along, but I feel like I’ve come a very long way in a short amount of time and I’m far more comfortable on the command line now than I ever was even back when Linux was my primary OS on personal machines.

Since then, we’ve hired quite a few Linux folks. Less pressure is square on my shoulders now that we have more very capable people to help distribute the load. We’re making progress to working smarter and not harder, spending less of our nights in contests to put out fires and more time with opportunities to relax. Things are becoming increasingly stable which is giving me more free time during off-work hours to do whatever I want. At first, I took this time to goof off and not do a whole lot, because I hadn’t had the opportunity to do so in so long. Now, I’ve decided to transition back to active development work in my free time.

I’m sure those of you who follow me on Twitter noticed that I said I’ve officially started working on ComicShout and OmegaFlash again. That’s not all, and I’ll have a lot to say about these and other projects in future posts. In the meantime, you can keep track of what I’m working on via GitHub and Ohloh.

The repositories on GitHub are very ugly at the moment. They’re essentially dumps of what was in the private Omega Vortex repositories as of last night. A lot of code that never got committed was lost on a few of these. Keep in mind that these projects didn’t get enough love, before. My plan is to fix that. My current focus for a while is going to be OmegaFlash, so don’t expect too much activity on the others for now. As I’m able, I’m going to start putting up more information on my vision and goals for each project at their respective GitHub wikis. Anyone who’s looking to contribute after I’ve put up more info, please fork away. I’ll be keeping an eye on forks and will quickly integrate good additions. Habitual good contributors can be given direct commit access to the repositories.

If I’ve got your interest, please keep an eye on the progress at GitHub and Ohloh. Also, keep an eye on this blog. I’m going to start putting up some high-level overviews of what I want to do with the projects. Until then, I’m interested to hear ideas and suggestions from all of you.

/// <summary>
/// A C# implementation of "ArrayShift" this is a generic method that
/// will take an Array of T's, shift one off of the beginning of the
/// array and return it.
/// </summary>
/// <typeparam name="T">The type of array.</typeparam>
/// <param name="array">An array of T's, will be modified to remove
/// the first element.</param>
/// <returns>First element of array.</returns>
public static T ArrayShift<T>(ref T[] array)
{
   T first = array[0];
   IList<T> list = array.ToList();
   list.RemoveAt(0);
   array = list.ToArray();

   return first;
}

It’s a quick and dirty way to accomplish what I needed. If anyone has a better method, I’m open to it.

After noticing someone on Twitter mention a LINQ to WMI project, it seemed like the perfect fit. LINQ (Language-Integrated Query) is something I’m not too familiar with and want to learn. While I’m somewhat familiar with WMI (Windows Management Instrumentation), it’s huge. There’s still plenty left to be learned about it.

I’ve become a developer on the LinqToWMI project at Microsoft’s CodePlex and I’ve already made two major updates for those who are interested. One of which is the ability to generate “Commonly Used” WMI classes instead of just generating the ones you need one at a time. The next is a major speed enhancing change on the ClassGenerator.

It came to my attention while testing the project that it would crash with a NullReferenceException if there were no instances available of the class you wanted to generate. (Example: It would crash when trying to generate a Win32_FloppyDrive class. My laptop has no floppy drive.) In re-working the generator to not use an instance to generate code from, we gained a pretty huge speed boost from not having to search for an instance. Before, it took about 4 or 5 seconds to generate around 15 classes. Now it takes a fraction of a second.

If you’re needing to use the WMI on a project and want an easy way to query it, give this project a shot. If you think it’s good, help us out by contributing patches or bug reports so we can make the project even better.

Quite a while ago, Omega Vortex adopted a policy that we would refrain from announcing specific release dates. We won’t even narrow it down to a month for you. There’s quite a few reasons that we do this.

We’re a startup that’s bootstrapping from consulting work. At any given time, said consulting work currently takes priority over all other things, because we have to make money in order to pay bills and keep developers paid. That’s all fine and dandy, but while we’re having to focus so much on consulting, software isn’t being written. This is eating us like the plague. We’re presently amazingly profitable, but not in the way that we want to be. No matter how good our scheduling is, it doesn’t make a difference because we’re constantly having to drop everything to invest time in a new consulting project.

On the plus side, we’re about to simultaneously release a new product that hasn’t been announced yet along with updates to two other products that you may already be familiar with. No matter how close we get to that day, we’re not going to tell you when that day will be, in advance. All of our releases are marked by quarters. Any one year is divided up into three month quarters. Q1 is January – March, Q2 is April – June, Q3 is July – September, and Q4 is October – December. That means that when we mark a release as Q3 of 2008, we could potentially release that product at any point within those three months. If we’re expecting to release in September, we’ll actually really say Q4 so that we have three extra months worth of time buffer to use in the even that something goes wrong. If we happen to meet our goal of September, we just managed to release an entire month early.

Three months of buffer is a pretty decent amount of time. Sadly, because of time constraints with our consulting work, we’re still having trouble meeting those release dates. OmegaVerge has suffered considerably because of this and it has allowed competitors to get a jump on us. (Speaking of OmegaVerge, I’d like to give a shoutout to Ben Babcock who actually managed to help me with a SimpleXML issue by letting me help him with a SimpleXML issue. We now have type-safety/inference of IP.Converge methods in OmegaVerge since we solved that issue, instead of having to pass around SimpleXMLElement objects. Thanks, Ben.)

If you’re a software development shop and, like us, you can’t dedicate 100% of your time to software development, don’t announce release dates. Even vague ones. Surprise people. People get incredibly antsy / angry when you don’t meet release dates.

Oh, and if you have a historic trend of lack of ability to execute, don’t try to say things like “this summer” or “next month” … I’m guilty of this too, but this is a practice that really needs to stop. I’ve seen so many projects say “next month” and it take so much longer than that. Two in particular have me facepalming, right now …

Most of your [code] comments are unnecessary.

Don't ever tell a developer that. Especially, one that is learning. Code commenting is one of biggest components of code maintainability and there are simply not enough developers that do it enough. The thought that someone really would instill the thought that comments are unnecessary really peeves me. I've had so many problems over the years that could've been solved if the programmer before me had just commented his stuff properly.

Don't be this idiot.

Not Including Basic Information

Like, for one, your name. I had a resume show up in my inbox the other day that didn’t have a name to go with it. So, I figured I could get the name out of the resume itself in order to respond. I couldn’t find the person’s name to save my life. It’s really not smart to send in a resume without basic contact details so I can get in touch with you. If you don’t include something as basic as your name, I’m going to feel dumb trying to contact you without knowing it. The likelihood of me contacting you if I feel dumb about it? Pretty low. To the tune of 0%.

Not Knowing the Basics (Or Lying)

I got a “spectacular” resume from someone who had (claimed to have) been working in this industry for 10+ years. Bachelor’s Degree in Computer Science from a very prestigious college and a laundry list of work experience that went on for a few pages …

First of all, I don’t need a seven page resume. That sets off some alarms in my head when I open up a huge document that’s supposed to be a resume. You’re either full of yourself or lying. I don’t need to know where you were working in 1991 if it isn’t one of your three or four most recent jobs. For this particular person, I’m inclined to say that they were lying. Against my better judgement, I decided to interview.

As part of my interview process, I like to ask some really basic questions. I do this for two reasons. One, it relieves tension. People like to get things right. As they get more things right, they become more comfortable and we can move on to more complicated concepts. For two, I know to stop the interview immediately if the person misses any of these questions … This particular person happened to miss all but two of my questions. These questions are some that my younger programming buddies who are still in High School would laugh at this person for not being able to answer. How can you have 10 years of experience and not know dead-simple concepts?

Massive Font to Extend an Otherwise Short Resume

Please, please don’t try to hide the fact that in Arial 12pt your resume is only 1 page. I just finished looking through a resume whose font was literally set to 23pt. That’s huge! And quite unnecessary. I’m not measuring to see who has the longest, but if your font is so big that I can only fit less than 1/8 of what would be the first page on my screen, I’m probably just going to delete it.

Not Knowing English

First off, don’t take this the wrong way. I’m a fan of equal opportunity, but you’ve got to meet our requirements. One of our requirements is “an excellent command of written and spoken English”. I’d just as quickly trash a resume from an white American man as I would from anyone else for not meeting that requirement.

Telling Me Too Much

Piggy backing somewhat on one of the other points, don’t tell me too much. If I’m looking for a PHP/MySQL developer, I want to know how much experience you have in those two things and maybe some other closely-related technologies. I don’t want to know or care to know about how much experience you have in Adobe Photoshop, MS Access, ILE RPG, CL400/CLLE, etc. Yes, all of those were from an actual resume. I don’t care. Don’t tell me all that crap, it’s not related to the position you’re applying for.

Lying by Omission

Or, concealing the fact that you don’t have a college degree by using phrases like “Attended X university”. Again, I don’t care, but don’t try to make me believe something by covering it up. People drop out of college all the time for various different reasons. Just couldn’t cut it? Ran out of money? Decide college wasn’t for you? That’s your business. I’m still in college. I haven’t finished my Bachelor’s, yet. I’m really not going to hold that against you. Some of the best programmers I know don’t have college degrees. Some of the worst programmers I know do. Interesting demographic. I’m more of a believer in cold, hard experience.

Telling Me Sensitive Information

If I’m not allowed to ask, I don’t want to know at least until I give you a yay or a nay. Don’t tell me your gender (if it’s obvious, I’ll figure it out), don’t tell me your sexual orientation, don’t tell me your age, etc. If you put that kind of crap on your resume, that puts employers in a bad position, because we’re not allowed to make decisions based on that information. That requires us to consciously ignore it. If it’s there, I’m not even going to bother. It’s not because you’re white, black, asian, mexican, 85, 13, gay, bi, married, divorce, have 37 kids, a woman, or a paraplegic. It’s because I don’t want to touch something that could put me in a bad position, because you gave me information that I’m not allowed to judge you on. So, I’m just not going to judge you at all and act like I never saw your resume.

Not Attaching your Resume

This is a good one. I’ve excused it a couple times and contacted people to have them send it to me, but I’m slowly starting to not give it a second thought. Make sure you’re thorough enough to remember to actually attach your resume to an e-mail when you send it off.

That’s just a few things. As I come across more, I’ll probably post a part two. You never know what people are going to do, after all …

Programmers don’t throw away code enough. When faced with a hunk of code someone else wrote, which doesn’t appear to be quite right, or is misbehaving, the proper action is to figure out what it’s supposed to do, and its interface, and then scrap it and start from scratch. (I’m not talking about rewriting whole programs here, just sections.) Instead, people try to handle the corner cases, or hunt down where the leak is. Just stop, think for a little while, get the structure well posed, then write that.

We were bit by this problem at OV recently. Instead of trashing pieces that were there in order to make them work, and writing them based on the original specification, we attempted to bend them into place in order to “save time”. Needless to say, that didn’t work out so well. Not only did we not save time, we used up too much.

Next time, I think it would be more appropriate to go with my gut feeling. Instead of trying to bend the immalleable, we should strive to replace the pieces. Sometimes code is just so bad that it’s not smart, safe, or sane to leave it in place.

I’m certainly losing my sanity, about now.

1. Hire at least one professional

This point is crucial and will save you a lot of time and money. If you have at least one person on your in-house staff who can walk the walk and talk the talk, you’ve got someone within your organization who can look over the work that’s being done. This is very important for a number of different reasons. First, you’ve hired this guy. You know what he can do, you’ve seen his work, you’ve talked to his references. He must have done something right in order to stand out from the pile of resumes you received for the position. Make sure this person knows everything there is to know about the project that’s being worked on. He needs to be the point of contact for the consultants, because he’ll immediately be able to tell you when something isn’t right. This person’s salary will pay for itself on numerous occasions, especially if you do a lot of outsourcing.

2. Ask Questions, Get Technical

This is another place where your professional is going to help out a lot, if you don’t know enough about the technology. If the company you’re working with shows any signs that they don’t know what they’re taking about, run. Fast. If you don’t, they’ll suck you in under the premise that they know exactly what they’re doing and waste your time and money while they get little to nothing actually accomplished. Which brings me to my next point …

3. Transparency

Transparency is a huge issue. At Omega Vortex, when our clients’ don’t come with their own infrastructure, we bring them into ours so that everybody’s productivity is increased. If our clients don’t have their own concept of source control, we’ll place their code in our repository. This is complimented by our build system which will produce nightlies of the work we’ve done and post it directly to a specified location on our development server. Once the project gets farther along, we’ll enable continuous integration so that each check-in gets reflected in our development copy. This way, the client can always be sure they’re looking at the most up-to-date code.

4. Look for value

Unlike some places, we’re not interested in taking your money, doing the work, and sending you on your way. We like to form lasting relationships so that you’ll consider doing business with us again or referring people you know who need work done. A way that we add value to our services is to help them in ways that we believe they need to be helped. Bad code is bad code, there’s no two ways about that. When we can, we don’t throw away everything and start over, though. To some degree, the code works, and that’s more progress than what we would have if we just started all over. What we don’t like is when our clients get burned and come to us with code that is littered with security vulnerabilities. I mean brain-dead obvious security vulnerabilities. Like, say … Taking data directly out of $_REQUEST and feeding it directly into a SQL Query. In cases like this, we like to do a very light security audit. This isn’t anything extensive, just something we use to identify the extremely obvious stuff, and bring it to the client’s attention.

5. References – Recommendations – Required

This is a huge one. This is hard for me to say, because we were new once too (we still kinda are), but taking a chance on a company with no references or recommendations from other people is dangerous. For Omega Vortex, I can provide you with professional references of people I’ve worked with in the past and know me and how I do things. We also have a few clients that have spoken highly of us. Just make sure you get references and recommendations from real people. Testimonials on websites can be faked. While they’re a decent way to tell what a company’s done at a glance, when you can you should talk to people who have worked with the company in the past. Ask the company to provide formal references. Remember, you’re about to spend what could be a good chunk of time and money with this company. Would you hire a random person for your company without references?

Hopefully, this list will help you make a more informed decision about the next company you decide to do a project with. Even if we’re not right for you, we certainly don’t want you picking someone else who’s even more wrong for you. While this is obviously tailored toward programming, I’m sure you could adapt this list some for other industries, too.

Take a look.