.

[Alphathree33]

.

 

[Ameesh]

When i first came out of college i was very uncomfortable reading other peoples code, now i can read pretty much anyone's code and understand whats going on, looks like you work with a bunch of n00bs. dont worry, the clarity comes with time and practice. randomly changing variables values in code you dont understand is poor and very innefficient.

 

[lancestorm]

Being a programmer is like being Peter from Office Space. I really hate my job.

 

it's mental
understanding the logic is what makes one a programmer...........that and knowing the languages to create logic

 

[Daishiki]

wouldn't hurt if your co-workers tossed in some comment lines here and there

 

[CraigRT]

Originally posted by: lancestorm
Being a programmer is like being Peter from Office Space. I really hate my job.

best movie...could it depict this stuff any better?
nah

 

[Ameesh]

Originally posted by: xUCIxDaiSHi
wouldn't hurt if your co-workers tossed in some comment lines here and there

comments can lie.

 

[DaveSimmons]

Flailing about changing things at random is definitely not the right way to do maintenance programming -- you should be learning to use trace and assert macros and to use the interactive debuuger if your environment supports one. More important though is that you should understand the structure of the program you're maintaining.

Yes, some random block of code might not make sense at first, but if you understand what it's supposed to accomplish and step through it (either in a debugger or on paper) it should become clear why it's failing.

You need to master maintenance programming, since at successful companies, products persist for years and maintenance work often far exceeds work on new products. Once you know what you're doing it's not so bad though.

 

[rh71]

Programmers are a different breed. Either you like looking at [real]code, or you don't.

<-- living the life, but not exactly liking all aspects...

 

[CChaos]

It really depends on where you work. I know this relationship is going to sound convoluted, but here we go: my wife's cousin's fiance works for GE in upstate New York doing experimental work with Java. From what he told me, they play around with the limits of the language's functionality and really just do research, but they aren't developing systems for any particular purpose. On the other end of the spectrum is me. I work on a well-developed system doing bug fixes and the occasional enhancement to existing applications. I can have projects that involve as little as deleting radio buttons from a dialog or adding 2-3 lines of code. I can certainly understand how the system works (it's VB after all), but usually it requires some research due to the amount of code and components involved. I occasionally do a little work in SQL or Crystal Reports, but only very minor development. I'd say we're both programmers, but clearly we do very different things.

 

[Ynog]

Originally posted by: Ameesh

Originally posted by: xUCIxDaiSHi
wouldn't hurt if your co-workers tossed in some comment lines here and there

comments can lie.

Ahhh there is nothing like outdated comments.

I love saying something like the code says this, and getting in response, oh don't worry about
that, we changed that a while ago, it doesn't do that anymore.

 

[Descartes]

What Ameesh said pretty much sums it up. Just changing things to "see what happens" is sometimes called programming by coincidence, and doing so is usually indicative of a lack of understanding of the code and/or problem. The first step to ameliorating this problem is to NOT program by coincidence. Do NOT make a change until you profoundly understand the problem and are unequivocally certain that your change will resolve your issue collaboratively (with other changes) or directly.

IMO of course.

 

[XZeroII]

//Increase number by 1
X += 2


"Oh yea, I forgot to update the comment"

 

[Ameesh]

Originally posted by: XZeroII
//Increase number by 1
X += 2


"Oh yea, I forgot to update the comment"

if you comment when you increment numbers you should be killed. people who end up doing that usually have more comments then code.

 

[yllus]

Usually when analyzing someone else's work I do a couple of quick pass-throughs over a section of code to visualize in my head what it does. Then start at the top of the code and break it down line by line until you have a complete understand of what you're looking at.

Every language I've learned (save for Pascal and Java way way early on) has been primarily through looking at existing code and taking or modifying the chunks I want from it. If you have a solid base of knowledge on how things should be coded, unless you're looking at the work of utter idiots you'll figure out how things work quickly enough.

 

[melly]

It means to go crosseyed. Get out now. While you can.

 

[XZeroII]

Originally posted by: Ameesh

Originally posted by: XZeroII
//Increase number by 1
X += 2


"Oh yea, I forgot to update the comment"

if you comment when you increment numbers you should be killed. people who end up doing that usually have more comments then code.

//Response
It was just an example
//Done with response

//Click Reply To Topic button
//Clicking Button

 

[weezergirl]

When I first started with the project I'm on, to familiarize myself with what we were doing my project lead had me look at old code and fix the "bugs". OMG..it was so freaking hard and confusing. But then I got the hang of it and now mostly I write my own code from the ground up, which is definitely more fun.

I still have to debug other people's code once in awhile but it's mostly my own code now. And now that I understand everything a lot more, it's easy to look at other people's code and debug it. If you have a firm grasp of the language...it shouldn't be TOO hard to decipher most people's code..no matter how bad. Of course, there are exceptions. If you are at the point where you are just changing values and getting "lucky"...I would think you don't have a firm grasp of the coding language being used...