A tale of two software career paths

Software can be the best of careers, it can be the worse of careers. It's up to you.

Path 1: Write sensibly-designed software, resilient to change, on a fast update loop. You aggressively squish bugs, of which you have fewer than do your peers because of your unit tests. You talk to people early and often. Work isn't killing you, so you have time to learn stuff--cool stuff that improves your designs, makes them more fault-tolerant or speeds your update loop. You can take on more responsibilities as your services take care of themselves and process is automated away. There's a lot more work up-front, but your tech improvements keep paying huge dividends. You have the option of decreasing your workload even as responsibilities increase. Increasing responsibilities increases your visibility, influence and rewards. You're a star individual contributor. What you do matters. You learn enough about corporate politics to magnify the influence you have from your technical prestige. You're good at that, but do you understand business? You have a nonzero risk of becoming part of The Problem at your company. If you're The Problem now, that's fine. You're a star IC, we're happy to have you.

Path 2: Continually accepting one-off shortcuts to deliver the task at hand. You deliver results fast, or you don't have to work as hard at the beginning, or you don't know how to squeeze in long-term improvements. You get into constant Fire Drill mode. Work is exhausting you. You don't have time to learn anything cool or try anything new. Extra responsibilities are punishments. You fear them. You're stuck working nights and weekends to keep your head above water for things that shouldn't be that tough. Your projects aren't important. You become very political to compensate for an inability to deliver. You're good at that, but do you understand technology? You have a nonzero risk of becoming part of The Problem at your company. If you're The Problem now, try again somewhere else and try to be more like that #1 guy.

A Litany of Do's

In response to one more Don't, presented here: http://ndsmcobserver.com/cm/2.682/viewpoint/what-not-to-do-to-make-a-lasting-relationship-1.2594645

