SQLServerCentral / Editorials / SQLServerCentral.com / Coding More Carefully / Latest Posts

RE: Coding More Carefully

Steve Jones - SSC Editor — Wed, 02 May 2012 14:21:18 GMT

[quote][b]Revenant (5/2/2012)[/b][hr]Perl can do a lot with one command.[/quote]So could APL, but it was PITA to read.[/quote]Arrgggghhhh, I think I disliked APL more than any other language. Neat idea, raised my blood pressure in college more than most coursework should.

RE: Coding More Carefully

L' Eomot Inversé — Wed, 02 May 2012 11:56:00 GMT

[quote][b]Revenant (5/2/2012)[/b][hr][quote][b]Eric M Russell (5/2/2012)[/b][hr][quote][b]Revenant (5/2/2012)[/b][hr][quote][b]L' Eomot Inversé (5/2/2012)[/b][hr]. . . So, I think the plus side of being able to let the machine do some of the grunt-work for us greatly outweighs the minus side; . . .[/quote]Yeah, I have always wished for a programming language that would have only two statements: DO and UNDO. Compiler should figure out the rest from the context.:-D[/quote]Perl can do a lot with one command.[/quote]So could APL, but it was PITA to read.[/quote]So could most Unix shell script languages, and they are a POP to read instead.Just think of "rm -r *" as a nice single command.

RE: Coding More Carefully

Revenant — Wed, 02 May 2012 11:09:42 GMT

[quote][b]Eric M Russell (5/2/2012)[/b][hr][quote][b]Revenant (5/2/2012)[/b][hr][quote][b]L' Eomot Inversé (5/2/2012)[/b][hr]. . . So, I think the plus side of being able to let the machine do some of the grunt-work for us greatly outweighs the minus side; . . .[/quote]Yeah, I have always wished for a programming language that would have only two statements: DO and UNDO. Compiler should figure out the rest from the context.:-D[/quote]Perl can do a lot with one command.[/quote]So could APL, but it was PITA to read.

RE: Coding More Carefully

Eric M Russell — Wed, 02 May 2012 10:08:54 GMT

[quote][b]Revenant (5/2/2012)[/b][hr][quote][b]L' Eomot Inversé (5/2/2012)[/b][hr]. . . So, I think the plus side of being able to let the machine do some of the grunt-work for us greatly outweighs the minus side; . . .[/quote]Yeah, I have always wished for a programming language that would have only two statements: DO and UNDO. Compiler should figure out the rest from the context.:-D[/quote]Perl can do a lot with one command.

RE: Coding More Carefully

Revenant — Wed, 02 May 2012 09:42:25 GMT

[quote][b]L' Eomot Inversé (5/2/2012)[/b][hr]. . . So, I think the plus side of being able to let the machine do some of the grunt-work for us greatly outweighs the minus side; . . .[/quote]Yeah, I have always wished for a programming language that would have only two statements: DO and UNDO. Compiler should figure out the rest from the context.:-D

RE: Coding More Carefully

L' Eomot Inversé — Wed, 02 May 2012 07:27:06 GMT

