Jay Harris is Cpt. LoadTest

If there is one thing that I have learned throughout my career, it is that I need to do what I do because I love it. I need to do what I do for me. There can be no other reason: not because someone else wants me to do it, nor because of recognition from another person or organization, nor for the money or the stature. Wherever direction I take in my career, it must be because of my passion for the craft and my drive to improve. Awards, money, and fame are all welcome side-effects that let me know that others like what I do and think I do it well—this recognition is still rewarding, and even more so, is an essential component to self-improvement—but that is all for naught if I don't like what I am doing or I don't think I am doing it well. Awards, money, and fame should purely serve as feedback, and not as motivation.

I first got into computers because I wanted to see how they worked. My mother bought the family's first computer while I was in high school, and I ran all of the little programs that inexperienced users are never supposed to run. I ran them simply because I wanted to see what they did, what purpose they served, and what would happen if they were run by a novice user like I was at the time. I didn't stay a novice for long, and I became quite adept at fixing broken systems, including everyone's favorite command: format c:. I had to; it was the family computer, and if I broke it, I had to fix it quickly or suffer the consequences.

Soon, the door to programming was opened to me, and an entirely new frontier was available for me to explore. With a shiny new copy of Visual Basic 3, I now had an opportunity to write my own programs to learn and manipulate that computer to an even greater degree. Now instead of black box programs doing bad things for unexplained reasons, I had the opportunity to create my own evil-doings. Whether it was creating sprite-based side-scrolling video games to blow up baddies or an investigation into "I wonder what this module does," the opportunities—and the imagination—were endless. Memory management and boot configurations for optimizing frame rates in Doom transformed into a passion for performance optimization of enterprise-level applications. Finding better ways to mail-bomb friends' AOL accounts without getting banned led to an obsession for managing resources outside of immediate control. And those awful GeoCities and Tripod sites filled with animated lava lamps and blinking text instilled both a drive for a better user experience and a need to expertly manipulate the search engines in my favor; I wanted users to find my little flag in the internet sand and to enjoy their stay once they arrived.

But somewhere along the path, I lost my way.

I don't know how it happened, but it did. I lost my focus on pursuing the craft for me, and was guided by external influences. I experienced burn out, an inability to engage, and a complete lack of drive for what I had grown up doing. My passion was gone. Blogging became more about keeping a schedule than it was about learning new things. Community involvement became more about the pursuit of recognition than it was about giving back to the community from which I had learned so much. Development became a chore rather than a thrill. Work became…well…work.

Last summer was my epiphany. I was one of the development leads for a client that I was working with, and my fellow leads and I were interviewing candidates for a development opening. Endless weeks of candidate after candidate left me feeling very uninspired. One night I came home and was discussing with my wife that I just wished one candidate—just one—was truly passionate about their craft; they would get my vote right away. I remember saying "I can teach them to code, but I can't teach them to want to code." And I remember that sinking feeling when I realized that I was describing myself, too. I was the uninspired developer.

I wouldn't hire me.

Since that time, I've been slowly re-energizing. I eased off of community involvement, my speaking engagements, my writing, and my pursuit of technology. I needed to assess my entire plate, and identify what I was doing for Me and what I was doing for Them. The items for Me were the only items that were kept. These Items For Me were the only items that could be kept, else it was a futile exercise and I would never reclaim my passion for my craft. It has taken a long time to process everything, to figure out what I loved and what I didn't, what was important and what wasn't, and above all how my passion stems from executing the plan with people and not for people.

Executing the plan with people, and not for people.

Early on in this process, I was working late at a client one night and a developer that I highly respect spoke simply over the cube wall, "it's good to have you back in the game, Jay." I had a long way to go on the new path, but at least I knew it was the right one. I wish that I could tell you how I did it, how I rediscovered my passion, but I think it would only dilute the message that it happened in the first place. You have your own thing, your own love, your own approach, and your own nuances. But you also already know each of those intimately, and you have either already found that passion, or are ignoring it in favor of what's easy, what's comfortable, what is expected of you, or worse, what has always been.

I challenge each of you to find your own passion. Pursue it. Realize it. Live it. Thirteen colonies proclaimed to the world that everyone has the right to pursue happiness, but do not confuse this with an entitlement to actually be happy; that part is entirely on you. Your right—your responsibility—is to go after it. Or as the Great Morpheus put it, "I can only show you the door. You're the one that has to walk through it."