A gentleman trying to bring himself up to be a good man in the Catholic faith is presented with a litany of don'ts regarding relationships: Don't have sex before marriage, don't pressure women for sex, don't hit on women at the gym (they're just trying to work out), don't bother girls who are studying at the library or LaFun, don't use alcohol as an excuse for unbecoming behavior, don't be too forward with a woman, don't disrespect a woman, don't date a friend's ex, don't try to date her before showing what a sensitive guy you are, don't risk ruining a friendship with a woman by dating her. Some of these don'ts are reasonable, some are a little neurotic, but in either case a good Catholic boy doesn't come across a single Do until he's discerned a vocation to marriage with a good Catholic girl.

As a Computer Engineering student, I was an angel when it concerned all of the Don'ts. I was led not into temptation by my choice of major. But this perfect record came at a cost of debilitating loneliness: What was the point of studying hard to make a nice living if current trends showed I wouldn't be building a family to share it with?

I looked everywhere for Dos from the Church regarding dating in a modern context and came up short. The closest I could find was the Theology of the Body, which saves its Dos for once you have a wife. Unless it's time to experiment by going up to LaFortune and asking young women if they would like to discern a vocation to marriage with me, there wasn't a lot there.

What about "do have confidence," "do be yourself"? That advice is 100% true. It's also 100% useless to the guys who need it most. What about "do have patience, the right person will come along when you least expect it"? That one is worse than useless. If every guy on the planet followed that advice we'd have an extinction of the species.

Frustrated to the point of jealousy of cultures with arranged marriages, I had to seek my Dos outside of the Church. I scoured the askmen.com dating advice column and bought an e-book called "The Art of Approaching Women" and received the first useful advice of my dating life. That was over four years ago. Today I'm a confident guy. I present the best version of myself to the world. I'm not afraid to take a risk to go after what I want. I now have what might be considered a "normal" dating life in 2011. Do I wish I had found the girl of my dreams and we agreed to marry at Notre Dame? Of course. Is that what I have now? No. Is what I have better than the crippling chronic loneliness of my college years? Infinitely so. Would I be in the same mess I was in if I had waited to get some Dos from the Church? Almost certainly.

Here are my Dos for good guys who can't get the girls (especially if they know they only need one woman):

• Do decide how you want to present yourself to the world
• Do present yourself to the world not only verbally, but with a strong posture, deep tone of voice and open body language
• Do pick out a cool hobby. Tons of cash and no love in your life? Nothing's sexier or cooler than flying airplanes, and getting your license only costs several thousand dollars!
• Do learn how to kiss a girl. Watch Hitch or something.
• Do expand your comfort zone by taking risks. Do realize that even the worst you're imagining really isn't that bad and that you're better at inventing ways for things to go terribly wrong than the Universe is at executing those tragedies.
• Do make sure your cell phone plan includes unlimited texting.
• Do have a plan for a date. Better yet, have a plan for this fun thing you're doing anyway but you'd really like it if this girl came too.
• Do learn to interpret ambiguous data in your favor. If you don't, who will? The fact that an interpretation is in your favor doesn't make it a false interpretation. This was a big one for me: I basically needed a girl to sign forms in triplicate before I would put her through the "inconvenience" of having me try to date her.
• Do get used to rejection. I know, it'll hurt the same every time, but getting rejected a lot will at least show you there are plenty of girls out there you would like to date.
• Do make decisions. The only wrong decision about where to eat for a dinner date is "I don't know, where do you want to go?" She doesn't want to go eat food. She wants to spend time with a man, and part of being a man is not getting hung up on trivial decisions.
• Do recognize that there are far more profound sexual differences than genitalia. Don't you wish that women could ask men out? Guess what? They can but they won't. Why? Because they're women, you're a man and it's your job to put yourself out there and risk that pain of rejection. Sexual equality is awesome. Pretensions to sexual sameness lead to travesties.
• Do learn to flirt. It's kind of similar to teasing. Think of her as a bratty little sister for a bit, see how that goes. We're all brothers and sisters in Christ, right?
• Do draw attention to sexual differences. This is why Barney Stinson wears suits. There's precious little in this world today that says "I'm a man, you're a woman" without being so base as whipping it out. And that's animalistic behavior unbecoming of higher beings such as ourselves. Animalistic whipping it out is for later.
• Do move your focus from attracting a specific woman to becoming more attractive to women generally. Then maybe you'll get the one you're after, maybe you won't, but how is that single-focus thing working for you now? Not so well? Thought so.
• Do experiment. You can't just sit back in an armchair and deduce what is going to attract women. You need to try stuff, see if it works, maybe try a few times but then ditch what isn't working and keep what is working. Start with that "would you like to discern a vocation to marriage with me?" line at LaFun. Maybe it works at Notre Dame, who knows? You'll know, after you try.
• Do realize that how you say things, especially on first meeting, is way more important than what you're actually saying. Do a thought experiment: Think of all the ways you can say, "Hi, I'm , how are you?" starting with the most awkward, botched deliveries and moving up to the most engaging, cool-as-a-cucumber stud-like deliveries. When people say the best pick-up line is "Hi," this is what they mean. For fun, try this experiment with cheesy pick-up lines, too ("Would you like to discern a vocation to marriage with me?").
• Do put on a clean shirt and stop farting. This is actually all you really need in order to get started, along with the willingness to experiment one. All else flows from this.
• Women have five basic senses. Do see that you can make yourself a delight to as many of them as you can. Bath, groom, learn to salsa and swing dance, invest in some timeless fashions and select and apply subtly a suitable cologne.
• Do have everything together in your life: grades/job, decent health, interests, a good character. This actually isn't a prerequisite for attracting women (I'm sure you can name many counterexamples), but it's a prerequisite for me to be interested in helping you. Those gorgeous girls with those loser guys who don't have it together, you want to rescue them, don't you? Get them with some guy who can take care of them and appreciate them like, say, you, right? Then you need to be that kind of guy.
• Do realize that even if you're getting advice on attracting women from sleazy PUAs, you don't have to be a sleazy PUA. Do look at what works for jerks and adopt what works without becoming a jerk. You're a smart guy, you can figure that out. By the way, sleazy PUAs will often tell you exactly the same thing and they have awesome advice because they've made experimenting with ways of attracting women their job.
• Do realize that in this day and age (outside of the Notre Dame campus), you *AS THE MAN* might have to put out. Boo-hoo, I know you're really upset that in order to find the woman of your dreams you might have to have sex. Do I wish I had met and married the woman of my dreams in school, that we saved ourselves for each other and that we lived happily ever after? Of course. Did that happen? No. Do I have friends who waited only get a nasty surprise in the bedroom post-nuptuals? Yes. Do I have friends who did it the night they met who went on to marry each other? Yes.
• Do realize that some of those Catholic Don'ts are good and valid, some are useless but benign, some are crippling.
• Don't become a scumbag now that you can all of a sudden attract women. First, you're capable of it, not super-awesome at it, so don't take any of them for granted. Second, being a scumbag to women makes it harder on decent, honest guys like who I thought you were, or at least who you used to be.

