Sunday, May 20, 2007

I'm A Professional

I hate meetings. Some meetings are really needed, like brainstorming or stuff like that. Those meetings are just fine, I still don't like them, but I understand. What I abhor most though, are the "study group" meetings.

There are I think two facts that we can assume here. People want to control how they use their time. I think that's a fair assessment, even if you're not Type-A. And second, people have differing ways of learning. They pace differently, people have different styles. Some study at night, some at day. Some prefer reading from a paper book, some from a PDF. Some learn very quickly, some need the slow ingestion of data. What we can assume rightfully so is that it differs, and no two persons are alike in studying style.

What "study meetings" do is throw those two facts into the air, and when they fall, spit and stomp on them for good measure. It forces people to "use" (I'm using this word very generously) a specific block of time to enforce "studying" (again, used very generously). A topic that could have otherwise been studied by an engineer, by herself/himself, for 15 minutes, is turned into an hour and a half of mind-numbing Powerpoint slide-infested reading session. It forces people to "learn" by reading slides on the screen and ingesting the interpretation of the presenter. Hey, isn't that familiar? Yeah that's right! That's school.

I thought when I graduated I got away from that. Apparently, No. From experience, people spend most of their time trying hard *not* to fall asleep during these meetings (lights closed, and only a slide projection up front as illumination, why not?). To enforce this "study meeting" style is to be callous to the differing needs of people, and is a stark failure in recognizing we are all mature and responsible, professionals.

I don't understand why the engineer can't be told "Study this. We need to learn about it by [date]." Why is that so hard? Is it because the boss doesn't trust the engineer to study it by himself? Excuse me. We're all professionals here. We all know our responsibilities. When I fail to study, that's MY fault and my ass on the line. He did his part by telling me to study. He's absolved! Why does he feel the need to hold my hand through the goddamned process? What am I, eight? Jesus H Christ.

I'm sorry, but I just can't wrap my mind around this shitty "style" for learning. All it does is waste time, which could've been otherwise spent on something more productive. Or I could've spent that time learning by myself, at my cube. I could've finished earlier, and studied some more stuff. About the only thing it is viable now is as a time-eater. And if we're having them for the sake of appearing busy, then that's just sad.

The Job

A job, for most people, has one primary purpose: source of income. We work to obtain money. Money to pay the bills, money to buy stuff, money to eat. In a slightly narrow-minded view of the world, we could say we work in order to live. Something like that.

Now when your job doesn't pay you enough money (its all relative really), you turn to its secondary purpose: satisfaction. It makes you happy. Some are really lucky to find a job they absolutely love. Not just the people they work with, but the job itself. Perhaps the work offers challenges. Or it manages to fill your interest in one specific area or whatnot.

But when your job fails to make you happy and doesn't pay you enough money, then you've got a problem right there. It just doesn't make any sense to stay. Not only are you doing yourself a disservice, but you are almost torturing yourself (masochism is now being served).

And no, logic doesn't make leaving any easier. It makes it heartless and cold, but not easier.

Tuesday, May 15, 2007

Why I'd Rather Burn In Hell Than Fill Up A Design Portfolio Document

A handful for a title, right? Just like a Design Portfolio document.

I don't know whose idea this was originally, but I have to applaud the sheer *ingeniousness* of putting ALL of your accomplishments the past year into one document. I have trouble recalling what I did last week. Let alone LAST YEAR.

If the aim of this document is to make rating as objective as possible by relying on physically recorded accomplishments, then bravo. Riddled with document titles and page numbers, source code files and line count and other nuggets of information deemed "appropriate", this document is to objectivity as cookies are to basil. No, that doesn't make any sense. Neither does a Design Portfolio document.

Sure it makes for good reading of what you've accomplished during the past year. If you just didn't spend an unwarranted excruciating week filling it up.

I know of no person that likes doing this document. The rookies don't like it either. I think the general sentiment toward it is borderline HATE. When the majority of people who have to do one thing don't like it, there's a real problem. Yes, nobody likes throwing out the trash either, but that's a NECESSITY. Doing this unholy abomination of a task, is NOT.

If the aim is to create an objective atmosphere in terms of rating, why not do the rating 4 times a year? That way, the accomplishments will still be fresh in everybody's (the rater's and the ratee's) minds. Plus you don't have to create an ungodly 10-page document that nobody really reads. Rather than waste everybody's time with something that serves no purpose other than for ego-boosting (or deflating, if you find yourself at a complete loss on what to jot down), why not inject a little bit of creativity here and go with a different style. Surely almost a decade of doing this crap has tired somebody out.


Tuesday, May 8, 2007

Oracle solutions...good, great fantastic, but do we have the money?

Today, a bunch of us went to the oracle solutions forum . Aside from nourishing us with the thousand calorie breakfast, we were also fed information regarding the three oracle products in store for application development namely

The Oracle *10 (seems to work 10* faster than Oracle)
The Oracle Berkeley (no SQL needed, straightforward access to database)
Oracle Light (online sub when the server is away)

They also talked about partnership and everything embedded with their product. starting from the Cisco Routers, Google, Amazon, Shisheido, HP, Miscrosoft, Linux and our client whom I will not disclose the name anymore.

It's an eye-opener and a wallet burner maybe, since it seems like a fantastic product, does the company have the budget for it anyway?

o_O

not to mention one of our crack jokes was is their employment opportunities in oracle.

Wednesday, May 2, 2007

because life goes on in the cube farm..

post-release activities. memory leak check! o_O

say hello to Valgrind, a mean little tool that sniffs out the memory leaks in your program. we were all given modules to check, and modules to fix.

running valgrind needs to have your program or library running on some environment first, since the executable will be released later on in the program, frank made a script to dupe our program to say "hey! i'm the _ _ _ exe file, run me so I can run a memory leak check test on you since you aren't the first exe running this show."

#!/bin/bash
BIN=fake executable.bin
valgrind --leak-check=full --leak-resolution=high --log-file="actual executable" ./$BIN $*
memory leaks. wtf are they anyway...if you're those computer g33ks, you'd know right away its those memory that is still all over the place after you run a program in C/C++. most of the problems are with regards to the following:
  • missing free, delete, delete[] - i admit, i am sometimes at fault with this regard of programming principle.
  • mismatched free, delete[] and delete - now this is just....craptastic...enough said.
  • unused memory, memory violations and the like - more other troublesome fixes that you have to either know the codes / classes back to back. or you just blindly stab in the dark hoping it's the right memory you're freeing.
so the usual, check line numbers, trace and fix. the missing and mismatched frees and deletes
were easy to fix, but we encountered a problem with the module that still had some leaks ranging from 48 bytes --> n*16 bytes depending on the number of subscribers.

so we had the following clues (same scenario/sequence all through out):
  1. an n number of subscribers running has a memleak of (random number) + 16*n
  2. infinite loops sequences is okay, doesn't change the memory leak
  3. disconnection detection doesn't really affect the memory leak.
  4. no leaks of that matter detected on an erroneous gsq file (there was 1, and we fixed that one too).
  5. same leak detected on an erroneous cfg file.
  6. happened during start of test execution (scenario was target nodes are disconnected), so nothing about execution.
turns out it was a front memory leak for a BUNCH of memory that wasn't deleted in a certain .cpp the formula on number 1 was just the top level memory. the object in question was a certain
dictionary data structure pointer

what's in the pointer anyway? well, it's an array of Node pointers each containing more node pointers inside it (and inside the nodes contain data).

it was enough to bust my brains out. the actual module owner got to fix this problem, with me in the wings. since you really need to know the ins and out of this module for it to run safely, and not accidentally delete a bunch of vital information. so here's that happened:

old destructor of dictionary file:
Nodes::~Nodes()
{
delete []next;
}

sure, it WOULD work, but doing this would delete only the top level array and leave all the memory inside it hanging and leaking and exploding in the background.

so here's the new added code.
Nodes::~Nodes()
{
//ADDED by XXX XXXXX 05/02/2007 XXXXXXX BEGIN
for (int mIdx_i = 0; mIdx_i < nLength; mIdx_i++)
{
if (next[mIdx_i] != 0)
{
delete ( next[mIdx_i] );
}
}
if (Data != NULL)
{
free (Data);
}
//ADDED by XXX XXXXX 05/02/2007 XXXXXXX END
delete []next;
}


this ensures that the node arrays inside of the node array gets cleanly deleted...
and that was the end of the supposed memory leak problems.