Looking Back

Someone sent me this post on 40 years of programming. It’s a read that laments a few things and complains about many others. Most of the thoughts are opinions, and as such, you may or may not see validity in them. I suspect most of you, like me, see some things are mostly true and some as just false. Since I’ve been in this business for nearly 30 years, many of the comments bring back memories and thoughts about my career as well.

One of the things I do lament is the declining quality of documentation. I’ve seen the volume and detail decline over the years. I wouldn’t want to go back to paper, but I would like to see better examples and more complete examination of the ins and outs of the various functions and features. Far too often I find that there are examples, explanations, or behaviors that are missing. I see the same thing in blogs and articles, which often leap and skip steps in their race to publish.

Focus and detail on a specific topic has been forgotten by too many. Even understanding the way your code works, or the ways the dependencies work has been lost. As more and more people move to using NuGet and pulling down packages, I find too often that many developers don’t quite understand how their systems work. The divide between those that practice DevOps well and those that just release code faster continues to grow. Few learn from their efforts and produce smoother software development pipelines. Most release code faster, losing track of which versions and dependencies that are required.

I still see projects from GitHub and other sources that lack explanations of how to actually compile and setup the project. It seems far too many developers half release software, expecting others to spend time learning what works and what doesn’t. What versions were used, and might be needed again. Maybe in some places the software evolves so quickly, adopting new methodologies and technologies constantly, that developers never need to truly understand the system. They just get things working and then change them.

Maybe that’s why so many people want to rewrite and reproduce software rather than using some existing project and improving on it.

The one thing I do wish was in all languages is a standard way of handling data types and comparing them. I constantly struggle with = and == when I move away from SQL. The comparisons in PoSh make no sense, and I regularly get errors from > until I change to -gt. It seems plenty of language designers want to make their own creation and cause divergence for no good reason. I do wish SQL had implemented == for comparisons, or that they would in the future.

As I look back, some things in computer science haven’t really changed at all. Speed and scales have grown, but many concepts remain the same. However, in other ways, I think we’ve come so far, building amazing systems that are interconnected in ways that we might never have imagined a decade ago, much less 30 years ago.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 4.4MB) podcast or subscribe to the feed at iTunes and Libsyn.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial. Bookmark the permalink.

2 Responses to Looking Back

  1. pianorayk says:

    There is a reason why my SQL Saturday presentations have revolved around tech writing and documentation. It has changed, and not for the better; I’ve seen organizations that don’t document ANYTHING, and I strongly believe they’re setting themselves up for failure. I’m giving a SQL Saturday talk called “Tech Writing For Techies.” If anyone is in Albany, NY for SQL Saturday #622 on 7/29 (a week from tomorrow), come check it out.

  2. pianorayk says:

    Reblogged this on Welcome to Ray Kim's 'blog and commented:
    This is a reblog of a post from my friend, Steve Jones. He touches on a topic that is near and dear to my heart, and one that I strongly believe is crucially important.

    Nearly all of my SQL Saturday presentations have revolved around documentation and technical communication. Technology may have changed over the years, but the importance of documentation has not. I strongly believe that documentation is getting to the point where it is being dangerously ignored, something that we, as technical professionals, cannot afford to do.

Comments are closed.