First solo cross-country debrief

190100Z, KRNT
Destination: KBVS via KPAE
Sky condition FEW at 4500, ceiling greater than 12,000. A beautiful day.
Cruising altitude: 2500 there, 3500 back.
Winds aloft calm and variable. Easiest WCA's ever.

I left work in time to meet my instructor Nyle as he was finishing up with his previous student's lesson. He reviewed my flight plan and endorsed me to fly. I had pre-flighted 639SP while he was finishing up with his student: 6 quarts of oil, gas tanks full to the brim, sumps as clear, blue, and avgas-smelly as ever, the drops from the sumps briefly appearing to bleach my thumbs where they touched via rapid drying.

It's a warm day, let's go for a hot start. It took a little extra cranking, but sure enough the engine started before I had a chance to try flooding the engine with the fuel pump. It's the Seattle area in the summertime, so everyone who's anyone who can fly an airplane based out of Renton is out there that day. The runup box has a single occupant when I reach it, leaving more than enough room for my own runup.

Traffic is the busiest I've seen at KRNT: after the runup, I'm third in line to take off from runway 34. Looks like I've got some time, might as well enter in the Paine VOR, the Skagit NDB and Seattle Approach. Then it's time to wait. And wait. I'm holding short at runway 34, and I probably waited for five minutes while other planes landed and performed touch and goes. No problem, it all counts on the Hobbs meter. The better to speed me towards my requisite 5 hours of solo cross-country time.

Finally it's my turn: Cessna 639SP, no delay, clear to take off Runway 34, make East Channel departure. My fingers have been poised over the landing light, strobes and mode-C transponder. Without delay, I snap them all on as I release the breaks and enter the runway. As I climb past pattern altitude past the East Channel I-90 bridge I note the time. I keep out of Seatac's keyhole-shaped bravo layer and turn towards the north end of Lake Washington. Don't need stinking headings for that. Not in calm but variable winds aloft and surface observations.

I request VFR flight following to Skagit while over Lake Washington. I dutifully enter my transponder code. Seattle approach soon hands me off to Seattle Center. I'm at 2500 feet and sauntering towards Paine Field's airspace at 110 KTAS. Getting closer. Closer. Closer. Where's my clearance? Closer. Paine's ceiling is 3100 feet. Closer. Time to turn right. 9SP, do I have clearance to enter Paine's airspace? No answer. Oh well. I circumnavigate the delta and note the time half way around. I was going to use the center of Paine Field as a waypoint, but this works too. Plus I get to log extra solo cross-country time. And it gives me time to think. What's my next heading going to be? Yeah, at this point I can just follow the GPS to Skagit, but I'd like to try to stick as close to my flight plan as possible. My first nav radio already tuned to Paine's VOR, I set the indicator for my KPAE - Port Susan heading (no wind, so my course matches my heading!). It takes a long time to get to my radial, but at last I'm there (and yes, the VOR properly reads FROM. Smart Alec).