I'm inclined to agree with Craig: if some tool will remember things for me so that I have more room in my head for stuff that needs me, rather than a tool, to do it then that tool (unless it also has some nasty habits) is going to be welcome. Also of course I agree with Gus - some people will abuse the ability to have a tool check syntax for them and pay no attention to what they are doing because they think the tool will spot all the errors - it's essential to keep track of the things that the tool can't spot the errors in (like the semantics of the code, as opposed to its syntax).The first computing I did was with paper tape and maybe two runs per day; so after a couple of days when writing Fortran I wrote very few syntax errors, because they took too long to correct. Later I was in a world where syntax checker software was common, but it was still batch even though it took less resources than running the compiler. Still later and I had interactive syntax checkers available using a teletype or a VTU to access a remote interactive system, and that changed the world - I could now put more software to gether more quickly and much more economically (Revenant put his finger on the economical aspect) and that of course carried through into the desktop computer world.I've worked with many different languages, so that I know several different syntaxes for describing the same passive structure; for example should I use [code](int X, int Y, float Z)[/code]or[code] (X int, Y int, Z float)[/code]? Should I care and make sure I type it right first time, or just let the syntax check (usually done by a compiler) pick it up if I type it wrong? If I had dealt only with resonably sane and sound languages I might think it sensible to do it myself, but having dealt with several real abominations (of which the worst was C++) I have no wish to waste brain space on the nonsense that some language designers have devised so now I let the system find things for me. Neither do I want to restrict my typing speed by ensuring by looking at the keys I strike to make sure that there are no adjacent transposition errors, no double key hits, no mishits: if I'm typing text a spell checker can spot those for me, if I'm typing in a programming langauge the compiler can spot them.The other problem is that whatever modern system designers shave with, it clearly isn't Occam's Razor. The number of libraries of functions, procedures, subroutines, classes, datatypes, modules, macros that a typical language system now provides is such that it would, in my view, be foolish to try to remember them all (although perhaps some people use only one language, and if it's a parsimonious one they can maybe afford to learn all that junk). My own way of dealing with this is to keep reference books open in a spare window, plus allow autocompletion to make suggestions for me in systems where that makes sense (not in SSMS: I hate autocompletion as implemented there); some people I know allow autocompletion to make the decisions, but that in my view is insanity; other people type something and let the compiler tell them if it's invalid, which is OK as long as there aren't pairs of different but similarly named objects with the compatible parametrisation.So, I think the plus side of being able to let the machine do some of the grunt-work for us greatly outweighs the minus side; but some people do misuse it.

RE: Coding More Carefully

Eric M Russell — Fri, 13 Jan 2012 12:00:22 GMT

[quote][b]Steve Jones - SSC Editor (1/13/2012)[/b][hr][quote][b]ben.mcintyre (1/12/2012)[/b][hr]As primarily a c# coder, I emphatically disagree with this proposition.In fact, being able to compile frequently (any I often do it once every couple of minutes) allows me to focus fully on the architecture and getting the important details right. The 'fluff' is then picked up by the compiler as errors and I can use it as a brainless 'to do' list.The fact is, it's entirely possible (and usual, some might say) to write compilable but architecturally shocking code.Also, the really tricky bugs often arise as a result of subtle procedural interactions which are far from the syntax or grammar of the language.Compiling is the equivalent of spell and grammar checking a word document.[/quote]I think you might be the exception rather than the rule. I would like to think that the compiler is just a "to do" list for many people, but I think many of them write code, compile it, and hope it works rather than thinking things through.[/quote]When coding SQL, the developer receives positive reenforcement, because thinking things though in the design results in a significantly shorter compile + runtime.

RE: Coding More Carefully

Steve Jones - SSC Editor — Fri, 13 Jan 2012 09:14:56 GMT

[quote][b]ben.mcintyre (1/12/2012)[/b][hr]As primarily a c# coder, I emphatically disagree with this proposition.In fact, being able to compile frequently (any I often do it once every couple of minutes) allows me to focus fully on the architecture and getting the important details right. The 'fluff' is then picked up by the compiler as errors and I can use it as a brainless 'to do' list.The fact is, it's entirely possible (and usual, some might say) to write compilable but architecturally shocking code.Also, the really tricky bugs often arise as a result of subtle procedural interactions which are far from the syntax or grammar of the language.Compiling is the equivalent of spell and grammar checking a word document.[/quote]I think you might be the exception rather than the rule. I would like to think that the compiler is just a "to do" list for many people, but I think many of them write code, compile it, and hope it works rather than thinking things through.

RE: Coding More Carefully

dcraday — Fri, 13 Jan 2012 07:53:09 GMT

[quote] At college a girl, she was called Amanda, once completed an exercise to learn to programme in Ada (under the section iteration) which was to print the alphabet backward.[/quote]I love that bit of code. I know it was probably[b] meant[/b] to start with the alphabet then rearrange it backward.I'd like to see what the assignment actually said though, because if it WAS to print the alphabet backward, then it does EXACTLY what it is supposed to do.It rather reminds me of an assignment, set by Edison (I think), to find the volumn of a light bulb. After many measurements and calculations, he came back, filled it with water and poured it into a measuring cup.As far as coders today not thinking about what they are producing, one of my first tasks was to debug a massive RPG program where the program flow consisted entirely of GOTO statements and this was production code that had been in place for quite a long time.Sure, if you were smart you would put a lot of thought and time into your program if you had a single compile a day, but this wouldn't necessarly mean it was better. It would just have a better chance of compiling the first time.

RE: Coding More Carefully

Gary Varga — Fri, 13 Jan 2012 01:00:58 GMT

As a developer who started with home computers to program (Vic 20 in my case) I missed the whole compile a day thing but was taught using non-IDE compilers. This did allow for using the compiler to statically check your code - which I see as a good thing - but the cycle of Edit/Compile/Run being longer than it is today ensured that the cost of writing gibberish was too high. Unfortunately, the problem with some coders today is that they will not THINK about what they are producing in terms of what it is doing and how maintainable it will be.Strangely, too many people are viewing their own code as black boxes in which they only care about the answer and not how they got it. "Wait a minute!" I hear you cry "Does it really matter?". Well, yes. If you run it and it works for one scenario because it has been "jiggled" (as one poster said) how confident are we that it will work under most, if not all, scenarios?At college a girl, she was called Amanda, once completed an exercise to learn to programme in Ada (under the section iteration) which was to print the alphabet backwards. She achieved it with the following line of code:[code]with Ada.Text_IO; use Ada.Text_IO;procedure ReverseAlphabet isbegin Put_Line("zyxwvutsrqponmlkjihgfedcba");end ReverseAlphabet;[/code]The result was correct but she had missed the point entirely (or maybe she hadn't and was struggling).Is jiggling until you get the right answer good enough for a professional software developer? I say no.

RE: Coding More Carefully

ben.mcintyre — Thu, 12 Jan 2012 19:45:20 GMT

[quote][b]Revenant (1/12/2012)[/b][hr][quote][b]ben.mcintyre (1/12/2012)[/b][hr]As primarily a c# coder, I emphatically disagree with this proposition.In fact, being able to compile frequently (any I often do it once every couple of minutes) allows me to focus fully on the architecture and getting the important details right. The 'fluff' is then picked up by the compiler as errors and I can use it as a brainless 'to do' list.The fact is, it's entirely possible (and usual, some might say) to write compilable but [b]architecturally shocking code[/b].Also, the really tricky bugs often arise as a result of subtle procedural interactions which are far from the syntax or grammar of the language.Compiling is the equivalent of spell and grammar checking a word document.Keep in mind that my first programs were written on paper before being typed into an Apple II.[/quote]Te word "architecture" may have a different ring on this forum that is dealing with SQL Server than on a forum that deals, say, with physical representation of a UML domain model.What exactly do you mean by "architecture" when you are scripting SQL Server (22 millions lines of code) running on top of Win2k8 Server (55 million lines of code), within the (perhaps unstated) confines of both?[/quote]The OP did specifically mention Turbo Pascal and other non SQL languages.SQL not being an object oriented language, the architecture is less clear from the code structure. But I should clarify that I'm speaking of software architecture, not hardware/tiering.So at the crudest, the equivalent in SQL would be correct normalisation of data (perhaps with judicious denormalisation), and indexing of primary keys, etc.Of course there is usually an 'X' factor with software architecture once getting into the more complex realms; which usually involves having been there before and knowing the consequences of decisions 8 steps down the track rather than at first sight.My point is, I suppose, that you could write a script for to create an improperly normalised data structure without helpful indexing which would execute correctly.The true challenges are not at the level of spelling or grammar.

RE: Coding More Carefully

Revenant — Thu, 12 Jan 2012 19:32:07 GMT

[quote][b]ben.mcintyre (1/12/2012)[/b][hr]As primarily a c# coder, I emphatically disagree with this proposition.In fact, being able to compile frequently (any I often do it once every couple of minutes) allows me to focus fully on the architecture and getting the important details right. The 'fluff' is then picked up by the compiler as errors and I can use it as a brainless 'to do' list.The fact is, it's entirely possible (and usual, some might say) to write compilable but [b]architecturally shocking code[/b].Also, the really tricky bugs often arise as a result of subtle procedural interactions which are far from the syntax or grammar of the language.Compiling is the equivalent of spell and grammar checking a word document.Keep in mind that my first programs were written on paper before being typed into an Apple II.[/quote]Te word "architecture" may have a different ring on this forum that is dealing with SQL Server than on a forum that deals, say, with physical representation of a UML domain model.What exactly do you mean by "architecture" when you are scripting SQL Server (22 millions lines of code) running on top of Win2k8 Server (55 million lines of code), within the (perhaps unstated) confines of both?

RE: Coding More Carefully

ben.mcintyre — Thu, 12 Jan 2012 18:41:11 GMT

As primarily a c# coder, I emphatically disagree with this proposition.In fact, being able to compile frequently (any I often do it once every couple of minutes) allows me to focus fully on the architecture and getting the important details right. The 'fluff' is then picked up by the compiler as errors and I can use it as a brainless 'to do' list.The fact is, it's entirely possible (and usual, some might say) to write compilable but architecturally shocking code.Also, the really tricky bugs often arise as a result of subtle procedural interactions which are far from the syntax or grammar of the language.Compiling is the equivalent of spell and grammar checking a word document.Keep in mind that my first programs were written on paper before being typed into an Apple II.

RE: Coding More Carefully

David.Poole — Thu, 12 Jan 2012 15:19:06 GMT

Someone posted a comment on this site about not using a hammer to cut boards. The right tool at the right time used in the right way delivers the goods.Given the richness of most APIs I would not want to go back to wading through a tome like "Programming the Windows API" in order to find a function. Auto-complete plus context sensitive F1 is my friend.Having got SQLPrompt set up just so I feel like my hands have been chopped off when I hot desk to a machine that doesn't have it.For the most part I feel the same way about SQL Refactor. I personally wouldn't format my code the way that SQL Refactor does but that isn't the point. A unified way of formatting code is very useful when reading other peoples code irrespective of my personal preferences.I've said it before that when I taught myself C++ (using Ivor Horton's books) I became a much better VB programmer. It wasn't really a skill thing it was a mentality thing. Which brings me back to the original point of the editorial. How do you foster a mentality that prizes quality and thought?I'm a great fan of cycling people through the IT disciplines including a stint of being on-call in operational support. A few 3am phone calls with a live priority one incident changes your perspective on what constitutes quality, and why code can never be considered self-documenting. Walk a mile in another mans shoes and all that!

RE: Coding More Carefully

Darren Wallace — Thu, 12 Jan 2012 14:42:13 GMT

[quote][b]Evil Kraig F (1/12/2012)[/b][hr]Heh, New Guy on the block I guess.Ctrl-F5 is my friend. Where'd I typo?I want to worry and keep in my head the object model and the inter-communication and the algorithmic intents. I don't want to worry so much about if I typed INT or ITN. That's what the compiler and checkers are THERE for.I understand what you're saying, I just disagree horribly. My brain has x space that I can juggle a lot of things in. Do I want to typo? No. Do I want to spend 15 minutes manually de-bugging syntax and typos when in 10 seconds the machine will do it for me and I *don't* have to try to get all that algorithmic methodology back into my head? No. I'd rather spend the mental energy on the method and let the machine let me know if I goofed up the instruction. The output will let me know (and the part *I* have to debug) if I goofed up the method.[/quote]This method ranks rite up their with using spell check and auto-correct to insure that you right in proper anguish.Syntactically valid and logically consistent are sometimes very different things, and "It worked on my machine" is never something I want to try and explain to senior management in the heat of a crisis.Now that I've gotten that out of my system... I do agree that lint tools are a good idea, and having them integrated into the IDE is even better, but everytime I see a coder search through the auto-complete list to look for a function that has a name that sounds like it does X I cringe. I've seen too many caveats in API docs about memory leaks that aren't obvious.

RE: Coding More Carefully

David.Poole — Thu, 12 Jan 2012 14:30:15 GMT

[quote][b]Revenant (1/12/2012)[/b][hr]No Agile, back then. ;-)[/quote]Actually if you read "The mythical man month" by Fred P Brooks you will see that one of his peers was recommending the progenitor of agile back in the 1960s.The mythical man month was written in 1975 and was the Fred's experience over 25 years in the computer business. I was amused by one of the Amazon reviews of it that said "taught me nothing new". Of course not, a lot of what was proposed became industry standard practise.

RE: Coding More Carefully

Evil Kraig F — Thu, 12 Jan 2012 14:14:44 GMT

Heh, New Guy on the block I guess.Ctrl-F5 is my friend. Where'd I typo?I want to worry and keep in my head the object model and the inter-communication and the algorithmic intents. I don't want to worry so much about if I typed INT or ITN. That's what the compiler and checkers are THERE for.I understand what you're saying, I just disagree horribly. My brain has x space that I can juggle a lot of things in. Do I want to typo? No. Do I want to spend 15 minutes manually de-bugging syntax and typos when in 10 seconds the machine will do it for me and I *don't* have to try to get all that algorithmic methodology back into my head? No. I'd rather spend the mental energy on the method and let the machine let me know if I goofed up the instruction. The output will let me know (and the part *I* have to debug) if I goofed up the method.

RE: Coding More Carefully

Revenant — Thu, 12 Jan 2012 13:57:21 GMT

No Agile, back then. ;-)

RE: Coding More Carefully

tlockwood — Thu, 12 Jan 2012 13:39:10 GMT

One thing no one has mentioned is that before you punched out your program on cards, you wrote the entire thing out on paper. That meant you spent a lot of time thinking about your code before the computer even attempted to run it. I think when you can make a small change and run it, over and over, makes you think less about the best way to code something and what affects that small change may have on the overall application.

RE: Coding More Carefully

cdesmarais 49673 — Thu, 12 Jan 2012 13:26:18 GMT

Well, let's compare the programs of today, with the programs back then...Any questions?I know, you really liked edlin. :cool:

RE: Coding More Carefully

mstjean — Thu, 12 Jan 2012 13:02:04 GMT

You kids today with your Pascal... When I was a youngster the standard admonition was, "don't use the compiler to debug your code". One compile a day? Sounds about right. If you were really lucky, you got a keypunch machine that printed the card number on it... for IfWhen you dropped your card stack. You had to put the card stack in the bin with your identifying information and if [i]"Bruce Fortran and the gods of top-down programming"[/i] were with you, the job would get run the same night.ahh, school days...To this day, every time I use the compiler to debug my code I [b]still[/b] feel a little guilty.

RE: Coding More Carefully

Revenant — Thu, 12 Jan 2012 13:01:14 GMT

"Limiting developers to one compile a day wouldn't work these days, but I wonder if limiting the number of compiles might result in developers spending a little more time thinking about their code, their logic, and writing applications with a little more care?"It depends on the price ratio of the computer time and programmer's time. Forty years ago programmer's salary was about $500 per month, which was the price of one 2311 6.5 MB disk pack (not drive, just the replaceable pack) or 3 hours of IBM /360.40. COBOL or PL/I compile of 1,500-2,000 cards took say 10 minutes, unless there was a serious error.Then it made sense to spend half a day simulating the program, which is now forgotten art, just to save one compile.We used to have three compiles to catch syntactic mistakes and five test runs. If you did not get it done in five runs, you had some explanations to do.I was largely exempt because I was programming in Assembler; however, I think that some of that "get it done right the first time" is still with me.

RE: Coding More Carefully

Eric M Russell — Thu, 12 Jan 2012 11:58:00 GMT

Thanks to code completion, I don't think developers today really spend a significant amount of time correcting syntax errors or invalid object references. I think the old timers back in the day of hour long compiles spent a lot of time on smoke breaks. That seemed to be my impression back in the early 90's during that brief period when the old timers (COBOL / AS400) and new guys (SQL / HTML / Visual Basic / NT Server) were still working in parallel at the same company.We new guys don't smoke. If I have a compile that lasts longer than 10 seconds, then I'm leaning back in my chair and doing the stretch and yawn thing. If it takes longer than a minute to run, then it's time to check the discussion groups or start working on the next 100 lines of code.

RE: Coding More Carefully

TravisDBA — Thu, 12 Jan 2012 09:58:56 GMT

[quote][b]David.Poole (1/12/2012)[/b][hr]If you changed the environment in which someone works then they change the way in which they work. That is in human nature.[/quote]I tend to agree with this also. The way you do things, and the time you take to do them, is driven by the environment and the specific situation you happen to be in at the time. :-D

RE: Coding More Carefully

David.Poole — Thu, 12 Jan 2012 09:50:19 GMT

If you changed the environment in which someone works then they change the way in which they work. That is in human nature.To give a non-IT world example, drivers give cyclists who don't wear helmets a wider berth resulting is fewer cyclist/motor vehicle incidents. However if an incident does occur then its much more likely to go badly wrong for the cyclist.Anyone recall the jokes about Volvo drivers being the worst in the world! Their cars were so damn safe they thought they were immortal!I don't think anyone is advocating putting an artificial constraint on programmers but I do think pair programming is much more likely to yield better quality coding.Incidentally I did ask a very experienced technical lead developer what his experience was with pair programming. His take was as follows: -[ul][li]Initially it slows everyone down[/li][li]80% of the work is done by 20% of the staff. Pair programming can have a dramatic negative affect on team performance as it inevitable (and desirable) to pair an 80percenter with a 20 percenter[/li][li]Once it beds in the weaker developers get an accelerated learning experience from the better ones leading to a much stronger team[/li][li]The stronger team results in higher code quality, fewer post implementation hot fixes[/li][/ul]The benefits go beyond the immediately apparent.[ul][li]If fewer fixes are needed then the development team are available to move on to the next business deliverable[/li][li]Providing a quality deliverable is a morale booster for the team[/li][li]Business satisfaction increases partly due to the ability to move onto the next deliverable but also without the corrosive effect of small and often minor errors drip-feeding the perception of poor quality[/li][/ul]

RE: Coding More Carefully

Steve Jones - SSC Editor — Thu, 12 Jan 2012 09:29:29 GMT

[quote][b]GSquared (1/12/2012)[/b][hr]...Yeah, it's one of those "yes but no" kind of things. I at least partially disagree with myself here.[/quote]As I get older, this is an hourly occurrence with me.

RE: Coding More Carefully

GSquared — Thu, 12 Jan 2012 09:02:24 GMT

[quote][b]Steve Jones - SSC Editor (1/12/2012)[/b][hr]I agree, but don't agree with you. It's not necessarily about avoiding a tool that can help, but using the tool appropriately. It's potentially a problem with many of today's younger coders that they just keep "jiggling things" to see if they work without thinking about them.If limit the amount of "just try this" attempts, do we turn out better code? The people that build cabinets, or anything out of wood, make mistakes, and try things, but not in an unlimited fashion. They know there is a limit to how many mistakes or attempts they can make because of cost.We don't have a material cost, but we have a time cost, and we also have a mental cost. If someone isn't taking the time to actually think more, does some limit to resources help them think more about what they do?[/quote]Yeah, it's one of those "yes but no" kind of things. I at least partially disagree with myself here.I think it's more complex than just trial-and-error being a waste of time, though.For one thing, it makes the learning curve for a beginning program a lot easier. Over time, it will generally lead to better coding, simply because "this is what finally ended up working last time so I'll do it first this time". Expert systems work almost exclusively that way, and they can do amazingly complex things once they've self-educated enough.At the same time, that low barrier-to-entry has the drawback of a lot of junk software being used for critical business functions, where it often isn't really appropriate, but nobody knows better. There's no way to tell what the cost of that is.But I tend to think it's more of a positive than a negative, based on my own experiences in learning coding and databases. Universal rule on it? Nah. But my opinion does tend towards it being more positive than not.

RE: Coding More Carefully

dcraday — Thu, 12 Jan 2012 08:54:14 GMT

Good code is based on ability and knowledge, better code is based on design. If you have to jiggle things a lot then one or the other is probably lacking. To take our examples, I can cook by throwing things together, but only because I have a good idea of what I'm doing, but I certainly can't bake that way. It most likely won't turn out. A great cabinet maker can probably build from scratch, but most folks need a drawing. And I'd better know how to use that backhoe:-)Limiting resources won't change that, you probably would end up with a bunch of jiggles at one time.

