Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase 1234»»»

Coding More Carefully Expand / Collapse
Author
Message
Posted Thursday, January 12, 2012 12:13 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 4:10 PM
Points: 33,095, Visits: 15,202
Comments posted to this topic are about the item Coding More Carefully






Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1234540
Posted Thursday, January 12, 2012 6:25 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Friday, June 27, 2014 12:43 PM
Points: 15,444, Visits: 9,596
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
Post #1234719
Posted Thursday, January 12, 2012 6:56 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, June 27, 2014 12:59 PM
Points: 24, Visits: 169
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.
Post #1234772
Posted Thursday, January 12, 2012 8:11 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 4:10 PM
Points: 33,095, Visits: 15,202
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?







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1234857
Posted Thursday, January 12, 2012 8:53 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Yesterday @ 8:57 AM
Points: 2,518, Visits: 3,718
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.

Post #1234923
Posted Thursday, January 12, 2012 8:54 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Friday, June 27, 2014 12:59 PM
Points: 24, Visits: 169
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.
Post #1234926
Posted Thursday, January 12, 2012 9:02 AM


SSCoach

SSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoachSSCoach

Group: General Forum Members
Last Login: Friday, June 27, 2014 12:43 PM
Points: 15,444, Visits: 9,596
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
Post #1234941
Posted Thursday, January 12, 2012 9:29 AM


SSC-Dedicated

SSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-DedicatedSSC-Dedicated

Group: Administrators
Last Login: Yesterday @ 4:10 PM
Points: 33,095, Visits: 15,202
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.







Follow me on Twitter: @way0utwest

Forum Etiquette: How to post data/code on a forum to get the best help
Post #1234998
Posted Thursday, January 12, 2012 9:50 AM
SSCrazy

SSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazySSCrazy

Group: General Forum Members
Last Login: Monday, July 28, 2014 3:45 PM
Points: 2,892, Visits: 1,784
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: -

  • Initially it slows everyone down

  • 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

  • Once it beds in the weaker developers get an accelerated learning experience from the better ones leading to a much stronger team

  • The stronger team results in higher code quality, fewer post implementation hot fixes



The benefits go beyond the immediately apparent.

  • If fewer fixes are needed then the development team are available to move on to the next business deliverable

  • Providing a quality deliverable is a morale booster for the team

  • 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



LinkedIn Profile
Newbie on www.simple-talk.com
Post #1235035
Posted Thursday, January 12, 2012 9:58 AM


Ten Centuries

Ten CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen CenturiesTen Centuries

Group: General Forum Members
Last Login: Thursday, March 6, 2014 1:05 PM
Points: 1,334, Visits: 3,068
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. ..."
Post #1235051
« Prev Topic | Next Topic »

Add to briefcase 1234»»»

Permissions Expand / Collapse