Once you learn how to code, do you learn how to live?

I read Mitch Albom's Tuesdays with Morrie long after the hype from Oprah's book club recommendation subsided. In fact, I probably wouldn't have read it all had it not been for my teenage daughter seeking help on a psychology paper, as I am quick to assume that a book's true merit can be measured in inverse proportion to the amount of press it gets. It was the sort of book that can be described as profound or simple, moving or sappy, depending on your perspective. But I liked it...despite the fact that the sober ending is revealed in the first line of text, leaving the reader with no doubt about the degree of vicarious suffering he has in store.

It was not until the weighty matters of life and death sank in that I began to recognize some correlation between Albom's sociology professor, Morrie Schwartz, and developerdotstar's infamous blogger, Edward Nilges; between the life-to-death journey and a career in coding. Perhaps Mr. Nilges will not appreciate the comparison, but in a manner of speaking, he has been meeting with us all--his distant students--often on a more frequent basis than Tuesdays. He shares application aphorisms from the software development counter-culture--wisdom that is alternately insightful, brilliant, indecipherable, critical, clever, and occasionally bitter. But perhaps his diverse views reflect the reality of an extraordinary profession in a complex world. While Morrie's idea of life's lowest moment was a time when he would no longer be able to wipe his own behind, Edward's seems to be the notion of having to code on someone else's terms--prostituting his programming prowess in the red light district of commerce. But enough about Edward Nilges--he is more than able to speak for himself. I'll devote the rest of this rambling on what we, as developers, can learn from Morrie Schwartz, a humble professor introduced to the world through a thin volume--a man who shared bits of wisdom on life and death, and as it happens, the software development profession.

"Accept what you are able to do and what you are not able to do."

We've all heard that the more you learn, the more you realize you don't know. That's never more true than in the software development profession with the breadth and depth of skills you're expected to have--and their incredibly short shelf-life. In recent discussions with a group of developers, several admitted they'd considered changing professions for the very reason that they found it too demanding to keep up with the technology while simultaneously trying to have a relationship, raise a family, or have some quality of life outside of work. This confession came on the heels of the newest hire, celebrating his 25th birthday, giving an update on the VS Live conference he'd just attended in Orlando. "AJAX is awesome," be began, dragging and plopping objects around on a form with apparent smoke and mirrors while we gawked and nodded.

Often developers who began their careers as "power-coders" see their skills atrophying, ironically as promotions to project management roles take their toll. The impact is demoralizing and many either give up, hoping to coast until retirement, or nurse secret fears of incompetence being revealed, like nightmares of standing before a large audience...naked. Morrie's advice here is well-advised: realize that you cannot be an expert at everything, but recognize and value the experience and skills that you have gained. That's not a license to quit learning, but practical advice to make peace with your limitations. Specialization is one sanity-preserving strategy.

"Accept the past as past, without denying or discarding it."

When I read this quote, I immediately thought of older coworkers who cut their coding teeth on mainframes. Like a person learning a foreign language, they think first in their native tongue (be it COBOL or RPG) and struggle with the mind-mapping required to translate processes to current technology. I recently realized with quite a jolt that I am now doing the same thing: thinking in a traditional, Client/Server language like Visual Basic 6, and secondarily translating to the browser-based world of .NET. We all eventually get wrinkles and tired eyes that balk at fine print. But Morrie explained it best to his student Mitch, "As you grow, you learn more. If you stayed twenty-two, you'd always be as ignorant as you were at twenty-two. Aging is not just decay, you know. It's growth." A great deal of experience gained with mainframe, client/server, or the next flavor is transferable. It's not all about the syntax, but knowledge of the myriad details that are involved with negotiating an application from concept to production code.

"Don't assume it's too late to get involved."

Can you teach an old developer new languages? Of course not. Old developers can teach themselves. We only hurt ourselves (and the profession) by buying into the stereotype of the young (and male) developer. It may very well be true that some older developers are no longer willing to do what it takes to stay current with new tools, but that is a personal choice, not a physical limitation.

"So many people walk around with a meaningless life. They seem half-asleep, even when they're busy doing things they think are important. This is because they're chasing the wrong things."

While many of us will admit that income potential was a factor in our career choice, we eventually realize there isn't enough money to compensate for loss of youthful aspiration or at least a measure of self-negotiated peace. Whether you're an educator in Hong Kong who codes on the ferry, a self-employed consultant in Atlanta who moonlights his vision of a web magazine and an independent book line, or a government worker in eastern North Carolina, at some point you must come to grips with what on earth you're here for and what is even worth doing. You have to be willing to walk away (if that's what it takes) to peel away frustration and fatigue. The ideal, I suppose, is to search for fulfillment in the work your hands have found to do--and find it in each line of code. A practical alternative (that will still put food on the table) is to augment the "day job" with professional diversion that restores autonomy and creative license, much like Mr. Nilges and Mr. Read have done. As Morrie put it, "devote yourself to creating something [Spinoza?] that gives you purpose and meaning."

Creating something--an application that subjugates the power of the machine to the will of man from the intangible spark of an idea--is a remarkable ability. Perhaps the software development profession's greatest lesson is to not let the static of the unavoidable overhead (schedules, methodology, technology upheaval, internal politics) allow us to lose sight of that fact.