Search this blog

21 March, 2008

No direction home.

I've noticed a couple of things about coding. One is about drunken coding, but it's not the topic of this post. The other one is about finding solutions.
I'm always surprised that most of the times when investigating bugs, or when trying to optimize a piece of code, or in other words, to find a new solution for a given code snippet, I tend to spend a lot of time at work with tools, iterating between the code, the debugger, Pix, and stuff like that. I probe the code, I dissect it and gather a huge amount of info.
But many times I don't find the solutions for those problems at work but on my way back home. At the same time I exit the company I start thinking and after a few minutes I find something to experiment with the following day.
Are those tools, fast iteration, the wealth of possibilities we have to operate on the code, reducing our thinking time? Many times it seems easier to tweak the code and find what happens, instead of pondering about the problem.
Is that something that happens only to me? Probably this is why I love minimal IDEs and languages for my home projects.


Anonymous said...

How about the feeling of ease, when you leave the building?
It's usual, when you "take some fresh air" to solve things even if you think less about them.

DEADC0DE said...

Yes probably that is a big component as well, because if I simply wander in the building I still can't think as freely, I get distracted by my friends/coworkers, I'm wondering if someone has a good technique for reaching that kind of concentration while we still are at work, and if other people have found what I wrote to be true.

Unknown said...

As you know, at work I'm using C# and maxscript, which to some extent frees me from thinking about many problems.
On the contrary, at home, I'm using g++, makefiles and I even avoid STL (you know why, after all your company has it's own STL implementation;)
And the answer to your question: not understanding what your colleagues are saying really helps to concentrate (unless they are screaming) :)

DEADC0DE said...

C# is not minimal, but it's really a great language and yes, I find it very inspiring. I don't agree with STL, for games having an in-house implementation is nice because it's the same across all the different platforms, we can control better the memory allocations and we also have some non-standard data structures in it, but in general, even plain compiler-provided STL is nice (the only exception being the usually cryptic error messages)

Unknown said...

Perhaps we misunderstood each other a bit. To me "minimal" means more or less "low-level". And at work I'm forced to use tools that will get the job done as soon as possible (C# and maxscript for example). This speed often comes at the cost of me not knowing exactly what happens under the hood (still from time to time this pops out: like max reporting problems with redraw callback whereas it's in fact a problem with the use of maxscript heap).
Now at home I want to get back to the full control and so I'm not even using any IDE for g++. I think this is a good way for people like me, who are just learning, cause it increases my awareness of what I'm actually doing.
I'm not saying that STL is EVIL, quite the contrary. Just, after discovering what exactly happens inside some of its classes, I decided that they are not necessarily the best option for my own needs.
The point is that your idea of tools freeing us from thinking is a more general trend, which I think manifests itself in the increased use of managed languages like C# or C++ gurus who blindly advice to use STL without looking at its implementation.