I have been doing SQL database programming, hands-on coding of queries and procedures, since 1986. One of my work-study jobs as a college student was as a data-entry clerk of information about prospective students and applicants. That was into an antiquated file-based system with simple (but poorly designed) entry screens and BASIC batch processing. At graduation they hired me as one of a two-man team to convert that spotty mess into a better-designed relational system using Oracle 3, doing the data modeling to match the desired business processes, and redoing all the reporting, batches, and entry screens. We spent three years (1986-9) carefully rewriting the entire administrative system for the college. I had already done quite a bit of BASIC programming through high school (1978-82) and college (82-86), and I took PASCAL courses during my job, for further professional development.
Overlapping the end of my graduate work in music, from 1993-6 I went back to SQL programming again to pay the bills. This was in an Oracle environment moving toward client/server applications and data warehousing: large data sets refreshed daily from mainframes into relational tables for reporting and decision-making purposes. I worked on graphical querying environments for the users, did some data-entry screens for stand-alone Oracle projects, and met several times a month as a member of the DBA and power developers' groups to discuss designs and optimizations. We built some fairly complex views and calculations to reorganize data, drilling down by different levels of abstraction. Those strategies and programming optimizations (indexing, use of EXISTS clauses instead of IN clauses, efficient normalization, etc.) continue to be useful even when the flashy add-ons around the SQL layer are perpetually changing in Oracle's, Microsoft's, and other competing packages.
When HTML and the web started to blossom in 1994, I began to work in that as well, developing many static web sites. I moved to Virginia in 1996 to marry my wife, and took a job as a web applications programmer. I developed database-driven (SQL Server) systems for university/college administration, again using my previous content experience in that area. In autumn 1998 we took one semester off and led a university trip to Ireland. Part of my job there was to write, edit, and post the group's blog for the students' families and friends back home (and done with direct HTML coding and FTP uploads, since this was long before any blogging or wiki tools). Upon returning to my programming job, I was assigned to upgrade the touchtone telephone application for university course registration. I discovered that I especially enjoyed the challenges of that environment.
In 1999 I moved on to a job that would allow me to continue developing touchtone telephone projects and interactive web systems. The web projects at first were in a proprietary environment, and then we switched to use classic ASP (Active Server Pages) for better standardization. I developed the standard models for other programmers on the team to use, with reusable bits of JavaScript, Cascading Style Sheets, and functions for other repetitive web programming tasks. It is much easier to copy and then change a tested and working model, than to restart every project from scratch. I built the standard FAXing components for the company's core product, and a standard (resellable) web interface for another core product that did wholesale-order transmissions.
The telephony projects were in a proprietary scripting language called ScriptWrite. It was a powerful and typical programming language with buffers, stacks, subroutines, operators, conditionals, loops, and functions around the telephony commands such as DIAL, ANSWER, SPEAK, or INPUT. We also had a GUI and object-oriented environment called ScriptExpress to generate, document, and debug ScriptWrite code. It did very well at abstracting repetitive code blocks into reusable packaged components, and a well-organized system of resource files. The graphical interface could be printed out itself as part of the documentation of call flows.
Because of the interactive and unpredictable nature of telephony applications, many objects and commands had error branches and configurable behaviors for timeouts, busy signals, invalid response, dropped transfer, network unresponsiveness, etc. The telephony commands themselves required close control of pauses and continuations in the output, the reuse of carefully-worded phrase recordings, and the design of intuitively-clear user interfaces (asking the right types of questions the first time so the caller won't be confused or frustrated). As an expert harpsichordist (where control of timing and delivery is "everything"), I especially enjoy handling these types of timing issues in communication. That contributes to my skill at IVR design, development, and testing. I am much more interested in the user perspective toward the system than the nuts-and-bolts technology at the wires and switches. I love to build things in which the timing has to be just right, and in which all the odd exceptions get handled and tested properly for reasonable behavior. Badly-designed telephony user interfaces (other people's!) annoy me as a customer, because I know how to do them correctly.
I quickly attained a senior level of expertise in coding and debugging telephony applications in both ScriptExpress and ScriptWrite, writing new projects or upgrading old ones. We moved gradually into Nuance speech recognition alongside the touchtone functions. I was one of several programmers given the most complicated projects and most delicate business relationships with the clients, because of ability to deliver carefully planned and well-documented work. Many of my projects continued to use and refine my SQL skills: making data-driven IVR applications, storage and reporting environments, and building the DTS/SSIS layers to import and export data to other host formats. Most of that was in SQL Server 2000, plus a SQL Server 2005 project in 2007.
I continued to build web-based utilities as administrative parts of these IVR and speech recognition projects. I learned XML and XSL formatting well enough to accomplish assigned tasks: delivering working systems and documentation. My managers also gave me copy-editing tasks on technical documents, and the writing of project estimates for the sales staff. Often I was the one called in by managers and teammates to look at troublesome systems (whether during development or in go-live emergency), and find the elusive bug in design or code, because of my knack of quickly grasping structures and noticing any anomalies. I was also the one tasked with testing other people's Spanish or bilingual applications, and finding where a wrong question or ambiguously-worded phrase was causing user errors.
Some of my team-oriented skills come in through my wife's expertise: she directs an academic department and teaches university courses in conflict resolution and peace studies. Everyone's needs must be respected and served, and in some way that is mutually beneficial to all parties. People state their requirements in different manners, or sometimes fail to state them well; someone has to figure out what is really needed, all around. That has always been one of my own programming skills, too: taking a step out to the big picture to be sure a business process really makes sense, beyond supplying the technical functions that were asked for.
In 2004 and following, in spare time, I have continued a part-time career with music performances and a major academic research paper (published by Oxford University Press in 2005)...and have maintained a web site (www.larips.com) to organize and publicize that work. My music work is and has always been more "right-brained" than "left-brained", and I thrive on the conceptual level of projects. I love to build things, try them out, to experiment with different parameters in them, to get to the essence of an idea in best balance. My best computer projects are like that, too: refine the system until its quality is clear and obvious, and until it can meet untrained users where they are.
All of this creative business gradually took me away from the classic computer programming languages, and the newer emerging languages (C, C++, Visual Basic, C#, .NET, AJAX/JavaScript, et al), from simple lack of opportunity to use them day-to-day. We had "much bigger fish to fry" than such a basic level of coding. However, it did give me excellent experience dealing with client requirements, prohibitively difficult security systems (working as a developer/vendor without access to the client's machines!), complicated business rules, basic SQL Server administration, speech recognition glitches, usability, VPN connectivity, and the perpetual need for clear documentation. I am always careful to document all my code changes at several levels (line, object, flowcharts, manuals) to make the business processes clear, and to give a clear versioning trail for myself or other programmers revisiting the project in support.
My best value as a creative programmer/analyst comes from this business experience of integrating disparate parts of projects, extensive testing with clients, clarity of requirements, and the ability to help colleagues do their jobs in support. With wide exposure to different systems I see patterns and concepts. Things I learn in playing music, playing bridge, and playing with my young children inform the way I approach my business as a thoughtful computer programmer.