3p||<

Ronaldinho gets some attention from a pitch invader but a red-shirted security guy has control of the situation and escorts the invader off the pitch using a bear-hug. Just as the both of them are about to step off the pitch, another red-shirted guy runs onto the pitch and uses unnecessary roughness to subdue the already subdued invader.

So there, you have it, an actual video of a person rushing in to claim some credit when someone else has already done all the hard work!

I have made this mistake countless times in Java where I type “if (variable=1)” instead of “if (variable==1)”. The former will always return true since there is no error assigning the value “1″ to the variable (assuming correct variable type), whereas the latter depends on whether the variable contains the value “1″.

To prevent such errors from cropping up in your code in your conditions, you can make use of the non-intuitive reverse conditionals. To modify my example above using reverse conditionals, I will type “if (1=variable)” and “if (1==variable)” instead. In this case, the former will immediately throw up an error upon compilation since it is not possible to assign a value to a literal in this case.

Some sites seem to perform a simple date check where they just check if “Day” is a number between 1 to 31, “Month” is a number between 1 to 12 and the “Year” is a valid number.

While this check is inexpensive, it is definitely wrong as you may end up with strange combinations such as “31st April 2010″ or you may also wrongly allow “29th February” to occur on non-leap years.

To save yourself some grief, make sure you use the checkdate() function to validate your date data.

The word “hero” often conjures up the image of someone in a spandex costume with a cape who swoops in to save the day. In the context of an IT project, it may be someone who is called in to assist or take over the reins due to resource restrictions or some other purpose.

All is well and good if the person turns out to be a real deal and is able to guide the project back even though “all the roads that lead us there are winding, and all the lights that light the way are blinding” (thanks to Oasis).

But of course, there are also self-proclaimed “heroes” who somehow manage to blunder their way to a project conclusion and then spare no effort in trumpeting their “achievements” while all the other members in the project team know that little credit (if any) was due to the person. To use a football analogy, sometimes Manchester United can be playing so well that you can even put your grandma in the first team and they’ll still win the match comfortably. Sufferers of such “heroes” should take comfort that luck, smoke and mirrors can only carry the ”hero” so far. The truth will reveal itself sooner rather than later.

With regards to benchmarking, there is a chinese saying “人比人，气死人” (You will only anger yourself when comparing yourself against others).

When it comes to benchmarking, perhaps it is most useful when comparing against similar projects within the same organisation since the baselines (company culture, company structure, etc.) should be the same. However, what is most important is that project reporting is truthful and the management is willing to accept deviations from the benchmark if there are valid reasons.

Problem is, we’re talking about corporate flexibility when it comes to standards. “Flexible standards” comes close to being an oxymoron, and few are the corporations that have management willing to commit to such an undertaking.

In the IT world, certification is given quite heavy weightage when it comes to beefing up your resume, however employers should be wary that a certification just means that the person knows about the best practises behind the certification standards but does not necessarily mean that they will make use of those skills.

For instance, I have come across PMP and PRINCE 2 certified professionals who have detracted far from what is preached by those standards. Some of them may have been restricted in the sense that they need to fit into the corporate culture, but others may just lack the necessary skills (both hard and soft skills) and are just hiding behind those pieces of paper.

Certification may be important, but it is not what defines the person. Ultimately, since IT work usually involves working closely together in teams, such cert-rich but skills-poor people will get exposed and lose their credibility.

Although I like the concept of Test Driven Development (TDD), I have yet to apply it in a corporate context as it might be excessively off the beaten path for management to accept comfortably.

As it will be difficult to explain TDD within 3 paragraphs, I have left it to Wikipedia to do the honours. Basically what it entails is to write the test case first before writing the code that is expected to pass the test case.

In the course of improving a process or product, you may need to utilise experiments to isolate which are the factors that are most important (remember the 80/20 rule?).

While the design of experiments is usually touched on in University, the concepts may all be forgotten by the time the student is ready to apply them in the commercial world. For a quick refresher, Wikipedia has a succinct article: http://en.wikipedia.org/wiki/Design_of_experiments

Unfortunately, this is one skill that probably can only be developed through repeated mistakes because it is not likely that a freshly minted graduate will be able to give an accurate estimate of the duration that an activity will require.

If anything, it is common for people to overestimate their abilities and underestimate the amount of time required to complete an activity. As a rule of thumb, you will probably need to add a buffer to your estimates but not to the extent that you end up “padding” your duration estimates (which is not considered professional behaviour).

When accepting input from users in your web application, there is always the chance that the user will key in some code that causes errors ranging from the cosmetic to the malicious.

One of the most common cosmetic errors is when the user formats everything nicely in a <textarea> but all the formatting is lost when it is redisplayed. This can usually be easily solved by using the nl2br() function where all the new lines in the user’s input is converted to HTML-friendly <br /> tags.

To guard against malicious code such as when users try a cross-site scripting attack or inject some HTML that can seriously screw up your web page, you should clean up the input by using the htmlspecialchars(), htmlentities() or strip_tags() (arranged in ascending order of “paranoidness”) functions depending on your requirements.