Quote: Original post by CmpDev

Quote: Original post by SiCrane

Quote: Original post by CmpDev
I only posted it a couple of posts above!!

Quote: I would suggest you seek legal advice as to what your position is in relation to if they followed correct procedure during your evaluation period.

And what do you hope to accomplish with that?

I do not wish to accomplish anything, that is a matter for Journey and a dismissal board if it came to that. Maybe Journey would:
- like the job back
- like compensation for ill treatment or for the company not following rules.
- or to stop the company treating future employees in a same manner if there is anything to complain about.

The impression I got from Journey based on an earlier post was that he was working for them during a 'trial' period; this is not unusual and it is normally written into the contract that at any point during this period, including the end, they can show you do the door with no problems.

If he reached the end of the trial period and they didn't wish to keep him, for whatever reason, and the contract he signed at the start stated as such they can terminate there and then with no reason to explain themselves.

If Journey signed such a contract and tried to take them to court over it it would be thrown out faster than rotten eggs as he has NO legal recourse at all.

Now, if during this time the company didn't provide feedback as to what he was doing 'wrong' in their eyes, well thats regretable but again I doubt it leave you with a leg to stand on either. (During my 3 month trial at my current job I had a meeting once a month to discuss how things were going and would have had feedback then on any problems I might have had).

One further observation I might make;

Quote:
Those who get to stay, who get to be promoted, and so on, are usually not the best ones at their job but the best ones at getting along with whoever is in charge.

The thing with working in a team is that while you might be technically better than those around you if you can't communicate with your team members or get on with them you are not 'best at your job'.

This point of communication is, unfortunately, something starry eyed bedroom coders often miss out on when entering the work force. Indeed, we had a guy who started with us the middle of last year who, during his trial period, had a tendancy to rewrite large chunks of code without informing anyone ahead of time causing headaches all around when he totally changed interfaces without letting anyone know. He is a good coder, unfortunately he lacked communication skills and thus at one point was looking like he might be leaving at the end of the 3 months. Fortuntately he took on board the problems, learnt to communicate and is now a valued member of the team.

So, yes, it might look like those around you who are not as good are getting promoted/raises/whatever but chances are they are seen to be better because their communication skills are better and it goes hand in hand with the job.

That again, is a point that merits discussion. The fact that I was never informed of any problems I might be having because as they said, they had "no time", and when we did have meetings, we only discussed the next step in the project, never the problems I was posing to them, NOT ONCE. So if there were problems indeed, why did they keep on giving me assignments?

I was definetly at a severe disadvantage because I was developing a library for a platform that I was competely new to. Every change I meant to make to the new library had to be consulted first, sometimes with other programmers when my superiors were not available, since I didn't want to just stop working and do nothing until he came back. And the fact was that he was away a lot.

In fact my assigned superior was ANOTHER programmer, who had just suddenly dropped interest in checking anything, simply because he was already planning on leaving the company. So I had to use someone else as a backup higher-up.

Here's a question, what did you think of them during this period? Especially during the times when they asked you to rewrite things back the way you had them before?

You were probably annoyed with them because of course you had been doing it right all along, and they should have just let you do it that way to begin with. I would suggest that this kind of thinking can really show through in your attitude and that's probably what people are picking up on.

Also, I would recommand against the idea of "documenting everything". Your goal is not to "prove" that you were right and it was your superiors/collegues who were wrong. That's exactly the kind of attitude that I am thinking of above. There's nothing wrong with asking for clarification or confirming requirements, but if you're just emailing people so that you have "documented" evidence of conversations taking place, then you've got to ask yourself whether that's the kind of evironment you want to work in anyway.

Look at this way, the evaluation period is not just for them to decide if they want to work with you. It's also for you to decide if you want to work with them. If they're going to change their requirements for no valid reason and then blame you for having to rewrite things over and over, then you don't want to be working with them anyway.

