Haxwell.org

Readers Digest Version of An Open Letter To My Future Employer.

Hello Future Employer Of Mine,

I want to speak to you honestly and frankly. I hope that by writing this letter I can let you know up front what kind of environment I believe is a great place to work in. I hope I do not appear conceited. I do not write this to say my way is the best or only way. But if you have these things in place, or something else to address the problems they circumvent, I would enjoy working there. You would enjoy having me there. I have no doubt that we would be able to do some great things together.

I have been writing software all my life because I love doing it. More specifically, I love doing it on a team that prides themselves on doing it well. Unfortunately, in the past three to four years, I have been working at places where it was not done well. I have come into each of these teams with the same hope that it will be (or become) an environment I can love. But invariably, I end up on a team that is writing buggy software too fast, without a true sense of direction, planning or purpose. These are not ignorant or naive people that I have worked with. They see the same problems I do. But because the organization doesn't see the need to seriously address the issues, they continue to exist. Time is never taken to step back, improve the process, and do better next time. Creating a great piece of software is not the goal.

In order to succeed, I believe a team needs software that specifically handles the following tasks:

• Design
• Development
• Defect and enhancement tracking.
  
• Source code control (i.e., a source repository like SourceSafe, Dimensions or CVS)
• Testing
• Code documentation
• Team collaboration

Using those tools, there are some actions that need to happen in order for a team to be efficient.

• Product Management should schedule firm releases dates.
• Product Management should determine the features of each release before the development on that release begins.
• Product Management should have firm, complete, written requirements for features to be developed.
• Development should build the code in its entirety on a daily basis.
• The team should consider each build a different version of the software.
• Development should mark the code in the source repository each time a build is done.
• Quality Assurance (QA) should test all of the code at one time, at regular intervals.

I know from experience that most places do not use all the above tools or actions in their team. But I also know from experience that these are important things to have on a team. Its not all about a software philosophy, I recognize that software is created in order to solve some business need. That need usually comes down to money. But I guarantee that a team that is doing the above things is generating better quality software at a lower cost than a team suffering from the mistakes destined to occur by not following them. I'd bet a paycheck.

This is by no means an exhaustive list. But I hope it gives you a picture of what would be a great place to get work done in. If you are interested in a developer like me, please read my resume (word format). I would love to hear from you.

Thanks!

Johnathan James

---

You might want to read the full version of this letter here.