Programmer Professionalism

I repeatedly hear, as a programmer, that I should be concerned with my overall professionalism. I should be concerned with the quality of what I produce, the knowledge and experience that I have obtained through work and education and the attitude I bring towards solving complexity.

I should be a professional, no different than say a doctor, a lawyer or an engineer. Engineer is even in my title, it is so clear.

On the other hand,  I also feel that I should be more like a tradesman or a craftsman. Learning under a master on a linear path that never ends, always improving.

Here is an analogy that I used to describe programmer to my father, a tradesman.

Working as a programmer is not too dissimilar to building a house. There is an initial design, planning of the work, sign-off on everything  and then the actual building commences.

Only recently have we started practicing the fact that the user must be involved if we want to succeed. The strict set of rules to follow in design are always changing, especially if the designer is constantly self improving, as they should be.

Programmers must both design and build the systems they work on. They are a tradesman (builder) and a professional (designer). With all these different expectations and the only constant being change, it would be surprising if one person was capable in one of these directions.

We will probably never have a clear Apprentice to Journeyman to Master tradesman approach nor a professional accreditation. What we will have is the highest expectations any career has known and so much change that we will never be able to agree on things of consequence.

Object-Oriented Design Basics

In order to achieve each of the metrics defined previously we can employ some very fundamental techniques. Techniques that should appear to be common sense, hopefully. Though broad in scope and concept, they are the basis for much of what we currently try to achieve in programming.

Abstraction

The notion of abstraction is to distill a complicated system down to its most fundamental parts and describe these parts in a simple, precise language. Typically, describing the parts of a system involves naming them and describing their functionality. For instance, take a design pattern such as the Abstract Factory. When I use this pattern, declaring its name in the class definition, I am telling the next programmer what this class is supposed to do without documentation and without comments. When I declare some class called, CarFactory, a programmer should know that an instance of this class with provide instances of Car objects.

Encapsulation

Another important principle of object-oriented design is the concept of encapsulation or information hiding. Encapsulation means that different components of a software system should not reveal the internal details of their respective implementations.  In general terms, the principle of encapsulation states that all the different components of a large software system should operate on a strictly need-to-know basis. There is a common saying surrounding this, “TELL, DON’T ASK”.

One of the main advantages of encapsulation is that it gives the programmer freedom in implementing the details of a system. The only constraint on the programmer is to maintain the abstract interface that is visible. Encapsulation aids in adaptability because it allows the how to change without altering the expected outcome.

Modularity

In addition to abstraction and encapsulation, a principle fundamental to object-oriented design is modularity. Software systems typically consist of several different components that must interact correctly in order for the entire system to work properly. Keeping these interactions straight requires that these different components be well organized. In the object-oriented approach, this structure centers around the concept of modularity, which refers to an organizing structure in which different components of a software system are divided into separate functional units.

The structure imposed by modularity helps to enable software reusability. If software modules are written in an abstract way to solve general problems, then modules can be reused when instance of these same general problems may arise under a different context.

Problematic Processes

I have always disliked following process for the most part. There is something dehumanizing when I enter into the conversation where I am told about some event and then told what I am expected to do. I understand what processes are in place for in the broader sense and often try to discover the particular reason for each process before I will follow it. Generally though, the employer wants workers A through Z to all behave in a similar fashion. Why though?

Consistency. If all your workers do the same thing, then they will be consistent in their day to day work. This also means they are predicable and replaceable. Each worker is desired to be a replacement for any other as long as they follow the same processes. Is that a good thing?

In some case, I would argue yes it is. There was a time in my life when I worked on an assembly line  and process would make or break the productivity. Each day followed a specific process, breaks followed a process, each task always had a specific and predicable process. When the feeder has space, put in another tray. When the pallet of trays are gone, get another pallet. Very rudimentary process that is basic and practical. Often this process is the discovered best techniques of what you are supposed to be doing and essentially giving you the optimized way to do each task. Do this because it has proven to be the fastest or most maintainable way of doing things. Great I say.

However, bureaucratic process is a whole different beast. The domain is larger, the number of employees usually greater and the types of tasks being done much more complex. Process in this case is often more to do with getting each groups interests met rather than providing the most efficient or maintainable way of doing things. That is the part I dislike. A giant muddled mess of wide concerns, each at a different level of importance based entirely upon your current job, department and/or pay grade. Yuck.

Thinking about how many concerns are no longer valid or important will only depress you further. How much of your day is spent doing tasks that don’t provide any benefit to you, your employer or your employer’s customers. You can tell things are bad when you ask, “Why do we do X?” and you get a response such as, “Because legal wants us to” or worse, “Because I told you to”.