Pursue your happiness. You already know what that thing is, and you already know how to do it. The only person not allowing you to be happy is you. So stop working against yourself, and walk through the door.

Knock, knock, Neo.

1. Access Word Options
   Access Word Options by clicking the Office Button in Microsoft Word (the Office logo in the top-left corner of the window), and click on the Word Options button in the lower-right corner of the menu popup. The Word Options window should display.
2. Access Proofing Settings
   In the Word Options window, access proofing settings by clicking Proofing on the left-side navigation.
3. Access Grammar Settings
   Once you are in Proofing settings, you will find Grammar Settings by clicking the Settings... button next to Writing Style. Writing Style can be found under the Proofing section titled When correcting spelling and grammar in Word.
   
4. Use Only One Space
   In the Grammar Settings window, the number of spaces after a period is controlled by the option titled Spaces required between sentences. This is set to don't check by default, but options for 1 space and 2 spaces are available. Set this option to 1.
5. Include a Comma Before the Last Item
   Also in the Grammar Settings window, check for commas after and and or through the field titled Comma required before last list item. This is also set to don't check by default, though always and never are available options. Set this option to always.

At the devLink Technical Conference, one of the Open Spaces focused on Computer Science curriculum at universities, and what things that the developer community would CRUD on the CompSci tradition. Though I did not have opportunity to participate in the discussion—I was facilitating an Open Space on Continuous Integration, next door—I do have one proposal: "Writing." For Computer Scientists—a traditionally introverted and communication-challenged group—programming in English (substitute with your native language) should be paramount. Communicating to humans is part of our job description, and we must be able to do so effectively and using their language, whether it be for status updates, business justifications, SOWs, proposals, or just another email. Developers need to communicate effectively; write well rather than write good. We must be right like a writer.

We programmers should write like we code. The written word should be concise, to the point, just like code. Coders do not frivolously use fancy namespaces and complicated classes so that their code looks smart, as it has the opposite effect by resulting in bloated, inefficient, unmaintainable systems. Big words implemented frivolously for the sake of sounding smart perform the opposite function, and likewise result in bloated, inefficient, unmaintanable text. We avoid power robbers in our code, such as using string builders rather than underperforming string concatenations, and should avoid similar performance kills in our writing. Additionally, using the wrong keyword in code, or misusing grammatical marks in our code, results in compiler errors or runtime errors. The written word—a language void of any compiler benefits—throws runtime exceptions on execution when it is improperly authored, much like JavaScript or XSL.

“Vigorous writing is concise. A sentence should contain no unnecessary words, a paragraph no unnecessary sentences, for the same reason that a drawing should have no unnecessary lines and a machine no unnecessary parts. This requires not that the writer make all sentences short or avoid all detail and treat subjects only in outline, but that every word tell.” — William Strunk

But like a programming language, English is simply a matter of keywords and laws. We must learn the rules of the system; we must learn its syntax; we must learn how to test and validate our code before shipping it off to a client or to production. Approaching the English language like we approach a programming language would also provide an effective learning mechanism for us developer-types. This would make an effective course at university: "Writing : For Programmers." Learn English like we learn any other language—approach it using our virtues—as what works for us may not be the same path that works for an English major.

Throughout my career, I have noticed a few areas that are typically mis-coded. I have included a few items below that every developer should be aware of to help learn English's keywords, its laws, and to provide opportunities to improve end-user experience.

Knowing the Language at an Elementary Level

1. Homonyms : words that sound the same but can mean different things. This is often a challenge for people new to English, but even veterans get confused. Everyone should learn the difference, and make proper use a habit. And proof read, as spell check will not catch misuse of homonyms. This applies to:
• Their / There / They're
• To / Too / Two
• Your / You're
• Its / It's
• Hear / Here
• Threw / Through
• Write / Right
  
2. Irregardless is not a word.
3. Who vs. Whom : Who, the subject, is doing the acting, and whom, the object, is being acted upon. The shortcut is to use who and whom as you would he and him. (Remember that him and whom both end in "m".) <Who did what to whom for how many jellybeans? He did that to him for five jellybeans.>
4. Me vs. I : Follow the same rules as for who vs. whom, above. The subject is doing the acting, and the object is being acted upon. Subject pronouns are I, he, she, we, they, and who. Object pronouns are me, him, her, us, them, and whom. <Sally gave me five dollars. I used to money to buy lunch.>
5. Than vs. Then : A comparison (than) vs. a measure of time (then). In code, than is used when describing a comparison operator; the '>' operator is a greater-than operator. In code, time sequences are an if...then statement. <Apples are better than oranges. I will eat my apple first, then I will eat my orange.>
   

