March 24, 2016 at 1:51 am
I am often shocked about how many IT graduates have not been taught the fundamentals of different programming paradigms. Or even that there are different ones. I am not just talking of recent graduates but those of all ages (or more importantly those graduates' study covers the last 60 years).
I am also surprised by those who will not change even in the face of evidence that what they are doing is inherently wrong and not only more painful for their employer but also themselves.
To top it off, many companies that are aware of the issue will not back it up by training and corporate standards.
All this leads me to believe that maybe some places and people deserve what they get. Unfortunately, other places and people also suffer from the fallout.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 24, 2016 at 6:06 am
Gary, I wonder what percentage are really "graduates" (vs independent learners) and of those graduates, of what kind of courses they took? I think a part of the problem is where to start teaching/learning. I think it makes a lot of sense to start out with a higher level language and see if they get at all IF/THEN and let them feel the success of building something, but if/when does it go to a lower level? I learned in pre-GUI days when I had to capture the keystrokes and decide what to do, quite the revelation to realize that pressing backspace doesn't "do" anything unless you move the cursor and change the display appropriately. I learned about sorting the hard way - I made it work, then had to figure out how to make it work in a reasonable amount of time (on something like 5000 records!). I don't know that we need to teach everyone how to optimize at the compiler level, but one class on debugging and optimization would not be time wasted.
March 24, 2016 at 6:17 am
My personal favourite was the guy who was asked why he was retrieving every record from a table and then filtering within the application. Using a WHERE clause was business logic and everybody knows not to put business logic in the database layer:w00t:
Least favourite was the surviving brain donor who convinced the powers that be that "in my opinion ETL applications are a failed paradigm" and proceeded to have his team waste a two week sprint to write a web based data import process that took 30 minutes to load 3000 records (a few Mb). This was after he had been shown the ETL package used to upload data during the data provider evaluation. Not sure how many million records you can load in 30 minutes but it is a lot.
Then there is the web scale wailer who instantiated a new connection within a loop when what they should have done is instantiated the connection outside the loop and changed the query parameters within the loop. Multiple hour process shrunk to under a minute when that one was corrected.
Use the right tool for the right job. If it helps draw out your process. Flow charts are prehistoric but they still work.
March 24, 2016 at 6:34 am
The main ones I see repeatedly are the lack of understanding of Boolean algebra or how data is stored and its implications particularly wrt floating point arithmetic.
March 24, 2016 at 6:55 am
I find this so true with so many of our programmers.
March 24, 2016 at 7:02 am
Preaching to the choir here. 😀
My first programming was done on a 1962 vintage IBM 1130. In Fortran. On punch cards. (laughing)
Yeah, you learn minimalism really fast when you have a whopping 8K of core memory (NOT RAM!) and no virtual memory...
As for different paradigms, well, that's usually because the language in question sucks at doing the old one. The reason RBAR is such a nightmare in SQL Server is because T/SQL's interpreter is abyssmal when it comes to performance outside SELECT and company.
Oh well, keeps things interesting I suppose. 😎
March 24, 2016 at 8:17 am
I don't think there is a wide respect for the basics and resource limitations. I see software that works well with a 100K records drop to a crawl with a million. Lack of understanding of indexing and I/O. No load or capacity testing.
Also I abhor web sites that have MBs of scripts, audio and video ads. Not every connection is fast nor every browser capable of dealing with so much unwanted ordure. (Not to mention security issues.)
Complexity is also hobgoblin. When you must know 6 different languages or have layers of fragile dependencies, (NPM for a left pad win!), just to get a simple application going, something is fundamentally wrong.
And our core foundation languages, (C, C++) are flawed.
March 24, 2016 at 8:56 am
Andy Warren (3/24/2016)
Gary, I wonder what percentage are really "graduates" (vs independent learners) and of those graduates, of what kind of courses they took? I think a part of the problem is where to start teaching/learning. I think it makes a lot of sense to start out with a higher level language and see if they get at all IF/THEN and let them feel the success of building something, but if/when does it go to a lower level? I learned in pre-GUI days when I had to capture the keystrokes and decide what to do, quite the revelation to realize that pressing backspace doesn't "do" anything unless you move the cursor and change the display appropriately. I learned about sorting the hard way - I made it work, then had to figure out how to make it work in a reasonable amount of time (on something like 5000 records!). I don't know that we need to teach everyone how to optimize at the compiler level, but one class on debugging and optimization would not be time wasted.
My college (16-18 years old) was amazing. The lecturers were, in the main, ex-programmers. This was in the mid-80s so most in IT were programmers/sysadmins/DBAs. With regards to sorting I would refer to the way we were taught as being intelligent.
We first learned the Bubble Sort. It is easy to conceptualise. Easy to program. Easy to follow debugging (no interactive debugger - console at best). Then we went through a bunch of the obvious ones and started to take timing as we advanced (optional). Then we had a theory lesson that talked of measurements like O(n) etc. (look up or ask if you don't recognise what this means). Finally we had to implement some of the additional sorts discussed in the theory lesson. I cannot remember which.
We ended up with the ability to understand sorts, implement sorts (even the ones we hadn't already) and understand a bit about the cost in time. We also discussed the reasoning behind the selection of sort algorithms including considering when we really don't care e.g. you are sorting between 3 and 5 strings held in memory in a desktop application.
Gaz
-- Stop your grinnin' and drop your linen...they're everywhere!!!
March 24, 2016 at 9:47 am
Far too often there are developers that write inefficient code because they apply techniques they've learned from programming applications in some other language, or even from some other relational database.
Far too often, Microsoft -- and other vendors -- ignore the ANSI standard for the SQL language and instead create vendor-specific syntax and constructs.
Greater adherence to the ANSI standard by the vendors might reduce some of the problems Mr Jones notes.
March 24, 2016 at 10:02 am
It's more an issue of how many people are willing to accept things that can easily be improved. There's usually not as much value in today's age in squeezing out every last CPU cycle and byte of memory you can save but processes that just blatantly are wrong should be fixed.
The last place I worked had some ETL they wrote to import records from a vendor using a ruby script(the original developer was an outside web developer who thought ruby was just the greatest thing every, sigh...). Well it always ran slow but as we started getting to the point where the vendor increased the record count we were getting weekly, nothing drastic 10's of thousands of rows to 100's of thousands of rows, the process got to the point where it would crash routinely because ruby isn't designed to handle ETL like that(or it just sucks) and the original file would have to be manually edited to remove the rows already processed which took days to run. I had no idea that was going on because the person running it never complained or mentioned it. When they left and I had to take it over I did that exactly once before rewriting the entire thing using SSIS to import into a temp table and dump the appropriate SQL commands out to load into the website, that process took around 10 minutes total, only failed when the vendor screwed up the file format and the majority of that time was still manually copying files around.
March 24, 2016 at 10:06 am
ZZartin (3/24/2016)
It's more an issue of how many people are willing to accept things that can easily be improved. There's usually not as much value in today's age in squeezing out every last CPU cycle and byte of memory you can save but processes that just blatantly are wrong should be fixed.
It's a balancing act, and one you have to be careful of. The cost of people is larger than hardware, in many cases. That wasn't the case 30 years ago.
We should learn to optimize to a point, and avoid poor performing practices.
March 24, 2016 at 10:09 am
Yes, just like in life 'be careful what you ask for, you just might get it.' I'm curious to see how Hekaton and it's complexity (new engine component, dynamic dll generation etc.) translates into maintenance overhead (if any). Improving performance usually (if not always) comes with a trade-off in flexibility.
March 24, 2016 at 10:22 am
GoofyGuy (3/24/2016)
Greater adherence to the ANSI standard by the vendors might reduce some of the problems Mr Jones notes.
ANSI evolves slowly, and doesn't always meet business needs. Going past ANSI gets us better products.
I know that's hard if you want to support multiple products, but if you're selling on multiple platforms, I never understood why you didn't have a team optimizing for each platform? We know how to build a data access layer. Use it and separate platform from functional call.
March 24, 2016 at 10:25 am
Andy Warren (3/24/2016)
Gary, I wonder what percentage are really "graduates" (vs independent learners) and of those graduates, of what kind of courses they took? I think a part of the problem is where to start teaching/learning. I think it makes a lot of sense to start out with a higher level language and see if they get at all IF/THEN and let them feel the success of building something, but if/when does it go to a lower level? I learned in pre-GUI days when I had to capture the keystrokes and decide what to do, quite the revelation to realize that pressing backspace doesn't "do" anything unless you move the cursor and change the display appropriately. I learned about sorting the hard way - I made it work, then had to figure out how to make it work in a reasonable amount of time (on something like 5000 records!). I don't know that we need to teach everyone how to optimize at the compiler level, but one class on debugging and optimization would not be time wasted.
I think that once someone has some basic aptitude, they decide they like working with SQL, or C#, or Python, that they need some grounding in basic programming exercises. It's still on my list to do some of these for SQL, but having some kind of set of exercises, like the Advent of Code, to practice and improve your skills on, is good.
With discussions that facilitate the reasons why you make certain choices.
Going cross platforms, like C# or VB.NET to SQL, that's harder. However we need exercises there as lots of sample code isn't well written.
Viewing 15 posts - 1 through 15 (of 32 total)
You must be logged in to reply to this topic. Login to reply