**Edit: A friend of mine pointed out to me that if I'm on flight following with a squawk code, I should be clear to enter the airspace. I didn't know this at the time since on previous flights I'd received positive clearance to enter other airspaces.

Runway 10/28 is closed at Skagit, leaving runway 4/22. Surface observations suggest runway 22, and area traffic confirms this is the case. I overfly the runway, give friendly updates on my position to other planes and land. I take a few pictures on the ground to share later via Google+, text Nyle and call my Mom. Traffic has cleared out, so nothing slows my crosswind departure to the south from runway 22. I contact Whidbey Approach for flight following back to Renton.

Around Port Susan I'm handed back to Seattle Center. At 3500 feet I can just overfly Paine's airspace. I accidentally tune the wrong Seatac frequency. It's a little embarrassing, but I correct my radio and I'm back in business. When Seattle Approach hands me over to Renton they tell me to keep my squawk code but approve a frequency change to Renton's tower. Okay, whatever. I'd assume they'd have me squawk 1200, but I guess their way works too. Renton tower tells me to squawk VFR as I make my Factoria arrival. Told ya.

**Edit: Like the above correction, this may have been to signal I was clear to enter Renton's delta airspace. My foot is in my mouth a little bit right now, but you can believe me that with my knowledge at the time it made no sense.

I do a few Victory Laps in the Renton pattern. I hit the tail end of the air traffic as I enter the pattern and extend my first downwind for an inbound Piper Warrior on a long final for a straight-in. It's a fairly normal touch-and-go from there: flaps 10, 85 KIAS, 500 FPM descent, turn base way before 800' AGL because of the extended downwind, flaps 20, 75 KIAS, turn final, flaps 30, establish glide path, 65 KIAS, power idle when crossing the threshold, flare, hold it, hold it, hold it, gentle landing, flaps up, full throttle, add rudder, 55 KIAS, rotate, climb at Vy, 100', 200', 300', 40----BIRDS! BIRDS OVER THE RUNWAY! BIG FLOCK OF THEM!

So I turned left. I doubt the birds established 2-way communication with KRNT, but I wasn't going to be self-righteous about how that space over the runway was mine. I was going to turn left. I had little faith that the birds would obey right-of-way rules and break right and there was more space on that side. It's all about see-and-avoid. I'm now at 38.7 hours in my log book and I can't wait to finish. There's no finer hobby, if you can afford it (thanks, software industry!).

PICT documentation does exist!

I knew I saw it somewhere before.
Microsoft has a powerful tool for all-pairs testing called PICT. It can store models far more advanced than simply listing the equivalence classes available for each parameter, but the documentation is hard to find because it's buried in an MSDN article which also gives a great motivation (with data!) for pairwise testing in general.

Anyway, here's the link so you don't have to hunt any more (and if you're new to pairwise testing, you're in for a treat). Thanks, Jacek Czerwonka!

Pairwise motivation and PICT documentation:
http://msdn.microsoft.com/en-us/library/cc150619.aspx

Argumentum ad cerebrum

We know what ad hominem arguments are, and we don't like them. They hurt, they distract from the real issue and they are far closer to coercion than persuasion. The closest noble purpose of an ad hominem attack is to lower the audience's confidence in the speaker's judgement. But why lower the confidence of the speaker as a person? Why should the audience trust him less? Perhaps in some tirade, the speaker has expressed contradictory interpretations or opinions. Maybe he hasn't thought through all the issues at hand. I would like to think of calling the speaker on mutually contradictory positions an argument ad cerebrum.

