From the "Lessons Learned" section of my journal:

The real problem is almost certainly not what the customer says it is.

Also:

Sullivan's Rules for Getting and Keeping Clients:

• Listen to your clients so that you understand their business needs
• Match leading-edge technology to the client's goals
• Explain in business terms how your solution will help the client meet goals
• Deliver on time and within budget
• Use a framework that helps ensure quality control
• Network with associates who can bring value to your projects
• Use your success stories to sell yourself to clients
• Keep your technical skills up to date through training
• Develop good verbal and written communication skills
• Share knowledge of IT trends with your clients

- Romeo, Jim: "The Fine Art of Getting and Keeping Clients." Contract Professional, Vol. 4, No. 7, March 2000, pp. 28

Source unknown:

Know your priorities. A computer that crashes constantly isn't as important as part of a network that has suddenly gone down.

Murphy's Law states if anything can go wrong, it will. Always be prepared for anything that might happen throughout the day. Keep a backup plan for everything.

Know how to deal with everything on your network. It's good advice to know how to do everything, from running the server to adding new hardware in a machine.

Use a team effort whenever possible. Things get done faster when you team up to work with your fellow IT peers.

Know your users. This helps you understand their wants and needs, and allows you to provide assistance to them much more easily.

Give extreme timeframes. If someone needs something done, tell him or her it will be done in a week, and hand it to them 3 days later.

From Tech Republic:

Develop and test a backup plan.

Schedule hardware upgrades during a known good environment.

Communication is key.

Walk away from a problem to take a deep breath, then return to the troubleshooting basics. We were so intent on fixing the problem that we neglected to first identify the problem.

Never anticipate that you can have a smooth day, get off on time, and enjoy hours of play online with Rogue Spear.

From: Just another smooth-running day in IT . . .NOT! (original link - still works, to my surprise)

Give extreme timeframes. If someone needs something done, tell him or her it will be done in a week, and hand it to them 3 days later.

I got told about this one by a senior colleague (sp?), and it is the best lesson i ever learnt: People are pleased when you finish 'early' and not angry when (inevitably) your timeframe was over-ambitious and things take longer than you expect! Brilliant.

It also helps combat the extreme under-estimation of timeframes by non-programmers:

"All you have to do is click a button! Why will this take so long!?"
"Well, first i have to build the button..."

Just a something something...

I got told about this one by a senior colleague (sp?), and it is the best lesson i ever learnt: People are pleased when you finish 'early' and not angry when (inevitably) your timeframe was over-ambitious and things take longer than you expect! Brilliant.




Well, it worked for Scotty:

James T. Kirk: How much refit time before we can take her out again?

Montgomery Scott: Eight weeks, Sir, [Kirk opens his mouth] but ya don't have eight weeks, so I'll do it for ya in two.

James T. Kirk: Mr.Scott. Have you always multiplied your repair estimates by a factor of four?

Montgomery Scott: Certainly, Sir. How else can I keep my reputation as a miracle worker?

James T. Kirk: [over the intercom] Your reputation is secure, Scotty.

;-)

HTH,

planetscape

Every program contains at least one bug. Every program can be shortened by at least one instruction. Therefore, by induction, every program can be reduced to one instruction, which doesn't work.

• you can have it fast, cheap, well done - pick two
• work to the documentation

you can have it fast, cheap, well done - pick two

That should be pick at most two.

G. Wade

Use a table, even if most of the entries are the same/empty, it makes your logic simpler and computers like them (remember this was when you sweated over every byte your code used).

No, that was back when the CPU would run on the same frequency as the RAM so you didn't have to think about caching. Nowadays looking up something in a large table can be expensive because accessing RAM is slow, but on the other hand conditional jumps can be expensive too because of prefetching and decoding, so figuring out what takes more time is much more complicated. (But at least there's still good documentation (eg.) so if you really take the time to RTFM then you can make an educated guess.)

Meta request: Is it possible to derive a statistic for a given monk, that shows how many of their original, or first reply posts, contain a (significant) code section?

---

Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.

"Science is about questioning the status quo. Questioning authority".

In the absence of evidence, opinion is indistinguishable from prejudice.

RIP PCW It is as I've been saying!(Audio until 20090817)

I think that's only possible when someone starts an ambitious project to download almost all content of perlmonks again and does all kinds of analysis of the data.

Formal process doesn't improve code quality. It just increases the delays and annoys the developers.

Having each and every code release approved by ten people that know nothing about the code changes and would not understand the code even if they tried, doesn't increase security. Just the feel of it.

Making changes on production is dangerous. As such it should be done by someone who understands the application and the changes being released. Do you really think a separate "release engineer team" who is in charge of releases for all the company's aplication, blindly following a "release plan" is a good idea?

A small example of code that got through a massive formal process and had been on prod for some time now:

sub syb_executeQuerySingleValue {
    my $query = shift;
    my $dbh = shift;
    my $val = undef;
    $recordSize = executeQuerySingleValue($query,$dbh) ;
    return $recordSize ;
}
[download]

nostrum |ˈnɑstrəm| (noun)
* a medicine, esp. one that is not considered effective, prepared by an unqualified person.
• a pet scheme or favorite remedy, esp. one for bringing about some social or political reform or improvement.

A link to Perl Best Practices.

Or if you're looking for things you could actually pin up on a notice board, how about copies of some of the Top Ten lists at the back of the book?

common exit

^*Did I miss any?

Does %SIG fit into that list?

I considered that, but if %SIG breaks "common exit", then any subroutine or function call would, wouldn't? Assuming the handler doesn't terminate the process, a signal handler returns to the point where the block was left, so it's not more an exit that calling any other sub.