I learned two new things today:

grep -c

lsof

I thought I learned a third, but I can’t get the syntax right for ${var_name}, alas.

(You can find the full list here)

Gather near, grasshopper, and let me tell you of the venerable ancients of programming. These sages of the code pass their wisdom on to the young, instructing them in the ways of pointers, and objects, and closures. There is much experience to be found here, in their minds. You have only to listen.

Venerable Ancients are the experts of the programming world - the ones who have been doing it longer than some of their peers have been alive. They can tell you stories of the old days. Before the dark times. Before Microsoft.

er, where was I? Ah yes. Venerable Ancients. There are two kinds of Venerable Ancients. Those who have changed with the times, and those who havent. If you are so fortunate as to work with a Venerable Ancient who is still an avid learner, who can compare and contrast Ruby with Smalltalk, C with C#, Python with Lisp, then you ought to spend as much spare time as you can working with that person. Experience is good, but experience and adaptation? Priceless.

If, on the other hand, you work with a Venerable Ancient who seems set in their ways, who is excruciatingly well informed about one language, or one particular hardware platform, or one set of compiler tricks, then your road is more difficult. These people are often smart, and knowledgeable, but they don’t like all this newfangled stuff that keeps you away from the machine. Pointers and Drivers and hand-crafted assembler - that was real programming. These kids todays? They’re playing with toys.

Good Things

• Adaptive Ancients are usually incredibly good at solving problems elegantly and simply. Mainly because they’ve solved it 1500 times before
• Adaptive Ancients do not fall for hype, but do listen
• Both kinds of Ancients can tell you stories of the old days that will make your toes curl
• “Set in their ways” Ancients can spot and fix problems within their area of expertise faster than anyone else, usually much, much faster

Bad Things