This is different from an argument by contradiction, which shows that if several propositions widely held as true are true, the opponent's position must be false. In argumentum ad cerebrum, you show that two or more stances of your opponent are mutually contradicting, forcing him either to abandon the weak link in his chain (perhaps his most recent point) and lose a little credibility with the audience, or hang on to the contradiction at all costs and lose massive amounts of credibility with the audience. More importantly than the speaker's credibility, the entire tuple of ideas contrary to your own is at odds with the audience. They know now at least one must be wrong.

Not only is argumentum ad cerebrum more effective, it is more civil. A successful ad hominem attack leaves your opponent thought of not only as wrong, but as hateful, mean-spirited and unworthy of taking seriously or even human dignity. A successful ad cerebrum attack forces your opponent to yield a talking point, gives the audience another chance to think about the tuple of ideas under question and lets your opponent save face as a human being. Ad cerebrum attacks have nothing to do with the personal faults of your opponent, rather a weakness in the set of positions he holds. Personal faults are the bread and butter of ad hominem attacks.

Argumentum ad cerebrum isn't always available in a debate (though argumentum ad hominem almost certainly is), especially when both sides are well-prepared, mentally clear, intellectually honest and courageous to recognize unpopular consequences of their positions (do we debate issues when one side is bereft of unpopular consequences?). Don't force it if it isn't there, but if you're bristling at your opponent expounding on ideas that are not only different from yours but contradictory, it might be time for a dose of ad cerebrum.

Finally, let me note that I'm not a debater and I don't know Latin. Does this concept exist under another name (granting that it is distinct from argument by contradiction)? A Google search for "agrumentum ad cerebrum" yielded an energy blog, adcerebrum.com, but nothing about styles of argument. Let me know, learning is fun!

General Aviation-themed Stack Exchange Site

If you're a pilot and you don't know everything there is to know about flying, you should be interested. If you're a pilot and you do know everything there is to know about flying, you should still be interested!

General Aviation on StackExchange

You keep running that test...

First Solo Debrief

KRNT, 190130Z

Winds Calm, runway 16 in use, standard left pattern at 1000’ AGL east of the runway.

Ceiling: 5500 BRK, 7000 OVC, scattered light rain

AIRMETs: Mountain obscuration, moderate icing. Freezing level 2000 feet. No factor, I’m just in the pattern today.

Informal PIREP reported hail on final in the previous flight, so I called the briefer for an updated VFR area briefing for Renton Municipal with a focus on convective activity. We’re OK.

Fuel nearly full, 6 quarts of oil in Rainier Flight Service’s Cessna 172S N639SP.

Preflight: Inop strobe and taxi lights. A recent tail touch has me paying special attention to the rudder. Control surfaces are still scratched, but the damage is minor and the bent metal guard doesn’t inhibit the rudder’s range of motion. The airplane has had recent troubles with the flaps deciding to stay down when rolling on the runway during touch-and-goes, so I’ll pay special attention to make sure they do what I tell them to do.

The first three laps are with my instructor. The plane had just returned from another flight, so I tried a hot start. Crank, crank, crank, nothing. I guess the engine’s cooled down. Temperature 11 C, dew point -1. I prime the engine with a 3-second rich mixture. Now I’ve flooded the thing. My first flooded engine. My instructor just had me crank, but I knew what he was doing from common sense and studying the 172’s POH at the barber shop on Saturday: He’s having me crank with a low mixture and full throttle to get the intake back into a combustible condition, then swapping the mixture and throttle controls once the engine catches for a normal 1000 RPM idling speed on the tach. Mixture out 1” to taxi. Break check.

Altimeter 30.09. The wind has picked up and is now 190@4 KTS. 2 KT crosswind. 639SP requests taxi for close traffic with Papa. Cleared to taxi to runway 16 via Alpha. I goof a little on my turn up to the runup box and I’m almost in the taxiway for my mag/vac/alt check. Only the tower and my instructor are there for my goof. The engine is singing. Differential breaking with full right nosewheel and almost a half open throttle are needed to get my momentum going to taxi back to the taxiway centerline to hold short of runway 16.