Knowing the Language at a High School Level

1. Power Robbers : Never use due to the fact that. It weakens your sentence. Use because.
2. Contractions : In formal writing (e.g. Proposals, SOWs), avoid contractions. Contractions are for casual writing. Think along the lines of a Debug Build versus a Release Build.
3. Simply & Obviously : Avoid using simply and obviously as it may be both to you, but neither to your audience. If it was simple or obvious, then you didn't need to write it.
4. Use one space after a sentence, not two. A PC is not a typewriter. On a typewriter, with fixed-width fonts, two spaces are preferred, but on a PC, True Type fonts will properly space "<dot><space>" for you. Don't believe me? Open up any book and look at the spaces between sentences. Microsoft Word has an option to indicate this for you under grammar preferences.
5. Effect vs. Affect : Effect is the result, affect is the action. Noun and verb. <Poor engine performance is the effect of ignored maintenance. Ignoring maintenance affects engine performance.>
   

Knowing the Language at a Collegiate Level

1. Lists : Just like when defining an array, use a comma after every item in a list except the last. This includes before "and." <I like red, white, and blue.>
2. i.e. vs. e.g. : The first is in other words and the second is for example, though this does not do much for clarity. Essentially, i.e. is a complete, clarifying list, while e.g. is an incomplete list of examples. <I watch the three stooges (i.e., Larry, Curly, and Moe). I like all four-player card games (e.g., Euchre, Spades, and Hearts).>
3. Semicolons : Semicolons are used to separate two independent yet related clauses that could be broken into separate sentences. <The water is very hot; I hope I don't burn myself.> Also, use semicolons to separate items in a list where the items contain commas. <When the cards were dealt, Jack had a straight; Sally had two nines, two fives, and a queen; and George had a full house.>
   

Be mindful of your native language. It is the one you use the most, even more than C#, or Ruby, or Java. If you don't already own a copy, pick up The Elements of Style by Strunk & White; if you do own a copy, either have it at your desk so you can use it, or give it to someone who will. Effectively communicating with humans, using their rules, will help you have better testing, better design, better requirements, and have a better job. Become an effective English developer, and it will help you be a more effective developer, overall.

A question was posed on LinkedIn asking readers if they used Twitter, and if so, how and why? Because of the impact that Twitter has had on my life, I felt compelled to answer.

Twitter is a phenomenal tool that I feel should be included in any developer's toolset. I use Twitter for both business and personal reasons, including socializing with friends, scheduling lunch, and also for networking with business associates. There is a lot of value in having a consolidated service through which I can plan both happy hour and a business meeting. I have also made many new business contacts through the service, and the personal nature of Twitter communications have created relationships that are much more solid than those from other services, such as LinkedIn. When I travel to a conference such as devLink or Codestock, I often meet these twitter contacts for the first time, yet the bond that has matured on Twitter makes it seem like we have been friends for a long time.

In addition to networking, Twitter is effective with asking questions and getting quick responses (similar to what was on LinkedIn), or for driving traffic to my blog by promoting when there is a new post.

I access Twitter four different ways: through Witty on my primary computer, directly through the web when not at my primary computer, through Twitterific on my iPod Touch, or through SMS on my phone. The possibilities allow me to stay connected wherever I go. I have a presence on many of the social networks, too, such a Pownce, Jaiku, and Identi.ca, but I rely on Twitter. I can't live without it.

Do you Twitter? How do you use Twitter? How has it had an impact on you?

Everyone is always seeking the old cliché, “a bigger piece of the pie.” I propose a new cliché, penned by a colleague, Dennis Burton: “Make the pie bigger.”

In my experiences and interactions with other people, when someone gets a bigger piece of the pie it is usually at the expense of the person that used to have that portion. A simple Google for “bigger piece of the pie” returns a slew of articles about somebody who is miffed because their buddy is getting a larger percentage that they are, or the buddy is miffed because somebody stole their piece. I say, “Make the pie bigger.” When the pie gets bigger, so does your piece of it.