RE: Coding More Carefully

OCTom — Thu, 12 Jan 2012 08:53:30 GMT

When I programmed using punched cards, I took extra care with the code because I could only use the card reader early in the morning and late in the afternoon. It doesn't mean the code was perfect the first time but you become very careful.Today's IDEs allow you to code and compile quickly. However, I still only compile about three times a day. I still take the same time to code carefully.Note: Last year I finally got management to agree to allow me access to the card reader thrice daily. ;-)

RE: Coding More Carefully

Steve Jones - SSC Editor — Thu, 12 Jan 2012 08:11:22 GMT

I agree, but don't agree with you. It's not necessarily about avoiding a tool that can help, but using the tool appropriately. It's potentially a problem with many of today's younger coders that they just keep "jiggling things" to see if they work without thinking about them.If limit the amount of "just try this" attempts, do we turn out better code? The people that build cabinets, or anything out of wood, make mistakes, and try things, but not in an unlimited fashion. They know there is a limit to how many mistakes or attempts they can make because of cost.We don't have a material cost, but we have a time cost, and we also have a mental cost. If someone isn't taking the time to actually think more, does some limit to resources help them think more about what they do?

RE: Coding More Carefully

dcraday — Thu, 12 Jan 2012 06:56:56 GMT

I do coding, or programming, and I tend to run the programs many times when building a solution so that I can see how things are working at that point. Programming in today's IDE's is far removed from the text based languages of the past, even in SQL, where in SMSS you can simply right click to get a basis for a new stored prodecure, or to modify one. I can dig a hole with a shovel when I need to, but if there is a backhoe around I'd use it.

RE: Coding More Carefully

GSquared — Thu, 12 Jan 2012 06:25:07 GMT

I don't see it as a bad thing that coders can have blind-spots handled for them by the tools.Seems kind of like thinking microwaves are bad because people used to have to be much more careful about what they did cooking-wise, when it took several minutes to get a fire started by rubbing sticks together, and a mistake on the sticks thing could result in a several hour delay in dinner, or even in the loss of precious firewood.Yeah, someone cooking that way is going to pay a lot more attention to details. Add in the scorched eyebrows phenomenon, and it might even be much, much more attention. But I'll use an electric range and a microwave, and if I overcook something in the microwave every now and again, I can easily throw it away and start over.

Coding More Carefully

Steve Jones - SSC Editor — Thu, 12 Jan 2012 00:13:43 GMT

Comments posted to this topic are about the item [B]Coding More Carefully[/B]