admin

Since I’m on the subject of great quotes, I came across this one some time ago. I think it contains advice that we should all take to heart:

Any society that would give up a little liberty to gain a little security will
deserve neither and lose both.

Have a guess who said this? I bet you’re thinking it was some modern radical? It was non-other than that great and diverse American, Benjamin Franklin (1706 – 1790).

Maybe we should display this on gigantic bill boards instead of promoting the ‘war’ on ‘terror’. He also said:

If you would not be forgotten, as soon as you are dead and rotten,
either write things worth reading, or do things worth the writing.

Certain quotes seem to resonate in the mind. One of my favorite is from a man who was born in the 15th century, but whom I feel would not be too out of place in the world as we know it today:

In the land of the blind, the one-eyed man is king.
[In regione caecorum rex est luscus]

DesideriusErasmus, Adagia (III, IV, 96)
Dutch author, philosopher, & scholar (1466 – 1536)

Desiderius Erasmus was a spiritual man, but loathed the corruption inherent in the organised religion of the time. Erasmus stands as the supreme type of cultivated common sense applied to human affairs.

He is the author of a surprising number of well known quotes that have endured through 500 years of history:

Prevention is better than cure.

He who allows oppression shares the crime.

And rather surprisingly!:

Women, can’t live with them, can’t live without them.

1. Make Sure the Promotion System is Unassailable: In companies where promotions are not available, merit pay systems tend to become contentious, because merit increases are the only way to earn more money. When promotions are available, employees tend to focus on promotions rather than the merit pay system. A promotion system should be founded upon a series of job grades, each with a salary range in line with industry standards and regional averages.
2. De-emphasise the Merit Pay System: Studies have shown that, when information sharing and coordination are essential, organisations that reduce pay differences between the highest and lowest paid employees tend to perform better over time.
3. Tie Profit Sharing to Economic Divers: Identifying a key economic driver and tying team profit sharing to it avoids suboptimisation by ensuring rewards are linked to improvements as a whole.
4. Reward based on Span of Influence, Not Span of Control: Evaluating individual results rather than group results, creates competition rather than collaboration amongst team members. Profit sharing should reward large teams rather than individuals or small groups. This reward system fits well within an Agile environment, which takes the broad approach of involving everyone in the development process.
5. Find Better Motivators than Money: Do not use money as a primary motivator. Invest in people by developing their skills, share information widely, emphasise Leadership rather than Management. Emphasise the intrinsic rewards of fun, growth, teamwork, challenge and accomplishment. Monetary rewards should be treated like explosives! Use them lightly and with caution.

(Taken from ‘Team Compensation’ by Mary Poppendieck, Aug 2004, reprinted in ‘The Best Software Writing I’, selected and introduced by Joel Spolsky)

Noticed this String Formatting in c# compendium via Mitch Denny‘s blog. A nice reference to bookmark. Most of this information can be found in MSDN, it’s just that I have trouble finding it every time!

If you have already subscribed to this feed in an aggregator, could you redirect it to the new feedburner feed at the link on the left hand side. Thanks!

…So I’m having this nightmare about a marauding robotic giant Squid controlled over the internet by masterminds unknown…Bruce Schneier continues his squid themed Friday blog posts!

Microsoft have recently released Performance Console (PerfConsole) 1.0 a tool that can be used to simplify and analyse Visual Studio profiler output:

“PerfConsole is a simple performance investigation tool which tries to adopt a
debugger like experience to drilling into Visual Studio Performance Profiler
generated data.”

This is for those managers who believe they can promote team work by giving raises to just a few members of a team! If you are a manager that has recently experienced high staff turnover, I suggest you read this carefully:

1. When team members are in competition with one another for their livelihood, team work quickly evaporates.
2. There is no greater demotivator than a reward system that is perceived to be unfair. It does not matter whether the system is fair or not, only that there is a perception of unfairness.
3. When management exhort team members to do what is clearly impossible through the offer of rewards rather than helping to make the task possible, people are likely to be insulted and give up without even trying.
4. Optimising a part of chain invariably suboptimises overall performance. One example is separating software development from support and maintenance. If developers are rewarded for meeting a schedule even if they consequently deliver error-prone code without automated test suites, then support and maintenance will cost far more than was saved during development.
5. Once team members get used to receiving financial rewards for meeting goals, they begin to work solely for the rewards, not the intrinsic motivation that derives from doing a good job and making their company successful.

(Taken from ‘Team Compensation’ by Mary Poppendieck, Aug 2004, reprinted in ‘The Best Software Writing I’, selected and introduced by Joel Spolsky)

I’ve been hearing a lot of good things about this book Beyond Bullet Points by Cliff Atkinson. I haven’t actually got my hands on a copy yet (one topic sure to get me on a rant, is how it is quicker to get a shipment of books from Amazon in the US to my doorstep, faster and cheaper than going to a technical bookseller in Perth), but I will presently.

I noticed that a recent talk by Brad Wilson on the topic of agile pair programming was written using these techniques, and several other high profile presenters seem to be taking Cliff’s advice on board. Definitely one to add to the reading list.

Want to hear something really scary? On average, a programmer reads just one technical book a year (Code Complete: Steve McConnell). It got me thinking; let’s be optimistic and say that the average every programmer reads 2 technical books related to their work each year. Now assuming you have a productive working career from the age of 20 to 60. That means you will read just 80 technical books in your entire working life! As a consequence, it means you should be very discerning about which ones you read. You may not have realised it but you just don’t have time to read any poor or out of date technical books!

OK. Now you have decided to only read useful books, how will you pick which ones you should read? Jeff Atwood put up a list of recommended reading for developers, and I’ve previously posted a list of recommended computing books. One that is on Jeff’s list that I really should add to mine is The Pragmatic Programmer: From Journeyman to Master. You could probably read this book together with Code Complete and be well on the road to enlightenment!