jessenoller.com

A nice quote:

One machine can do the work of fifty ordinary men. No machine can do the work of one extraordinary man. -Elbert Hubbard

I find this to be very, very true when I talk to people about 100% automation goals, and outsourcing of iterative/isolated tasks.

People always respond "automation/outsourcing will take my job!". My reply is always the same - no, it won't, not if you alter the collateral/value you generate. People have the capacity to grow, to change and to learn. The automation of repeatable steps, and the outsourcing of isolated projects (generally, iterative and simple) frees people to excel in their area, to become domain specialists, and to generally "become better".

Now, does it always work this way? No. Large corporations are notorious for automating/outsourcing and then canning a large swath of people. Like all ideas, and like all tools (and automation/outsourcing is a tool), the idea can be abused.

I am lucky enough to work for a company that is small, agile and understands these things. Both the benefits and the pitfalls of theses ideas.

Just a random thought.

Marketing? Why Do You Use Python?

Steve Holden has hit the nail on the head in a recent blog post about python "marketing" Marketing? Why Do You Use Python?

I've already posted a comment, but I figured I would expand on it a litte - at my current company we originally went with Perl/Java/Shell/C for everything outside of the core product (ie: tools, installers, etc). Having an amalgamation of languages is interesting, and people really simply picked those things they already knew.

Over the past few years, as I have gotten "better with the Python" I have slowly seeded a "revolution" of sorts. I've managed to get a lot of people (Java people, Perl people, Shell People) using Python for many things. (And no, I can't talk about most of them).

But the way I "started the revolution" was to show them the RAD aspects of the language, and showcase the fact that yes - it does scale, yes, other companies use it. Yes, it is easy to learn - "look, I just hooked N people on the language and they have become X+% more productive". I generated examples, taught people, and led by example wherever possible, frequently building highly useful applications and pointing at them and saying "look!".

I would showcase the standard library and ease of use. Luckily - everyone in the chain of command is highly technical, so it is easy for me to "win" on technical merit. But Python can't just be marketed to the technical people. I/we can't/shouldn't make the same mistakes that the Java Hype Machine made, and we can't start a Microsoft-esque smear campaign against other languages.

Python is a wonderful tool, and a wonderful language. It's ease of use, portability and RAD aspects make it highly versatile and easy to use to ramp up less technical people into more technical roles (this is what I have done with the QA team internally), but it also serves as a highly powerful tool for even the most technical of developers. (We should market to both groups)

Don't market Python based off the negative of other languages. Show people the merits of the language, and show them applications, show them how to Win and become successful with the language. Show them case studies of other companies, and let them decide.

Get the word out, and make is simple, and make it clear. Good marketing campaigns tend to offer a clarity and simplicity that attract people. You don't see Nike marketing messages about the new sole of a new shoe, do you? No. You see them saying "if you get this shoe, you will be a winner".

Let's see if we can show people "If you pick Python, you will be a winner!" (And here's why...)

Python Libraries

Does anyone have any good "guides" for build nicely self contained Python Libraries? I'm converting a few thousand lines of code from application-specific libraries to thing that will be dropped into site-packages.

While I have a really good idea about what has to be done, I'm looking around for something that says something akin to "good idea, bad idea". For example:

• Logging to the screen, or stderr (unless raising an error) : Bad Idea
• Not properly checking for dependencies : Bad Idea
• Properly raising exceptions (and providing custom ones) : Good Idea
• Unit Tests and PyDoc : Good Idea

I'm still scouring for information, but any suggestions and pointers are welcome.