Constant Random Change

I’m now selling books to help cover for shipping expenses spread hard to find knowledge to people thirsty for information. More information here.

You know the drill.

Learn a new language to complement your programming skills.

It would be a typical New Year’s resolution for developers to learn a new programming language this year. But seriously, what’s the point of learning C# when you’re a Java developer (or vice versa)?

What you should be striving for are programming languages that are orthogonal to your current skill set. If you’re an enterprise developer used to statically typed OO programming languages, try dynamic languages like Python and Ruby. If you’re already using dynamic languages, try your hands on functional programming like Erlang and Scala. Same goes for platforms: web developers might want try programming in RIAs.

The point here isn’t to add bullet points to your resume, but to have different ways of looking at problems, like adding new tools to a toolbox. For example, had I not been aware of the basics of functional programming, I might have tried to force traditional Java-like synchronization techniques in my Google Wave gadgets instead of the more elegant FP approach.

—

Just a short plugging:

Rapid Development’s Classic Mistakes (in software development) was a real eye-opener for me when I read it four years ago. Even though it was written almost a decade ago, a lot of the mistakes listed there were still present in my company.

To keep the list up to date, Construx (Steve McConnell’s company) is now holding the Classic Mistakes survey for 2010. Help update the study by taking the survey here.

For anyone who has experienced working in a corporate environment, reading books about 21st century management can be really depressing. Rapid Development made me feel really down (especially since it was just lying there in the office bookshelf with no managers or senior developers reading it), but it wasn’t as bad as The Essential Drucker: that book affected me so much that at one point I closed the book and didn’t touch it until I felt better.

Here’s an excerpt from Peopleware, another book on managing software teams, discussing something about productivity. See if it could make you put your face in your hands and groan:

Historians long ago formed an abstraction about different theories of value: The Spanish Theory, for one, held that only a fixed amount of value existed on earth, and therefore the path to the accumulation of wealth was to learn to extract it more efficiently from the soil or from people’s backs. Then there was the English Theory that held that value could be created through ingenuity and technology. So the English had an Industrial Revolution, while the Spanish spun their wheels trying to exploit the land and the Indians in the New World. They moved huge quantities of gold across the ocean, and all they got for their effort was enormous inflation (too much gold money chasing too few usable goods).

The Spanish Theory of Value is alive and well among managers everywhere. You see that whenever they talk about productivity. Productivity ought to mean achieving more in an hour of work, but all too often it has come to mean extracting more for an hour of pay. There is a large difference. The Spanish Theory managers dream of attaining new productivity levels through the simple mechanism of unpaid overtime. They divide whatever work is done in a week by forty hours, not by the eighty or ninety hours that the worker actually put in.

That’s not exactly productivity—it’s more like fraud—but it’s the state of the art for many American managers. They bully and cajole their people into long hours. They impress upon them how important the delivery date is (even though it may be totally arbitrary; the world isn’t going to stop just because a project completes a month late). They trick them into accepting hopelessly tight schedules, shame them into sacrificing any and all to meet the deadline, and do anything to get them to work longer and harder.

While I was going through Rapid Development looking for the backhoe story for the previous post, I came across the graph above.

Looks familiar, huh?

It’s practically the same productivity-to-time graph as the one in the Satir Change Model.

Continue reading »

No Silver Bullet tells us to be skeptical about claims of tools that can provide drastic improvements in productivity. What we can instead hope for from productivity tools are minor, yet still significant, improvements.

However, both lowering our expectations and going with proven technologies aren’t enough to receive productivity benefits when introducing a new tool. Many companies still fail because of a certain classic mistake: Lack of Training.

Continue reading »

The most annoying part about passing by the Computer section of bookstores is when you realize that all of the books in the bookshelves will be obsolete in 5-10 years. This is why serious software engineers prioritize books on processes and methodologies over books on tools.

One guy (Jurgen Appelo) compiled a list of the best of SE books based on “1) number of Amazon reviews, 2) average Amazon rating, 3) number of Google hits and 4) Jolt awards”. Think SE version of Personal MBA.

Below the cut is the top ten. I’ve included my own mini-reviews for the books that I’ve already read.

Continue reading »