The Weird and The Wonderful

There is no way you are going to change this guy. The only reasonable option is to get out of there as soon as you can. I'm glad to hear that you are starting your own company, hopfully you will be able to make that your full time job soon. :) Bill W Just because the code works, it doesn't mean that it is good code.

Having been there myself many times I understand that at crunch time error messages get minimal consideration. But if there is time to write "Something is really wrong!" surely there is time to write an error message that is a wee bit more helpful. :| Bill W Just because the code works, it doesn't mean that it is good code.

If it is intended for use in production code it is a real horror. If it is just a diagnostic messagebox that will be removed for production code then it is not too bad; the programmer has to be sure to remove it though ;) Just because the code works, it doesn't mean that it is good code.

I reserve my judgment and give the title idiot sparingly and in this case the person is truly an idiot (and no, he's had 10+ years of dev experience). If you had seen the code he wrote you would agree too. "A democracy is nothing more than mob rule, where fifty-one percent of the people may take away the rights of the other forty-nine." - Thomas Jefferson "Democracy is two wolves and a lamb voting on what to have for lunch. Liberty is a well-armed lamb contesting the vote." - Benjamin Franklin Edbert Sydney, Australia

Why would you assume that? "God doesn't play dice" - Albert Einstein "God not only plays dice, He sometimes throws the dices where they cannot be seen" - Niels Bohr

My thoughts exactly. If there were more developers with your kind of humility it would make the rest of our jobs much easier. Thanks

And remind him he was drinking poison... It feels good to learn and achieve

or the ricers who duct tape a coffee can to the muffler of their Civic. :rolleyes:

But the code works so well! :) This statement is false.

What I do is keep crib notes of basic algorithms in my notebook in case they ask you to do one. With the iPhone, you can keep electronic notes of the same things and review them while waiting for the interview to start. :-D

This is my five cents ;-) if(guess == random || guess != random)

This table design could be used to reduce the size of a database and improve manageability that contains unknown/highly dynamic structures I will make an assumption (the only one in this post) and say this project deals with loading structures that change frequently. Could be wrong and be looking at a noob's 'work of art' There are three approaches for highly dynamic structural data: 1. Dynamically create the schema's based on external blue-prints, giving real names to columns. This might not be the best solution for a few subtle reasons which have to do with the degree of knowledge by the end-user's of the database and any planned api's or DAL's. Generating the dynamic schema prior to loading data can be done in two modes: 1. immediately, where new un-generated schemas are encountered and have to be generated on the spot. This presents an obvious problem if you have multiple clients performing the imports for a single database (similar to SETI). Such as, what if two clients encounter the same type of schema that isn't in the database yet, only one schema should be generated. 2. Delayed, where after loading many imports and discovering that some new files failed to match any current dynamic schema, the database user can manually kick off schema generation and then attempt a reload of those files that failed earlier. 2. Contain the all the data into a single table (or a table for each datatype) with four columns (ImportFileId, RowId[original structure's], ParameterName, ParameterValue). This solution gobbles up WAY MORE disk space (more than doubles the space requirement of the solution given above as well as in #1 (In oracle, at least, the remaining columns that are null take up no space.) This is considered serializing the data, also could be called demuxing. 3. Then there is the solution above. The only requirement is that any API must map the ImportFileId to some blue-print of the columns involved. This solution saves much more space than #2 AND has the added benefit of simplicity on the database up-keep side (ie. no schema generation prior to import) I've been down this road dealing with a database with over 400,000 actual unique fields of data. We actually used option #1 for good reason. So, I wouldn't knock it just because it's different.

You might not have seen the post before it was deleted. Why it was? I don't know. The fellow wrote ABOUT a question in the c# forum (NOT THIS ONE). There were no rules broken on posting procedure.

Super Lloyd wrote: Admittedly it does slow down the program a bit Yup. Don't even try to use it in a loop... Greetings - Jacek

omgz my new backround and screen saver image ;P

That would be the first person that admit first and then code. :laugh: I thought of pointing out something like that, but since the sun is shining and I am in a good mood. I didn't wan't to be cruel. Cheers You have the thought that modern physics just relay on assumptions, that somehow depends on a smile of a cat, which isn’t there.( Albert Einstein)

Wow! That literally hurt my eyes. :wtf: Unfortunately I have seen similar code for text processing. You have to keep scrolling back up a hundred lines or so to find out where the value stored in that variable came from and just what the heck it is supposed to be; of course it was probably modified on the way down – loads of fun. :rolleyes: INTP "Program testing can be used to show the presence of bugs, but never to show their absence."Edsger Dijkstra

I think, this code is a result of Reflector disassembling :-D

Whoa.. It didn't even optimize the literals when it was compiled? Did someone forget to turn on the optimizer? :~ -- Kein Mitleid Für Die Mehrheit