October 5, 2018 at 8:25 am
TomThomson - Friday, October 5, 2018 8:13 AMEirikur Eiriksson - Wednesday, September 26, 2018 7:48 AMDocumentation does not have to be the Ugly Duckling of development, but only if it is an integral part of it. The abstraction of code generation from the development process, is of course a key factor, as if a developer has to write both, there will be difference in priorities and it doesn't take a genius to figure out which of those will be ignored.If developers won't maintain documentation on their designs and code, they should not be employed. If validating the documentation s part of release control (as it should be, especially for devops) there is no priority conflict between writing it and writing code.
of course if managemen tells the developers that doc is lower priority than code you can expect a calamity.
I comment my code, naturally and any developer coming behind me or working with me has absolutely 0 question on that is going on. That said outside documentation nearly never exists. I have written it; perhaps a dozen times in my career. It is not something that is really ever requested or expected. I do have tools that will extract code and create diagrams or DB documentation from the code including dependency views and such.
<hr noshade size=1 width=250 color=#BBC8E5> Regards,Jeffery Williams http://www.linkedin.com/in/jwilliamsoh
October 5, 2018 at 8:40 am
TomThomson - Friday, October 5, 2018 8:13 AMEirikur Eiriksson - Wednesday, September 26, 2018 7:48 AMDocumentation does not have to be the Ugly Duckling of development, but only if it is an integral part of it. The abstraction of code generation from the development process, is of course a key factor, as if a developer has to write both, there will be difference in priorities and it doesn't take a genius to figure out which of those will be ignored.If developers won't maintain documentation on their designs and code, they should not be employed. If validating the documentation s part of release control (as it should be, especially for devops) there is no priority conflict between writing it and writing code.
of course if managemen tells the developers that doc is lower priority than code you can expect a calamity.
Preach it, Brother!
--Jeff Moden
Change is inevitable... Change for the better is not.
October 5, 2018 at 8:44 am
Jeffery Williams - Friday, October 5, 2018 8:25 AMI comment my code, naturally and any developer coming behind me or working with me has absolutely 0 question on that is going on. That said outside documentation nearly never exists. I have written it; perhaps a dozen times in my career. It is not something that is really ever requested or expected. I do have tools that will extract code and create diagrams or DB documentation from the code including dependency views and such.
One of our Business Analysts came up to me last week, thanking me profusely for all the comments I add to my code. She'd been searching our ticket tracking system to find out when a certain business rule change went in, but couldn't find it. Then she double-checked my code and found not just the ticket number, but the date and a good enough description to realize she had been looking for the wrong keywords.
So even non-devs can find use in good documentation. And I feel vindicated for writing "short stories" in my procs and packages detailing all the important W's.
October 5, 2018 at 8:45 am
TomThomson - Thursday, October 4, 2018 3:27 PMI find it very depressing - people should not be stuck into jobs like that where they will learn nothing useful.
I find it very depressing that many people that are "stuck" in great jobs with the opportunity to learn new things is the norm rather than the exception still won't take the time to learn something new especially if it requires them to do a little study on their own time. How often have we heard folks say something like "The company won't pay for training so I'm not learning anything. Should I move to a different company?"
Heh... slackers and skaters, posers and fakers.... Oh MY!
--Jeff Moden
Change is inevitable... Change for the better is not.
October 5, 2018 at 8:47 am
Brandie Tarvin - Friday, October 5, 2018 8:44 AMOne of our Business Analysts came up to me last week, thanking me profusely for all the comments I add to my code. She'd been searching our ticket tracking system to find out when a certain business rule change went in, but couldn't find it. Then she double-checked my code and found not just the ticket number, but the date and a good enough description to realize she had been looking for the wrong keywords.
So even non-devs can find use in good documentation. And I feel vindicated for writing "short stories" in my procs and packages detailing all the important W's.
YEP.
<hr noshade size=1 width=250 color=#BBC8E5> Regards,Jeffery Williams http://www.linkedin.com/in/jwilliamsoh
October 5, 2018 at 8:47 am
TomThomson - Friday, October 5, 2018 8:13 AMEirikur Eiriksson - Wednesday, September 26, 2018 7:48 AMDocumentation does not have to be the Ugly Duckling of development, but only if it is an integral part of it. The abstraction of code generation from the development process, is of course a key factor, as if a developer has to write both, there will be difference in priorities and it doesn't take a genius to figure out which of those will be ignored.If developers won't maintain documentation on their designs and code, they should not be employed. If validating the documentation s part of release control (as it should be, especially for devops) there is no priority conflict between writing it and writing code.
of course if managemen tells the developers that doc is lower priority than code you can expect a calamity.
Code should meet requirements, requirements should be properly documented and validation of requirements should also be properly documented, developers don't write requirements or validate results.
Now if you're doing something extremely complex technically that should be documented by the developer.
October 5, 2018 at 8:51 am
Jeff Moden - Friday, October 5, 2018 8:45 AMTomThomson - Thursday, October 4, 2018 3:27 PMI find it very depressing - people should not be stuck into jobs like that where they will learn nothing useful.
I find it very depressing that many people that are "stuck" in great jobs with the opportunity to learn new things is the norm rather than the exception still won't take the time to learn something new especially if it requires them to do a little study on their own time. How often have we heard folks say something like "The company won't pay for training so I'm not learning anything. Should I move to a different company?"
Heh... slackers and skaters, posers and fakers.... Oh MY!
OMG no kidding... First if you are in this space and can't afford some classes (if a formal class is what you need) then you are doing something seriously wrong. There are entire courses on YouTube for FREE. Pages and pages of them. Of course there is this thing called Google... If you are a developer and can't / don't incrementally learn new skills if by nothing else than exposure you are likely in the wrong field.
<hr noshade size=1 width=250 color=#BBC8E5> Regards,Jeffery Williams http://www.linkedin.com/in/jwilliamsoh
October 5, 2018 at 9:02 am
ZZartin - Friday, October 5, 2018 8:47 AMCode should meet requirements, requirements should be properly documented and validation of requirements should also be properly documented, developers don't write requirements or validate results.Now if you're doing something extremely complex technically that should be documented by the developer.
It costs very little for a developer to add comments referencing different requirements tickets in different sections of the code and explaining why a specific CASE statement was used instead of another alternative. And not all developers have access to old requirements or know how to find them. Especially if the code doesn't contain its own internal documentation at all. How would I know to look for ticket 12345 to see what the rules for Disneyworld regarding scenario B are if no one bothered to mention ticket 12345 even in the code's version history section?
Yes, code should meet requirements. But if code doesn't contain its own documentation, people spend a lot more time on the code's learning curve then they absolutely have to. Hence the need for properly documented code.
October 5, 2018 at 9:51 am
Sorry for the "on topic" question, but my Google-fu is failing me, and some of you are (very likely) more informed on such matter than I am. Has anyone seen a list of SQL Server 2019 Breaking Changes as yet? The documentation only cover 2017's (even on the 2019 page: https://docs.microsoft.com/en-us/sql/database-engine/breaking-changes-to-database-engine-features-in-sql-server-2017?view=sql-server-ver15). Or, perhaps are there none (like SQL Server 2014)? That would be nice, but it also means that still haven't dropped the image and (n)text data types after 15 or so years, and so people are going to continue to (mis)use them.
Thom~
Excuse my typos and sometimes awful grammar. My fingers work faster than my brain does.
Larnu.uk
October 5, 2018 at 10:19 am
I'm not sure I'm ever going to forgive the PoSh builders for using -eq instead of = or ==. I just lost 30 minutes trying to debug a script that acted "slightly" strangely with an -or (I hate that as well) that scrolled off the screen.
Grrr
October 5, 2018 at 11:13 am
Thom A - Friday, October 5, 2018 9:51 AMSorry for the "on topic" question, but my Google-fu is failing me, and some of you are (very likely) more informed on such matter than I am. Has anyone seen a list of SQL Server 2019 Breaking Changes as yet? The documentation only cover 2017's (even on the 2019 page: https://docs.microsoft.com/en-us/sql/database-engine/breaking-changes-to-database-engine-features-in-sql-server-2017?view=sql-server-ver15). Or, perhaps are there none (like SQL Server 2014)? That would be nice, but it also means that still haven't dropped the image and (n)text data types after 15 or so years, and so people are going to continue to (mis)use them.
The only thing I've found so far are here
October 5, 2018 at 11:20 am
Sorry for the "on topic" question, but my Google-fu is failing me, and some of you are (very likely) more informed on such matter than I am. Has anyone seen a list of SQL Server 2019 Breaking Changes as yet? The documentation only cover 2017's (even on the 2019 page: https://docs.microsoft.com/en-us/sql/database-engine/breaking-changes-to-database-engine-features-in-sql-server-2017?view=sql-server-ver15). Or, perhaps are there none (like SQL Server 2014)? That would be nice, but it also means that still haven't dropped the image and (n)text data types after 15 or so years, and so people are going to continue to (mis)use server
<hr noshade size=1 width=250 color=#BBC8E5> Regards,Jeffery Williams http://www.linkedin.com/in/jwilliamsoh
October 5, 2018 at 11:21 am
Eirikur Eiriksson - Friday, October 5, 2018 11:13 AMThe only thing I've found so far are hereWhat's new in SQL Server 2019
😎
Should have looked at your reply first. I just posted the same damn thing.
<hr noshade size=1 width=250 color=#BBC8E5> Regards,Jeffery Williams http://www.linkedin.com/in/jwilliamsoh
October 5, 2018 at 11:31 am
Steve Jones - SSC Editor - Friday, October 5, 2018 10:19 AMI'm not sure I'm ever going to forgive the PoSh builders for using -eq instead of = or ==. I just lost 30 minutes trying to debug a script that acted "slightly" strangely with an -or (I hate that as well) that scrolled off the screen.Grrr
In all fairness you can spend just as long trouble shooting a = instead of a == in languages that allow assignment inside boolean expressions :crazy:
October 5, 2018 at 11:43 am
Jeffery Williams - Friday, October 5, 2018 11:21 AMEirikur Eiriksson - Friday, October 5, 2018 11:13 AMThom A - Friday, October 5, 2018 9:51 AMSorry for the "on topic" question, but my Google-fu is failing me, and some of you are (very likely) more informed on such matter than I am. Has anyone seen a list of SQL Server 2019 Breaking Changes as yet? The documentation only cover 2017's (even on the 2019 page: https://docs.microsoft.com/en-us/sql/database-engine/breaking-changes-to-database-engine-features-in-sql-server-2017?view=sql-server-ver15). Or, perhaps are there none (like SQL Server 2014)? That would be nice, but it also means that still haven't dropped the image and (n)text data types after 15 or so years, and so people are going to continue to (mis)use them.The only thing I've found so far are here
What's new in SQL Server 2019
😎Should have looked at your reply first. I just posted the same damn thing.
<hr noshade size=1 width=250 color=#BBC8E5> Regards,Jeffery Williams http://www.linkedin.com/in/jwilliamsoh
Viewing 15 posts - 62,416 through 62,430 (of 66,610 total)
You must be logged in to reply to this topic. Login to reply