Click here to Skip to main content
15,122,003 members
Articles
Article
Posted 23 Feb 2017

Tagged as

(untagged)

Stats

5.8K views
1 bookmarked

On Being a Programmer: A Reply

Rate me:
Please Sign up or sign in to vote.
5.00/5 (4 votes)
23 Feb 2017CPOL13 min read
This started out as a comment to John Simmons' "Being a Programmer," but it grew so large, it became its own article.

The Programmer's Serenity Prayer

Lord, grant me the serenity to accept that there are some things I just can't keep up with, the determination to keep up with the things I must keep up with, and the wisdom to find a good RSS feed from someone who keeps up with what I'd like to, but just don't have the damn bandwidth to handle right now. (©2009, Rex Hammock)

Introduction

John Simmons, in his recently highlighted article Being a Programmer, brought out many good points, all of them valid. I find myself agreeing with him on all points. In this article, I would like to amplify some of his and add a few points of my own.

Coding, for me, is not just my profession, but also my hobby. I wrote my first program in PL/1 as a college freshman in 1968. I started getting paid for writing code in 1969. That is forty eight years ago. Over the years, I have worked in FORTRAN, Dartmouth BASIC, PL/1, Pascal, APL, BCPL, C, C++, C#, Ada, Visual Basic, Structured Query Language(SQL) and assembler language for IBM 360, Data General Nova, DEC-PDP (several), Perkin-Elmer (nee Interdata), Intel 80x86, Motorola 680x0 and several others. I have worked for both large and small companies, both in and out of Department of Defense contracts. (Getting into defense work is easy. Getting out is more difficult: how do you answer questions about what you did for your last employer, when what you did is classified at Secret, Top Secret or at levels above Top Secret and are forbidden to talk about it?)

In the Working World

Most programmers, myself included, are employed by a corporation. This puts you in an office where you may be a solo contributor, but are most often are part of a team. Each team, each office and each employer has its own unique culture. During orientation, you will be briefed by human resources and by your immediate boss on the formal organizational hierarchy. You will quickly find out that there is an informal hierarchy of people whose friendship and good will are key to getting the better assignments in the better projects. This informal hierarchy is part of the political structure of you coworkers.

Yes, I am talking about office politics. As a programmer, and especially as a newbie, I would advise you to observe carefully and keep your mouth shut. Most programmers I know, including myself, do not have the strong social skills to successfully maneuver or to exert control in this space.

While I am speaking on office politics, there are a few topics best not discussed in the office unless you are very sure of your audience. The top items on this list are rates of pay, unions, gender issues, racial and sexual discrimination, political parties, politicians and philosophies, closely followed by your and your friends' sex life, partying, medical problems and legal problems. Discussing from the first group pigeon-holes you in the minds of others and from the last group, is sharing too much information. Each organization also has its own informal list of taboo topics.

When you start work in a new organization, you start out as a stereotype — the newbie. This stereotype is temporary. As people get to know you, they will start to pigeon-hole you in their minds. As human beings, we all tend to try to group things and people. When applied to people, these groupings are stereotypes. Sharing too much information or discussing controversial topics will make pigeon-holing you easy. This reduces you to a stereotype, making people less interested in meeting and getting to know you, unless there is something unique and interesting about you.

Meetings

Whether you are a member of a team, the leader of the team or a solo contributor, you will have to attend meetings where the primary topic is supposed to be the project you are working on. Always listen carefully and take notes – that part of the project that is currently furthest removed from the parts you are assigned may, after a few key resignations and reassignments to other projects, become one of your parts of the project. You are the newbie, therefore you get the least interesting work.

Taking notes helps you keep track of the whole project, the issues that may bite and the progress made. At meetings with the customer, promises are often made or implied that will effect the ultimate success of the project. Meetings with sales and marketing people are the worst, filled with promises that cannot be kept, schedules which are vague or unreasonable, requests for features that are misstated and lots of just plain “puffery.” Sales and marketing people excel at the pretty sales pitch that implies everything but says nothing. Taking notes gives you an anchor point for discussing the project with your boss, or with other stakeholders at the meeting. Make sure you list the attendees in your notes.

