I’m planning on this post being the first in a series about my naïve thoughts about the significance of Software Engineering as an undergraduate with little so-called real-world experience. Stay tuned for followup posts, which I’ll post back here.
For the past several decades, computer programming has been done in special programming languages which can be either interpreted or compiled (translated) into a form which is natively comprehensible to computers (known as machine code). The original programming languages (the Assembly family of languages specifically) were very simple, used for the simple purpose of avoiding the tedium of needing to program directly in machine code, but which otherwise required the same effort and had the same exact meaning as the machine code it translated to. Later on, slightly more powerful languages were created which could encapsulate more machine code into less words which in turn more closely resembled English. This eventually culminated in the development of Object-Oriented and Functional programming languages, which allow programs to be phrased in terms of programmer-defined nouns and verbs — thus giving birth to a large part of Software Engineering.
In a sense, this ability to program in arbitrary nouns and verbs (which have special significance to the computer) allows a programmer to tell a story to other programmers in his code by defining and composing simple words. There is a dog and a cat and tuna fish. The dog barks. The cat runs away. The dog eats the tuna fish. The does not know or care what a dog, cat, tuna fish, barking, eating, or running mean in English because it can still make the story happen. On the other hand, if another programmer comes along, s/he does care what those words mean, and s/he needs to either know or be able to easily find out. In order to edit the story, or even follow it, the other programmer needs to follow the story and understand exactly what is going on.
However, with only a limited language, expressing a complex story may become extremely difficult. After hearing the terrible throaty barking of the Mastiff, the Tabby cat questioned her own self image, and so fled the scene! Although English (or any other human languages) gives us the linguistic devices necessary to convey such a thought, not all programming languages inherently do, which in turn requires structuring a more complex series thoughts as an idiom of simple thoughts. This is where many neophyte programmers go astray.
Many programming languages are inherently limited in that their “linguistic structure” is limited to nouns, verbs, and occasionally prepositions. Therefore, writing a complex story at some point or another will require defining idioms to continue expressing complex ideas. Without using idioms when appropriate, or perhaps worse, when creating inappropriate idioms, one can horribly muddle or confuse the story being told (even to him/herself). Although the code underlying the story may still be comprehensible to a computer, if another programmer cannot follow the story, it defeats the purpose of telling it!
At a young age, we are taught in school about language and how to express complex ideas so that they are understood. When learning computer programming, it becomes necessary to learn a similar art for conveying complex ideas in terms of programming entities which both may have universal semantic meaning or at the very least may have implicit cultural meaning. This is in no small part the meaning of Software Engineering! Computer Science stops after teaching the words and defining them for computers — it takes Software Engineering to weave a comprehensible story out of it. Much like with spoken languages, although becoming conversational only requires knowing the basics, being fluent requires more, and is an art unto itself. If you want to consider yourself fluent in computer programming, you should also ensure that you speak the same language as other programmers.