December 25, 2017 at 9:17 pm
Comments posted to this topic are about the item Is the old stuff worth learning?
December 26, 2017 at 2:17 am
Every step taken, whether mistake or true, made me what I am today. The past has a far greater influence on us than we are aware or would be comfortable admitting. I look at my script header telling people who wrote the script, when and for what purpose. COBOL identification division. I've never written a line of COBOL and some of the people I work with probably haven't heard of COBOL but still the practice persists.
Bash has been added to Windows 10. Ancient, but very powerful. As far as I can tell a key difference between Powershell and Bash is that Powershell handles & returns objects where as Bash handles and returns text streams. Knowing when object handling is required or when text stream handling is required will tell you which tool is appropriate for the problem you are trying to solve.
In fact I don't worry about whether something is "old", I worry about whether it is obsolete which is something different entirely. The great challenge of our lives is moving with the times rather than the fashions.
Steve has often commented on the expert beginner. I have found that learning a tool thoroughly helps me understand what the inventors were intending, the fundamental principles they were applying and whether they were right to do so. Understanding fundamental principles will help you spot the inflatable dartboard solutions and those that you can build on or contain a good idea that can be applied elsewhere.
I'm not a fan of SSIS. I've used 5 other ETL tools and prefer all but one of them. But too many of them aren't used primarily for ETL or even ELT. They are used for job orchestration because OnSuccess, OnFail & OnComplete flows are incredibly useful.
I'd say that learning & understanding the principles of something is more important than learning the thing itself. I have also found that learning about the tech surrounding your core competency makes you much stronger in your core competency.
December 26, 2017 at 5:23 am
I think old / new is not a major point in whether or not to pick up some skill / Tool. Key point should be whether it's relevant or not. If the Project was to do data Integration In a UNIX Environment I would expect any developer to have an understanding of basic Shell Scripting including some of the more common commands like ps, netstat to vi(m) as well as understanding the underlying concepts of process communication, Environment variables etc. That really hasn´t changed all that much in the last 30 years, and it seems very common to Access the Linux / UNIX back end via Terminal / Shell. Even given Big Data type of Projects, awk / sed and similar often do a better job (both in Terms of performance but especially in Terms of Project cost) for many Tasks where people without much background start to code something in some high Level language. So yes: These skills should be readily available, even if you can learn 95% from 30 year old books.
On the Windows side DOS Batch Scripting to me seems a lot less important. It used to be that without understanding command.com and autoexec.bat there really wasn't all that much you could do with an IBM compatible PC. I am not sure most "digital" natives really understand where the term "IBM compatible" Comes from, or whether that's relevant for more than trivia and you can get by fine with "Windows PC". Still it can be helpful to understand some of what you can do with cmd.exe and programs like netstat, Tracert and similar, but there are a lot more GUI based Tools available for a standard Windows Server Environment than what you would expect on the UNIX side.
So yes: as long as it is relevant to the application stack you are running, basic understanding of the components and interfaces should be mandatory not just for admin type people. But learning "old" Technology that is available just because nobody has gotten around to removing it from the standard installation yet is not really a good reason to learn something.
December 26, 2017 at 6:35 am
David.Poole - Tuesday, December 26, 2017 2:17 AMEvery step taken, whether mistake or true, made me what I am today. The past has a far greater influence on us than we are aware or would be comfortable admitting. I look at my script header telling people who wrote the script, when and for what purpose. COBOL identification division. I've never written a line of COBOL and some of the people I work with probably haven't heard of COBOL but still the practice persists.
Bash has been added to Windows 10. Ancient, but very powerful. As far as I can tell a key difference between Powershell and Bash is that Powershell handles & returns objects where as Bash handles and returns text streams. Knowing when object handling is required or when text stream handling is required will tell you which tool is appropriate for the problem you are trying to solve.
In fact I don't worry about whether something is "old", I worry about whether it is obsolete which is something different entirely. The great challenge of our lives is moving with the times rather than the fashions.
Steve has often commented on the expert beginner. I have found that learning a tool thoroughly helps me understand what the inventors were intending, the fundamental principles they were applying and whether they were right to do so. Understanding fundamental principles will help you spot the inflatable dartboard solutions and those that you can build on or contain a good idea that can be applied elsewhere.
I'm not a fan of SSIS. I've used 5 other ETL tools and prefer all but one of them. But too many of them aren't used primarily for ETL or even ELT. They are used for job orchestration because OnSuccess, OnFail & OnComplete flows are incredibly useful.
I'd say that learning & understanding the principles of something is more important than learning the thing itself. I have also found that learning about the tech surrounding your core competency makes you much stronger in your core competency.
Heh... That's a part of the point I tried to make... I wonder how much of that could easily be done using only T-SQL and a bit of DOS... especially when it comes to the 4 ETL tools that you ended up preferring over SSIS. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
December 26, 2017 at 6:39 am
silvio.schurig - Tuesday, December 26, 2017 5:23 AMI think old / new is not a major point in whether or not to pick up some skill / Tool. Key point should be whether it's relevant or not. If the Project was to do data Integration In a UNIX Environment I would expect any developer to have an understanding of basic Shell Scripting including some of the more common commands like ps, netstat to vi(m) as well as understanding the underlying concepts of process communication, Environment variables etc. That really hasn´t changed all that much in the last 30 years, and it seems very common to Access the Linux / UNIX back end via Terminal / Shell. Even given Big Data type of Projects, awk / sed and similar often do a better job (both in Terms of performance but especially in Terms of Project cost) for many Tasks where people without much background start to code something in some high Level language. So yes: These skills should be readily available, even if you can learn 95% from 30 year old books.On the Windows side DOS Batch Scripting to me seems a lot less important. It used to be that without understanding command.com and autoexec.bat there really wasn't all that much you could do with an IBM compatible PC. I am not sure most "digital" natives really understand where the term "IBM compatible" Comes from, or whether that's relevant for more than trivia and you can get by fine with "Windows PC". Still it can be helpful to understand some of what you can do with cmd.exe and programs like netstat, Tracert and similar, but there are a lot more GUI based Tools available for a standard Windows Server Environment than what you would expect on the UNIX side.
So yes: as long as it is relevant to the application stack you are running, basic understanding of the components and interfaces should be mandatory not just for admin type people. But learning "old" Technology that is available just because nobody has gotten around to removing it from the standard installation yet is not really a good reason to learn something.
Have you ever looked into the command line interface of WMI, which is available on every Windows machine? Very old... very powerful... very very underused and unknown to a great many. And, to be honest, I've found that many of the GUI tools (as good as some of them can be), don't do what I want them to or they do things in a way that makes it difficult for me to extract the data I need for automated analysis, distribution, or archival.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 26, 2017 at 7:41 am
Being one of the "old dogs" in the office, I'm not only respected for my knowledge of the arcane past, but the ability to figure out tools and methods to complete tasks and solve problems.
Some of the old stuff that's helped me this year has been my knowledge of the Windows CLI, batch files and Registry Fu.
December 26, 2017 at 8:45 am
I'm also one of the more experienced ones that people rely on for knowledge of how things work under the hood. I think understanding the old stuff really helps to understand the new stuff. Granted, some of the old stuff works quite a bit better than the shiny new toys, but there are some cool new things that perform well. If you limit your toolbox to only the newest tools, you're missing a whole set of tools that can help you solve problems.
I think the real point is that without knowledge of the old stuff, how can you even know if the new things work well? What constitutes "good performance" when evaluating something like FORMAT or EOMONTH unless there's a point of comparison?
December 26, 2017 at 8:53 am
Good topic, Ben. I'm of two minds on this. When I was unemployed I learned fast that skills I didn't have were paramount. They were newer skills. Simply put, if I didn't learn them I would never get another job. So, I learned them.
But I think you're right that all things shiny and new doesn't always mean better. I work with a young developer who really hates SSIS. He would much rather write any and all ETL operations in C#. He refers to SSIS using the derogatory term "Sissy". I'm more of the opinion, if a tool exists to easily perform ETL operations, why go through the effort of reinventing the wheel? On the other hand I work with an older fellow who really hates Windows 10, mainly because of all of the newer features people look for. I can tell he really wishes we were only using Windows XP.
I believe that you've got it right that its good to have knowledge of and at least some skills of older technologies as well as learning newer technologies.
Rod
December 26, 2017 at 9:00 am
If the question is should you learn the old stuff just because that's what more senior workers had to use, no there is no reason to walk 10 miles uphill in the snow both ways just because someone else had to.
On the other hand there is every reason to use the best technique available which in some cases like shell scripting is an old old style. So from that perspective don't pass on learning something just because it happens to be old or doesn't appear to be new and fancy. Don't go pick up a javascript book from 15 years ago to learn web design but do learn how to use the command line, learn how to do things directly in SQL without a GUI etc.. 🙂
December 26, 2017 at 9:11 am
Doctor Who 2 - Tuesday, December 26, 2017 8:53 AMBut I think you're right that all things shiny and new doesn't always mean better. I work with a young developer who really hates SSIS. He would much rather write any and all ETL operations in C#. He refers to SSIS using the derogatory term "Sissy". I'm more of the opinion, if a tool exists to easily perform ETL operations, why go through the effort of reinventing the wheel?
That's a really great example of what I'm talking about. While I agree that I don't need the SSIS tool to do so, it's pretty obvious that developer has no clue of what you can actually do very easily and faster in T-SQL. I can sometimes see reinventing the wheel if you can, in fact, create a better wheel but a whole lot of people simply can't because they don't actually know what a wheel (and the required axle) should actually do.
--Jeff Moden
Change is inevitable... Change for the better is not.
December 26, 2017 at 9:30 am
Jeff Moden - Tuesday, December 26, 2017 6:35 AMHeh... That's a part of the point I tried to make... I wonder how much of that could easily be done using only T-SQL and a bit of DOS... especially when it comes to the 4 ETL tools that you ended up preferring over SSIS. 😉
It boils down to what you really need. One of the bits I like in a decent ETL tool is the ease of making an ETL graph data driven. Some tools make the use of metadata compulsory, you can't hard code a database connection. That means that changing the source/target DB is a change to metadata not the ETL graph itself. I particularly liked Ab Initio and the way it provides outputs from most components for failed data and log data
I'd be careful of describing Windows command scripting "a bit of DOS" even if that's what it really is. Doing so opens you up to the accusation of banging on about the IT of yesteryear and "the older we are the better we were"
December 26, 2017 at 9:32 am
I remember reading DOS for Dummies in 1996 (studying for the A+ exam) and, in it, there is a discussion about how DOS is never going away. I thought the guy was crazy but, 21 years later I'm beginning to agree with him. I have written .cmd files as recently as this month - some times you need a quick & easy way to do something.
Other old stuff of value for me is knowing HTML. I learned it in the 90's and, even though I haven't been a web developer in many years , as a person who works in BI - I have found HTML knowledge indispensable.
-- Itzik Ben-Gan 2001
December 26, 2017 at 9:43 am
Alan.B - Tuesday, December 26, 2017 9:32 AMI remember reading DOS for Dummies in 1996 (studying for the A+ exam) and, in it, there is a discussion about how DOS is never going away. I thought the guy was crazy but, 21 years later I'm beginning to agree with him. I have written .cmd files as recently as this month - some times you need a quick & easy way to do something.Other old stuff of value for me is knowing HTML. I learned it in the 90's and, even though I haven't been a web developer in many years , as a person who works in BI - I have found HTML knowledge indispensable.
Alan, I couldn't agree more. I think of HTML as a prerequisite for working in IT. Granted, we don't have to know the latest CSS-driven frameworks or be experts in JQuery, but there's a lot to be said for knowing the basics and being able to carry on intelligent conversations about them. DOS is a different story for me because it's just so darn useful for DBAs to have. It's another tool in the toolbox to bring out when you need it.
December 26, 2017 at 10:26 am
I thinking having a few deep categories of expertise, combined with a broad knowledge of the entire realm of computers and IT makes one very valuable and flexible.
Just this weekend I was able to troubleshoot a home networking issue and change the subnet to accommodate a specific piece of gear. Also fixed a Windows 10 install driver issue. Then did a new SQL Server 2017 setup, remembering what Brent Ozar taught me. And then helped the internet provider fix our physical connection.
December 26, 2017 at 10:40 am
David.Poole - Tuesday, December 26, 2017 9:30 AMJeff Moden - Tuesday, December 26, 2017 6:35 AMHeh... That's a part of the point I tried to make... I wonder how much of that could easily be done using only T-SQL and a bit of DOS... especially when it comes to the 4 ETL tools that you ended up preferring over SSIS. 😉
It boils down to what you really need. One of the bits I like in a decent ETL tool is the ease of making an ETL graph data driven. Some tools make the use of metadata compulsory, you can't hard code a database connection. That means that changing the source/target DB is a change to metadata not the ETL graph itself. I particularly liked Ab Initio and the way it provides outputs from most components for failed data and log data
I'd be careful of describing Windows command scripting "a bit of DOS" even if that's what it really is. Doing so opens you up to the accusation of banging on about the IT of yesteryear and "the older we are the better we were"
I actually don't mind being categorized as so "yesteryear". 😉 It only adds to the intrigue that people have when I quickly fix something using something that's wicked old and wicked simple.
One of my favorites was something I did near the end of 2016. People were cursing a blue streak because all their modern tools missed errors during their ETL imports when it "pulled the trigger on BULK INSERT". They found out the hard way that a particular row was missing for more than 6 months and someone found it quite by accident. They tried some fixes and tricks and, although they could get things to tell them there was an error, they couldn't get it to tell them even what row and column the error was in. Heh... to borrow from a previous post on this thread, they were "walking 10 miles in a foot of snow uphill in both directions". It took me about 5 minutes to have a working example of how to solve the problem because I had "walked uphill in both directions" before and knew how to fix it. "Old folks rock".
On a lot of the new stuff coming out, people think us old folks are hard of hearing. We're not. We're just tired of listening. 😉
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 15 posts - 1 through 15 (of 44 total)
You must be logged in to reply to this topic. Login to reply