My First Post in the Learn to Code Tribe was titled White Space Wars.
White Space is the area around the code. Coders should be attentive to white space. The substance of the code is the logic of the code.
For my second post, I thought I would touch on a deeper problem: How does one create value with code?
This second question is far more important than the first. If you wish to land a job coding; then you need to write code that is worth more than the salary you receive.
In school one might learn coding for the sake of coding. In the real world employees must find a way to justify the expense of coding to a jealous employer. Self employed coders must find a way to justify the expense of their time.
In this regard. HIVE is a wonderful forum for discussing code, because HIVE is centered on an economic model that rewards users for posts.
How do I create a post that is worth the BYTE that I will receive for the post?
When I program, I tend to wax philosophic about the value created by the code.
There is some intrinsic value to good code. Just as one can say "Art for the sake of art!" One can declare "code for the sake of code!"
We live in a world saturated with art. It took less time for me to create the image for this post than it did for me to write this paragraph. I created the image by writing a phrase. To publish the image, I had to save to disk and upload the saved file.
BTW: I find it interesting that NightCafe has the background artwork raising the same defiant fist as the coder. The NightCafe image shows live imitating art.
It took very little time to create the image. How much value did it create?
When one writes code, one needs to consider the value created by the code.
Defining Business Rules
Coding can help businesses define and hone their business rules. Students of business history will see a tremendous improvement in product quality. There were major improvements in efficiency. The improvements were not the direct result of code, but resulted because the code forced companies to analyze their business rules.
Creating Long Term Value
I ended up writing code for an insurance company. Insurance is a long term game. For example, a life insurance policy is a legal agreement that must last for the life of an individual.
I realized that programming styles would change during the life of a policy. I realized that the data the program collected was far more important than the code. I suspect that the company has since replaced the code I wrote. They are still using the data the code gathered.
The data was the thing of value. A quality datastore needs to last indefinitely.
The same statement is true for most academic research. Quality academic research involves building up large quantities of quality information over time.
The Data is the Deliverable
When I write code, I see the data created by the program as a primary deliverable of my project. I want my programs to produce data which is clean, coherent and legible.
A student of programming history would find that early programmers were often more interested in the data that they produced than in the code itself.
I think that programmers should study the data that their programs create.
I would like you to take a second and right click on this page. Many browsers have the option "view source."
I regularly check out HTML for web sites that I visit. Most programs produce really sloppy HTML. I like to produce clean HTML as I see the HTML as the deliverable.
The Political Mind
The constructive mind focuses on creating value.
Unfortunately, the productive elements of our society are subordinate to political elements.
The political mind is driven by a desire for power.
When the political mind looks at programming, the political mind jumps to the question: "How do I use this technology to gain power?"
The political mind will look at coding and ask: "How can I use this code to disrupt my enemies and build my power base.
Since the political mind can't create, it seeks to disrupt and to gain power with the disruption.
People who gained power during the last disruption ask the reactionary question: "How do I prevent the next generation of coders from doing what I did to gain my position."
I usually find myself in conflict with the political mind. Unfortunately, since political minds gain power, one often forced to cowtow to the demands of politics.
Conclusion
IMHO Programmers shouldn't just look at the code they create. Programmers who want to make money by coding should look at the value that their creates. Code that doesn't create value is just white noise.
The code you create should create more value than one's salary.
When I code I consider the business rules, aka workflow, set by the code. I also look at the data as a deliverable. I spend more time obsessing over data format as I do over the names of the stupid variables in the stupid program.
So, to end this piece, I would like to look at the Google NGram for several coding terms. The ngram shows the number of occurences of words is a subset of publications. The ngram below looks at the terms "xml,sql,json,csv"; Sadly the data ends at 2019. It would be fun the see the last five years.
SQL is a query language used in many relational databases. There was an attempt at the turn of the millennia to make XML the standardized mark up language for industry, government and the Internet.
In 2000, W3C tried to force people to use an extremely terse version of HTML called XHTML.
It didn't take.
JSON (JavaScript Object Notation) is a relatively streamline notation designed for pushing data between Javascript programs. It was adopted as a standard between 2014 and 2017.
CSV (Comma Seperated Value) is type of flat file that was used by Microsoft. As the name implies, CSV uses commas and quotation marks to delimit text. This is problematic because people use commas and "quotation marks" in their writing. Different languages use different marks. This means that people have to use complex code to escape the commas and quotes in the text.
I used the term "CSV" because it indicates that there is still a great deal of interest in flat files.
With flat files one defines the structure of the data on the first line. In json one distributes the data definition throughout the file. Flat files tend to be smaller and it is easier to code for flat files.
I was surprised to see that the term SQL has dipped in popularity.
SQL is a query language. SQL doesn't change with time. So, I guess that people don't write about it all that often. A SQL query written in 1987 will still work today. In contrast coders need to spend hours to get JSON formatted properly.
The rising popularity of blockchain technology and JSON shows that coders still consider the data created by programs to be a primary deliverable of the code. This is a good sign.
