Better SQL is a Good Career Investment

  • I 100% agree with this article.  At least I believe it was true in my case.  In my best position as a DBA, my first position with the company was called SQL Developer, from which I moved into the DBA team.  I was always impressed with the power and simplicity of SQL, and first joined the company specifically developing stored procedures for several very large VBA multiple application front-end  packages for a nation-wide dealer network.  My first focus was developing the stored procedures in tandem with the VBA developers and working on improvement and optimization of performance.  Efforts to minimize front-end data manipulation created the need for hundreds of stored procedures to be used on the remote dealer network of SQL Servers including large scale replication  processes including hourly and daily data movement.  Eventually the project evolved to having 5-6 full-time DBA's building and handling over 50 local and remote SQL Server instances.

    Through this project I was constantly learning and improving my SQL skills at the same time as doing database design and server building.  I discovered that I enjoy SQL work much more than front-end coding, love the challenges of database design and data manipulation.  SQL Server has been my favorite flavor for years, and at 78 years old I am still honing my SQL for personal use and am constantly becoming more skilled in the built-in functions in SQL Server sql.

    I found that database design was somewhat cyclical as projects came and went,  but the need for well-designed SQL was an ongoing challenge that I enjoyed.

     

    • This reply was modified 1 month, 1 week ago by  skeleton567.

    Rick

    One of the best days of my IT career was they day I told my boss if the problem was so simple he should go fix it himself.

  • Congratulations skeleton567 on your seniority in programming! Have you worked on mainframes?

    In my opinion there are two basic skills needed in programming SQL (or any other language): mechanical and engineering.

    The mechanical side has a good handle on the features of the language, which is critical for choosing the right features, debugging, and so on.

    The engineering side views these features as tools to implement some vision on how to solve a problem.

    For example, I recently worked on a large ETL project moving school districts to the cloud. It was expected that I would use SSIS (which I really like) but it couldn't handle really ugly flat files where new columns had somehow been randomly introduced into some records. So we used Python. That was a mechanical problem. But then, during the migration, the target system forced me to assign virtual PERSONS to student contacts who were entered free-form with tons of duplications, inconsistent information, etc. The mechanical side wanted to me to GROUP BY the contacts in some way to build those persons, but it was a mess. That's when the engineering side realized that simple graph theory would do the trick in a natural way.

    Both skills are important, and employers should not focus exclusively on the list of acronyms after your name.

    After all, if you're renovating your home, what's the first question you ask the carpenter? It won't be about what's in his toolbox. Rather, what's he done in the past? Ditto for brain surgeons.

     

     

     

    R Glen Cooper

  • Glen Cooper wrote:

    Congratulations skeleton567 on your seniority in programming! Have you worked on mainframes?

    Glen, great pun there on the 'seniority'.  My career began back in the 60's on IBM 360 and older machines, and later on included Burroughs/Unisys and on to Dec/Vax machines, but in the early 90's moved to the PC world when I got to the Windows environment.  Early on I was enthusiastic about the Apple offerings, but soon became disillusioned and never looked back.  At one point in the 80's I did go back to a community college for night courses to do a bit of catchup in the mainframe  world just in case an opportunity came along.   Once I moved into DB design and development, over the years I used DB2, DMS II, Ingres (the worst DB system ever!).

    I don't recall the earliest version of SQL Server that I worked with but it was in 1991 when I went to Bandag, Inc, now a part of Bridgestone-Firestone, as my last employer.  They were a large IBM installation and were moving into Windows and SQL Server to support remote applications across their world-wide dealer network.  The closest I came to mainframes was when I  went into our server farm which was next door to the 'computer room'.  There was some batch interfacing of SQL Server to it, then using SQL Server Replication to communicate with the dealer servers.

    Of course now I am very obsolete in all but the Windows world and fast becoming obsolete here too!

    I had a funny experience this morning in a doctor's office where a lady mentioned that she had a few years on me because she was in her 60's.  Then I told her I turned 78 last spring!

    I really enjoy SQL Server Central because it keeps me in touch with what you all are facing and dealing with now.  Otherwise my wife and I regularly share a bottle of our favorite wine on the patio and have lots of younger folks in the 'hood who stop in and visit after their workdays.  We have 4 business owners, an attorney, and a Toll Road Commissioner as neighbors.  I think maybe they are attracted since I keep a good supply of red and white wine and amber beer.  We also have a famous Amish community about 40 miles away that has wonderful smoked cheese and sausage that I get in regular shipments.

    Yesterday I ordered myself a new 32" 4K UHD monitor as the second display for my i9 laptop.  Yes, SQL was a very good career investment.  Life is good for this old programmer.

    Rick

    One of the best days of my IT career was they day I told my boss if the problem was so simple he should go fix it himself.

Viewing 4 posts - 1 through 4 (of 4 total)

You must be logged in to reply to this topic. Login to reply