Good Enough to Learn

Most programmers would be more effective if they understood business better.

(When programmers talk about MBAs as "empty suits" and decry marketing as "convincing stupid sheeple to buy things they don't need", we can all imagine unscrupulous and ineffective people doing bad things, but we ought to acknowledge that building things only works if we build the right things and get it into the hands of people who value it.)

My YAPC::NA 2012 and OS Bridge 2012 talk is all about doing things wrong. Sometimes getting things done on time, or under budget, or within any of the other constraints you might face, means doing things differently.

I don't advise cutting corners on quality or security. I do mean figuring out your priorities and relentlessly getting rid of things that stand in the way.

For example, I don't use strict on most of my one-liners. I don't write robust test suites for little system administration scripts. Some code I never refactor because it just works as it is.

The more time I spend building and managing my business, the more cognizant I am of simplicity. It might be a fun technical exercise to build a big all-singing, all-dancing framework for all of my applications and spin out everything possible in a generic form to the CPAN, and I could spend the next six to nine months doing that, but that's a lower priority than defining my market, finding customers, and delighting them.

Something similar seems to apply when finding and teaching novice programmers.

We're not going to convince them to ditch Windows (or the Mac) for the one true Unix way before they're worthy of learning from us. We're probably not going to indoctrinate them into whichever branch of the Vim/Emacs debate we care about, nor should we. They won't be registering for PAUSE accounts within the first couple of days (or weeks or months) of typing perl -E "say 'Hello, world!'".

That's fine and that should be a beautiful thing.

Yes, they need to know about perldoc as soon as possible.

Yes, they should get in the habit of using a version declaration and strictures and warnings.

Yes, they ought to begin to explore abstraction and decomposition and how to break a problem into discrete steps on the way to a solution.

Yes, they must know that CPAN exists and is the first place to look when facing a new problem.

Yes, they will one day need comprehensive test suites and refactorings and good tools. They may one day need to understand XS and memory management and shared libraries and linkers and compilation.

Tell me they need that before they write "Hello, world!" or move a little frog around on the screen with Perl SDL or make a stateful little counter with raw PSGI—because they don't.

Perl has a learning curve. (Programming has a learning curve.) We can smooth out the start, maybe flatten it a little to encourage more people to take the first few steps, but we must be careful not to make it so steep that they get exhausted looking at it.

All of our tools and techniques and patterns and disciplines are guiderails. They're not ends in and of themselves. They can keep you from accidental trouble, but they can also block your path (and if you're determined to drive off the road, they will at best slow you down).

Not everyone should be a professional programmer, and that's fine. Not everyone will be and not everyone wants to be.

With that said, we really ought to celebrate the fact that typing perl -E "say 'Hello, world!'" is an accomplishment for someone who's never programmed before. He or she still has much to learn, but writing baby Perl is good enough for now. By all means do we encourage them to continue learning, but we owe it to them to keep practicality in mind.

First, solve problems. Then clean it up. Always do both, but always do both in that order.