Artistic Diplomacy

In a larger project your success will depend upon your concordance to the appropriate strategic plan for your company. This is a fairly sensitive and deep subject: nothing seems to be as politicized in a company as much as the knowledge and implementation of its strategic plan. Many of the decisions and tradeoffs that you make very early in the architectural design will depend however upon a firm understanding of how your company will spend money, invest, and hire people across a range of various timeframes.

To further complicate matters once you have this wisdom, even though you may use it to guide system design decisions, it may still be in your best interest to safeguard your insight as private. High diplomacy may be in order.

To reach this firm foundation you need to understand your company, its finances, the industry in which it competes, and your direct competitors. You can research some of this through public sources, but you will still need to rely on the experience of the smarter and more senior employees for their knowledge.

Most people will be happy to give their counsel and experience if you establish a non-confrontational and supportive friendship with them. You also need to understand and appreciate the nature of their advice, and be thankful and willing to give them public credit for their ideas and contributions.

Most companies (and industries) follow a natural cycle of growth and decline. Even companies approaching the end of their utility however can still keep folks gainfully employed for a short while; under such circumstances you will certainly focus your approach more on quick results than long term maintainability, yet you still need to proceed in a courteous and professional manner.

Finally, remember to always balance your decisions with your innate sense for what is the right thing to do.

Artistic Growth

More than most professionals (perhaps with the exception of doctors) software developers contend with change and growth.

Outsiders identify the instigators as advances in hardware and new deployment platforms, but when you're deep inside the works -- a fish in the fishtank -- the view of change and growth are quite different.

From inside you see your assignments and what the nearby developers are creating, along with occasional somersaults from the development environment. Food drifts down in fits and starts. Occasionally you get a new bubbly castle.

In the workplace you tend to get caught up in the office rivalry to impress your boss with your capabilities; you want to eventually move up the ladder from programmer1 to the lead software architect. In this industry staying static -- just creating with the same level of technological adeptness -- is a certain downward spiral. It's like being a plastic plant: you may look really good all the time at just one thing, but nobody is going to get terribly excited over what you have to offer. After awhile you will disappear amongst the accumulated algae.

People acquire skills on the job in various fashions, with as many styles of growth as fish have personalities. One key element to success however is to challenge yourself by volunteering when you smell opportunities. The way you move beyond what you currently know is to step outside of your comfort zone and offer to assume responsibility for something that is slightly beyond, slightly harder than what you think matches your present capabilities. Then the only way out of this predicament is to learn new things and to ask for help.

You need to make an occasional leap out of the fishtank into a new body of water, spawn and reseed yourself once in a while. Growth is all about the research, the struggle, and the experimentation. And more than anything growth is about the stretch.

Artful Observation

Now that you've slept with that little software baby of yours for the past three months (or past year) you may feel confident that you actually know how it works. Do us all a favor though friend and patiently watch it run. And no I don't mean by peering over the shoulder of the user or by firing up a remote server-session to view the batch-log scroll by.

No, really watch it. Turn on the full eight-hundred-million candlepower searchlight and glare that baby down to its bones. Numerous tools enable visibility to the hardware utilization; you can even configure the lowly task-manager to show such useful metrics as GDI objects, memory use, CPU, page faults, threads, and network activity (the big six resources).

Is your process pegging a CPU? Do you have a memory leak? Did you fail to deallocate objects? Are you performing way more disk IO than you need to? Are you losing control of the quantity of threads that you are spawning? Are you hosing the network? Well maybe you should fix it!

During the heat of design and development it's certainly less demanding to code things for quick creativity that end up just wasting resources. Code that runs efficiently, however, is also code that allows for scalability. Raise the bar on the quality of your work: refactor those resource-hogs and take the time to seriously watch your application run.