Friday, November 18, 2011

Working Below the Radar: Make Yourself a More Valuable Employee, or Prospective New Hire

Note: The following is meant to refer to “add-on” level software that may be created with compiled languages such as C#.NET or VB.NET. It is not meant to refer to the creation of applications with integrated, proprietary interpreted languages such as VBA (Visual Basic for Applications), or AutoCAD’s LISP language.

Most of the large “out of the box” software tools used in today’s office work environment have a built-in customization capability. This customization capability allows the tailoring of data flows, processing, reporting, etc. A customizer niche (which is often unoccupied) is created by the facts that:
· Most users of the software do not know how to make use of these capabilities, or may not even be aware they exist.
· The above goes double for levels of management above the software users.
· Users who do not understand how to customize usually also are not aware of what types of customization could possibly be accomplished by others, so are not even at the level of making a “wish list”.
· There is usually no time or money available to train an employee on how to do desired customization.
· There is usually no time or money to hire a professional programmer to address such needs.
· If a professional programmer were hired there would have to be a formal contract developed that would fully list expected functionality and interfaces, and the final software tool would not be capable of being further evolved or revised.

In order to occupy this niche, the occupier will have to find for himself alternative motivation(s). Some possible motivations are:
· An opportunity to be creative. Someone familiar with the existing work practice can imagine or envision software tools that would increase speed and/or quality of work. It is quite satisfying then to create such tools and integrate them into an upgraded work process. Many technical jobs do not allow for as much creativity as an employee would like. Here is an opportunity to add that desired creativity as an avocation.
· Increased quality and quantity and even standardization of production, which increases the morale of the software tool user (which could be the customizer or other employees), while decreasing stress in meeting commitments and dead-lines.
· Some broader use software tools that have a high ratio of utility output to programming time input may be suitable for issuance as freeware or shareware to help to “raise the baseline” of what users of the software in other offices or companies are capable of accomplishing, and so in a small way contributing to an upgrade of production and a resulting upgrade to the economy.
· If any such shareware tools are popular enough, there may be a (usually) small financial return on the programming time invested.
· If any such shareware or freeware tools become popular enough they may serve to motivate the parent software company to incorporate them into new revisions of the parent software.
· Opening new doors by learning programming languages and becoming experienced in their use.
· A long-tenured successful niche programmer may find it desirable to “work himself out of a job”. Possible reasons for this are:
o Most or all of the large-scale customizations are done in the current job, and he would like to have further opportunity to upgrade a new work environment.
o He may want to help lower or remove some of the barriers to hiring a “green” or less-experienced employee by enabling such an employee to continue an existing viable level of production through the use of such software tools. If he has put a lot into upgrading his current position he will probably feel a strong desire to see it be continued into the future at the higher levels of quantity and quality of production he has achieved.
o He may have acquired sufficient experience to work exclusively in software development (doubtful).

If a person decides to become a “niche programmer” here are some guidelines he may find useful:

· He should plan to do most, if not all of the programming as an avocation rather than as part of his vocation. This means devoting enough of his own time to complete the creation of such software tools.
· Prioritize prospective projects according to improvements in the work flow versus time required to effect them.
· Try to get a “payback” of work flow improvements as quickly in the process of development as possible, so that the increased production can then be used to justify further development/debugging of the tool.
· Break down larger projects into smaller “steps”, or levels of functionality that can each be brought into service on their own to increase productivity and also serve as a base for further steps to build upon.
· Use existing tools regularly in the work process to help justify the development of other tools.
· Try to leave “hooks” in software tools that can be tied into or built out from with future tools.
· Try to incorporate consistency in the interfaces and functionality of such tools.
· Do not let other employees use developed tools until:
o They are fully “Beta tested” and are stable (will not crash).
o They have a simple, straight-forward GUI (graphic user interface), incorporating normal Windows functionality (or at least a subset of it), and have a complete compiled Help file that can be accessed from the GUI and gives a description of the functionality, purpose and usage of the software tool, and supplies a FAQ section.
o They meet any other agreed-upon criteria (see below).
· The niche programmer will have to realize that he is his own boss in the process of software development.
o Since he is not being financially compensated for his work he must maintain his independence from hints, directions or orders of others as to what should be developed.
o He should be sensitive to the inputs of other employees in regards to the GUI and functionality, realizing that a large part of the acceptance of a new tool is the affinity another user has for it as a result of
§ Ease of use
§ Low learning curve
§ Significant improvements in desired areas
§ “transparent” invocation or even self-invocation on an event-driven basis
o He should work out an agreement with his supervisor regarding criteria that must be met by his software tools before they can be entered into use by other employees. Such agreement should be made AFTER he has developed at least some software tools for his own use and has made significant use of them, but BEFORE he allows the use of such tools by other employees.
o He should make an effort, with the cooperation of his supervisor and other employees to collate in a central location any tools he has made that qualify according to the agreement mentioned above.
· He should realize that many companies have an employee agreement that stipulates that software developed on the job becomes the property of the company. For this reason (and for the larger reason that such development is usually not even possible at work due to the lack of an Integrated Development Environment for the chosen development language) he should do all development and compilation of larger jobs on his own time (not at work). He should also recognize that the final compiled tools he develops to the point that they can be used by other employees will then become the property of the company (if he has brought them into the office place), but that he retains full control of the source code as long as he has developed and compiled it on his own time and outside of the work place.
· He should write straight-forward, maintainable source code, realizing that at least some of the tools he creates for a particular company could also be modified for use in a possible future job in another company.
· It is recommended that the niche programmer maintain a profile “below the radar” of the IT (Information Technology) group of his company. The reasons for this are:
o The IT group usually likes to maintain the large view. This means pushing for standardization and automation rather than getting pulled into particularization. All forms of customization will be a type of particularization. Keep such off the IT plate.
o The niche programmer should recognize that there are limits to the size and scope of a project that he is capable of developing. These limits may become larger as he gains experience, but they will always exist.
o The niche programmer should always be a “good IT citizen”. This means that he should never need special attention or resources more than any other user, and that he should never jeopardize existing IT resources, such as shared network drives, shared databases, etc.
o Some guidelines to use for being a “good IT citizen” are:
§ Never write programmatically to a file or database on a network or shared drive.
§ If a database is used, make it a small, local, proprietary database. Any requirement for a large, frequently-accessed, or shared database will be a sign that the prospective project is beyond the reach of a niche programmer.
§ Keep programmatic data storage within a standard file-type of the parent software to a minimum (e.g. within AutoCAD drawing files, or Office application files).
§ Limit himself to no more than the development of “add-on” software to parent software packages that can be added by individual users and that operate in the local workspace of the parent software.
§ Do not modify, or even read from the Windows Registry.
§ Do not require that the user would need Administrator privileges on his account to make use of a developed software tool.
§ Do not require an installation program to be run.

All of this takes time and commitment. It is not for everyone, but it can be quite valuable to upgrade some of the lower-level workplace data management activities that take place at the “Indian” level.

Tip to employers:
While it is not legal to require or direct such software tools to be created by an employee on their own time without compensation, there is nothing wrong with regularly assigning tedious, repetitive tasks that are crying to be automated to someone who is capable of creating software tools to automate them and has shown a desire and willingness to do so. ;) Just be careful not to state or imply the need for such automation, or set unrealistic timetables for the completion of such work that could only be met with the use of automation unless you are willing to compensate for the creation of the software tools or allow them to be created in the workplace on company time. Remember, there are lower-level programming languages such as VBA and AutoCAD’s LISP that can be used for on-the-job development of general or ad-hoc solutions for simpler tasks.