º Understanding SoundEx
º CSV File Format
º Temporality
º Dell Svc Tag Algorithm
º Round Table Corners
º Menu Flowers (exercise)
º Show XML in I.E. Browsers

º Points for Programmers
º CTXTM File Format
º Hybrid Oriented Programming
º Software Stability Ratings
º The JSMsg Convention
º Glosssary XML
º CUFTM Codes

Managing IT
º The LOC Monster
º The Un-Methodology
º Continuous Independence
º Agile Bridge Building
º Platform Neutral Computing

Random Notes
º C.S. Vs Olivier
º Seeing Through Hype



Points For Programmers

Sorry* Alinskyites . . . *not sorry


There is no rule-of-thumb for function-size. — A function ("method," "subroutine") should be just as big or small as it needs to be, and (this is important) NO SMALLER. There are a variety of concerns that can affect the determination of how big or small "it needs to be." These sometimes include trade-offs regarding performance, function-versatility, code-maintainability, and resource usage just to throw out a few. They should NEVER include aesthetic, herd-based, fashion concerns.


You know less than you think about the client's business — Recognize that there is considerable interplay during the requirements-acquisition phase between you and the Dunning-Kruger effect. If you have ever said, in response to a client's expressed requirements: "They're probably not going to need it." there are dominatrices standing by who will be happy to strip you, hog-tie you, and flog you until you agree never to refer to yourself as a programmer again. Don't worry, they are well versed in how to put the pen between your teeth, and hold the clipboard so you can sign the contract. In fact, I wouldn't be surprised if some of them own ball-gags with pen-holders built right in.


Simplicity is hard — Perhaps, when reading that, you thought to yourself in classic Dwight Schrute fashion: "No it's not. Simplicity is, by definition, simple." Could our disconnect here be simply (sorry) that you were thinking in terms of making things simpler for THE CODERS, rather than for THE USERS? If so, please report to the dominatrices introduced in Point-2, above. It's possible you may actually enjoy that sort of thing, and that's okay. Unicuique suum. No judgment at all. At least not in THAT regard.


Comments are good. — The net effect of explanatory comments can be extremely helpful and edifying. They provide HUGE advantages in understanding and time-savings when returning to code. Yes, old comments that have been inadvertently left in the code (or not marked as OBSOLETE), can be misleading, but just KNOWING that is enough to almost completely alleviate the time that might have been lost otherwise. No, you can't write code that explains itself with anywhere near the nuance, and subtlety that a well-written explanatory comment can. If you've convinced yourself code can do this (I'd guess because you just don't LIKE to write comments), please introduce yourself to the ladies. There's no reason you can't start practicing for your encounter with them right away. Say: "Thank you mistress. May I have another." . . . I like the way you say that.


Don't give up on the craft. — If you've altered existing code so that it enables[NOTE-1] bad software to continue to be written by bad software writers, then you are giving up on the craft, the vocation, the discipline, and the art that is programming. You should feel something deep down in the pit of your stomach about doing that. . . at least, you should if you are a programmer.


Rubber-bands, tape, band-aids, and bubblegum should be avoided and cleared, whenever possible. Knowing exactly what is happening in a failure is not the same as knowing how to properly fix it. Simply throwing in some code to solve the immediate problem without taking a holistic (metta? higher-order?) approach may (at times) be required, but it seldom leads to a durable fix. In fact, it almost always leads to a brittle section of code that will come back at you in the future. Code that is filled with such patchwork fixes and feature-additions is holistically fragile, and becomes increasingly difficult to add features to going forward.


Don't fix a design oversight with marketing. — You may be very passionate about software, but if your first love; that thing you were born to do; that thing which is truely the thing that you live for; is marketing, you will be tempted to fall back on the thing you know best when life gets bumpy in your software endevor. Don't do it!

Consider that you may have developed your way into a really tough corner with your software, and —because marketing is the thing you can rise to any challenge in— the solution that will seem most natural to you will be one that is marketing-based.

To make this example more concrete, let's say you've developed a bit of software that will hold a particular server-side interpreted-code program in memory, keeping it persistent so it runs faster and with fewer server resources. Your design gets you to an application that runs really well, but hits a snag, in that it completely drops all file-scoped variables within the interpretted-code scripts that it keeps in memory.

If your first love is programming, it will not even occur to you to do anything other than to simply correct your design. If, on the other hand, your first love is marketing, it will likely be much easier for you to promote the notion that scoping variables to the file-level is "bad programming practice." Don't do that. You may fool some noobies, but people whose first love is programming are likely to see right through it. If you must, find somebody who is as passionate about programming as you are about marketing and convince them (that's what marketers do, right?) to help you fix your program.

[NOTE-1]     return
That may need some explaining. As an example, consider the folks who are convinced they are programmers-extraordinaire, but who write web-pages that suck down every last byte of spare memory in the user's entire system <cough>#!%facebook#@$%<cough>. To do things that continue to enable these bad software writers hurts —first and foremost— them. Thanks to you, they are able to continue to delude themselves into staying in a profession for which they are ill suited. Secondly, it harms the users who are unnecessarily spending countless man-years waiting a few seconds each time, for their suspended pages to re-build when they return to a tab. Finally, (and this is where this kind of enabling really betrays the craft), it punishes good programmers — those who don't produce code that has delays and leaks like a flood-gate.


This article is © Copyright, Creativyst 2022 ALL RIGHTS RESERVED.

Links to this article are always welcome.

However, you may not copy, modify, or distribute this work or any part of it without first obtaining express written permission from me Production and distribution of derivative products, such as displaying this content along with directly related content in a common browser view are expressly forbidden!

Those wishing to obtain permission to distribute copies of this article or derivatives in any form should contact Creativyst.

Permissions printed over any code, DTD, or schema files are supported as our permission statement for those constructs.

© Copyright 2022, Creativyst, Inc.

Written by: Dominic John Repici