|
I graduated from Dartmouth College in 1969, and got a Ph.D. in Experimental Pyschology from the University of California Santa Barbara in 1978.
As an academic research Psychologist, I was mostly a data junkie. I spent more time on data analysis, data management and experimental design problems than on theoretical work. When my wife took a faculty position at Rensselaer Polytechnic Institute in 1980, I realized that radical adjustments were required--realistic prospects for an academic career were unpromising, to say the least. So, I took advantage of RPI's superb technical environment and joined the Masters program in Computer Science.
With that change of direction, I spent the next two decades developing mostly financial applications for mostly Wall Street firms, using a variety of programing languages on a number of different platforms, at various levels of management responsibility.
The problem was that which I most enjoyed doing,
and for which I was clearly tempermentally best suited,
was application development--hands-on creation of programs that worked.
But, invariably it was the management role that was most appreciated,
best understood, and most highly compensated. I did very well in
strictly career terms as a technology and business manager. I was
particularly effective when
the core problem was to understand the business so well that we could
develop solutions that really worked
for the business side.
But I never developed any real passion for that role,
and the higher I got in the management structure the further I got
from actually building anything.
Ultimately the conflict between the desire to be hands-on with development versus the severe career constraints for that option got to me. I left New York City, finance, Wall Street and the corporate world to set out as an independent consultant and developer in upstate New York, centered in the Capital District of Albany, Schnectady and Troy. The bet was that I could build a consulting practice on an ability to bridge the worlds of business and technology, on being able to communicate effectively with practicioners in both.
In Albany I met up with Paul, who I had known for almost 20 years and with whom I had occasionally worked on Wall Street projects. We found we had compatible expectations, work styles, and knowledge sets. So, we created Merle+Culbertson as a corporate vehicle within which we could work together to exploit the synergies in our skillsets.
As a very small company focusing on software development (an endeavor for which team efforts are the norm, with sometimes the team approximating the size of a small army!) we have come to embrace the web as our natural environment. The tools, problems, options and affordances that come with the web are what make it feasible for a small shop in upstate New York to take on serious work, something that would have been very difficult under earlier development models.
For me personally, the web has opened up a whole new realm of possibilities. I have done quite a bit with it, but feel I have only just begun to exploit the options it opens. Almost of my previous programing experience had been in a client-server paradigm. My rate of learning of new tools and concepts and techniques had slowed over time, partly because I was doing more managing than building, but also because the paradigm was getting pretty mature. The paradigm shift to programing in a web-centric environment is quite interesting. One result is that I am again continually learning, exploring new approaches. It is renewing and stimulating.
It's not all gold, of course. It can be frustrating to work within the constraints of this medium--in particular the stateless exchanges between browser requests and server response can be limiting when you have always taken for granted the total control over the entire set of conditions and logical settings in a client-server application. The browser itself can be limiting, with its somewhat impoverished set of GUI controls and behaviors. And the continuing security issues around identification, verification and validation of your user are an order of magnitude more difficult where you are not safely embedded in an internal corporate network. However, the freedom that comes with being able to access the application from anywhere, with never having to install an application on anyone's desktop while making updates instantly available everywhere, more than compensates.
It is most intriguing that the Relational Database Management System, which has been a standard component in most client-server application software stacks and has played a major role in almost all the applications on which I've worked over my career, is just starting to be exploited to provide real service in the web-centric application space. It is this marriage of web services and database services to create dynamic web-enabled applications where most of my work and explorations are now to be found.