It has been said that most programmers in their '20s are in their prime and they know everything. It has been said that most programmers in their '30s are good at hanging on to their job with the skills they learned in the last 10 years. It has been said that most programmers north of their '40s are just knowledgeable on what has been done and are always viewed with suspicion because their skill set is believed to be 20 years out of date. It has been said that most programmers just north of their '50s have limited knowledge of today's languages and technologies since their skill set is 30 years out of date. It has been said that most programmers in their '60s should have already retired or must be hiding in the mainframe closet because nobody remembers what languages or technology knowledge they could have known.
Why would you decide either overtly or covertly to not continue learning? If you are a lawyer most states require Continuing Legal Education or CLE to maintain your standing in the bar association. Lawyer in many states, you must have additional hours in professional responsibility and ethics and other courses. Engineers, depending on their specialty, may be required to complete Professional Development Hours or PDH to maintain their state license. Some states require as well some hours for professional ethics as well as other courses. Software engineers are not considered real engineers and almost all states do not require a license. However, if you call yourself an engineer in some states you can get into a bit of legal trouble if they find out you are just experienced in software.
Could this be why most programmers do not consider themselves to be software engineers? Could this be why most programmers loath learning a new skill or even being certified on some vendor products? Could this be why year after year the skill set of programmers on balance never grows? Could this be why when a new release of the database, or a new release of your particular programming language specialty that the documentation sits unread?
Well some of us think this should not be the case. On average the databases, I work on are updated every 18 months. The manual that comes with it has to be read from cover to cover to see what changed or to see what I have forgotten. The latter is most often the case but I digress.
The database Universe started supporting JSON through a library call. There was little fanfare on the normal sites I look at. The documentation supplied by Rocket Software was very poor with no decent examples. About 5 years later there was a good example from one of their engineers a little late for me. Nonetheless, I was able to wade through the syntax and get an idea of what it could do to replace our hand-coded string builder. I converted our handed coded JSON string UniBasic code to create JSON objects using the new functionality. For the most part, it took about 2 days to get the production code changed to use this new library call. Ironically, to create JSON the new way was not much faster until the strings reach about a megabyte then the code was much faster. Below is a sample of the changes.
SET.PROPERTY.OLD:
JSON = "" ; ADD.IT = @FALSE
MAX.FM = DCOUNT(PARAM1,@FM) ; * Example: CustomerName:@FM:Address
FOR X = 1 TO MAX.FMT
IF ADD.IT THEN JSON := \,\
JSON := \"\:PARAM1<X>:\":"\:PARAM2<X>:\"\ ; * PARAM2 is the data
ADD.IT = @TRUE
NEXT X
RETURN.ID = "{":JSON:"}"
RETURN
SET.PROPERTY:*
JSON = ""
RTN.STATUS = UDOSetOption(UDOOPTION_OUTPUTMODE, UDO_OUTPUT_COMPACT)
RTN.STATUS = UDOCreate(UDO_OBJECT,udoObj)
MAX.ROWS = DCOUNT(PARAM1,@FM)
FOR X = 1 TO MAX.ROWS
RTN.STATUS = UDOSetProperty(udoObj,PARAM1<X>,PARAM2<X>)
NEXT X
RTN.STATUS = UDOWrite(udoObj, UDOFORMAT_JSON, JSON)
RTN.STATUS = UDOFree(udoObj)
RETURN.ID = JSON
RETURN
Our main entry tool web browsers get updated every 6 to 8 weeks. When they do update there are two things that always change for us such as JavaScript and CSS language support. It took 7 plus years for Firefox to fix a problem with the cursor moving to the URL after an AJAX call instead of the next column in the data table grid. Of course, this worked in Chrome but we had to put in a dead function call to not lose tab support to create a workaround for our Firefox users. Nevertheless, you have to read the developer notes to see what is new, what is changed, what is fixed, and what is no longer supported.
Somewhere around 2016 ES6 JavaScript language brought arrow functions also called fat arrows. They are used to help in writing concise functions. It took a bit of practice to understand what they can do for you. Nonetheless, there was some push back from clients and staff asking why would a programmer go into working code and change just because JavaScript had new features. Again, they are not wrong but the why is important here.
The word that describes "fat arrows" is that they are concise. Why is that not a good thing? Learning new things can introduce bugs that have been routed out. Maybe since some of this code was written in the early 2000's it could use an update and the next set of programmers that would not roll their eyes when they talk about this old code if it is constantly updated as standards change. Below is a sample of old and new code.
oDrivers = [{"id":"1","value":"Unitas"},{"id":"2","value":"Brisco"}]
// Old Code
for (var i=0;i<oDrivers.length;i++){
if (oDrivers[i].id==DriverNo){
driver_name = oDrivers[i].value;
}
}
// New Code
var driverItem = oDrivers.find(obj=>obj.id==DriverNo, true);
driver_name = driverItem.value;
If you are not willing to learn then maybe it is time to retire from programming. Or you could look into another profession that requires less continuous education suggestions. Or if you are so inclined you could get promoted to management. See the Dilbert Principle for more informed comments on management style and substance.
