But herein lies the rub. In this era of ubiquitous opportunity available through the Internet, open source tools, and low-cost educational versions of development software, I find it difficult to take a candidate seriously when he has not taken the initiative to develop anything outside a classroom assignment.

One of our senior developers offered a few .NET technical questions to add to the interview script, but when candidates were mute after the question, "How to you implement exception handling in .NET?” I knew we were in trouble. No need to ask about the assembly cache.

Previous discussions on d.* centered on an article about only hiring the best. "The best," we might agree, is a relative and somewhat subjective characterization, but I believe we can also agree there aren't enough of the best to go around, nor can every organization afford to pay what the best demand.

But I hope that developers realize this: When you are called to an interview, the hiring manager is desperately hoping you will be the one. Most of the time being "the best" means you have to be "good enough" or better than the others, differentiating yourself from others who may have a degree just like you.

I get the feeling that many of our applicants feel they just need a break, a chance. Some are working outside the field in jobs just to pay the bills. I understand that, but if you aren't interested enough in the profession to build a website for a friend's business or develop a game or an application for fun, just to prove what you can do, will you magically develop a drive *after* you get the job? Heck, when the job you’re applying for clearly states it is .NET centric, wouldn't it at least be worth the trouble to do a little reading on .NET before the interview?

I can still remember an interview that I botched many years ago. At the time I was confused about it, but now I understand completely. A large hospital was hiring numerous positions in several different areas of IT as they beefed up their department. I seem to remember the question went something like this: "Do you see yourself as more of a developer or maintenance programmer?"

My thought processes at the time went something like this: "I wonder what I am supposed to say...what will give me the best odds of getting hired? I just want to be hired. I wonder if they need more developers or maintenance programmers? Maybe it's a trick question: maybe they do very little outright development here..."

So I responded in some lukewarm fashion like, "Oh, either, really. I'm flexible," which was very likely instrumental in my name being stricken from the list with a black marker.

Hiring managers want to hire people with hard skills, like .NET experience, surely. But they also want to hire people who have a professional identity.

I'll never forget when an intern in our department wanted so desperately to move from the workstation support group to the development group. When his wish was finally granted, he lasted less than a week. "I hate it," he admitted. He enjoyed the quick turnaround of requests to replace a mouse, or install a program. He hated the sometimes-solitary, desk-stapled existence of a developer who might work on the same project for months.

Another time I conducted an interview, after describing the open position at some length as being primarily a position involving developing software applications, I asked the question, "What area of IT are you most interested in?" The answer? Workstation support.

I realize that until a person has actually worked in the field, he or she may not be certain which area to specialize in. But that is why you should use the everyday opportunities that present themselves (and I know that they do) to try out various aspects of the industry. Try setting up a wireless network for your neighbor and they will love you. Install virus protection software on your parents' computer, or develop a website with a link to a database of inventory for your brother-in-law's business. That way you'll know which jobs to pursue and when you sit for an interview, you can come across as passionate about your field.

In addition to professional identity, it helps to have technical identity. The profession is a goldmine (or minefield, depending on your perspective) of platforms, languages, tools. A hiring manager might very well ask the question, "What are the two programming languages you’re most comfortable using, and what are their relative strengths?" If you cannot respond with some confidence to this question, then the hiring supervisor is going to consider you a crap-shoot candidate. You may very well be able to pick up .NET quickly after being sent to class, but only a crystal ball would be able to tell, because there is no supporting evidence.

I've said all that to say this to aspiring developers: If you're going to go to the trouble and expense to invest precious time in college to develop a career in software development, invest just a little more of yourself to set your resume apart from the slush pile.

