|Pedantic|

My development work browser is Mozilla (I do my surfing in FF). Years of fighting IE means that I generally write stuff that will just work in that browser without having to test it too extensively. So, naturally, I became a little complacent... and don't even test in IE anymore.

My boss is finding that a portion of Javascript validation for the current project is just not working. His work browser is IE...

Here's my code:

name = find('name'+i); email = find('email'+i);
if (name.value == "")
{
 alert("Please enter this name")
 namefield.focus();
 return false;
}

So when I don't enter a name, Moz/FF warns me. IE... just pretends like it's not there. No warning or error.

Turns out, for some reason, that name is reserved in some way.. I can still use it.. it just ignores what I do with it!

Changing name to namefield fixed it.

The ActiveRecord pattern is one of the most useful patterns to come out of the current excitement over Ruby on Rails: Rails didn't invent it, it just made it popular.

But it is not limited in any way to Rails or Ruby. A PHP framework I'm using at the moment, called PHP On Trax (more on that later), has a great PHP implementation of ActiveRecord. You don't even have to use their whole stack to take advantage of their ActiveRecord implementation.

So why aren't Design Patterns more popular ?

The aaaaa database: it covers for your mistakes

The database restore tool in Enterprise Manager selects the first database alphabetically as the one to restore over. If you forget to change that trouble ensues. Having a dummy database in place means you will never restore over anything important. Our A customer was not too pleased when he lost a days work; especially the second time it happened.

I can truthfully say, though, that it wasn't me! *phew*

A colleague said something which echoes my dilemma:

Well I have issues with the company for sure but maybe I have a too high opinion of myself.

Some nice viewpoints from an experienced manager/IT worker: Stevey's Blog Rants: (Not) Managing Software Developers

I still have a lot more experience to gain; I know my firmly held beliefs will change. That being said, I still think that some formality, some measurement is very valuable. I think it's because I am frustrated by not knowing where I stand right now: What is expected of me? Am I meeting up? That's why I'm so big on one-on-ones. You can give and get that kind of valuable feedback, even if there isn't a formal plan with concrete metrics.

"...Metrics and ROI are closely related and subject to many of the same fallacies.

I think that this "management by spreadsheet"... is in many cases a defense against unwanted ideas. If managers don't want something to happen they can ask for ROI calculations and dispute them ’till the cows come home.

If they do want something to happen (like corporate jets), they can simply do it without demanding ROI analysis. Thus metrics become a tool for defending the status quo and any preconceived notions management may have."

From the comments of The Problem with metrics on Positive Sharing

I don't think metrics have to be bad. There's just so much bad management going around and metrics are misused for "management by spreadsheet". I think  good management is like good news;  you never hear about it.

Tags: management, metrics

I just had to link to this:

"That’s why managers matter, and why management is vitally important."
The 10 Beliefs of Great Managers

Tags: Management

I "interviewed" a friend about performance measurement at his organization.

---

Do you think the performance measurement is effective?
Effective in doing or changing what is really the question. Some companies do it cause it is "best practice" and don't even measure the effectiveness or care. If the aim to be effective in creating better code - then I don't think it is effective in that. I don't think something that is done once every 6 months (or even 12) and done on a piece of paper is going to change "micro" things like creating better code - Better developers sitting with weaker developers numerous times throughout a day is more likely to create better code. What I do think performance measurement could be good for (but most companies don't see it like that) is measuring the "macro" or longer term performance of someone (especially measuring them against what they are MEANT to be doing as opposed to what they ARE doing). A lot of smaller companies I think are very used to "put your head down and work" they never look at the bigger picture and never even get to setting longer term goals let alone measuring them. What is a longer term goal is questionable but things like building up coding knowledge base, or migrating all historic systems to a new code base maybe?

 Do you get an accurate appraisal of your contribution and effort?
As above I think generally the problem is that the appraisal is trying to use a "macro" type of forum to address "micro" type issues. What good is saying to someone your code is "generally" of "good" quality. I do not think that quantitative measurements are particularly helpful either - after all what does being a 7/10 for clean code really mean? However when tying into a bonus system sometimes you need these. Also a 7/10 is completely relevant to what company you are in as well as what is expected of you. A senior developer is expected to produce better code than a junior developer, however that doesn't mean you give the junior guy 2/10 for everything. Far more useful is knowing how to improve. So short answer - No, not in my experience is it very useful.

Do you think that other measurements might be better?
Specifically I would like to see IT companies spending more time measuring the employee (and the company) in a far broader view. The company (or representative) and the employee need to continually discuss how they are being mutually beneficial to each other - with specific reference to the longer term. Many companies (and especially IT companies) seem to think people work for them so that they can get paid. While this is true - people have a lot more reasons for working at a company - their career being one. I wait for the day when my boss has an open (and non-threatening chat) to me about what other options I have in terms of job/company as well as career. I think bosses prefer to be ignorant and presume that as long as they pay their staff (and enough) they don't have to think about anything else. I think bosses would prefer "not to know" why their staff might want to work elsewhere. Anyway - the reason I think this is so important is that once companies and employees can start to align their longer term goals - and continually ensure that they are still aligned - the shorted term goals are far more likely to fit in place.

Do you think the measurements used contribute to your productivity?
Productivity for measuring performance is misleading. Attainment of Goals is far more useful. I can be productive because I write thousands of lines of code. But it could be very bad code. Or maybe it is really good code but the client didn't really want that function in the first place and I was just getting distracted because it interested me. Productivity measures quantity (within a certain quality allowance). Measuring someone's performance is FAR more complex than measuring quantity (or quality). To only measure productivity assumes that productivity is even a goal in the first place. Short answer again - No I generally don't think the appraisals or the measurements generally contribute to productivity.

---

Not very encouraging. What is the job description of Manager?

I'm intrigued by the concept of Performance Measurement. I think that an organization must set concrete goals for its staff, transparently measures progress towards those goals and provide regular feedback on that progress. That, to me, is the essence of management. As a manager I ask myself:

• Am I setting goals for my staff?
• Am I providing ways to measure progress and are those methods transparent?
• Am I providing regular feedback?
• Do my staff have an opportunity to feed back to me?

I'm not implying I'm good at this! But a step in the right direction can make a big difference. Some people think this is the management of the future. I think it's common sense. And I'll tell you why.

Give your people credit for knowing what needs to be done. Don't take their word for granted. But at least be open to really hear what they have to say. Encourage them to be open and say what's on their mind.

News From The Trenches

Managers, are you listening more than you are talking? One-on-ones!

Is it possible that three simple rules can make you a great manager? Yes. Hire the right guys, set them free, and give them all the glory. It works.

from Computerworld Security