General discussion


Certs are needed for some

By sremiger ·
I think Certs are a good in the sense that they provide a goal for learning. In fact when I shifted to Project Manager I made it clear to my developers that any materials needed for learning to develop software on the dot net platform would be paid for by the company. 0 takers, In fact I have fired 2 senior developers because they chose not to use coding standards and best practices in developing the software. So as of 9/1 of this year I told every developer that they need to get the MCSD by 8/31/2007. The company has stated many times that they will pay for training, books practice test and cert test regardless of pass or fail. Of the 5 developers still remaining 0 books have been ordered 0 practice test and 0 classes have been registered.

This conversation is currently closed to new comments.

Thread display: Collapse - | Expand +

All Comments

Collapse -

CERTS Required?

by Jaqui In reply to Certs are needed for some

complete stupidity on the part of management.
a cert means nothing, specially in something as wasted as a Micosoft product.

grab a couple of brain cells from your developers, they aren't stupid enough to beleive an ms cert is worth the paper it's printed on.

Collapse -

Certs are NOT needed

by Snak In reply to Certs are needed for some

I have to agree with other posters that totalitarian style 'project leadership' does not work with talent.

Two points:

One of my better, well self-disciplined programmers has not one single cert. When asked why, he said 'I'm so far ahead of the game, slowing down to be assessed would be a retrograde step.'

Standardisation stifles innovation. You want same-old same-old, then standardise.

Collapse -

Standards and Best Practices aren't a bad thing

by ed.carden In reply to Certs are NOT needed

While I don?t disagree with many of the response that a totalitarian approach to management is a bad idea as well as being threatening to employees I must also disagree with those same posters about Standards and or Best Practices being a bad thing.

I have to believe that most if not all of the posters who criticized Standards and or Best Practices in some way are most likely programmers themselves who don?t like these 2 ideas and prefer the ?Cowboy? approach to coding. There is a lot to be said for using a defined standard and following a set of Best Practices. And I say this not as a programmer or as a manager but as a support tech who has to deal with what development puts out and I can tell you that when every developer is doing their own thing and not following a standard or any best practices guidelines is only making it harder on everyone else both inside development and outside. If every programmer codes like he or she likes to then when it comes time to make changes to another developers code it?s difficult to make those changes in a simple and efficient manner unless you just know how that programmer writes code. And while some of you may be in a small enough shop that you do know each others coding style and practices, not every one is that lucky. At my company we have over a hundred persons connected to development in some way that have a say in what goes in the code. Now if everyone of these employees is doing their own thing instead of following a set of guidelines then the end result is a nightmarish pile of code that becomes harder and harder to follow and or revise.

A perfect example of how not following a standard and or set of best practices guidelines is something that happened not to long ago at a place I worked at. The company hired this 4 star programmer, a real whiz kid, who could do some amazing things. He was tasked with creating a fairly large set of code that produced something that worked with XML. I don?t know the details of the product he worked on only the story about what happened with it and the programmer. Shortly after completing the project he left the company for a better paying job elsewhere. When it came time to integrate what he had built into the core product, no developer in the company could do it. And that?s because no one could follow what he had done. Because no standards where in place, he wrote code however it suited him resulting in something that was impressive but useless because no one could integrate it into our product. Had he still been with the company then yes he could have either assisted someone or just integrated it himself. Even without this guy we still had some very talented programmers and so the problem wasn?t that we didn?t have anyone that was good we just didn?t have anyone that could understand what this genius programmer had done.

The moral of the story is that no matter who good you are or how good something is that you produce, if no one but you can understand it then it?s worthless.

For those of you out there who keep posting criticisms about having to follow some standards or best practices guidelines, get off your high horse and quit being so arrogant. Your cavalier attitude affects more then just your project manager.

Collapse -

I know him

by Tony Hopkinson In reply to Standards and Best Practi ...

people like that drive me barking mad.
I'm so clever no one else can understand me = ksv\cablBSBA A QOJIW49U590 !

Loose translation, too stupid to communicate effectively.

Collapse -

Perfect Reply: Can I work with you?

by ray.labrecque In reply to Standards and Best Practi ...

That is an excellent reply. I am willing to bet your premise that the whiners are themselves rogue programmers is right on spot! I have appr. 30 years experience in s/w systems design and development and am not the primary contact point to IT Admin and Tech Support. I do not have certs or degrees (ok, one Assoc degree...) but I do have tons of hands on experience. The most problematic projects I have been on were either mis-managed, or, implemented by design and development teams that had insufficient standards and procedures. Absolute mandates are not good per se, but it looks to me like this manager is between a rock and a hard place and trying his/her best to resolve an issue. No Certs do not make good programmers, but it seems he has already stated that his team needs to standardize and get with the program and they still refuse. Golly, gee, but in my school, the boss is the boss, and if he is signing the check, that gives him lots more rights than what I have! Get off your high horse, get on the team and conduct yourselves in a manner that is condusive to LONG TERM success for yourselves, your team, your management and your industry. Compromise, respect, good work ethics, morals and consideration all have a place in the work environment. I hear a bunch of prima-donnas that don't like to be told what to do. Guess what folks, in every successfull work environment there is ALWAYS a boss...

Collapse -


by NOW LEFT TR In reply to Certs are NOT needed

'I'm so far ahead of the game, slowing down to be assessed would be a retrograde step.'

That reads to me - I'm scared of being assessed.

Collapse -

No - not scared

by Snak In reply to Question?

I appreciate your comment but this guy actually writes good code, documents every line and is my top innovator. ALL genius operates 'outside the box'. Take any scientific discipline and look back at it's innovative heroes. They're all mavericks.

Collapse -

Documents every line and writes good code

by Tony Hopkinson In reply to No - not scared

If it was good code ie readable and maintainable, why does he have to explain every line in english ?

All that practice does is double your maintenance overhead and increase perceived points of failure.

Tell him to be more efficient with the annotation, you'll get about 30% more work out of him.

Collapse -


by ray.labrecque In reply to Documents every line and ...

>> All that practice does is double your maintenance overhead and increase perceived points of failure. << ARE YOU JOKING??? All code needs supportive comments and documentation. Maybe not every line, but certainly frequent and concise comments are NEVER wasted overhead! Wow, I can't believe you said that out loud!

Collapse -

You missed an entire thread on the topic

by Tony Hopkinson In reply to Huh?

I said it there, I say it here, I say it everywhere.

I say it LOUD enough so people start paying attention and thinking about what they are doing.

Comments are not necessarily documentation. If they are annotation, ie code 'in english', then 90% of them of an utter waste of time.

What does

int NumberOfInvoices; // The number of invoices

do for you.


//Loop through listOfInvoices
For Each InVoice:InvoiceType In InvoiceList Do

void PrintInvoices()
/* This method of InvoiceList prints the invoices in the list */

That's what the policy comment every line gives you, not to mention making searching the source a damn nightmare, and more than doubling the confusion level about the code after a cut and paste.

I say it loud and often, in the vain hope that someone will listen.

It's not a new idea and it's certainly not mine. I recommend you read the Pragmatic Programmer.

Every time you think I'd best comment that, ask yourself why. There might be a damn good reason, if so comment away by all means. At least then a comment in the source will be valuable, instead of **** retentive clutter.

Related Discussions

Related Forums