This isn't directed at anyone in particular but I am amazed at how many people seem to have absolutely no problem solving common sense. For instance:- syntax errors with dynamic sql and have never thought to print the command.- multi statement process that fails "somewhere" and never thinks of a way to track what succeeded and what didn't.- etc...

Has there always been developers can't think for themselves or is this a modern phenomenon caused by smart-phones and google?

This isn't directed at anyone in particular but I am amazed at how many people seem to have absolutely no problem solving common sense. For instance:- syntax errors with dynamic sql and have never thought to print the command.- multi statement process that fails "somewhere" and never thinks of a way to track what succeeded and what didn't.- etc...

Has there always been developers can't think for themselves or is this a modern phenomenon caused by smart-phones and google?

Be One with the OptimizerTG

People with the inability or lack of desire to track down problems existed way before smart-phones and google.

Taking it a bit further, I consider the ability to test, debug, and problem solve the true difference between a good developer and a bad one.

Looking at it a different way, good developers are pessimists who doubt their ability to produce perfect code, so they test it every possible way to make sure it does what it is supposed to do.

Bad developers are optimists who assume that their code will probably work, so they see no reason to waste time testing.

I've always considered my logical approach to life in general to be my most valuable mental asset in trying to be a good developer. Working through a solution step by step, to make sure each part of the process works before moving onto the next one, is for me the most fundamental approach to the art and one I always try to make clear to those I'm training or mentoring.

You can teach someone SQL code until the cows come home, but as we all know, there's much more to it than knowing commands and syntax.

>> Working through a solution step by step, to make sure each part of the process works before moving onto the next one

Nice in theory but inflexible and unlikely to succeed in anything but the simplest cases. Means if you are waiting for something for one step you sit around doing nothing rather than working on things further down the line. Also later steps might affect what needs to be done in earlier steps so often all need to be dealt with in parallel.I would say you should teach people to concentrate on high risk areas first but always consider the whole system.

That's the problem with a lot of agile implementations. It often promotes silo development with people concentrating only on the task given, often to the detriment of the system as a whole.

I was at one recently where they knew an implementation wouldn't work and would bring down other systems but they said they couldn't take that into account - once it happened they could create a task and get a budget to fix the systems if the business wanted that. It was actually easier and quicker to implement a working system but that wouldn't fit in with their task split as it meant developing some infrastructure which would help in a number of areas and couldn't be linked to a single task.

==========================================Cursors are useful if you don't know sql.SSIS can be used in a similar way.Beer is not cold and it isn't fizzy.

>> Working through a solution step by step, to make sure each part of the process works before moving onto the next one

Nice in theory but inflexible and unlikely to succeed in anything but the simplest cases. Means if you are waiting for something for one step you sit around doing nothing rather than working on things further down the line. Also later steps might affect what needs to be done in earlier steps so often all need to be dealt with in parallel.I would say you should teach people to concentrate on high risk areas first but always consider the whole system.

Well yes I was simplyfying things, as we were talking in a context where someone relatively inexperienced writes a solution which doesn't work then they panic, rather than either a) being able to split the task into its compenent parts, or b) having developed the thing in a logical manner in the first place, finding any errors as they arose rather than getting to the end and not knowing where it went wrong.

The funny thing is that I did work with a minor application that had times before 1900. It was an insurance administration application for life insurance for veterans of World War 1, so almost all of their birthdays were before 1900. I doubt that application is still alive.

For an application that could still be alive, I was thinking about something like a database to hold real estate records, with dates for property transfers, deeds, mortgages, and so on. Of course you might have to go back past 1753 in some places...

"Then 17530107 is pure foolishness too...It's absolutely foolish to drastically over-design something to hold values it will NEVER need to hold..."

That's a bit overboard. Since there is no demonstrated drawback to using that date for a base, and it does produce correct results for the entire range of possible datetime values, I would just call it well designed.

"My business doesn't sell things in 1789 and never will."

Probably true, since that would require time travel into the past.

I am guessing there is a performance review somewhere with the words:"Does not respond well to criticism."

The same basic logic works with DATE and DATETIME2, but you have to explicitly cast everything, and the base year changes to 0001.

Of course the value of this for very old dates is debatable when you consider the change from the Julian to the Gregorian calendar, but I think if you are going to call it the last Sunday of the month, then it should actually be the last Sunday of the month.

But that's just my absolutely foolish tendency to drastically over-design talking. I guess you can blame that on my fondness for code that always works.

Along the same lines: my wife is a fan of Jane Austen (1775-1817). I recently set up a database for her to track all kinds of information relating to the period, in her quest to write a "Pride and Prejudice" variation. For those who are not as devoted to Jane Austen as my wife is, "Pride and Prejudice" is Jane Austen's most famous work, and several variations of that book have been written by a number of authors. All the dates of course are in the late 18th and early 19th century.

And speaking of wives and special women in our lives, "Happy Valentine's day to all!!"

Along the same lines: my wife is a fan of Jane Austen (1775-1817). I recently set up a database for her to track all kinds of information relating to the period, in her quest to write a "Pride and Prejudice" variation. For those who are not as devoted to Jane Austen as my wife is, "Pride and Prejudice" is Jane Austen's most famous work, and several variations of that book have been written by a number of authors. All the dates of course are in the late 18th and early 19th century.

And speaking of wives and special women in our lives, "Happy Valentine's day to all!!"

She could update Pride and Prejudice into the modern age or near future as a cyberpunk novel and avoid all those dates before 1900 that no one should ever use.