On the other hand, if they have valid criticisms of your work, then take them in and accept them as having come from somebody who may not know as much about "programming" than you, but they certainly know more about the project or the rest of the team than you (given that you've only just started there).

In my experience, and I don't want this to sound harsh, but I have found that problem usually starts a lot closer to home than most people like to admit.

I definetly had no problems working there. I never minded not making friends with anybody, though I certainly would have put no obstacle to it. I just wanted to advance in my career. Not to end up with an ugly blot on it. I would have stayed there no matter if anyone hated me.

And certainly some of my superiors had better skills than me. One of them was a physicist whom I admired very much. I was told I was still better "than most of the others" though. They might have felt a bit irritated with certain remarks however.

And even though my method of communication might have seemed a bit stubborn and annoying to them, it was not what I had in mind, and my goal was to simultaneously learn from them and to prove that I was no ignorant (since I was afraid I would be let go because of THAT instead).

Forget about that job. Keep Walking.

Quote: Original post by Journey
That again, is a point that merits discussion. The fact that I was never informed of any problems I might be having

Most jobs have people on probation during their first 90 days, and you can be fired at any time. No reason or warning has to be given.

Next time, spend your first 90 days being more friendly and easy to work with. You are on a trial basis during this time, and not a 'real employee'. Make sure your co-workers and your boss have a good feeling about you so they want to keep you around. If you are argumentative, or difficult to work with, you'll have lots of 90 day gigs.

Also note that you are nothing special, and there are a ton of other programmers out there to replace you. You need to show them why they should keep you! Make an effort to fit in and do everything exactly as instructed.

Sorry to hear about your experience...

Anyway. You see, if someone is critiquing your design, that doesn't necessarily means he wants you to rewrite.

You may have actually been doing things wrong...
"and it was impractical to predict where the text would be shown" - What? It calculates where to draw the text, when it is rendering whole thing, no?


I can tell how I do things on my OpenGL UI:
Any GUI element deals with coordinates in this element's coordinate space, which is analogous to your "standard coordinates". GUI element never stores anything in "client coordinates", why, because GUI element can be moved.
If I want to draw text without scaling, well, I'll just transform text's position (and orientation if I want it rotated) to client space and draw text in client space, non scaled. At most, I would need to add a conversion function, not some rewrite.
So if I were in your position, I would probably not have to do first rewrite because I would have used "client coordinates" anyway, and would not need second rewrite, I'd just calculate text position and orientation (in device space) from what I got.

[Edited by - Dmytry on March 29, 2009 5:17:14 PM]

Quote: Original post by Journey
I would have stayed there no matter if anyone hated me.

Well, no; if during the 3 month trial everyone had hated you then you would have been let go. No matter HOW skilled you are if you can't get on with people then you will be horrible to work with and no one wants to spend 37h+ a week in an office with someone they don't get on with.

Quote:
They might have felt a bit irritated with certain remarks however.

and now we start to get to the root of the issue here.

Quote:
And even though my method of communication might have seemed a bit stubborn and annoying to them, it was not what I had in mind, and my goal was to simultaneously learn from them and to prove that I was no ignorant (since I was afraid I would be let go because of THAT instead).

People are not mind readers, they don't know you, therefore they can't tell if you are being stubborn or just having problems expressing yourself. As for lack of knowledge about a perticular thing, well I assume in the interview/resume/cv you didn't claim to know about the system you were working with, as such they took you on knowing you didn't have that knowledge so that wouldn't have been a problem, indeed showing willingness to learn is important. However if you are comming across as stubborn and annoying instead they aren't likely to keep you.

Now, I wasn't there, I don't know what happened, but from those few comments alone I think we are getting to the root of the issue, to a degree at least anyways.

I didn't exactly have to rewrite "everything". In the beginning I was recalculating the new transformations for the child objects based on the final draw coordinates of the parent, instead of multiplying by the current matrix and passing that transformation on, thus not "relying" on final draw coordinates, which was what they guy wanted. Although my initial approach could be seen as ugly, the interface and functionality remained the same, and not exactly obscure. The point was that my superior ruled out any use of final draw coordinates, which was what I ended up needing anyway when trying to factorize the scaling by finding out the rotation based on the final coordinate of a dummy vector that got transformed by the current matrix. (since its impossible to take the coefficients of a matrix and separate the rotation from the scaling directly, given that the rotation and scaling are combined in the same coefficients)

I needed to write this code in every object's Draw function, so that was what had to be rewritten. The other point was that I ended up wasting time since I was told not to use the final coordinates, which I could have used from the beginning when drawing the text sans the size scaling.

Journey: what's with that second rewrite? You'd only ever need to touch text draw methods, if you do it even remotely right. Cant you just obtain back the matrix from your matrix stack or whatever?
edit:
"(since its impossible to take the coefficients of a matrix and separate the rotation from the scaling directly, given that the rotation and scaling are combined in the same coefficients)"
Really?
For 2x2 rotation+scaling matrix
a b
c d
, used with column vectors, rotation-only matrix is obtained with something like
s=1/sqrt(a*a+c*c);
a*=s;
c*=s;
b=-c;
d=a;
(of course, now, it wont scale your text coordinate right, so you'll need to transform your text position first)