I get asked (pretty often): “How did you learn to do what you do with computers?”
Unfortunately, I don’t have an easy answer. I’m 42, and I started writing code at about 8 - by the time the IBM-PC (with the original 4.77 hz 8088 CPU) came out, I was writing assembly language and pretty well versed on looking at a problem and intuitively finding a solution. Similarly, I picked up SQL between 1998-2002 on the job implementing software deployments - first for a hotel chain/property management company and later for dot com clients putting CRM solutions in place. I can’t explain how the stuff in my brain got there or point to a single resource (well, actually, after the fact I found a great resource - I’ll share it below).
That doesn’t mean you can pick up skills easily too. As pointed out in my blog about low-cost (and free) online education resources, there are plenty of semi-format training programs. I’ve recently been going through the Web Fundamentals course track on Codecademy just to brush up on my skills -- I’m launching my business website again so I can more easily provide ebooks and other solutions to clients rather than relying solely on word of mouth referrals.
Another great learning experience is to simply find examples of what you want to do and learn by doing. That is what the fine contributors over at Nacodes.com do for web design.
Here are some recent posts on the site:
As mentioned above, I did find a great resource for my particular area of greatest expertise: database architecture and enterprise reporting/analytics. An author named Joe Celko really does a fine job of explaining the difference between databases and traditional linear programming. In the programming classes most younger people have had in high school or college, programs were written in a linear fashion to act on input or data one item at a time. Joe boils down the reasons why for databases, and particularly those using SQL (structured query language), this is insane.
You see, SQL is designed to act on data in sets. For example, in a traditional program, we might search through a list of students to find which ones had a certain GPA (or above), then add them to a list or output to the screen or a report. This would be a loop of some sort and at least a chunk of code. The same thing in SQL could be done with one line, as we’d simply ask the database to give us all of the students based on a certain criteria in one step. While you might think the database server is simply recreating the steps of the loop on the server, saving us coding time, the truth is far more complex than that. SQL is optimized to act on sets and doesn’t have to approach the issue linearly.
Let me put it another way: if you or your business use any database software and anything you do takes more than a to pull up a screen or more than a few minutes for a report, your SQL is not optimized. I’ve taken reports that took literally 12 or more hours to run and with a handful of code changes (less than 200 characters of code, maybe 3 or 4 lines impacted), made those reports run in a few minutes.
You can get books by Joe Celko at Amazon.
I suggest starting with Joe Celko's Thinking in Sets: Auxiliary, Temporal, and Virtual Tables in SQL (The Morgan Kaufmann Series in Data Management Systems)
No comments:
Post a Comment
Suggestions welcome! Is there a big story on one of those corporate tech blogs you'd like to see analyzed from the perspective of one guy? Send me the link!