I strongly believe that after every meeting with people outside of the project, a memo of understanding should be drafted. It should contain a synopsis of the discussion and a list of action items to be performed and who is tasked to perform each.

Your Log Book

I find it very useful to keep a log book or daily journal. In some jobs, my employer or the contracting agency mandated that each team member keeps one. This should be a bound quadrille book with pre-numbered pages. In it, record what you did, who you discussed ideas with, what decisions you made, what meetings you attended along with the notes of that meeting, and so forth. The use of quadrille paper allows for graphs and charts to easily be drawn.

The log book thus tracks the distractions, changes and progress of the project. It is also useful when, months or years later, a new project team is assembled to upgrade your old project. You do not have to rely on your memory of the original project.

Design

Take great care when designing your code. Try to think ahead, to take a best guess where changes will be required in the future and then isolate these areas in easily replaceable modules. Design for maintainability and document your design. Most of the life cycle of any product is the maintenance phase. A maintainable design will save your company money (and maybe save you considerable effort) in the future. Most products contain user interfaces. If you are designing or implementing a user interface, remember that it will be used by a wide variety of people. This is one place where diversity in your company and your project team becomes very important. The use of your interface seems obvious to you: you created it. To others of the opposite gender, opposite handedness, members of different racial, economic or cultural groups, or different educational levels and backgrounds may see your interface as confusing. Work with the customer, when possible, and with diverse members of the project team to refine your interface.

When designing new tables for a database, be aware that database administrators (DBAs) have a very different idea regarding appropriate names for tables and field names than programmers. Our fellow CodeProject member Daniel Miller makes that clear in his article SQL Server Table and Column Naming Conventions. Also, depending upon which database they are using, they may strongly opposed to defining custom data types. It is best if you can represent the custom data types of your program in the basic data types available in the database.

Coding

Let's face it, writing code is where the “rubber meets the road” and, as such, where most of the work will be. I will break this down by topic to help keep this monograph readable.

Comments

This is the first subtopic because I believe it is the most important. When coding a module, I often write the comments first. I divide my initial comments into two groups: header and body.

The header comments I place at the top of the module. In these, I name the module and include with this the name of the project and a brief statement of the project's purpose. In the next paragraph, I explain the purpose of the module, followed by a brief description of the design. I end the header comments with a change log, with the first entry giving my name, the date, and “Original version.”

I follow the header with comment sections for, in order, global public data types and variables, global private data types and variables, public properties (.NET only), public entry points and, lastly, private routines. I place the code for each section immediately after the comment block.

Data Declarations

It is widely agreed upon that variables should be named descriptively of their function. I follow the practice, which I recommend highly, of including an indication of the type of the variable in the name. For those who remember FORTRAN, variables in that language beginning with the letters I through N were, by default, INTEGER and all others REAL. When possible, I use the first three or four letters of the name to indicate the type:

  • intName — integer
  • decName — decimal
  • chrName — single character
  • strName — string
  • boolName — boolean
  • dtName — date-time
  • enmName — enumeration
  • stxName — structure
  • dsName — .NET data set
  • tblName — .NET table
  • rowName — row from a .NET table
  • colName — column in a .NET table
  • evnName — .NET events

where Name, of course, is the descriptive name. For data types I define, I extract a three or four letter abbreviations for the type name and use that. Make up your own scheme and stick to it. It will save you precious time when you are looking at a snippet of your code and trying to debug it.

Always initialize your variables, even if you initialize them to NULL or Nothing. This will instantiate (allocate space for) them. Some systems still do not automatically instantiate and initialize variables, especially local variables, upon declaration. If you try to use an uninitialized variable, you may get an inconsistent nasty surprise. And, let's face it, inconsistent bugs are difficult to find.

Use the highest level appropriate data type. Yes, you can define a table as an array of arrays — it works. But in .NET, your code is clearer if you use a .NET table and rows with named fields. Instead an array of strings, use a List, Ordered List, or Collection of type string.

Data Conversion