We hold short for a 737 to land, then we’re cleared to take off. Throttle and right rudder come together in perfect harmony for a beautiful centerline ground roll. Airspeed stabilizes above 55 KIAS and I rotate, establishing Vy soon after. It’s perhaps my best takeoff. I do three laps with my instructor in the plane. Request stop-and-go, cleared. Once abeam my touch down point I bring the power back to 1500 rpm and prepare to lower the first 10 degrees of flaps. I turn base. The base and final turns at Renton are a little tricky since being straight over Lake Washington messes with your depth perception. I’ve overshot the centerline and need to line up. I’m a little fast and below glide path. Perfect—nose up and I’m back in business.

I have a natural bias to land flat. In my recent lessons I’ve started using a little power to counteract this, and I’ve gotten some wonderful landings out of it. It got addictive. It got the better of me. As we neared the approach end of runway 16, just off the shore of the lake, I was getting less and less happy with my approach. Time for a go-around. Full power, flaps 20, climb out, retracting flaps as appropriate.

To be sure I was nervous. Preparing for the solo I’d been rereading the Emergency Procedures section of the POH, reading AOPA articles about engine failure on climb-out and the “impossible turn,” thinking about what to do if I popped a main tire on touchdown or one of my brakes quit. It gets you a little nervous, thinking about all the ways your airplane might kill you before a solo.

Two more laps with the instructor. Once again I overshoot the runway centerline while turning final. I realize that I’m unconsciously pointing to the left as I start my landing procedure abeam the touchdown point, robbing me of valuable base leg length which I’d rather be using to establish 75 KIAS at a 500 fpm descent to get flaps down to 20 degrees. Back on centerline, I let myself land slightly flat. Stop-and-go.

Final lap with the instructor. This time I’ll beat that base leg. I stay just above the close edge of I-405 as I slow to 85 KIAS/500fpm descent/10 degrees flaps before making a crisp 30 degree standard-rate base turn. Without much hesitation, I turn final. Things are looking good. I fly a stabilized 65 KIAS centerline approach just below glide path, adding power to correct. I cross the threshold, close the throttle and flare…not as much as I could. I’m beginning to wonder what happened to those 20 wonderful landings I made last week. Nonetheless, my instructor thinks I’m ready. We taxi back to Rainier Flight Service and he endorses my log book for close-traffic solos. He adds a few of his personal minimums for students: 1500 foot ceiling, 8 miles visibility, maximum 8 KTS crosswind, prior permission required. The sun is going down, so he sends me out for two solo laps rather than the planned three. He calls the tower to let him know it’s my first solo, and the controller offers to stay late to assist, past the normal closing time of 8.

ATIS has switched to AWOS. Ceiling now 3000. Winds moving in. Engine start, lean the mixture 1” to taxi, run up (a much better runup turn), cleared to take off. I climb high, I climb fast. I defeat the base leg again and I’m on centerline. Tower calls the wind 060@8. Landing on Runway 16 means I’ve got just under an 8 KT crosswind. Too late now. Cleared touch-and-go. My left wheel touches first and I’m on the ground. I zig zag a little on the ground roll, turning more freely with less weight in the plane. Flaps up—yes, they went up. Back on the center line. Here I go again.

One last try. I got the centerline last time, now just add the right flare. My instructor wants the stall warning horn to go off a second before I touch down. Happy to oblige. I hold the aircraft off with the nose up as the mains caress the asphalt runway. My fourth landing and fifth approach of the night restore my belief that I was ready to solo tonight. I turn off at Foxtrot, thank the controller for staying a few minutes late and park the plane. Then I see it—for both of my solo landings, I left the mixture leaned out an inch rather than keeping it full rich. I have to laugh at myself. With all the bothering about flaps, transponders, landing lights, P-factor, tower communications, 30 degree banks, hugging 405 and flaring just right with the power cut, I forgot to enrich the mixture before requesting my takeoff clearance.

