Haxwell.org

An Open Letter To My Future Employer

Hello Future Employer of Mine,

I want to speak to you honestly and frankly. I need to tell you about myself in greater detail than a resume could. I need you to know up front what kind of organization I can be my best in. I hope you do not take me to be conceited for writing this. Rather that I know what I need out of life, and that I am attempting to share my experience and reasoning with you in order to achieve it.

To put it bluntly, I’m 30 years old and have spent the past three to four years looking for a company I could excel in. I have come to the conclusion that the company I work for and I must think along the same lines. I’m getting old(er)! I really don’t have time to waste being unhappy in a job that I should love! I’d write software for free if I could still eat at the same time. I want to wake up each morning happy, excited even, to come to work. I want you to be happy to pay me a couple times a month, with both of us feeling like we got the good end of the deal.

Fortunately, I have had this experience before. You can look at my resume and see Mirim LLC. Mirim was my favorite job by far. We did things generally the way I am about to express to you in this letter, and we produced some awesome software, on schedule, at cost if not below, and had some fun in the meanwhile.

Unfortunately, since then I have been looking for another great team of people to work with. In that time, I have come across some terrific people, people with the desire to do great things, but it has been my experience that the organization and what it said was the way things must be done has hampered them. These ways invariably led to problems, frustration, and lower morale on the team.

I believe that a software team should operate efficiently, as efficiently as possible. An efficient team is one that places great importance on doing things the best way possible. I would not be happy in a job where things are done a certain way just because that’s the way things have always been done. There needs to be an atmosphere where anybody can bring up any issue they have and have it addressed by the team in a timely manner. The addressing of that issue may be to decide its not actually an issue, or at least not worthy of a change in process. It may be that we just cannot, or will not, do it at this time, and it will be revisited later if necessary. In whatever way it is finally decided upon, it should be seriously considered by the team.

I believe that if it can be demonstrated that a process is not efficient, it needs to change. I choose to be a developer for the experience of creating great software. You as my employer are in business to sell great software, or to otherwise make use of great software in your organization to make your sales of something else higher. We both want money out of this deal. We are in this as a team. If our team is not efficient, that means we are losing money, and that doesn't do anybody any good. If our process is not efficient, then what are we really doing? Now without taking too much more time on this, I understand that there are going to be differences in opinion as far as what is efficient. I am not always correct; I can take rejection. Open communication from all of my team members is all I really need. Communication is the key. If we can talk about the issue, we can come to an accurate understanding of it, and we can then determine an accurate and efficient solution.

I believe there is a way that you develop software. There are things you simply must do, or else you are doing it wrong. These things form a general description of how things should be done, that can be applied to any organization. When these methods are applied to an organization, it invariably leads to higher quality software, developed faster, developed cheaper, and with happier developers.

I am an object-oriented developer. That means that when I think of a problem, I think of it in objects. I think of it in the smallest pieces I can. Then I think about how I can put those small pieces together most efficiently in order to achieve a solution. When I code I think of the task at hand, designing a solution in my mind, determining how it can be accomplished with Object Oriented Principles. I try to make the most of Inheritance, Encapsulation, and Polymorphism. I need to work in a company that recognizes that the language is not the important part. Over many years, I have written code in Applesoft Basic, QBasic, Visual Basic, ACOS, 65C02 Assembly, RPG, C, C++, Java, and C#. After a while, it’s not the language that is important, it is the process in which you think. The language is simply a means to an end. Some languages are better than others depending on the end you are trying to get to. Also, the fact that you have not yet learned a language does not mean you are any less capable of using it to achieve the desired outcome. There is always going to be a newer, better, greater, more fantastical language coming up. I need an environment that looks at the thinking process used more so than the syntax used.

My thinking process is especially important to me when I am writing something from scratch. By keeping appropriate design tenets in mind when writing code, I find you produce code that will make your job easier later. It will be easier because it will be easier to understand, and easier to adapt to other purposes. If one designs their objects with the philosophy that an object (and in turn, the methods in the object) should do one thing, and only one thing very well, those objects can be used in many other situations, most that are probably inconceivable at the time the object is written. It is similar to a phone jack in the wall. When phone jacks were first invented, the only purpose was that a phone would plug into them. But today, you can have a fax machine, a modem, your Tivo, and hundreds of other devices that plug into that single object that does one thing very well.

Now that you’ve read a little about me, there are some concrete things I believe a team needs to have in order to be efficient, after, of course, computers. The team should make use of software specifically designed for

Given tools such as those above, the following are some of the actions that need to happen in order for a team to be efficient.

  • Focus on developing code rather than how to build the software.
  • Deliver a build of our codebase as it stands on any day, just as soon as it is requested. This is especially useful in determining if scheduled functionality is actually complete or behind schedule.
  • Flesh out build errors faster because no more than a working day will have gone by without someone noticing the build is broken.
  • Get donuts from the perpetrator on the day after someone breaks the build.
Depending on how often code is being checked in, it may not be necessary to build everyday. It may be sufficient to do a build once a week. I would not consider any time period less than once a week a product under active development.

Though not an exhaustive list, these are things that I consider very necessary in order for a team to be its most successful. Of course, there are going to be exceptions to some of these things, different things will apply to some organizations that won’t to others, and there will be other systems that can do just what I’ve described above. I don’t think it is critical that my ideas are the only ones that are followed, just that these things are important and I honestly need them or something like them in place to be my best.

As a final belief, I believe it is okay that you don’t do things this way. I believe it is okay for you to have whatever system you want. I only present these things as a list of attributes I will be looking for in an organization, or at least a willingness to address these concerns in some way. An organization with that willingness, meaning it was willing to look at its process and update it where necessary, not for my sake, but in order to do the best possible job, is what I am looking for. I am writing this letter to that organization. I want that organization to be my future employer.

Of course my contact information is all over this website. If you got this far, I hope you want to read my resume (word format here) too. If you represent the organization I have in mind, and have a need for someone like me on your team, I'd be ecstatic to hear from you.

Thanks for reading all of this!

Johnathan James

The Reader's Digest version of this letter is here.

0.493 seconds. Powered by WordPress
(c) 2001 - 2005 Johnathan James