The Lounge is rated PG. If you're about to post something you wouldn't want your
kid sister to read then don't post it. No flame wars, no abusive conduct, no programming
questions and please don't post ads.
I was walking the dog this morning I saw a suspicious looking man dressed in dark clothing, crossing the street with a ladder. He had even gone to the trouble of disabling the street light so as not to be seen. I got a good look at him though as he was lit up by an oncoming car. I have passed his description on to the Police.
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952) Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
Yes. Most of my professional life was in tech support so I was trying to debug other people's code. I did enjoy the occasional break to write some code for myself, but soon got fed up and went back to debugging.
I have to agree. I learn a lot from chasing down the answers to the bugs to get the program to act how I want it to. Especially since a lot of times I'm parsing text files. I think I've learned a 100 different ways to manage strings.
Given that right now I'm trying to figure out why the application reports one record when the database query says I should have some 70 or so records, well, this isn't fun. It's not code that I've written, if I had I would have done it a lot differently (yes, I know, the mantra of all programmers working on someone else's stuff), but I definitely prefer writing code than debugging.
That said, I like to write code as if I'm debugging -- what I mean by that is that I imagine the whole stack, the possible exceptions, the possible paths the code can take, and I try coding for all of that. I imagine everyone does that. And when working with F#, I write everything first in the interactive console, test it, then put it into the application. I would love for something like FSI for C# development.
But personally, my first and true love is architecture. But I would have to say that many of my beautiful architecture ideas turn into puddles of mud when I actually try coding them against real world requirements. A good way to learn the difference between theory and application!
That said, I like to write code as if I'm debugging -- what I mean by that is that I imagine the whole stack, the possible exceptions, the possible paths the code can take, and I try coding for all of that.
I try to do that to. But sometimes it comes down to not getting the output I need from a certain block of code.
I would love for something like FSI for C# development.
After working in C++ for a very long time, with edit-compile-debug cycle lengths measured in minutes or even hours, I find the 15-45 second turnaround time from my C# development refreshingly quick. On top of that, I have my entire C# application in a single solution. My C++ stuff had to be broken up into several solutions to bring the individual compile times down to something reasonable.
well actually both are like two side of a coin we can't say exactly that i like this one more than that. good code helps in reducing the chance of generating bug and good debugging skill helps to write better code. as a Programmer i like both coding and debugging.
I'm definitely a coder. Debugging means either (i) you didn't write your code well enough in the first place, so you have to debug it later, which is a failure and I don't like failing; or (ii) you are working in someone else's code which is always painful, and if you're debugging it it means it doesn't work and isn't well enough documented or tested to isolate the problem without debugging. Neither of those things is fun to me.