About half of the below consists of conventions for what word I use when. Unfortunately, chances are that I forgot them relatively soon after writing them down—and the reader is advised to take them with a grain of salt. (By February 2012, when I did some general reviewing, I found that I did not even recall having conventions...)
TODO: Go through the articles and ensure consistency; possibly, with a revised set of conventions.
I will typically use the word developer when referring to anyone involved in the actual development (not including specification, testing, maintenance): Coders, programmers, (software) designers, architects, engineers, whatnot.
The main reason is that the exact role of any individual discussed is often not relevant to the discussion. Should an exception occur, I will not hesitate to use a more specific term.
Further, the other terms are often poorly defined, have varying meanings from organisation to organisation, greatly overlap, or are otherwise unsuitable. Often the distinctions are even artificial (in particular, in small organizations) with a developer spending time doing anything from coding to architecture (and a number of other things too, e.g. documentation or database administration). In fact, there are some developers who argue that “programmer” is the only term worth using. I would not go quite as far, noting that the ranks of programming are evermore flooded by persons who have no idea of what they are doing—just like any other profession. (Whereas, in the past, the average “quality of mind” was noticeably higher than the global average.) Further, “programmer” has over the years become associated with low-level work, and could be misunderstood.
Apart from “developer”, I will typically use the following words:
| Coder: | Someone who currently engages in the act of coding |
| Programmer: | Someone whose main work is doing development at a comparatively low level of abstraction/conceptualization, and within a comparatively small scope of the application. |
| Designer: | Similar, but at a mid level and a mid-range scope. |
| Architect: | Similar, but at a high level and a wide-range scope. |
| Tester: | Depending on context: Someone whose main work is testing, someone currently assigned as a tester (it is not uncommon for this to be a temporary role, assigned to whomever can be spared during a test phase), or someone who currently engages in testing. |
The above list was added after a lot of content was already written. It could expand as I notice other uses in my writings (or, obviously, add new texts).
“Tester” is a complication: Only when writing the list, did I realize the multiple uses the term has in my own thinking. I might need to introduce additional, more differentiating, words later.
I will typically use “application” as the word for an end-product; including e.g. libraries, where the word, in the strict sense, does not apply. (Beware that not all libraries are end-products.) Alternatives, e.g. “program”, have similar or other complications.
“Artifact” in turn, will often be used as a more generic word signifying a reasonably stand-alone (in the current context) unit—it could be an application, an individual class, a library, ...
There is a great confusion from language to language about what to call methods/functions/procedures/sub-routines/routines/whatnot. Mostly, I will go with the Java convention of “method”, glossing over the differences that often occur between the exact meanings of various terms. On occasion other words will be used, e.g. when specifically discussing a non-Java language. (Similarly, I tend to use Java terminology for other programming concepts.)
I often discuss issues from a code-centric view. This does not mean that the discussions apply only to code—on the contrary, they are very often valid over a wide range of activities, including (m.m.) design and architecture. For more general principles they need not even be limited to software development.
The reasons for this choice include:
Code is relatively hands-on, and it is easier to write good examples and express thoughts concerning code than, say, architecture.
While opinions on what is good code, coding practices, etc., can vary, the differences in opinion on higher levels are much greater. Further, the accumulated knowledge that humanity has on more abstract levels is significantly smaller than where coding is concerned.
All developers will typically have a background in coding, likely even do coding today; beginning programmers, OTOH, will rarely have non-trivial experience of more abstract levels. (The average hobby programmer might have no such knowledge at all; but he is also unlikely to read these pages.)
Without developing an understanding of code, it is hard to become a proficient designer or architect (even when actual coding has become a thing of the past)—it can even be argued that many deficiencies showed by e.g. project managers would be diminished if they had some understanding of coding.
Coding remains at the core of software development: It can be argued that most other activities are just attempts at compensating for the wish to build increasingly, sometimes ridiculously, complex and feature-loaded software. If the industry returned to the Unix philosophy (unrealistic wish) of “do one thing, and do it well, “small is beautiful”, etc., then we would have better software, less need for concerns about requirements, architecture, project management, ...—and coding would again become the main concern of everyone involved.
This would also:
Drastically reduce the number of developers needed, leading to a higher quality of the developer corps.
Make it impossible for companies working along a Microsoftian model to make money. Notably, this marketing driven, add-more-and-more-features-so-we-can-sell-something-new, approach is responsible for much of the really third-rate software available today. Contrast this with, as a beautiful and contrary ideal, TeX πw.
This is obviously from a developer’s POV: The entire process involved will include other important factors, most notably finding out what the users want and need; however, this will all take place on a very different scale, in a different format, and with a different focus—e.g. in that the users actual needs are met, instead of building gigantic lists of what the users should need (from the POV of product management/business development) or what marketing and sales thinks will be attractive to various decision makers in other companies.
Design and architecture, similarly, will remain important, but be smaller, easier to correct after the fact, often be doable by the individual developers (with very many projects only involving one developer in the first place). Etc.
As of 2023, virtually all of the contents in this category were written during my period as a Java developer, and much of the writing is (consciously or unconsciously) Java-centric. However, the general principles will usually hold in a non-Java context.
Later writings might reflect other languages/environments/whatnot.
The following is an automatically generated list of other pages linking to this one. These may or may not contain further content relevant to this topic.