Conversion of types is common. Always use explicit conversions, especially with custom data types. When you are declaring your own data type, remember to include conversions and common operators. Always override the .toString conversion so it displays just what your design needs. And do not forget the subtypes. For example, if you derive a money data type from decimal, US dollars may be assumed at first. Expansion of the customer base may require adding other subtypes, such as Euros, Mexican pesos, rubles, Swiss francs and so forth. If the value is US$11.54, converting decimal with .toString yields “11.54.” Overriding this conversion allows you to get “$11.54” Adding a .toLongString function allows “eleven dollars and fifty-four cents.” For strings, I always define .toTitleCase and .toSentenseCase The first capitalizes the first letter of each major word in the string and the second capitalizes the first word of the string. If I need to compare strings, I define .trimMiddle to reduce the white space, such as tabs and multiple spaces, to single spaces.

Code

You will probably find that your favorite language is not the one you will be coding in. Every organization has its own set of rules for which language to use and how to format your code. Where I am working right now, the languages chosen are Visual Basic .NET and SQL. To access the databases from code, SQL must be used. LINQ is not an option. For actual code, Visual Basic was chosen because “the auditors can read it.” Good thing the budget was too tight to pay for a COBOL .Net compiler. I might not have taken the job, if I had to use my least favorite language, COBOL.

It is important to make your code readable. While many of you younger programmers are very comfortable doing everything on screen, many of us older programmers prefer to work on paper. Yes, we actually print a listing of the code. I find this especially helpful while reading someone else's code. It also really helps when the code is poorly commented. I can actually write on a listing, keeping track of my understanding of the code I will be revising.

Learn the features of the language you will be working in. Every year or two, Microsoft releases a new and improved version of their compiler and debugging environment, Visual Studio, introducing new features along the way. Learn them and use them — they will make you code easier to write.

In Conclusion

In spite of all I have just written here, I do not know everything. I have seen many “great ideas” for programming practices rise and fall again, just like a fashion fad. A very few have ever arisen again. Some language features have faded away (goto) while others (while – do, do – until, for each, raise event, try – catch) have risen and held their ground. The key here is that hardware and software always are changing and that regardless of whether this is your first job as a programmer or your 100th, there is always more to learn. Once you have worked for a few years as a programmer, take the time to teach and mentor the newcomers who are following you.

Programming can offer you a long and satisfying career. Finding the right job for you and keeping it through the economic turmoils of the modern era is a real challenge. Companies have come and gone. The once mighty IBM and the BUNCH (Burroughs, Univac, NCR, CDC and Honeywell) have faded, replaced by Cray, Motorola, Digital Equipment, Data General, only to be replaced again by Intel, Microsoft, Hewlett-Packard, Dell and many others.

The field has broadened tremendously during my career, with the creation of minicomputers, desktop (micro) computers, laptops, tablets, “smart phones,” graphical interfaces, the Internet, mobile devices, businesses relying on “always on” satellite communications, artificial intelligence and now, the “cloud” and the growing Internet of Things (IoT).

Our modern world has grown overly dependent upon the work of us and our predecessors. It is said that a major failure of the Internet blasts us back to the Nineteenth Century. We need to always take care to do our individual best on every commercial program that we write or modify. We may never know how the customer routes the output of our effort into the bigger picture of modern life, until the day comes that some latent bug causes our code to fail, crashing some major system that millions interact with daily.

One closing thought: in the words of the immortal Jimmy Doohan as “Scotty” in Star Trek III: The Search for Spock (1984):

The more they overthink the plumbing, the easier it is to stop up the drain.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Jalapeno Bob
Software Developer (Senior) S & D Acres
United States United States
BSEE 1972, Polytechnic Institute of Brooklyn, Brooklyn, NY
MSCS 1978, Stevens Institute, Hoboken, NJ

Now, I live in Texas with my wife and children and raise non-dairy (aka "meat") goats and chickens for fun and (maybe next year) profit.

As a hobby (we all need one, don't we?? Smile | :) ), I write agriculture related software.

Comments and Discussions

 
GeneralMy vote of 5 Pin
Member 1236439026-Feb-17 22:55
MemberMember 1236439026-Feb-17 22:55 
QuestionGood Working Relationships Pin
Paul Drury24-Feb-17 23:23
MemberPaul Drury24-Feb-17 23:23 
QuestionWisdom Pin
jrobb22924-Feb-17 10:51
Memberjrobb22924-Feb-17 10:51 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.