Our company has a revenue sharing bonus at the end of every year. Anyone who has been with the company for three years evenly splits up 1% of the total revenue for the year. For 2006, roughly 20 people will be eligible for that bonus. Hypothetically, let’s say we made $10m in total revenue this year; that means I get a nice check in January for $5,000.

$10m x 1% / 20 people = $5,000.00/person

I could just seek a bigger piece of the pie, off Dennis, and I would get another $263! However, depending on what I did, Dennis is miffed because he lost his job or his wife his miffed because Dennis is dead.

$10m x 1% / 19 people = $5,263.16/person

But, what if I instead try to make the pie bigger? Let’s say some recruiter at “XYZ Placement Services” called me up trying to give me a job, and I refer the head-hunter to our head recruiting guy. Soon, we have a new Corporate-to-Corporate deal with “XYZ Placement Services,” helping them fill job openings, and suddenly we are an $11m company. I gross another $500, which is $237 more than if I off’ed Dennis. Dennis, his wife, and the other 18 eligible people are happy because they also gross another $500, and to top it all off, my boss is thrilled because I just brought in another cool million, so he gives me a raise!

$11m x 1% / 20 people = $5,500.00/person

So, do not be concerned with getting a bigger piece of the pie. Change your focus to making the pie bigger; it will make everyone else happy, too, and you might just get a raise in the end. And, if you are the boss, provide incentives for making the pie bigger, like revenue or profit sharing bonuses; you will look better, too, when your team is contributing to the bottom-line of the company.

Steve Yegge blogged an interesting article, yesterday, on (Not) Managing Software Developers. I feel that it is a very interesting article, and definitely worth a read. I agree with most of it, though I do warn you that it should be read with an open mind to prevent feeling “slighted” if you are the managing type.

As the title proclaims, he covers how to (not) manage your developers, advising managing types to be open to new processes and practices, be reflective in a quest for constant self-improvement, and above all to be empathetic–developers are people, too. As his posts often are, his pessimism starts at “We are all bad managers!” to aid in his self-improvement quest, forcing an ego-driven drive to improvement. Again, this is not for everyone, as he already has a few flames in his comments, though perhaps if you are on the flaming side, you may most benefit from his words; everyone should pursue self-improvement if for only to improve their craft.

One modification that I would make is that this is not just for managers. It applies to everyone on the quality assurance team, too. (I am sure it applies to everyone, everywhere, but I only speak of what I know.) We all-to-often attack our developers–even if unintentionally, and if only from their point of view–over bug-ridden code and underperforming applications. Steve’s advice will help everyone have a better understanding of everyone else. Empathy is all too uncommon in our world.

I remember a day in my past when my project manager approached me, relaying a client request. This client always received a copy of the test cases we used when testing the application, and their request involved modifying our practices regarding case creation. Through this request—and you know how client ‘requests’ go—the client was convinced that we would be more efficient and better testers.

Fortunately I was able to convince my project manager that it was not a good idea, or at least “not a good idea right now.”
We relayed that we appreciated any suggestions to improve our process, but “would not be implementing this suggestion at this time.”

I am constantly looking for ways to improve my craft, and have received many quality suggestions from clients in a similar form to “Our testing department does [this]. You should take a look at it, and see you can benefit from it.” Suggestions carry the mood of “If you implement it, great. If you don’t, that’s great, too.” However, be weary of ‘missions from God’ to change your practices. The client’s plan may be driven by budget, promoting inferior methods that will save a few dollars. They may be based on their own practices that are less refined or matured than your own, also resulting in inferior methods. Finally, changing your practices mid-stream in a project—as many adopted “client requests” manifest—will disrupt flow, causing less quality over-all.

Your client is in the business of making whozigadgets. You trust that they know what they are doing, and know far better than you how to do it. You are in the business of testing. Likewise, your client should trust that you are the subject matter expert in your field.

I’m not advocating that all clients don’t know anything about what you do, and that everything they say about your craft should be blown off. All qualifying* suggestions should be thoroughly considered and evaluated; that’s good business. Perhaps there is a place in your organization for the process change, and that it would make you more efficient at what it is you do. However, I am advocating that you should not take a gung-ho attitude to please the client in any way possible, and implement every process change they utter; that’s suicide. Your testing team will turn in to a confused, ad-hoc organization. Your quality—and with it, your reputation—will crumble.

