|
Bacchus is all black, the most common color in greyhounds. He's nearly ten, so his muzzle has gotten quite gray. I tell people that he's been going so fast for so long, the color is draining toward his tail.
Software Zen: delete this;
|
|
|
|
|
|
I usually make it a walk to the coffee machine ![Java | [Coffee]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/coffee.gif)
|
|
|
|
|
Yea, but I'm out of this mornings allotment of coffee. I did spill a little while getting my last cup. I looked at the spill, wondering if I was irked because I had to wipe it up, or irked because I lost that bit of the morning's last cup.
|
|
|
|
|
I think it doesn't count as a full cup anymore, so you can have one more
Enjoy 
|
|
|
|
|
I think most of us can relate.
>64
Some days the dragon wins. Suck it up.
|
|
|
|
|
My moment was in a complicated mathematical computation. Was getting wrong results for about a week. Then one afternoon was debugging when I saw that a minus sign was keyed in as a plus sign. After that fix, all results became correct.
|
|
|
|
|
Reminds me of when I took the computer graphics class in college. I had been debugging a 3D clipping algorithm for a week, and it kept failing in a weird way. One night, after I'd been in the lab for almost 40 hours straight (yes, I was insane back then), I went out to the hallway with a listing and stretched it out on the floor. I looked at it for a couple hours, chain-smoking (I was also stupid back then) the whole time.
I finally got up and started walking the hallways. After about ten minutes, the thought occurred to me to check my variable names against the original algorithm. I had used the names the algorithm used, which were unfortunately single lower-case characters. In one place, I had typed a 'b' instead of an 'h', both of which were variables in the algorithm. Go look at your keyboard; I'll wait.
Software Zen: delete this;
|
|
|
|
|
Ah yes. Spreading out listings. I visualize listings on fan fold printer paper. I realize you can get a listing on sheets of paper from any modern printer, but it's just not the same.
|
|
|
|
|
Sounds like a good moment. I'm a big fan of some good math code.
|
|
|
|
|
YES! and like you when in the middle of a particularly annoying problem. I actually begin fantasying about what the get up and walk around is going to be like.
It is particularly fun when I have "budgeted" lets say 8 hours to fix something and have a moment of brilliance and solve in an hour or so. I almost always take an hour or so to bask in my walking around moment. I barely ever take the full 7 I have allotted myself.
It is a wonderful feeling.
To err is human to really elephant it up you need a computer
|
|
|
|
|
Certainly! I recognize the feeling, and the action, very well.
I'll take the opportunity to tell of two other ways of reacting to a victory. This was a math problem, but it might as well have been an algorithmic one:
In preparation for the math finals, two of my University classmates, Jon and Berit, were solving problems from the finals of previous years. Berit was the undisputed #1 in academic results, less so in self confidence. Jon was the other way around - certainly so for the confidence part.
For one problem, they got stuck, couldn't make out how to solve the problem. So rather than locking up each other's way of attacking it, they agreed to split, sit at separate tables apart from each other, trying to solve the problem alone. And so it happened that they both 'saw the light' at the very same moment.
And Jon exclaimed: Boy, am I smart!
And Berit exclaimed: Boy, have I been dumb!
(Those who know them both, says: Right! - That is just like both of them.) After Jon told me of this episode, with a laugh, I asked Berit if it was true. She looked down, and nodded: I guess that is exactly what happened ...
|
|
|
|
|
Anymore I look out the window and thank God in heaven for helping me, then run off to facebook to see what the rest of the world has been up to, play some phone solitaire and just be "analog" for a while before perusing the bug log to see what one will be next on the pole.
|
|
|
|
|
BBar2 wrote: a variable the should be volatile, and it’s not
Ah, memories of Microsoft 'C' 6.0 back in the MS-DOS days. They didn't implement the volatile keyword, and their optimizer would move what looked like loop-invariant code outside a loop. Made for a dandy interrupt service debugging experience. I had to disable optimization entirely.BBar2 wrote: Do you have other victory rituals?
I do the get up and walk around bit too. I wander around for a bit and then come back and make really sure I've fixed the problem.
Software Zen: delete this;
|
|
|
|
|
When I hit a snag and have no idea what else to try, I usually get, take a walk outside and when I return, I normally have some idea of what to try next, etc, until it's solved and time for a bourbon on the rocks.
|
|
|
|
|
Did you ever try to explain the problem to your rubber duck?
I, and many others, can tell you that it works!
A slightly modified variation: Write the documentation for it. Both the user/API documentation explaining how it is intended to be used, and the detailed maintenance documentation, explaining the data structures and the processing logic. Besides: Then the documentation is there, when someone asks for it!
For non-programming stuff, I have been using a further slightly modified way. I really never thoroughly understood how a gyro works. How a heat pump works. How genetics and inheritance works. The chemistry of a battery ... So in my imagination, I keep alive gang of smart junior high school kids in a "Young Scientist Club" giving presentations of various stuff to their schoolmates. As I gradually learn more about a topic, I write it down as these young people's 'lecture' to their schoolmates - including the questions they receive from their audience when something is not clear.
The rubber duck is a children's toy. A child needs to have things explained simply and clearly, yet in a correct manner. And you must be prepared for (sometimes shockingly) logic questions about why and how. Pretending that your rubber duck is that oh, so logic kid asking 'why' is a great help. Letting them materialize as an audience, and forcing that simple and clear explanation into a kid's presentation is mostly a way of 'formalizing' it, but for me, it has great value.
This is an excellent way to force yourself to really get a thorough basic understanding, extract the fundamental ideas in a simple way, making sure that all you say (while impersonating one of the "young scientists") is correct, even if in a simple form. And the question part pinpoints what you have not yet mastered: I write down, as question from the audience, all those nasty 'sorry, I do not have a good answer to that', and then keep up my search for information on the field so that I can provide and answer.
I rewrite 'lectures' all the time: If I manage to express my newly acquired understanding in simple terms, it goes into the basic presentation, but to keep the presentation at the simple level, some advanced parts must be kept as question/answer. It it definitely a goal to get as much as possible into such simple terms that they can be included in the basic presentation.
This is a great way of learning, in a way that ensures that you really understand the problem completely, that you know how to bring your understanding out to others, and you are prepared for a lot of 'surprise questions'. I'll say that I now am capable of explaining to a twelve year old both gyros, heat pumps, optical lenses, batteries, the heterozygote inheritance of apples, how to make cheese, starling flock formation and lots of other things, in far better ways than the school textbooks.
When my daughter was that age, she sort of proved it, coming to me with a schoolbook text that made no sense whatsoever (not even to me...). I explained it "my way", and she sighed: But if it is that simple, why didn't they say it that way, then?
|
|
|
|
|
I've never tried explaining it to a (possibly) inanimate object. I like it. I have had real success uncovering problems by attempting to explain the problem to a friend who is not close to the issue. That can definitely work. I'll try my next problem on my poodle.
On the topic of lecturing students, and getting good questions. I worked in aerospace, and often went to schools to talk to kids. Once I was talking to a group of 9 and 10 year old kids about rockets. The class smart a_s, asked me the best question. He thought he had me. "If fire is supposed to require air to burn, how can rockets burn in space?" Great question. Of course, we know they cary the oxidizer, but that was kid brains at their best. I gave him one of my models to encourage more of that kind of thinking.
|
|
|
|
|
Sure, there's a whole proces. For me often like this: Agitation, walking around and most succesfully, going to the toilet, the idea hits home in a double relief, anticipation walking back to confirm and often yeah, Victory! Then, a bit of an inward, not seeing much, complete rest, hardly a heartbeat and feeling good.
|
|
|
|
|
I remember the moment I wrote my first ever function (1994) in what was then called Access Basic. I had taken one class in Turbo Pascal up to that point, but didn't understand it. I was handy with spreadsheets and understood what functions were. But I was trying to bridge over to databases, and everything looked strange. I don't remember what my function did, but I remember straining to understand how to solve a certain problem I was having at the moment, then having a flash of understanding how a function would help me. I distinctly remember getting up to take a walk around the building on my college campus where I was. I don't really have a victory ritual as such these days. It feels like every victory comes a dozen more action items.
|
|
|
|
|
In baseball terms it's called a homerun
|
|
|
|
|
I am 66, I agree with the walk around time involved in some projects. I started
out writing assembly code, some new, some "maintenance" which really meant chasing
down reasons why the code misbehaved.
Right now I am back in the embedded C (not C++) world in what will probably be my
last full time job. The company is looking to move from one hardware platform to
another and what is now stable code will become unstable once the switch starts. I
have been tasked with understanding twenty year old code with an eye towards adapting
it to new hardware - not rewrite but re-fit. Going to be fun.
|
|
|
|
|
Absolutely. It is time to take half a day off. But first I have to deal with the urgent bodily needs that have been building up while I've been so concentrated on the task.
|
|
|
|
|
i can relate to your entire comment
~d~
|
|
|
|
|
I usually found that the get-up-and-walk-around time was during the analysis period.
Get the algorithm and data in my head, then go for a walk and let it roll around in there. What am I overlooking? What assumptions have I made that need to be challenged? etc, etc.
Then I had a plan of attack, and got into the debug work.
|
|
|
|
|
My get up and walk around moments are usual during debug sessions. Drop the debug session for something completely different and behold when I return I find the bug. This also works when writing on gnarling code. BTW, I'm 74 yr old coder and I also have had those joyful moments of satisfaction.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