Having said all that, (and if it's okay to add a shameless plug) if the idea of living in the southeast U.S appeals to you, you are interested in a career where your IT skills can make a direct impact on humanity, you are a competent (and passionate) .NET developer and might have an interest in a Programmer Analyst I or II position, see: http://www.pittcountync.gov/depts/hr/jobs.asp.

Some employees, in an effort to spare their pride, assume that management will wink and nod in their direction, offering clues that they should apply, if it would be in their best interest. More matter-of-fact employees are bold enough to ask, "Should I apply for this position?"

As one might guess, asking a supervisor or some form of management if you should apply for a position is rather pointless because they simply cannot prejudice the process. They’re going to say, "If you're interested, I encourage you to apply." But here's the thing: It's not simply management covering themselves for legal reasons. Very often the outcome cannot be predicted and to attempt to do so can really hurt an applicant. I've seen times when an employee wouldn't apply for a position because they felt another was sure to get it…and then that person didn’t apply either. So apply. It's your lottery ticket.

Having said that, the business of selecting an applicant among coworkers is sensitive business and it isn't easy for anyone. No one likes to stand in a line-up and be told they aren't the best. Often employees assume that favoritism is the driving force and that the entire process is like a chess game manipulating lives.

This subject is foremost in my mind today because I'm in the midst of it now. I probably slept two hours last night, and that was only accomplished by sheer force of will. Yesterday one employee resigned unexpectedly, after just four months work. It wasn't dissatisfaction, but a lifestyle change and move that drove the resignation. Yet, it was tough to take because the programmer analyst was very talented...that much was clear in even a short period of time.

At the same time, we were hiring our first DBA ever. Up until now the responsibilities were shared among those with greatest interest in databases. This was a position we had been trying to get approved for years and we finally did it. (There was a time when I would have given up my premium interior office in the former morgue and any other perk I had, such as my white board with indelible marks that no amount of erasing will whiten, for that job.)

The position was posted externally, but we had more qualified applicants internally. Coworkers were put in the position of competing with one another. Could any one of them have done the job? Probably so, especially given time and adequate training. Those that interviewed and were not selected were quite gracious to the one that was selected and expressed their desire to support that person. Yet, I can say with confidence that the process could not have been more painful for them than it was for me. Sending rejections to strangers you've only known for the span of a one-hour interview is not fun, but tolerable. But to people you work alongside every day? Sigh. But the saga isn't over. The dominoes start cascading. A Systems Analyst gets the DBA spot, so a Systems Analyst spot is open. If that happens to be filled by a Programmer Analyst II, then a Programmer Analyst I spot is opened. Each one has to be posted and the formal process followed. Ah, but if anywhere in that line of events there happens to be a strong external candidate, well, expectations are built and are dashed again.

The thing is, employees on a team feel like they have a pretty good grasp of the pecking order: who is strongest, weakest, and in-between. I do think that if I asked 10 staff to rank each other on their team, the list would not be identical, but there would be some definite patterns. The biggest deviation would come from the individual him/herself. I'm not sure, but perhaps it's a protective psychological mechanism, refusing to allow the brain to process a reality that cannot be accepted. In real life, supervisory terms, no one is generally the worst or best at every dimension of the job. This one's the best programmer, that one the best communicator, that one the best at troubleshooting, that one the most reliable and patient, etc. When a position opens, the supervisor has to look at what dimensions are most important to the team at the time. Yes, it can change based on the dynamics of the existing team members.

Maybe the organization I work for is not typical, but I don't know. When I worked for a large pharmaceutical company, it was not unusual (and it was allowed) for a supervisor to refuse to release an employee for a promotion/opportunity in another department because the employee was considered vital to the organization. Just like that. Valuable, but essentially punished for being indispensable.

In the traditional, good-ole-boy organization, job promotions were typically doled out based on longevity. At least that was less subjective, though not always deserved. Personally, I believe that the employees who deserve an opportunity/promotion are the ones who have been extending themselves already in daily leaps of faith to keep their skills current and do what needs to be done, whether or not it was technically in their job description. Sort of like dressing for the position you want, not the one you have, except it has little to do with fashion.

There are times, though, that the decision about who gets what position will be very close calls and disappointment is bound to ensue. How one responds to that disappointment (bitterness versus grace) may have a lot of bearing on how the next promotion/posting plays out.

The only thing tougher than feeling like a pawn in the game is being in a position of knowing there is rarely a hiring decision that will leave everyone involved feeling satisfied and treated fairly.

IT Managers who:

1. Do your evaluation but don't understand what you do.
2. Ask you to draft an email explaining a situation or project, but feel the need to proof and change it before it’s sent out.
3. Keep looking at the computer screen and occasionally type while the two of you are in the middle of an important discussion.
4. Walk in your office with the air of "whatever I'm about to say is more important than whatever you're doing right now" when you’re working on a problem with a coworker.
5. Have insecurity issues because they realize your skills are more marketable than theirs.
6. Correct your punctuation and spelling in project documents that will only be seen internally.
7. Tell you to get to the point.
8. Don't respond to your request for time off so you don’t know whether you can make plans or not.
9. Habitually expect for work to be completed by unrealistic deadlines to give you incentive to try harder.
10. Latch onto the latest buzzword.
11. Ask you to provide a project estimate, but then disregard it when setting the target date.
12. Ask you to train the person who makes significantly more money than you do.
13. Seem to be trying to mold you into a cloned mirror image.
14. Evaluate projects with unusual twists in retrospect, with the benefit of hindsight, and ask, "Why didn't you plan for that?"
15. Tell you to "focus on the big rocks" while assigning you a steady-stream of minor incoming service requests that require your immediate attention.
16. Nurse an arbitrary coding style preference that is different than yours.
17. Talk about other staff members in your presence, leading you to believe that you have at one time been the subject of conversation.
18. Do not keep up with industry changes and see no need to upgrade development tools that "get the job done."
19. Tell you dismissively not to worry about something when you know from past experience it will come back to haunt you if someone doesn't.
20. Seem more concerned about your caption alignment and tab order than whether your application actually works.
21. Take themselves too seriously in everything they do from the way they dress to the country club they join.
22. Call way too many meetings that are way too long.
23. Seem more concerned that you document it than do it.
24. Morph into Dr. Phil, taking opportunities to work in "coaching moments" that make you want to throw up.
25. Have selective memory.

IT Managers lives aren't easy and they can't be perfect, bless their hearts. I could make a laundry list (and maybe I will some day) of the crap that IT managers protect staff from that goes unseen and therefore unappreciated. But today is for venting.

I might add that my attendance at a conference targeted to the technology elite was not happenstance. After sharing CIO perspectives here for almost a year, based primarily on daily interaction with one CIO in particular, I was pleased to be attending the conference to witness his acceptance of a CIO 100 award on behalf of our organization.

Our organization was a speck among giants and it was all I could do not to be intimidated, especially since everything about the venue contributed to the aura of grandeur. L. Frank Baum (Wizard of Oz author) penned some of his books at The Del (as those-in-the-know fondly refer to the hotel) and designed the chandeliers in the Crown Room. The room is aptly named, as each chandelier is an illumination fit for a king (or CIO). The edifice itself conjured thoughts of a murder mystery, with an endless maze of hallways, massive staircase, proliferation of gleaming wood, and quaint elevators that enclose guests in a cage and justify numerous headcount to sustain operation.

The CIO 100 awards night was a black-tie event that felt like Technology Oscars. Fortunately since there were 100 awards to be presented, recipients weren’t allowed to give a monologue of thanks. The company name was announced, followed by polite clapping. Occasionally rowdy clapping, if the organization brought along a table-full of employees. Heralding from the south and meeting most of the criteria for being called educated red necks, we made as much noise as three people can in polite company, with a little help from stranger-CIOs at our table who were rendered somewhat more enthusiastic by the free-flowing beverages.

Speaking of stranger-CIOs, I went expecting a stiffer and less friendly set. Yes, occasionally I encountered the CIO, who upon learning you were an award recipient would ask rather bluntly, "What did you do to deserve the award?" followed by "What's special about that?" after hearing your elevator pitch. That was generally the exception. More often the CIOs were eager to share their own stories – like the fellow who was the top-tech for an au pair company, and another for a health supplement outfit that bore the name of NSA – a sure conversation starter.

I couldn't help wondering why conferences are held at such beautiful resort locations. I suppose to get you there. So they get you there, and then you have no time to take a dip in the Olympic-sized pool or dredge your toes in the cool waters of the Pacific or gold-specked sand…unless you blow off some of the sessions. I missed precious few sessions, feeling it my moral obligation to attend and absorb.

I will draw the substance of this post from the first morning's keynote, as I considered it the highlight of the first day.

Bill Walsh, Professional Football Hall of Fame Coach, walked onto the stage while speakers blasted strains of Queen’s We are the Champions. His topic was "Embracing Innovation to Sustain Success."

Skill Matters

One might wonder to what degree professional football relates to the job of a CIO, but software developers might assume the link to be even more tenuous. I was astonished by the relevance of the speaker's advice. For example, the man responsible for leading the San Francisco Forty-Niners from Sport's Illustrated's list of worst to best sports franchises in a span of 5 years said this:

"If you have skill, people can use you. If you don't and you fake it, you will be found out."

"At one time if you knew the right buzz words, had an attractive spouse and attended the right dinner parties, you would get promotions. We've matured as a society and now people like this hit a brick wall by age 40."

"If an employee is motivated to improve their own skill and expertise, they’re a good employee."

Walsh described an elaborate effort to boost ticket sales shortly after he was hired for the Forty-Niners. A public fun-day was planned, including every kind of free food imaginable, donkey rides, games – every conceivable attraction to lure families to the site. Red bows were attached to the seats already sold and staff were on hand to help customers hand-pick their own seats.

At the end of an exhausting day, Walsh looked for his marketing guy to get the final tally, only to learn that they sold a whopping 5 seats. Walsh bought 5 more himself just so he could report that they sold "in the double-digits." The moral of that story? It doesn't matter how you package it (or yourself): if you don't have a good product, people won't buy.

Improve While You're Losing

Walsh, who led his team to win five Super Bowls in 11 years, described a pivotal moment in his career when he broke down and cried quietly on the bus after a game. He felt he was instructing the team wisely and they were doing all the right things, but they continued to lose. He decided to finish out the year before resigning. Shortly after the lowest moment of his career, the wins started coming in, one after another. He explained simply: "We were improving while we lost."

That's a hard one to process. In a society that expects instant gratification, sometimes it's hard to tell that you're on the upswing of the curve; that you're getting better, even when improvement feels like failure.

Suppress the Ego

Walsh's proudest achievement is that his leadership ultimately produced 14 men who later became head coaches in the NFL. He said, "If you're a CIO, you have to suppress your own ego to listen to the people who work for you or with you..."

But this series is What the CIO Wants You to Know. Walsh's next statement was for us, the working stiffs who report to the CIO: "...And they have to suppress their ego when we don’t implement every idea they have."

It Takes all Kinds

Relating to the theme of innovation, Walsh admitted, "Whatever innovative ideas I had, I was probably over the edge most of the time and had to be reigned back in. I was thought of as the crazy professor a lot of the time. And likewise sometimes I had to respond to people on my staff with, 'That's a good idea, but there's a federal law against that.' If you have 10 employees, one or two will be creative but one or two might be institutional." It's good to have both employees who can envision the bright, crazy ideas, but also those who can provide a dose of reality when it's needed."

Have a Contingency Plan, or Two, or Three

"Pre-plan with contingencies for every situation you can think of…and openly discuss the plans. It's critical."

The temperature was well below freezing and the opposing team’s fans were screaming expletives through megaphones pointed in the general direction of Walsh’s face. His mind was a blur with the cacophony. He couldn't think of any plays…all he could think about getting out of the cold. What saved him (and helped the team win the game) was having a contingency plan that he’d carefully developed before the game.

This vivid image of work stress was not unlike the feeling in the pit of a technology worker’s stomach when facing a hard system failure: bad memory, suspect database, fried motherboard. Whether contingency planning involves football strategy or how to sustain business continuity during a disaster or what to do if a critical system isn't delivered on schedule, the formula is the same: preparation.

Beware of Success

Is failure your biggest fear? Consider the alternative.

"We lost nine players out of 45 because they couldn’t handle euphoric success," Walsh said. "People can self-destruct when they’re ultimately successful."

So what is the remedy? To fail?

"The more success we had, the firmer a leader I was and the more I expected from them," said Walsh.

Focus is critical, and never more so than following success.

Lead Authentically

"The players followed me because I knew what the h&*% I was doing. Leadership comes from being an expert in your field."

Independently develop every employee so they feel like they can be the best there is, at what they're assigned. And change their assignments eventually.

"You cannot influence people's minds – develop an attitude/atmosphere by giving one talk, or sending one memo. Today's leader must continually influence."

Play Intensely

"Don't be awed by the competition – by the stadium you're playing in or the team's reputation. Worse than that is having contempt for the competition. Play with the same intensity regardless of the score."

These are Bill Walsh's words (more or less, considering the error-factor of a note-scribbler). Personally I am a huge admirer of software developers, CIOs, or housekeeping staff who "play intensely," at whatever task is at hand – not adjusting the effort expended to the importance of the client or how they're feeling that day. It's a tall order when you have more work than you can ever do. But if you're going to accept the responsibility of going out on the field, then play (code, manage, clean, work) intensely.

Next Up

I would love to report next on other highlights from the CIO 100, including a presentation from the CIO of Circuit City who encouraged the audience to "celebrate failures," and a rocket scientist (chief engineer, planetary flight systems for the Jet Propulsion Laboratory) who made the audience feel collectively dim-witted by contrast.

I was primed for it by navigating the rental car in a mad rush from Vancouver to Seattle, gaping at road signage with names like Everette and Whidbey.

We were flying in the evening from Seattle to Las Vegas in order to catch the red-eye to our final destination (home), and most passengers were jockeying for an infant-sized pillow and a poor excuse of a blanket. Some, however, were engaged in the oh-we-have-something-in-common banter. (Never knowing whether that sort of thing would be considered more annoying than welcome, I typically fall mute when seated next to strangers. I imagine them telling their friends later, "I had the most considerate person sitting beside me…didn’t say a word.")

But the fellow talking to the Microsoft lady was saying plenty. Trouble is, I missed the part where he said where he worked. (Good thing for him.) I got the bit about the company he worked for providing contract IT services, however. He loudly went on to say something like this:

"Yeah, I was hired as a security expert...and I don’t know the first thing about security. Then they set me up to meet with these clients who've had like 12 years of experience in the industry...and I'm like, trying to wing it. Now I know how the game works so I just make sure I read up on whatever I'm supposed to present the night before."

Now those who are in the IT services or retail software business may relate sympathetically to this braggadocio, but I relate more. I relate to the demos of email archiving systems my colleagues and I sat through several months ago...only to later discover that the product we were demonstrated and the one we were quoted were not the same. Astonishingly, the one we saw had many more features and cost twice as much. Surprise! I relate to painful third-party implementations where we pay some outlandish hourly rate to "experts" and then end up telling them how to do their jobs. Because they have no version control in place, every time we get an update, it overwrites the customizations we paid for previously.

I know it's probably not exactly the poor drone's fault. Maybe he was hired by a company and in good faith believed he’d have adequate training before being released to the wilds of client contact. However, I now believe that I have something of a sixth sense, like the blonde on the TV show Mediator. Put me in the room with a vendor or consultant and within one paragraph or so I start getting mental images of competency or technological fraud. I'm too nice to purposefully ask probing, difficult questions in an attempt to see the vendor sweat, but sometimes it happens by accident because I simply have a need to know.

So, "Senseless in Seattle" (and other tell-all consultants out there) you might keep your voice down on your next flight. There's no telling who's listening, just itching to update their blog.

"Edward G. Nilges, a programmer who worked in Princeton University's computer center from 1987 to 1992, recalled that Nash 'acted frightened and silent' at first. In Nilges's last year or two at Princeton, however, Nash was asking him questions about the Internet and about programs he was working on. Nilges was impressed: 'Nash's computer programs were startlingly elegant.'"

Now I'm interested in reading some of Rebecca Goldstein's books such as Incompleteness: The Proof and Paradox of Kurt Godel, Mind-Body Problem and maybe Betraying Spinoza: The Renegade Jew Who Gave us Modernity that is due out next week (5/30/2006).

200 million installations.

2200 engineers.

10 hours to build clean.

Microsoft’s Russ Ryan opened his "What Goes in the Sausage: Lessons from the Factory Floor on How Microsoft Does Software Engineering" session with some impressive stats relating to Visual Studio and the .NET framework. With the sheer volume and complexity of the projects Microsoft tackles, it would seem the software giant would have some interesting words of wisdom (or horror stories) to share and Ryan was kind enough to do it. As customers we know that Microsoft's target dates have been fluid a time or two and some tolerance exists for shipping product with bugs. Yet, Microsoft knows that we know that and was still willing to invite guests into the house with dishes in the sink.

First, more on code names. Visual Studio 2002 was code named Las Vegas; VS 2003 : Everett, and VS 2005: Whidbey. Maybe everyone else had heard the story behind the code names, but alas, I don’t get out enough, so I had not. Apparently, originally Visual Studio 2003 was code-named Whidbey (an island 30 miles north of Seattle). When Microsoft realized they would not be able to deliver all the planned functionality in one product release, they decided to relabel the project Everett, a locale half-way to Whidbey. Incidentally, Orcas is another island further north than Whidbey.

Next, a few inside details about Microsoft’s development environment:

C++ and C# are the two common languages used in Microsoft.

Each product unit has 30-200 staff members.

Code that is shipped is supported for at least 10 years by company policy.

A central build lab is staffed 24 hours. The build process happens every day: it’s started about 4:00am and finishes about 1:00pm. (There are 40,339,207 functional test cases for Visual Studio 2005.)

All code check-ins (no matter how senior or junior the developer) must be code-reviewed by another developer prior to submitting any changes to the source tree.

If a developer gets to a specified number of bugs, he is in "bug hell" and is not allowed to work on anything else until they’re resolved.

The "war team" consists of senior members of the team. If any of the developers wants to fix a bug or make a change they tell the war team. When it's getting close to a release, they have to ask the war team if the change can be done and it has to be very critical and directly affect customers.

"Feature crews" are small, interdisciplinary teams who work together to design, code, test, and deliver specific product features.

Microsoft uses "scenario-driven" design.

Testing is very "intentional," starting with a test case.

So what are some of the lessons learned?

Shipping is a feature too. When deliberating which features to include in a release, they have to add the reality-check that meeting a reasonable ship date is as important a feature as the others.

The recognition that "cool technology" is not the same as "solutions to real customer problems."

Superman just doesn't scale. In the past one hero could pull a project out, but today's projects are too large and complex for that.

Load balance across units. (If one unit finishes their product early at Microsoft, they are shifted to another product unit; something that was unheard of in the past.)

Manual testing is expensive. You have to invest in more automation.

Once you check in the code, you are a hostage to it.

How has Microsoft changed, internally, as a result of lessons learned?

With Visual Studio 2005, Microsoft created:

Project "Ladybug" (code name): the product feedback center.

Self-sustaining communities (blogs, newsletters, forums)
Community Technology Previews (CTPs)

Technical Assistance Programs driven by (get this) the "evangelism organization." (It seems I wasn't too far off in my characterization of the Church of Microsoft in an earlier blog.)

Summary: While Jay Schmelzer might have won my arbitrary award for the most personality, Russ Ryan won the prize for sincerity. Even though I walked into the conference room with cold cynicism, thinking that having Microsoft lecture on software engineering would be akin to Jimmy Swaggart leading the sinner's prayer, I bought what he was selling. I came away with the impression that managing a software project is tricky, and managing countless numbers of projects with dependencies is crazy. Microsoft isn't perfect, but they are refining the process as they go. I hope I can say as much for my organization.

Nestled in the Disney Swan, the conference offers attendees thick carpet awash with geometric patterns and amenities like artic air-conditioning, a lacquered black grand piano and strategically placed fountains. Pleasant but non-descript music is piped in to sooth the beautiful (or in this case, technical) people.

Of course for VSLive attendees, the most sought after feature is a comfortable nook close to a power outlet for recharging the absolute necessity at such an event: a notebook with wireless connectivity. We all pull them out, like six-shooters, as evidence of technical prowess, and I catch attendees casting glances at each other's equipment out of their periphery. Mine is a humble Averatec that I appreciate for its lightweight portability; yet, in the realm of PC-envy, it doesn’t rate.

So far the sessions have been attended en masse, making for literally elbow-to-elbow seating. When the fellow to my left laughed to placate the speaker, I felt short bursts of air (breath?) on my arm. Am I just a little claustrophobic? I expect tomorrow to be a different configuration as we break into our respective (but annoyingly overlapping) focus areas.

The keynote speaker first thing this morning was Sam Guckenheimer, a low-key, scruffy-faced Microsoft employee who described himself as a former employee of the defunct Rational Corporation. When he said he'd also worked for IBM for three weeks, he was rewarded with a collective audience chuckle. The stage was set with Broadway-style black curtains swathed with crimson lighting for dramatic effect. Two giant project screens flanked a cockpit of 8-10 computer consoles for running the show. (At the beginning of the day I was hopeful with all that computing power we might see something more impressive than Powerpoint. We did, but only in tantalizing morsels.) In fact, I believe it would not be an overstatement to summarize the attendee reaction to the first day of VSLive like this: Cheers for projection-screen, live (though clearly rehearsed) coding; Jeers for Powerpoint droning.

The speaker and Microsoft employee who won the award for the most personality (and ability to keep the audience out of REM mode) was Jay Schmelzer. He described the Atlas framework as facilitating asynchronous calls with partial rendering (AJAX style), providing rich web experiences while leveraging development productivity. Sound like a sales pitch? Well, in Orlando, with evangelist Schmelzer at the pulpit, it was more like revival. If the crowd got too quiet, he'd demand an "Amen" by teasing, "Not that cool, eh?" to which the audience would clap. At one point he said, "For those who haven't heard me speak before, I feed off the audience," to which someone in the back bellowed, "Dude, this rocks!"

The day was riddled with a polyglot of features high on the cool scale such as triggered postbacks and LINQ (language integrated query). Buzzwords were "friction-free metrics" and "people-ready software." An interesting add-in for VS 2005 available free for download from MSDN was demonstrated: Refactor. The third-party tool had definite wow-appeal as it seemed to magically do what you wish you could yourself: streamline and beautify code. In the words of a conference attendee to my distant right: "Sweet."

Stay tuned as I plan to figure out how I can clone myself tomorrow to attend ASP Live! And SQL Live! scheduled in the same time slots.

However, this thought thread reminded me that we often engage in somewhat delusional self-labeling. Musician and writer wannabes are probably the worst, considering ourselves (at heart) to be musicians or writers, even when we go days, weeks, or months without truly practicing or writing creatively. We’re former high school athletes who, in our mind’s view, still flex taut muscles while the crowd cheers. Meanwhile, a middle-age spread has set in as we vegetate in the fat-man chair.

Even so-called developers fall prey to such mirages, considering themselves among the cutting edge elite, when in reality they spend their days applying fixes or supporting third party products, rarely having a good opportunity to utilize their hard-earned programming skills.

You're a product of your habits. You are what you do. If it pains me so much to be called a "former developer," then I should develop...for fun, if nothing else. If I want to call myself a writer, I should write. If I want to consider myself well-read, I should read...not watch TV. If I don't want to be fat, I should exercise.

Likewise, it really pains me to interview applicants for a programmer analyst position, have the candidate say with ardor, "I really want to be a programmer analyst more than anything," but then see no evidence that they’ve done *any* programming since graduation. In this day of technology accessibility, there is hardly an excuse to be made. To me this says that they want to land a decent paying position in programming, but they don’t necessarily have a passion for programming.

Sometimes it pays to be jolted by a little introspection. If your circumstances have placed you in a position where you feel your skills atrophying, either you need to change your habits or resign yourself to basking in the laurels (as John Mellencamp likes to say) of your former glory days.

I am also happy to report that I'll be headed due (and extreme) west in August to attend a certain function intended for the tasseled loafer set. It should be rich fodder for the What the CIO Wants You to Know series...you know...the one you love to hate.

I stumbled across the email by chance in my junk folder, but perked up when I saw it was from a company I’d done some work for, and not another ad promising to supply me dirt cheap pharmaceuticals or to make me larger than my friends.

I was tempted to respond, "Um, I write software…hardware is somebody else’s problem," but I didn’t, because I knew why she contacted me. I might not know as much about hardware as the other guy, but I was nicer. I wouldn’t look at her with an expression of thinly veiled boredom and borderline loathing that said You’re not worth my valuable time.

I reached into my bag of server tricks and pulled out the one that was smooth and worn from frequent use: the ole reboot. I explained the situation frankly, "Servers like to be rebooted every once in a while and yours probably hasn't been rebooted in months. It's a memory thing. It will either clear the problem right up, or make it worse...it might not boot up at all."

That's when the client, a woman I knew only professionally from interactions in her office where she chain-smoked and watched one soap opera after another, spoke these profound words: "That’s okay. If there's one thing I've learned about computers, it's that they work when they want to."

Alan Turing would burst with pride at the notion: computers personified to be temperamental. I gave her a weak smile—my blanket response to all such rhetorical statements. Yet, I was disturbed all afternoon, long after the reboot proved to be the cure.

I realized with a jolt that somehow we failed along the way. (We, being the purveyors of technology.) In our attempts to build systems that do just about everything, we lost the rote reliability inherent in machinery. It was supposed to be a 0 or 1, wasn’t it? Not .5. Certainly not mysterious blue.

We put our heads inside the jaws of technology and laughed, thinking we were smarter, more powerful—masters of the domain. But sometimes you can put your head in the proximity of sharp teeth one time too many.

I know I'm just being ridiculous and morose tonight. But last week I heard that for the May election primary, our county will be using "all new" election machines. Then I was told that the "new" machines use paper ballots with the sort of circles you fill in with a #2 pencil: "technology" we used 30 years ago for standardized tests in school. "Are these really new machines utilizing dated technology, or refurbished old machines?" I asked. "Oh, they're all new."

I pondered the fact that we probably salvaged similar machines years ago. This knee-jerk reaction to replace slick,touch-screens with back-to-the-future paper ballots was in response to perceived unreliability of newer systems.

"What’s next?" I asked another programmer. "A resurgence of DOS?" Hey...it's not so far fetched. Is newer and bluer better? We've programmed ourselves to think so. However, as far as I'm concerned, I'd like to move in the opposite direction of Alan Turing's vision. I don't care if computers think or feel. I certainly don't want them to be as flakey as humans. As software developers, I'm afraid too many of us have been too concerned with application sex appeal. We need to start wearing sensible shoes with good arch support, care about quality control, and build systems that do what they're supposed to do.

The entrepreneur spoke before a large audience comprised of primarily college students, as the lecture was sponsored by the local university. Students filed by me dressed in everything from slouchy jeans and sweatshirts to outfits suitable for an Apprentice taping with Donald Trump. My manager (and CIO), who sat to my immediate right, noticed the same thing and whispered, "Do you suppose there will be a correlation between how they are dressed for this occasion today and their success later in life?"

I reminded him about the last time we interviewed candidates for a Programmer Analyst I position and we saw everything from Italian suits suitable for a preacher or politician to golf-shirts and khakis. The person we hired was in-between, wearing a dress shirt, but no coat or tie. How a person dresses might reflect a little on judgment and the relative importance they place on comfort and making an impression at that particular event, but I like to believe (probably because of my own lack-luster wardrobe) it isn't a definitive statement in of itself.

The two front rows were reserved for business people and university dignitaries. I found myself sandwiched between my CIO and a School of Business staffer—a woman who was dressed impeccably, with the sort of hair that refuses to move or in any way detract from her statement of being well put together. Her look was in contrast to my own, despite my best efforts to wear what a coworker described as my "Agent Scully" suit. While we had a good 15 minutes of wait time before the speaker began, it wasn't until he was properly introduced and I was stunned by the relative silence in the room that I began to have an anxiety attack about my cell phone. Was it in my pocketbook under my chair? If so, it was definitely set to loud ring. My pager was in there too. Was in on silent mode? I couldn’t remember.

The scenario played out in my mind like a bad dream. I was sure the students had been threatened with a failing grade if their cell phones rang in the middle of such an important event. I could imagine mine resonating with a the first few notes of a bastardized classic—the digital din that invokes universal disgust. "What idiot doesn’t know any better than to turn off their stupid cell phone?" People would frown and crane their necks to get a better look at the hick. I became so obsessed by the mental image that I slowly reached down and fumbled in my pocketbook for the phone. Even that much movement was like flailing arms given my proximity to the stage. I couldn't see the phone...but that gave me little comfort. I waited a few minutes, wondering if I should just take my pocketbook with its potentially explosive contents and slip out. No luck there. I would have to step over 15 people to my right or walk directly in front of the speaker. Finally I put the pocketbook in my lap, rifling through it again. My CIO gave me a glance as if to say, "What on earth on you doing?" I stopped, hugging the pocketbook as though I could muffle the sound that might ensue at any minute with body mass. It was like the poignant image in the last episode of M*A*S*H, when a refugee smothered her chicken (baby) to stop its cackling (crying) to keep from being discovered and killed by the enemy.

It was at that moment I began to realize the true pain of those who suffer from some sort of obsession or compulsion. I had just finished reading about Alan Turing's tics, and even more recently about Nathaniel Hawthorne scribbling the number 64 obsessively on scraps of paper towards the end of his life. Then I had the same sort of Scarlett O'Hara epiphany that I had the last time I locked my keys in my car (while it was running): As God is my witness, I will never be tormented by the fear of an audible cell phone again. I decided to actually listen to the speaker and hope for the best.

This highly successful businessman with a southern drawl (of course, since he was and still is from eastern North Carolina) speaking at the invitation of the School of Business didn't actually get a degree in business. He majored in psychology. Interesting. He began his career working for Burroughs Corporation (yes, the big computer company). He decided that he wanted the freedom of not having to go to work next week if he didn't want to. That's what he said, anyway. From the entrepreneur-action I've seen, it was only a theoretical freedom. In real life, he probably worked harder than ever before, rarely taking any time off. Later comments confirmed my suspicion.

The ambitious, young Maynard started applying for franchises, soon realizing no one was going to work with him and his partner without some financial backing and expertise. His partner learned everything he could about the steak restaurant business, while he focused on getting the finances to build. He scraped up $50,000 in total from eight friends who were teachers (and former college buddies), who basically turned over their life-savings to him. His next move was to take the entire $50,000 and buy stock in a wholesale floral supply company that had nothing to do with the business he was trying to start. It was a move he said he wouldn't recommend...it could have backfired completely. Yet, after purchasing the stock he was able to convince the head of this company to invest in his restaurant idea. In the end, the company made most of their resources available to him as he stepped in and helped both businesses become more profitable.

So what does this have to do with software development? Well, shortly after opening the first Golden Corral in 1973, then President Nixon capped the price of beef and farmers refused to take their cattle to market, thereby making the cost skyrocket and supply plummet. Then, a few years later, consumers started realizing they shouldn't eat steak every day and the Golden Corral menu (at that time) had no variety. The entire business concept was suddenly obsolete. Investing oneself in a programming language or operating system and then being faced with staggering learning curves as everything you have known is chucked out the window of technology is something I can identify with.

Other steak restaurants refused to change and went under. Golden Corral started building bigger restaurants and morphed into the mega-buffet we know today. Granted, some view it with a bit of disdain as an altar to gluttony, with its emphasis on quantity, but it meets a need. Interestingly Maynard said he realized they may again become obsolete, but calmly accepted that possibility as just another day’s work. Obsolete? Fine. I’ll just reinvent myself. I will not be undone.

Maynard offered this advice: Don't worry about the fact that you don't have money. You just need a business plan that makes sense. Write out with clarity a business proposition including all the facts, costs, and why is good for shareholders. While the analogy may not be a perfect one, I couldn't help thinking of the correlation between starting a new business and developing a new application; the importance of being able to express *with clarity* your vision (or the client's, as the case may be). So many times we approach work with only the vaguest notion of what the end product will look and feel like. Ever heard the phrase "we'll flesh out the details later"? We assume the details will evolve and take shape as we work through the project. Sometimes they do, and then again, sometimes we paint ourselves into a corner.

"We hire the attitude and train the worker," said Maynard, advising students to find a company with similar values to their own. "If you love doing tax accounting alone in an office, don't accept a job selling door to door."

Three primary factors – turning points, he called them, contributed to Maynard's success:

(1) The belief that you’re rewarded to the extent you serve other people. The service should be valuable enough that customers want to choose us. (Certainly software consultants know this to be true as well.)

(2) There is more fun if other people share in the success. (Maynard made sure that every store manager had 20% interest in the business so that people had a sense that they were in this together: partners in business.)

(3) Entrepreneurial spirit: 75% of the restaurants are operated by franchisees, half of which used to be managers. (This is a recurring theme I have seen expressed here at DDS: the desire to maintain some independence and control over what you do.)

At the conclusion of James Maynard's speech, a few hands raised.

"Where are the eight friends today?" one professor asked. Apparently some had retired, but all had worked in the company at one time or another and had done quite well for themselves, following that "faith investment."

"How do you balance work and family?" a student asked.

Maynard looked at the audience with an expression tinged with experience and regret. Apparently he'd done okay...he was still married to the same woman he fell in love with during college and had two grown, successful children, one of them working as a social worker. (He said he told his daughter that he does some social work...he created a lot of jobs so that people could support their families.) However, he admitted that he had not done such a good job in the early years determining how much work was enough. He hated the thought that if his business failed, it had been because he hadn't worked hard enough. He said that if managers start working with his company and have a good family and end up without one (because of long hours working) then they consider that a failure. They offer training on maintaining an appropriate balance, making sure their managers do not work too many hours. Ah, I thought. Another favorite DDS topic: the work/family/life balance.

I passed throngs of students lined up at the reception table on my way out the back door. As I settled in the front seat of my car, I saw my cell phone nestled comfortably in the drink holder. *Sigh* Unnecessary worry. Maybe I'd learned more than one lesson today:

Take risks.

Learn how to express your vision with clarity.

Don't sacrifice your family life on the altar of work.

Be prepared to reinvent yourself more than once in your career.

Know yourself and your values.

Prepare (i.e. turn off your cell phone), but don't make yourself sick with worry.