January 12, 2012 at 12:13 am
Comments posted to this topic are about the item Coding More Carefully
January 12, 2012 at 6:25 am
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.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
January 12, 2012 at 6:56 am
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.
January 12, 2012 at 8:11 am
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?
January 12, 2012 at 8:53 am
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. 😉
January 12, 2012 at 8:54 am
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.
January 12, 2012 at 9:02 am
Steve Jones - SSC Editor (1/12/2012)
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?
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.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
January 12, 2012 at 9:29 am
GSquared (1/12/2012)
...Yeah, it's one of those "yes but no" kind of things. I at least partially disagree with myself here.
As I get older, this is an hourly occurrence with me.
January 12, 2012 at 9:50 am
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: -
The benefits go beyond the immediately apparent.
January 12, 2012 at 9:58 am
David.Poole (1/12/2012)
If you changed the environment in which someone works then they change the way in which they work. That is in human nature.
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. 😀
"Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"
January 12, 2012 at 11:58 am
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.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
January 12, 2012 at 1:01 pm
"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.
January 12, 2012 at 1:02 pm
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 "Bruce Fortran and the gods of top-down programming" 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 still feel a little guilty.
January 12, 2012 at 1:26 pm
Well, let's compare the programs of today, with the programs back then...
Any questions?
I know, you really liked edlin. 😎
January 12, 2012 at 1:39 pm
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.
Viewing 15 posts - 1 through 15 (of 32 total)
You must be logged in to reply to this topic. Login to reply