I
InterSystems Developer
Guest
This great article sparked some recent private discussion, and I'd like to share some of my own thoughts from it.
The motivating concern boils down to: Why do we need coding rules or conventions at all? What happened to the wonderful era of the Renaissance artist-programmer forging their own path, prior to being supplanted by the craftsman and now (even worse) by AI?
In short, there are a few reasons why coding standards/guidelines are useful, and the Renaissance artist-programmer is not entirely gone.
Reason 1: These days, when youβre training a true novice artist, you start out by having them try to color inside the lines. This artist might be brilliant someday, but not yet. If you want to learn to produce art, you do that first; then gradually learn techniques and concepts from the masters; then, if youβre really good or really lucky, set your own style and produce something novel the rest of the world will want to follow. But you need to start out by following the rules.
(note: found this on the internet; none of my children yet possess such skill.)
Reason 2: If youβre operating in an area where your niche of creativity must fit alongside that of others β something like a patchwork quilt β then you need some rules to play by or the art wonβt work because the pieces donβt fit together. You can either agree on the convention of βwe all make 40cm squaresβ or else have to work even more closely and collaboratively with a bunch of other people, which the solitary spend-4-years-painting-a-ceiling artist might not be the best at doing. (Especially if management decides that a few other such solitary artists need to be pulled in to βhelp.β)
(ChatGPT came up with that for me. Apologies to actual artists everywhere.)
Reason 3: If youβre working on an existing, particularly-old or particularly-brilliant piece of coding art, you often face the challenge between understanding and embracing the original authorβs intent and elegance of design and execution or just saying βIβm in charge now, weβll chuck it and do it my way.β Iβll give an example here: one web-based application I've worked on makes heavy use of βXML pagesβ where you have a trio of (pageName.xml, pageName.js, pageName.mac) that constitute a page. pageName.xml was, until more recently than I'd like to admit, probably written in this weird "WD-xsl" dialect that closely resembles standard XSLT but only works in Internet Explorer Microsoft Edge if it's pretending to be IE5. pageName.js probably contains "frame" about 40 times more than is comfortable. pageName.mac is probably full of dot syntax, short forms of commands, and incoherent macros. If youβre a new developer, you just cry and run away because it makes no sense. If youβre a senior developer, you read it and make some sense of it, then decide βthis is gross; Iβm going to do it better some other wayβ β but then the next person to work on the application needs to learn the original paradigm and your new clever paradigm. Extend that over 20 years and you have a real nightmare. But if youβre really an expert artist, you can do art restoration β see the elegance in the original framework and work within it, gently fixing the architecturally inconsequential things that make the new developer cry and the senior developer hit "delete", without creating a fragmented mess or taking on years of work repainting the whole thing. Maybe you'll even produce your own work in the style of the old master. The most important lesson from this tale is that, as a real artist, you have a vested interest in producing work of such quality that someone who inherits it without your years of experience wonβt decide to throw it all away - and the "little things" like code style, readability, and addressing technical debt go a long way in helping, preserving the architecture if not every single line of code.
So, in summary:
Continue reading...
The motivating concern boils down to: Why do we need coding rules or conventions at all? What happened to the wonderful era of the Renaissance artist-programmer forging their own path, prior to being supplanted by the craftsman and now (even worse) by AI?
In short, there are a few reasons why coding standards/guidelines are useful, and the Renaissance artist-programmer is not entirely gone.
Reason 1: These days, when youβre training a true novice artist, you start out by having them try to color inside the lines. This artist might be brilliant someday, but not yet. If you want to learn to produce art, you do that first; then gradually learn techniques and concepts from the masters; then, if youβre really good or really lucky, set your own style and produce something novel the rest of the world will want to follow. But you need to start out by following the rules.
(note: found this on the internet; none of my children yet possess such skill.)
Reason 2: If youβre operating in an area where your niche of creativity must fit alongside that of others β something like a patchwork quilt β then you need some rules to play by or the art wonβt work because the pieces donβt fit together. You can either agree on the convention of βwe all make 40cm squaresβ or else have to work even more closely and collaboratively with a bunch of other people, which the solitary spend-4-years-painting-a-ceiling artist might not be the best at doing. (Especially if management decides that a few other such solitary artists need to be pulled in to βhelp.β)
(ChatGPT came up with that for me. Apologies to actual artists everywhere.)
Reason 3: If youβre working on an existing, particularly-old or particularly-brilliant piece of coding art, you often face the challenge between understanding and embracing the original authorβs intent and elegance of design and execution or just saying βIβm in charge now, weβll chuck it and do it my way.β Iβll give an example here: one web-based application I've worked on makes heavy use of βXML pagesβ where you have a trio of (pageName.xml, pageName.js, pageName.mac) that constitute a page. pageName.xml was, until more recently than I'd like to admit, probably written in this weird "WD-xsl" dialect that closely resembles standard XSLT but only works in Internet Explorer Microsoft Edge if it's pretending to be IE5. pageName.js probably contains "frame" about 40 times more than is comfortable. pageName.mac is probably full of dot syntax, short forms of commands, and incoherent macros. If youβre a new developer, you just cry and run away because it makes no sense. If youβre a senior developer, you read it and make some sense of it, then decide βthis is gross; Iβm going to do it better some other wayβ β but then the next person to work on the application needs to learn the original paradigm and your new clever paradigm. Extend that over 20 years and you have a real nightmare. But if youβre really an expert artist, you can do art restoration β see the elegance in the original framework and work within it, gently fixing the architecturally inconsequential things that make the new developer cry and the senior developer hit "delete", without creating a fragmented mess or taking on years of work repainting the whole thing. Maybe you'll even produce your own work in the style of the old master. The most important lesson from this tale is that, as a real artist, you have a vested interest in producing work of such quality that someone who inherits it without your years of experience wonβt decide to throw it all away - and the "little things" like code style, readability, and addressing technical debt go a long way in helping, preserving the architecture if not every single line of code.
So, in summary:
- Rules and conventions let you train new brilliant artists before they're brilliant
- Rules and conventions give you a fixed canvas to exercise creativity without needing to waste time trying to get along with people
- Rules and conventions let you make something beautiful that will not be thrown away by the first person to inherit it
Continue reading...
