Computer Programmer And Analyst As A Consultant
Job Title: Programmer/Analyst
Education: MS, Mechanical Engineering University of Bridgeport, 1993; BSME, Mechanical Engineering, 1978
Job Tasks: I'm currently working as a consultant, developing computer programs for customers. For the client at which I was working most recently, I was updating their computer-aided engineering (CAE) system's Product Lifecycle Management system (PLM), the system used to maintain the design information - drawings, parts lists, documents - for the company's products so the PLM system could continue to be used for about the next five years.
Here's what's required with this project:
- Get the specifications from the customer. For good software development, the specifications must be thorough and unambiguous.
- Examine the current software. This was written in a mix of Fortran and C, communicating in SQL to a relational database management system (RDBMS) on an IBM mainframe. A significant issue was the need to preclude damaging the database's integrity, especially due to problems in ASCII to EBCDIC conversion (ASCII and EBCDIC are different methods for representing characters on a computer).
- Determine how to make the required changes.
- Write a set of test cases. While I perform some preliminary testing, the customer also performs acceptance tests, and giving them test scripts was needed so they would know what to test, and what to expect.
- Move the revised software into the production environment.
Most software development jobs have work flow rather similar to this: Specifications from a customer, design the software, write it, make it work, give it to the customer's testers, and install it.
Best and Worst Parts of the Job: I tend to find the best parts to be finalizing the specifications with the customer, designing and writing the program, and writing the documentation for the user and for any programmers who may need to maintain the program in the future.
The worst part is writing test cases and writing estimates.
1. My first piece of advice is to take at least one course in technical writing and at least one in public speaking. Expository writing is an absolutely critical skill for any technical professional, as is being able to make a coherent presentation. The fact that you may have Powerpoint on your PC doesn't mean that one can make a presentation, just as having a wrench doesn't make one a mechanic.
2. My second is to take as many technical courses outside of computer science as practical. A programmer has to be able to translate requirements from professionals in the areas of engineering, physical and natural sciences, social sciences, graphics, and business into software. This can't be done if you're not familiar, at least at an academic level, with the basic knowledge of the domain.