|
This is the first in a series of articles that will investigate professionalism in programming. Given that the ACCU exists to promote 'professionalism at all levels', these articles are going to delve into what this apparent oxymoron means. We will be addressing what makes a 'professional' programmer.
I hope that for many for you this series will be instructive. For others the issues raised here may seem 'old hat'. Please don't let that make you dismiss what will be discussed. A lot can be learned from simply seeing things that you take for granted written down.
These articles are aimed at both people who consider themselves 'professionals' and people who aspire to be professional.
So what is this professionalism?
Although that's the question that this whole series addresses, let's try to briefly define the term 'professionalism' at the outset. We'll also touch upon the concept of 'software engineering' on the way. The dictionary tells us that a professional is simply a person who performs a given activity as a career - i.e. for money. But that's not the spirit of what we're talking about here.
A professional field is one which requires training, experience and ability. The word implies a level of responsibility for what you do. Software engineering undoubtedly requires all of these. Being a professional implies seeking to be the best at what you do. Even if it's not your primary job function, or if you're not yet employed, it is natural and useful to aspire to this professionalism in what you do.
If professionalism involves seeking to be better, this means actively seeking to learn appropriate skills. Perhaps one of the most important qualities in a professional is to appreciate what you don't know - and to be aware of how to learn it when you need it. The skill most hackers[1] seem most proud of is the ability to blag it - pull something together at the last minute. These kind of pieces of work are almost always hideous hacks. This is not professional. This is not to say that hackers cannot be engineers.
We should also define here the term 'software engineer' since it is pivotal. It implies more than just a paid programmer. Software engineering is not just sitting at a keyboard banging out programs, software engineering is using a defined process to develop software predictably, reliably, on time and within budget (or at least aiming to ;-).
In the same way that structural engineers should follow a rigidly defined process to design and build a bridge (you wouldn't drive over it if they didn't, would you?) software engineering follows a process which leads to the development of high quality software. We'll develop this description further in a later article.
The madness in our method
The articles in this series will not focus simply on the single word 'professionalism', but will discuss topics ranging from coding style to working practices to our attitudes. Maybe some of the topics will not seem directly related to the banner 'professionalism' (or at least no more than any of the other CVu articles). However, what I am trying to pull out is the professional perspective that we should adopt behind each particular issue.
| 
