Project Management: Things the “Top 2%” Get Right

Andy Crowe’s “Alpha Project Managers,” published in 2006.

Crowe surveyed over 3,000 project managers and their co-workers/supervisors in order to identify the “top 2%” of project managers (“alpha project managers”). He tried to identify PMs who were consistently rated as excellent by the people they worked with and their customers. Once he found them, he zeroed in on their work habits and PM techniques.

Some of the interesting findings:

  • Alphas respond to fewer emails/day and spend less time in meetings than non-alphas, yet people rated them as being more responsive than non-alphas.
  • Alphas establish explicit communication expectations, and adhere to them stringently.
  • Alphas sent much shorter communications than their non-alpha peers.
  • Alphas spent twice as much time in the planning phase of their projects than did non-alphas.
  • Alphas used informal networks to get things done much more often than non-alphas (who stuck to formal channels).
  • Alphas were much more aware or how their bosses were being measured (ROI, etc.) than non-alphas.

— Excerpted from the review

Linux: How to Determine Cron-Execution-Time Environment Variable Values

Oftentimes it’s asked how to figure out which environment variables your cron scripts are running against.

The first step in doing so is the figure out exactly which shell cron is using.

/bin/sh is usually symbolically linked to bash on a variety of linux systems. Some Debian-based distros jave /bin/sh linked to dash (you can always run “ls -l /bin” to see such links).

To configure cron’s run-time environment in your shell scripts, add the following environment variables at the top of the cron tab. This will set the shell and $PATH, and it will also email you the output of STDOUT and STDERR as your script is executed.


To go a bit deeper in your investigations, you can have cron execute a Perl script (thanks to Po Petz for the code below). The following prints out your environment variable values. It shows you what is visible to cron at exeecution-time, and helps you figure out whether you need to make any adjustments to the cron environment (such as PATH or any special variables like $HOME or $JAVA_HOME).

#!/usr/bin/env perl
use warnings;
use strict;

my $filename = "$0.out"; # just tack on an ".out" to the name of this script

open my $filehandle, '>', $filename or die "Could not write to ' $filename ' : $!\n";

my $timestamp = scalar(localtime);
print $filehandle "Dumping environment values at $timestamp :\n";

# print out the whole environment
foreach my $key (sort (keys %ENV)) {
    print $filehandle "$key = $ENV{$key}\n";

MySQL: The reason for using the “DELIMITER” statement in MySQL routines (stored procedures, functions, triggers)

This short article illustrates how to format your MySQL routines (stored procedures, functions, triggers) for release. We’ll use the following code block to discuss.

DROP PROCEDURE IF EXISTS mytestproc; -- Don't use "dbname.mytestproc"
DELIMITER $$ -- Change delimiter from semicolon
CREATE PROCEDURE mytestproc() -- Again, don't use "dbname.mytestproc"
# ATS Created test for dbname data 06/20/2013
END$$ -- Use of new $$ delimiter
DELIMITER ; -- Change delimiter back to the default (semicolon). Note that the spacing used here is important!

1) The first step in the script is to drop the existing routine, if it exists. Notice how the procedure name is not prefixed with database name (e.g., dbname.mytestproc). This is so that we can run this same script against multiple databases.

2) The next step is to change the default MySQL script parser’s delimiter from semicolon (;) to double-dollar sign ($$). The reason you do this is so that the semicolons after each statement in the body of the routine are not interpreted by the parser as meaning the end of the CREATE PROCEDURE statement. This is because the entire CREATE PROCEDURE block, from CREATE PROCEDURE to END is actually a single statement that must be executed by itself. Were it not for the delimiter change, the script would break, since there each statement inside BEGIN and END would execute individually. Note that you can use a variety of non-reserved characters to make your own custom delimiter.

3) The next step is to create the routine.

4) Next is the BEGIN statement, indicating the start of the routine body

5) Next are the statements inside the routine, each terminated with semicolon (which will NOT be interpreted as end-of-CREATE PROCEDURE, since you changed the delimiter to $$).

6) Next is the END$$ statement. Notice how END is followed by $$. This actually ends the CREATE PROCEDURE statement.

7) Finally, the default delimiter (semicolon) is restored