• Adaptive Ancients rarely put up with bullshit, because they don’t have to, which makes them likely to leave all but the most developer-friendly environments.
• “Set in their ways” Ancients rarely accept change - they don’t like learning new things. (Otherwise, they wouldn’t be called “Set in their ways”

How to identify them

“Set in their ways” Ancients say things like:

• “The architecture of the PDP-10 was just art”
• “Garbage collection is for people who don’t know what they’re doing”
• “I like vi. vi works for me. I’m not going to use your stupid IDE”
• “I’m too old for this shit.”
• “I just want to see the contents of the registers. Why is that so hard?”

Adaptive Ancients say things like:

• “Ah, they borrowed that concept from Smalltalk”
• “Emacs was good, but this IDE is really powerful, once you get used to it.”
• “Wow. That’s neat.”

Update - I’ve seen enough comments on the subject that I will point out add that everyone who isn’t old enough to be a Venerable Ancient is obviously a Venerable Ancient in training.

If you want to experiment with Flex, but don’t want to pay for the full Flex Builder, the Flexifier is a great way to experiment, debug and get your hands dirty in a simple, online form.

How do I know? Because I learned a bunch of interesting things about Laszlo using the same technique.

This weekend has been an exciting one for me, with 10000 page views across several of my posts.  I was able to get general stats in real time from MyBlogLog, for free  - visitors, pages viewed, and # of off-site clickthroughs.   The actual data - the places the clickthroughs went, the referers and the pages they visited - not so much, but I have other tools that help me with that (various standard website reporting tools)
Given how easy it was to set up, and the interesting concepts of community associated with it, I would say that I’m glad I tried out MyBlogLog, and it might be worth your time to try it out as well.

Alice, Bob and Eve

A long, long time ago at JavaLobby, Eric asked:

The most common piece of advice is that in addition to technical skills, IT people need to develop “business skills”. A lot of these articles never list some of these business skills, they simply repeat that phrase.
So the main questions are: What are some of the “business skills” that IT people should acquire? How do I go about getting them?

What:

• Understand “Return on Investment“
• Understand “Opportunity Cost“
• Understand the difference betweeen Gross Revenue, EBITDA and Net Income
• Understand Cash Flow, and why it’s often more important than any of the others, especially in smaller companies

If you take the time to understand these things, you’ll have a pretty good understanding of why business people will often make decisions that

1. Seem shortsighted
2. Seem counterproductive
3. Seem greedy and abusive

Don’t get me wrong! There are times when business people are shortsighted, counterproductive and greedy/abusive. However, often they have reasons for what they do. Programmers often think that other people are stupid, because they don’t understand how to make computers dance. But they’re not stupid. They’re wired differently.
How:

• Join a startup, the earlier in its lifecycle the better
• Take some economics classes
• Listen to economics podcasts on your way in to work, or on your way home
• Read entrepreneurial blogs
• Update - Walter Williams has a 10-part series on Economics. It won’t be perfect, but it’s free, and easy to follow.
• Update #2 - A reader suggests: “Stop on the street, choose some random business nearby. Ask yourself how they make money.”

In my opinion, when you can listen to the Administrator explain why he likes the Machine that goes “Ping” and you understand what he is saying, and why he might prefer that model, you will have grasped the essence of business.

Update: - added two new suggestions to the “How” list.

Update 2: It just occurred to me that I should mention my own blog - PicoBusiness, which is obviously written from a business/technology cross-over background.

I just registered the domain name EnterpriseRails.com; let’s see whether I can come up with something interesting to put there.

Here are some interesting links discussing the concepts around Enterprise Rails

• Martin Fowler thinks Enterprise Rails is an oxymoron, but he thinks Enterprise Ruby is a valid and valuable concept.
• Defendem.com has a book on Enterprise Rails deployments
• Justin Gehtland thinks that there’s a huge opportunity for Enterprise Rails, and ThoughtWorks is showing the way. (Here’s a direct link to some Thoughtworks Rails news)
• Stefan Kaes has some analysis of performance improvements in Rails
• Jon Tirson thinks it’s already more Enterprise ready than J2EE in some ways.

I reserve judgement for now on that last one.

Update:

• More performance improvements and tips

What happens when you have 4 different versions of a language being worked on at the same time?

So, there are 4 Ruby runtimes in various states of being built. They all (except for 1.9) will be fully compatible with 1.8 and they will all run Rails just fine. So, what’s going to happen when some enterprise customer wants interfaces or some other optional typing mechanism

*snip*

At the core, I think Ruby is defined by Rails. Sooner or later, the Rails guys will realize they’re the dog and start finding a tail that’s easier to wag for the customers with lots of money. That will likely lead to fractured Ruby syntax and fractured Ruby dialects.

Try as I might, I can’t disagree with his analysis. There will be some very interesting challenges for Rails as it evolves forward.

Update:

Jonathan dissents.  He makes some good points, but Lisp doesn’t have the kind of Internet hype that Rails has, so I’m not sure it’s a valid comparison.

Inspired by this article from Marginal Revolution (which, in turn, was inspired by this article from Wired), I’ve already written a couple of Six Word Stories.

But I think it would be fun to try to write some that are constrained by the domain of software programming - i.e. stories about various programming languages, and maybe things related to programming.

Eclipse

Eventually, Eclipse became its own plugin.

C#

I am so better than Java!

Java

How did I become today’s COBOL?

Ruby

Rails, Rails, Rails… What about ME???

Rails

Must not… succumb to… the hype!

PHP

Rails? Hah. Flash in the pan.

Python

I’m just as good as Ruby!

User Submitted: “Because beautiful is better than Ugly.”

Notepad un-indented my code. Oh Shit!

Visual Basic

I was “it” once! What happened?

Perl

They’ll come crawling back. You’ll see!

I was the original web service.

C++

Hello World\n*hF3#lk 38&1@n a))$@ ~!P:l fl

Smalltalk
All your concepts belong to us.

Lisp

(no ‘they all belong to (us))

COBOL

Without me there wouldn’t be PCs.

FORTRAN

Without me there’s no Neutron Bombs.

IntelliJ

“No can do, Dave.” IntelliJ wrote.

Visual Studio

And in the darkness, bind them.

Update: Added a bunch of new ones, some grammar edits.

Update 2: Lots of visitors from Reddit. Thanks for stopping by.

Instapundit asks:

But as a wise woman once said: “The Colonel is dead, and here we are still enjoying his chicken.” Extra points if you can spot the source.

Answer:

• My first guess was the Mom from Beetlejuice, but…
• Googling has revealed it was the Mom from Strange Brew

A friend of mine wrote a great Rails app that aggregates movie news from a bunch of sources.  Check it out!

Critical-Acclaim.info

Courtesy of Johanna Rothman, but you’ll need to register (free) to read the article. She gives some good advice about how to handle slips early in a project, during the middle of the project, and then an all-too-familiar story about slips late in the project, and how the team got there by focusing on the plan and ignoring reality.

Which, (my words) ultimately, can be summed up as:

Reality Eventually Wins

Hat tip: Hal Macomber

(Click here for the full list)

Lazy Ones

I once worked with a guy named Ed. He was one of the most conscientious programmers I’ve ever met. He wrote beautiful code, well organized, easy to understand, virtually bug-free and rigorously commented. One day we were discussing programming, and he said that he wrote all those comments because he was lazy - he didn’t want to have to work hard to change the code later.

I’ve lost track of Ed through the years, but I often think about that conversation. For me, well-written unit tests are my way of being lazy. A good, use-case level automated test suite is (in my experience) an incredibly powerful way to validate the behavior of the core of the system, a great tool for teaching the key concepts, and, most importantly, an outstanding way to minimze the amount of frustration involved in changing and re-doing the system over time. And so far, it has worked very, very well - I don’t have to spend a lot of time maintaining old systems. They run, they do their job, and I revisit them occassionally to add features.

Many of you might have had a different image in your mind when I wrote “Lazy Ones.” - you were probably thinking of the slothful slackers who stealthily sneak and slither, souring source code serendipitously. (Sorry, couldn’t resist) But I don’t think they’re lazy. If anything, they are Tired.
Good Things

• Lazy programmers look at the whole system, and try to find the way to satisfy as many goals as possible, having learned through experience that not satisfying as many goals as possible will surely lead to annoying rework
• Lazy programmers often seek to improve themselves, learn new languages and techniques, so they can find new ways to solve problems efficiently.
• Lazy programmers hate doing grunt work, and will, whenever possible, find ways to automate or scriptify the work, instead of doing it by hand.

Bad Things

• If they get work that is not only tedious grunt work, but essentially impossible to automate, Lazy programmers get very, very grumpy
• Sometimes (perhaps more often than others) Lazy programmers are prone to overbuild - overreaching the actual need
• Lazy programmers often hate/despise/deplore the concept of having to fix and debug crappy code

I did some consulting work for Dreamworks last year, and early this year. I learned a little bit about Shrek 3. It’s interesting to see how the concept has evolved since I first read about it.

This one should go over really, really well with the Moms out there - a much more energetic and “take charge” role for the fairy princesses. Like this one:

I set up my site with the MyBlogLog tracking script.  So far, “You might be a Blub Programmer” is a huge hit, with about 75% of all of my traffic so far.

I’m not exactly sure, but I suspect that it’s the Smalltalk people who are shipping it around right now.

In any case, it’s been a fun day to experiment with.

An interesting new website, that tries to “humanize” blog readers and create communities around the readers, instead of creating communities around the authors.

I think it’s an interesting idea - it might help you (or me, or anyone) discover other blogs that you might find interesting.  You have to sign up, of course, but once you do, it will keep track of which blogs you visit within the community, and who visits yours.  You get some interesting stats as a “perk” for signing up.

If you read this blog, consider signing up.  It might be a great way to improve your blogging experience.

Thanks to Ashley Frieze for pointing me towards this.

Robert Martin provides us with a great demonstration of how to avoid bad programming in Ruby entitled “The Hungarian Abhorrence Principle”

The general rule can be summarized as:

When you are tempted to encode data structure in a variable name (e.g. Hungarian notation), you need to create an object that hides that structure and exposes behavior.

However, you should read the whole post for a concrete example and additional thoughts.

More generically - if you need to know the structure of your data type in order to work on it, it probably means you’re not using good encapsulation.

I probably do this several times a day, so it’s definitely something for me to be more aware of.

With apologies to Ambrose Bierce

Iteration

• A way to divide a large, impossible project into smaller, impossible chunks

Daily Meeting

• A means to receive inaccurate and untrustworthy information faster

Unit Testing

• The technique by which developers convince themselves that their bug-ridden software isn’t

Refactoring

• A practical example of the proverb “There’s never time to do it right, but there’s always time to do it over”

Burndown Chart

• A fancy graphic meant to distract the uncurious sponsors from the fact that your project is going to be late and over budget

Trust

• The art of smiling and nodding politely when you listen to a developer lying through their teeth about the status of their work.

Post-Mortem

• A technique by which the failure of a project is explained, without using words like ‘Trust’, ‘Refactoring’, ‘Unit Testing’, ‘Daily Meeting’ or ‘Iteration’

Pair-programming

• A way to force introverted, socially awkward software developers to work together in close proximity for hours on end.  See also: Hell

Scrum

• An agile development methodology famous for dogpiling on one person when the project is late

Extreme Programming

• An agile development methodology where team members who fail to deliver are forced to ride down steep mountainsides on uncomfortable, expensive bicycles

Sprint

• A form of iterative development that would work well if only every month was 30 days long

Backlog

• The list of things that everyone pretends are important, but will never get done

Emprical Process

• What you call something when you want to look professional, rather than shrugging and saying ‘How the hell should I know?’

User Stories

• The lies the end-users tell the  programmers so the programmers will leave them alone and let them get back to work

Continuous Integration

• Two falsehoods in series - “Continuous” should be “Regular” and “Integration” should be “Testing”

Regular Testing

• What any minimally competent software development organization should be doing, without trying to fancy it up with sophisticated names

Planning Game

• The art of making the critically important task of prioritizing work seem trite and child-like

Sustainable Pace

• A mechanism to ensure the developers will still be fresh when the marathon bug-fixing maelstrom occurs at the end of the project

Metaphor

• A way to describe the software project in layman’s terms, ensuring that the highly literal and technical software team will have no idea what they’re actually building

Big Design Up Front

• Also known as “Getting it right the first time”  (See: Refactoring)

Note to everyone who got offended by this -  If we can’t laugh at ourselves, others will.

Kevin gives us the 411.