D
o
c
u
m
e
n
t
s
 
Tech/How-to
º Understanding SoundEx
º CSV File Format
º Temporality
º Dell Svc Tag Algorithm
º Round Table Corners
º Menu Flowers (exercise)
º Show XML in I.E. Browsers

Conventions
º 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

 

Conventions:

Points For Programmers

Sorry* Alinskyites . . . *not sorry





Point-1

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, and resource usage just to throw out a few. They should NEVER include aesthetic, herd-based, fashion concerns.




Point-2

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.




Point-3

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.




Point-4

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.




Point-5

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.




Point-6

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.




Point-7

If you've got known, reproducible, and tractable bugs, and you make a full features-release that doesn't include fixes for those bugs, this paper isn't for you. Notice, it's titled Points —For PROGRAMMERS—. If this statement describes you, you are not —by any stretch of the meaning— in that set.









~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
[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.







Permissions

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.
ALL RIGHTS RESERVED

Written by: Dominic John Repici


v1.0b