Computing nerds bring value to any company for which they work. They bring knowledge and an understanding of systems and projects that can help managers avoid bad decisions. But the computing nerd in this stage still has room for growth. In this week's column, Payson Hall says there's a higher level of value computing nerds can achieve. And, in today's economic environment, this level is far more valuable than ever before.
Current economic conditions have many of us looking for ways to enhance the value we offer our organizations, reasoning that the more we contribute to the organization's survival, the better our chances for long-term employment and advancement.
I would like to share a hard-won insight from my career in the hope that if you haven't figured this out for yourself, I might expedite your process. Bear with me if this isn't news to you. Think of it as a booster shot and gentle reminder about the importance of balance between nerdiness and business context.
A Computing Nerd is Born
I chose the software profession because I like to build systems and solve problems. As a software developer and systems integrator, I worked on teams that built solutions to real-world problems, and it was gratifying to see those problems solved. I must confess to being a bit of an opinionated idealist earlier in my career. I had arguments about the "correct" architectural choices from the perspective of partitioning of function, hardware independence, and ease of maintenance. I had strongly held opinions about what constituted "sufficient testing." I thought that the people who disagreed with me weren't necessarily stupid but didn't understand the big picture. I was sure that I could enlighten them with my insights, wit, and pragmatism given sufficient time. I was a computing nerd.
Computing nerd is a step in the evolution of a computing professional that people enter when they possess sufficient practical experience and theoretical knowledge to have an informed opinion. They finally "get it" from a technical perspective. They have worked on a few successful projects and a few failed ones. They have seen corners cut and have learned which were ill-advised and caused violence and chaos. They have seen what matters from a technical perspective-like having a solid software architecture or good instrumentation in a system for tracing execution or monitoring performance-and are constantly trying to improve the state of the practice on their projects. They keep up on their professional reading, devouring magazines, online references, books, and other sources on their own time to gain wisdom from others. They can sort the useful ideas from the chaff and the smart practitioners with useful insights from academicians and theoreticians who needed to get a paper published but haven't really implemented production systems. They become opinionated and believe that there is a "right way" and a "wrong way" to do things. This is a computing nerd career plateau.
When you reach this level of practice, it is easy to look with scorn on the pointy-haired bosses of the world who want to talk about tradeoffs and who want to constrain budgets or meet deadlines. The nerd replies, "It will cost what it costs and be ready when we have done the things needed to build it right." I have been there and said this. If you have been in this place in your career, you recognize it. If you are there now, you aren't foolish but you might be a little naïve. I want to suggest a next step in your career enlightenment.
The Nerds' "Right Way" May Be the Wrong Way
Imagine you decide to renovate your kitchen. You meet with a contractor, explain what you don't like about the current kitchen, and sketch some changes that would better meet your needs. You jointly agree to your budget and schedule constraints (you want the kitchen ready for a big family gathering in two months). The next day, burly guys with crowbars destroy your existing kitchen and carry your appliances, sink, sheet rock, and flooring to a large dumpster. Construction has begun. I'm not a builder, but I'm sure there are "construction nerds" just like there are computing nerds. Imagine that a well-intentioned construction nerd, looking out for your best interests, discovers imperfections in the lumber sent to frame your new kitchen. The lumber will be structurally sound but will require some putty in places to make it fit "just right." The lumber supplier argues that the lumber meets specifications and refuses to replace the lumber for free, so our construction nerd insists on ordering lumber from another supplier to get the "right" product-with a net effect that your project is delayed two weeks and exceeds your budget by $5,000.
"Sorry about the Chinese takeout at the family gathering rather than the traditional communal cooking fest and that $5,000 cost overrun," says our construction nerd, "but there is a right way to do things and I was looking out for your interests."
Indignantly, you realize that this well-intentioned nerd is missing an important part of the equation-you. As the project "sponsor" you deserve a voice in the project priorities and decisions. "Right" and "wrong" are often not nearly so black and white as the nerds of the world believe. There are trade offs and compromises that should be discussed in any serious undertaking.
The same is true for the development, testing, and implementation of software. The business context of what is being done is a critical part of the problem. If your organization must get a product out the door by a specific date, there rarely are clear right and wrong guidelines about the level of functionality, performance, or even quality, only tradeoff discussions that should occur to assure that any compromise from the nerd definition of "right" is made with the informed consent of the sponsor paying the bills.
The Mature Nerd
This is the key to the next evolutionary step in the career of nerds-learning to be respectful of the business context in which decisions are being made and assuring that they are informed decisions. In these economic times, approaching this task honestly, openly, and ethically is critical to organizational survival. When you develop and demonstrate that you have the maturity to participate in this dialog, you will become more of an asset to your organization. To do this, consider asking more questions about the business aspects of your projects:
- Who wants this project completed? How will the product be used? What features are most critical? Who is the project sponsor? Who are the product consumers? What process will be used to identify and reconcile differences between these two sets of stakeholders?
- When is the project to be completed? Why then? What are the business consequences of a delay?
- What is the project budget? What human resources are available to work on the project? Who must approve increases of the budget or personnel assigned?
- Who has the authority to make tradeoffs on the project? What are the project's general priorities among schedule, resources, and quality or functionality? What is the process for considering and making decisions about tradeoffs?
These questions can enlighten nerds of all disciplines, helping orient teams to the subjective nature of their projects. The answers help move us past ideological arguments about what is "right" and "wrong" to more useful discussions of what is appropriate in a particular situation. This is a good time to improve your game and increase the level of discourse around your projects. Are you up to the task? Take the next evolutionary step in your career, if you haven't already.