* Qualifying Suggestion: Any suggestion that is reasonable, intelligent, and well-thought. i.e. Do not abandon all QA to save costs, and rely on the client’s internal testing to find all bugs.

As Lead QA, I have the fun responsibility of screening resumes and conducting phone interviews. I weed out the hackers from the script kiddies before we bring them in to face the firing squad. It never fails to amaze me how people embellish their resume beyond reasonable limits. I am particularly fond of people that list skills they can not define, and of people who don’t proof read their resume when applying for a detail-oriented position.

As I run through my stack of paper I came across one unfortunate soul that did both. I was quite amused in a genuinely entertained sense. He proclaimed is proficiency in ‘Quick Teat Professional 8.0′, presumably an application through which you can automate cow milking, complete with data drivers and checkpoints. “OK. So he missed the ’s’ and didn’t catch it. So what?” Well, he also bolded the misspelling, perhaps to point out his attentiveness. This was only slightly before listing its usage in 2003 for a former employer that he also misspelled. (Note: QTP v8.0 was not available until the summer of 2004.)

However, and forgivably, my recruiter is not aware of such things and had already scheduled a phone interview for me and my entertaining candidate; I honored the call, giving the prospective a chance at redemption.

He failed.

Question number two asks the candidate to list the types of testing with which s/he has experience. This reply included integration testing (also stated in his resume, correctly spelled). My follow-up asked him to define integration testing; a common ploy to make sure I’m not just being fed buzz-words. It was a definition he could not supply, or even attempt.

A candidate should be able to define every ‘word’ he claims experience with. If you can not define it you obviously do not have enough experience in it to make it applicable. If you can not define ‘integration testing’, I will not hold it against you providing you do not list experience in it. Similarly, if you do not list it, and I ask you what you know about it, be straight; tell me straight-up that you cannot define it. You will rate higher in my book than someone who stumbles through an obviously concocted and blatantly incorrect response.

BTW, if you are looking for a position as a quality analyst, and can work in the Brighton, Michigan area, drop me a line and a resume. I would be happy to hear from you. Ability to define ‘integration testing’ a plus.

Fictional scenario: Trek–Lance Armstrong’s bicycle sponsor–is behind schedule and over-budget on creating a new cycle. They need to find a way to get their product out the door, find it now, and find it cheap. Now, imagine that they threw my grandmother on their bike, had her drive it around the block, and declared it fully tested and ready for mass-production. Would you be satisfied? If it found 300 grandmothers and had them drive around the block twice, would that satisfy you? How about if they used 300 average Joes? Would that satisfy Lance Armstrong? Would he have full confidence in his ride for twenty-one days and over 3,500 km in the tour? I doubt it. That bike wouldn’t even make it out of the warehouse, let alone to the starting line. That bike would not earn respect until it was rigorously tested in a scenario that at least simulates its intended use. So why do so many fail to put their web applications through the same trials?

Money? It will cost more money to fix it after launch than it will to test it during development, identify the issues early, and get them fixed before the product goes out the door.

Time? Well, time is money, so see above.

Experience? There are a lot of good, quality testers out there. If my mechanic doesn’t properly fix my car, I’ll take my car to a different mechanic.

I’m curious about the thoughts of everyone out there.

It’s not all about Internet Explorer any more. Yet, I am surprised at the number of web houses still coding specifically to IE. Much to my dismay, even my own company does it. Though we have a little bit of an excuse—our client only supports IE in their organization, and the app is internal—it still bothers me that we are abandoning everyone else.

New figures released a week ago place IE’s market share at 89%. That means more than 1 in 10 users are not using IE. (Read the Article) By coding specific to Microsoft, you are abandoning 11% of your potential users. That is astonishing and disturbing.

Pay particular attention to Firefox. Its user-base is growing exponentially, and doubling every 9 months. I’m a fan of the application. It is much easier to use than IE, and much more solid. I’ve converted all of my friends and almost all of my family. I even have my in-laws using Firefox. (Get Firefox)

As the IE behemoth continues to fall, you and your organization should be paying more and more attention to standards and multiple-browser testing. Check that your HTML is compliant, and test your sites in at least IE and Firefox, if not others. Don’t force your users to use a particular browser; chances are that if they can, they will just go somewhere else for their information.