Live and learn. I’ve logged the first 20 minutes of the required 10 hours of solo flight required for my private pilot’s certificate. They’re the last .3 hours of my 19.2 hours logged to date. I look forward to completing this certificate, earning my instrument rating and building hours flying friends around and taking long trips to visit family in the Midwest, but for now I’m just enjoying the ride.

Fiction, fun and profit

A few months ago I realized I needed to read faster. I've always been an "A" student. I've shown my employers that I have the skills and wit they acquire. I needed to read faster because you can drown in the technical information available to people these days. The web is competing for the former juggernaut of time-sinks, television. What's more insidious is that the web surfer always has cause to surf further in the name of learning something edifying or useful to his job. I don't know anyone who complains that he can't find "anything good on the internet" the way people would gripe about there being nothing on TV.

With a strong and growing career in software engineering and a new hobby of aviation, I picked up the book 10 Days to Faster Reading, published by the Princeton Press. It's been a great investment, both of the paltry monetary sum and the 10 days themselves. The book mentions the physiology of reading, how our eyes make short stops when scanning across a page, how you can practice grabbing more words per eye movement and such.

What I realized was that technical science and math textbooks can train you to be a slower reader. Math books in particular are very dense, forcing the reader to savor each word, grok each sentence and appreciate each subtlety before moving on. But most of what we read isn't that dense. This extra redundancy allows readers to skip entire sections which may not apply or read passages quickly, confident that the important information will likely resurface soon. If you studied too hard in math, though, you may be carrying your habits over to non-technical works and slowing yourself down unnecessarily.

My solution? Read more novels. There are plenty of other reasons you would want to read novels as an engineer, but start with this one if you haven't picked up any pleasure reading in a while. Having an interesting plot and characters to look forward to can accelerate your engagement and your pace of reading. It just might train you out of reading each sentence like a mathematical equation.

*Note: 10 Days to Faster Reading notes that pleasure reading should just be done at your own pace. After all, it's for pleasure. While that's true, reading faster doesn't mean you miss much. I remember knocking back entire Goosebumps books in between 30 and 60 minutes as a kid, and I didn't enjoy them any less for the speed.

How Thinking Small Matters to your Success

At a certain size of team, success for the individual contributor means moving to a smaller team. Larger teams tend to support safer ventures while crowding out opportunities for meaningful contribution. If you feel unnecessary, or if you want more control over your work, maybe your team is just too big. You can solve two birds with one stone by switching teams. There are definitely places that could use you.

Speaking of which, the Amazon payments organization is hiring. See what you think: http://payments-jobs.amazon.com

6 Myths about Test Code

I cringe whenever I hear the phrase "it's just test code." Usually the speaker is implying that the code doesn't need to have well-named variables, doesn't need modularity, doesn't need clarity of thought and that copy-pasta is just fine. Automation code certainly differs from production code, but not at the expense of code quality.

Myth #1: Copying and Pasting can help write test code faster
I see this all the time from SDET contractors. They don't tend to get renewed. In a rush to get something out the door and point to a massive checkin as evidence of their developer prowess, they paste the same changes over and over again.
Fact: Copy-pasta doesn't help any code get out the door faster. Copying and pasting is a way to generate needless work in the future. Every time you paste what should have been the body of a method, you're multiplying the scenarios which will be out-of-date when it comes time for the next design change. Put it in a method body and just let everyone sleep easier at night. TestNG even allows you to parameterize your test cases.

Myth #2: Magic Numbers can help you write tests faster
Fact: Now that you've seen the statement in print, you immediately recognize it as absurd. Test code will constantly tempt you to hard-code magic data: retry timeouts, manually-created test orders, test account login information. Your task is to refuse such temptations. If your code can't create everything it needs to run at runtime, you'll wind up with dependencies on your environment or some configuration. Your tests become tightly coupled to the instance of the system they are testing against. If there is some common configuration data you need to reference, take a look at Spring or Java Beans (if you're testing Java code) as a convenient means to store common data.

