- A real programmer "thinks code" all the time. Not just at work.
- A real programmer is a problem solver. He/she can’t resist trying to solve a problem when presented with one, may it be computer related or not.
- A real programmer constantly try to improve himself and his applications, going back to fix old code to work better/faster, make the user interface better and more efficient, etc.
- A real programmer understands the need of user/customer and can come up with solutions for them.
- A real programmer have a set of functions in his "toolbox" that can be used in different applications, saving developmenttime.
- A real programmer can learn new languages and tools when needed. Knowledge about the syntax of a languages does not make you a good programmer, knowledge about how to write efficient and useful code makes you a good programmer.
Lotus Notes is a great tool, and I enjoy developing applications using the RAD capabilities in Domino Designer. But I also create some web applications on occasion.
This past week, when Hurricane Alex was moving in towards Texas, John, the CIO (and my boss), grabbed me first thing Wednesday morning and asked me to build a webpage. He wanted me to use the Google Earth plugin to consuming some KML files he created from the policy database (built using Visual FoxPro).
As I blogged about a year ago, I wrote some code to get the latitude and longitude for an address, and John had then rewrote the code for FoxPro so he could get the coordinates for the addresses he had in his system. So he could now very easily generate a couple of KML files, one of all our policies and one of the policy holders potentially in the path of the hurricane.
I built the webpage in a Domino database, that is usually the easiest way for me to put up a simple webpage. I added some overlays, the two different KML files that John created. I also found a KML file online with different projected paths, as well as one of the current path of Alex. The users could turn on and off these layers as they wanted. Suddenly it was very easy to see if we had any insured customers in the path, etc.
Of course, the same web page could as easily have been created using Notepad or any other tool, as it was pure HTML. But my next plan is to integrate this page with other Domino data, and we are talking about building a generic reporting tool with all different kind of geographic data. Imagine being able to map every accident/insurance claim, see where the accident happens, where the insured is located, etc. Perhaps run statistics showing the average distance from home the accidents take place, etc.
I think it is critical that I, as a Notes/Domino developer, show the power and business use of Notes by integrating it with different systems. When I first started working at this company, I was tasked with building a claim system, to handle insurance claims. The company had hired a pair of Notes consultants, who set up the environment and attempted to build a claim system. They failed, and they also told everyone that Notes and FoxPro could not talk to each other. Of course, when I came in and sat down with my (then) new boss after a few weeks at the new company, we quickly figured out a way to get the systems to communicate.
It took about 90 minutes to come up with the solution (using COM), write the basic specifications (yes, they changed some over the years, but not much), build the COM object and write some test code in Notes. Today, that COM object is used for all kind of things we never envisioned back then, in 2002. It even sends PDF files into our document imaging system.
Of course, it helps to have a CIO/manager who talks and thinks development. I don’t have to explain things that are obvious to me, we can go straight at the business logic or functionality. Something that would take 10-15 minutes to explain to a regular manager just takes seconds or a minute.
My next project, which I will start on Monday, is a database to document the claim system. There are so many design elements, with different functionality and access rights. Some buttons are hidden from certain users, using roles or document status, other design elements are restricted in other ways. Very little of this have been documented over the years, and I need to get all that documented in a good way. That is the power of Notes: I have a need, I build a solution.