Myth #3: Using try/catch blocks for flow control is OK in test code
Try/catch blocks are for error handling, and error handling alone. There's one situation that might tempt you to use a try/catch block in test code: Checking for expected exceptions. This is another area where TestNG shines. We've all seen the pattern:
public void throwsExceptionOnError() {
    try {
        makeErrorHappen();
        Assert.fail("We should have thrown an Exception");
    } catch(Exception e) {
        // Pass!
    }
}

Now: Go through your automation code base. How often have the authors omitted the unconditional Assert.fail() after your version of makeErrorHappen()? You're probably masking at least 1 or 2 bugs that you were never catching to begin with. Compare this with another great feature of TestNG: expectedExceptions and expectedExceptionMessageRegex. Now your test can look like this:
@Test(expectedExceptions = Exception.class)
public void throwsExceptionOnError() throws Exception {
    makeErrorHappen();
}

No spaghetti logic, no false passing when no exception is thrown. Check your test harness for its version of TestNG's expectedException feature. You owe it to your customers.

Myth 4: Using try/catch blocks for anything in your test methods is optimal
Fact: You've been tempted to use try/catches in exactly two circumstances:

1. Verifying expected exceptions
2. Handling unexpected states during your tests

Case 1 should be dealt with as in Myth #3 above. As for case 2, unexpected states during tests should lead to a test failure. Something went wrong, and your test didn't know about it! Either your tests are out-of-date or you just found a bug! Don't try to get the method to pass at all costs: just let the exception bubble up and fail the test. What's that? It's an intermittent timing issue? You're using exceptions to handle retry logic? Look into your test harness's version of TestNG's RetryAnalyzer. Don't write retry logic into every test you may want to retry. The work is tedious, you'll miss a detail, and even if you do it right you'll have a lot of needlessly repeated logic that will clutter your automation and obfuscate what you're really trying to test.

Myth #5: Logging to the console gives back important data about a test run
Fact: I'm running hundreds to thousands of tests every time you check in, and I'm only watching assert and exception messages from failed cases. I don't care what you logged to System.out, and I'm not going to read it. In fact, I can't read it. It's gone now. Well, I suppose I could run the tests again and redirect the output to a text file. Wait, this suite takes 15 minutes to run and the issue only appears 20% of the time.

Myth #6: Rerunning the failed tests in a suite until everything passes is acceptable
Fact: This obscures the very nature of software testing. Software Testing can NEVER tell you that everything's all right; it can only do its damnedest to break your code. Why give up that perfectly beautiful failure with a rerun? If the tests can't all pass at once, there's either a problem with your tests or a problem with your code, and it's your job to find out which one it is. It's also your job to make sure that your regression suite can pass with a single button press, or else you're passing off too large an inner loop to the product team.

Where does test code differ from production code?
The mission of every automated test is to fail. Test cases store knowledge about how your system works and demands it should be able to answer. Test code is different because of this mission, and it's different because test harnesses take care of a lot of the common reporting work of automated tests.

• Test methods can throw checked exceptions. Make it a habit to just add the "throws Exception" clause at the start of your test methods (if you're working in Java)
• Test methods handle errors by reporting them, not recovering from them. The system may have to recover, but your tests need to fail. A lot of the boilerplate logic of what expected/actual values were is taken care of by the suite of Assert methods you'll find with any testing framework worth its salt. In addition, the test harness knows to run every test, even if some fail. And it knows that you'll want the failure output, so expect that in the test reports.

Good code quality practices matter just as much to SDETs as they do to SDEs. They matter to anyone who writes code that may need to change in the future. The differences that exist exist because of what test harnesses do to help, not because test code is less worthy of maintainability. Think about that the next time that tiny, evil voice in your head whispers seductively, "it's only test code...Ctrl+V...."