Each of us has our own set of strengths and weaknesses but we never take the time to figure out what they are. Even if you did would you know what to do with the information?

You’ve probably heard that you need to identify weaknesses so you can fix them. After all, if you’re already strong in an area there’s no need to hone that skill, right? You should focus on your weaknesses so people don’t point and laugh at you when you try to…do whatever it is you’re weak at. Right?

That’s what most people think, but I’ve found this approach to be a recipe for mediocrity.

Becoming World Class
People who become world class at something begin with a strength in that area.

Tiger Woods had some kind of pre-disposition to be a decent golfer. Paul McCartney had some kind of innate musical talent before he picked up a guitar, Yo-Yo Ma was likely a tiny bit better playing stringed instruments than his classmates, and Albert Einstein had something unique about his brain chemistry before he ever thought about the cosmos.

But these strengths take time to develop. To become world-class (or to take it one step beyond and re-define that term in your field) you have to invest thousands of hours of focused practice into that strength. This is known in psychology as the ten thousand hour rule, and Malcolm Gladwell ruined it for the rest of us by beating this idea to death in his book Outliers.

But the idea is that you need something on the order of 10,000 hours of focused practice to master something like the cello, golf, songwriting, or theoretical physics.

Becoming Mediocre
Perhaps Paul McCartney is particularly deficient in the skills needed to properly operate a motor vehicle. I don’t know this to be true, let’s just suppose for the sake of argument.

Suppose that when Sir Paul was young that instead of spending hour upon hour playing music that he had instead focused on learning the skills necessary to drive a car. He practiced steering, using the gas pedal, shifting, etc… all with the hope of becoming a Formula One driver.

He would have become a better driver, but it’s almost certain that he would never have become world class at an activity where he has a particular weakness.

Instead of becoming one of the best known singer/songwriters of all time he would have become a second rate driver.

By focusing on something where he already had an innate strength (or innate passion) he was able to become one of the best of all time. And the same story can be applied to Woods, Einstein, and Yo-Yo Ma.

Football vs. Track
One more example and then I’ll get back to talking about software and entrepreneurship.

In high school I played football because that’s what the popular kids did, but I wasn’t well suited for it. I worked my butt of at becoming a good football player. Every Saturday my dad would take me and my brother down to a park to run routes, practice diving, do speed drills…things that none of my teammates were doing on the weekends.

And I got better. But I was never, and could never have been, great. The skills required for football were particularly lacking in me, and although I was able to improve through literally hundreds of hours of practice, I was never as good as the best receivers in the league.

The track was another story. With my height I was well-suited for the long hurdles and winning races became almost second nature. I worked at it, but the improvements were dramatic as I invested time into running.

I excelled at it from the start and ended up setting a school record, winning the league, and going to the state championships. A far cry from my mediocre performance on the gridiron.

I’ve always wondered how much better I could have been on the track had I never played football, and instead invested that time into becoming a better runner.

Now Back to Software
Let’s translate this to being a software developer / entrepreneur.

Most people have no idea about their strengths and weaknesses. So that’s the first step – learning what they are.

And secondly, when most people find out they have a weakness they want to improve it.

“Oh my gosh, I’m a terrible public speaker…I need to become better at it!”

But this is the polar opposite, 180 degrees off, wrong way to approach it.

Instead, figure out your strengths and re-configure your career to amplify and build on them. Avoid any position that requires a lot of public speaking, but instead take that job (or start your own company) where you do a lot of solo coding (if that’s what you’re good at). Some people excel at not needing social interaction and being extremely productive on their own.

After struggling for years, wondering why I was unhappy at most of my jobs I came to realize that they were pushing me to improve upon my weaknesses. After a few years of introspection I decided to change my career path and became a Micropreneur. Micropreneurship fits well with my strengths and has lead to more career happiness than I’ve experienced in years.

Now Back to You
Most people, and developers in particular, are unhappy with their jobs. And I conjecture that much of that is because you’re doing something that requires you to utilize one or more weaknesses, and at the same time not taking advantage of your strengths.

If you’re not a good public speaker and you don’t enjoy it, don’t take a position in management where you have to present to executives every month.

If you’re not a good writer and don’t enjoy it, don’t start a blog.

It’s not only more productive to capitalize on your strengths, it’s way more fun. You’re good at it from the start; better than most, in fact. So you will experience a lot of victory in that area. This will mean the activity will be enjoyable from the start.

So what can you do? Spend $13 to buy StrengthsFinder 2.0 (or any other book that helps you find your strengths – this one isn’t magic; it just happens to be the one I’ve used). For a more fact-based justification of this entire approach read the pre-cursor to StrengthsFinder called Now, Discover Your Strengths.

Take the test and figure out your strengths.

Consider making a change in your career path.

It may mean you need to change jobs. You may need to do something rash like start a startup or start building apps on the side and become a Micropreneur. Or you may be amazingly lucky and your current situation is already making you extremely happy (and ask yourself if it’s because it’s amplifying your strengths so you know how to find this optimal situation in the future should things change).

But whatever you do, don’t focus on improving a weakness. I’ve been there. It doesn’t end well.

They finally said it – the “R” word. According to the National Bureau of Economic Research the U.S. has been in recession since December of 2007.

It’s a bit anti-climactic, seeing as we’ve been hearing about the financial crisis from every major media source for months. But stock indexes continue to slide and the unemployment numbers are getting worse.

So in this age of uncertainty how should someone react who simply wants to collect a few greenbacks in exchange for their brilliant programming acumen?

You could hide under your imitation Aeron and hope no one notices, or you could start pursuing ways to recession-proof your career.

1. Volunteer to Lead a Big Project
The opportunity to lead a project may not be available to everyone, but if you have serious concerns about losing your job it’s a sure-fire way to make yourself almost irreplaceable.

No manager in their right mind would fire the technical lead of a big software project. And if your manage isn’t in their right mind, it’s probably time to find another job.

2. Show Up Early, Leave Late
I’ve talked about how crunch time should be the exception in software projects. But desperate times may call for some extra hours.

I know, I know…it sounds like you’re giving in to “the man,” but let’s be honest: your company has more to worry about right now than keeping you happy. Realize it’s only temporary, and a better way to spend your time than looking for a new job.

If you were a manager forced to layoff 10% of your team, who would you let go?

3. Start a MicroISV
Build it or buy it, it doesn’t matter. What matters is that you begin generating recurring income that will sustain without your day job.

The average U.S. recession lasts 10 months and we’re supposedly 12 months into our current situation. If you were laid off next week how long do you think it would take you to find a job? A month? 2 months? 4 months?

How much would an extra $1000 or $2000 per month help during that time?

MicroISVs are a fantastic way to create recurring income that weathers tough economic times, especially if you have a niche product and you’re ruthless about automating everything.

I recently wrote about the challenges of launching a microISV, but I’ll be talking more about how to get past these difficulties in a future post.

4. Moonlight
If you have the chance think about taking on side work.

Right now companies are cutting costs and letting go of their $125/hour development shop. A lot of contract work is out there looking for mid- to low-cost providers. Keep your feelers out for contract work.

While moonlighting is not a sustainable option, if you start during a recession you’ll find that one of three things will happen:

1. You’ll get so much work you’ll be able to quit your job and consult full time. Lucky you.
2. You’ll make some money and won’t get laid off. When the recession is over you can buy an iPhone, a Kindle, and go to Cancun.
3. You’ll make some money and get laid off and be really glad you have the extra cash.

5. Become a Popular Blogger, Author, Speaker, Podcaster, etc…
In good times and bad, being a superstar is a good way to keep your job.

It’s hard to fire a developer with 10,000 podcast listeners, not because she might say bad things about the company, but because co-workers look up to her as an alpha-geek. Fire her and morale will take a big hit.

6. Become a Trainer
It’s generally accepted that recessions boost college enrollment. But companies that perform technical training also see a jump as laid off workers go back to the classroom to update their skills.

Back in 2001 I worked with a consultant who was a developer when times were really good, and a trainer when times were really bad. He did a little of both during the rest of the time to keep himself interested, and  maintain his skills in both arenas.

If you have the gift of teaching, now is a great time to pursue it.

7. Write Technical Articles
Not only do technical articles help with your alpha-geek status (see #5), but you can make a little coin along the way.

Surprisingly enough, articles for programming magazines can bring in several hundred to a thousand dollars each, depending on length.

Check out one of these directories for a magazine that matches your skillset.

8. Work for a “Recession-Proof” Company
Granted, no company is completely recession-proof, but sectors like health care, pharmaceuticals, defense, government, and consumer staples do well in good or bad times.

Boring programming jobs? Indeed. Stable in a recession? You betcha.

Coinstar, and companies like it, do well during recessions because people start cashing in their unused change.

Walmart, Target and other discount retailers also fare well, since consumers tend to ease back on luxury items and head to the discount stores.

The Startup Success Podcast – After the demise of The Micro-ISV Show, Bob Walsh is back discussing issues affecting software startups. A good weekly listen.

Open Source, For-Profit Startups – “FairSoftware is the place to start and grow your online business. We help you team with others, track revenue and share it openly and fairly. Hire people in return for a share of your income stream instead of upfront cash. You save money and they have more incentive to collaborate.”

One Laptop Per Child Give One Get One 2008 – For $399 you get one XO laptop for yourself, and one is sent to a child in a developing nation. The keyboards are small, but they run Linux and have wireless NICs.

$19 Usability Testing -  This is awesome. For around $19 (you can add bonus money to get your tests completed faster), you get a 15-minute video of a real user going through your site or web app, and a written summary of their findings. I’ve used it on two projects and it has raised a slew of issues we had no idea people would have problems with. Definitely worth a look.

And finally, from Paul Graham’s essay Why to Start a Startup in a Bad Economy (emphasis added):

If we’ve learned one thing from funding so many startups, it’s that they succeed or fail based on the qualities of the founders. The economy has some effect, certainly, but as a predictor of success it’s a rounding error compared to the founders.

A Software by Rob reader writes:

Today, after typing in “learning .net through apprenticeship” into my Live search bar, I was pleased to see as the number 1 hit: Software Training Sucks: Why We Need to Roll it Back 1,000 Years … .  As I read the article, I found myself nodding in agreement and wishing for a solution. You see, as a programmer who hasn’t done what I would consider real programming since back in the BASIC and COBOL days, I’ve been struggling trying to pull myself up by my bootstraps learning C# by meticulously going through books and online material

I am right now in a position where I’ve made a commitment to stop what I’m doing to devote full time to learning a new programming model and I chose .NET over the LAMP stack. Since publishing your article, have you heard of anyone who has gotten creative with apprenticing new programmers?

A very interesting apprenticeship model I’ve encountered in the past few years, albeit in another industry, is one in the entertainment industry. My daughter had an aptitude for audio recording and, through research, found a company out in L.A. that does recording apprenticeships. She was chosen as an apprentice and within 10 months they were pleased with her work and hired her full-time as an assistant engineer.

Is there any reason in your opinion that such a model (or something close to it) could not work apprenticing .NET developers?

I haven’t heard of any real apprenticeship programs for .NET developers. I think it would be an excellent model for improving development skills, building morale, etc… but it would take a very special company, probably one run by a software developer, to even consider such a thing.

Has anyone heard of such a company? [Consider this permission to shamelessly plug your company]

Update:

I was recently contacted by a company in the UK offering a real software apprenticeship program. Details are below:

e-skills UK (an industry body for IT skills) is piloting a Software & Web Developer Apprenticeship in the UK, working with Microsoft and QA (a training company). Ten IT companies of all different shapes and sizes will be recruiting 20 apprentices, who will receive a 12 month structured apprenticeship programme. This starts with a 4 week programming boot camp, with 5 further weeks of technical training, on topics such as Data Modelling and Software Testing and, dotted throughout the year.

The key is that the apprentices will be working for the rest of the time, learning their trade as developers from the technical mentors in their companies, but also being productive employees. The pilot will be focusing on C# and the.NET framework, and the apprentices will be aged between 16 and 20, using this as an alternative route to going straight to college/university.

To get in touch, email ben.sweetman@e-skills.com or follow him on twitter @bensweetman.

What’s Next?
Like many software developers I’m afflicted with ‘What’s Next?’ Syndrome. It’s a disease whereby you’re never content with your situation, no matter how cool it is, how long you planned for it, or how many hours you spent working to get there. My stagnation range is 6-12 months; if I’m not learning new things by then I start to unravel. Blessing? Curse? Not quite sure.

It seems like the most common activities for climbing the ranks in the development community are blogging, writing books, training/teaching, and public speaking.

Blogging? Check.

So what’s next?

I’ve waffled on this decision for a long time due to the high barriers to entry and uncertainty of the payoff. Since I’m an independent developer working for an hourly rate, taking hundreds (thousands) of hours to write a book is a tremendous commitment. Training is similar: it requires learning a whole new set of skills, earning a certification or two (the easy part), and shifting your work schedule and marketing approach to accommodate a hybrid business model. I’m not sure how many trainers remain day-to-day developers.

But of the three options public speaking certainly has the lowest barrier to entry, especially in the .NET community where there are frequent local events that welcome new speakers. So 6 months ago I dipped my toe into the water and participated in my first speaking engagement.

The Numbers
I had mixed emotions about the outcome. On the one hand getting out of the house and seeing other developers face to face was a welcome change (even though it was 28 degrees outside). On the other hand, the amount of time invested seemed out of synch with the benefits.

Since I didn’t have much development experience with my topic I spent 8 hours learning it, creating the slide deck, and coding the examples. Then on a chilly Saturday morning I traveled an hour to the conference, spoke for an hour, and traveled home. In the end I spent about 11 hours and spoke to around 25 people.

As a point of comparison, in 11 hours I could have written 1-2 long-form articles or 5-10 blog posts that would have been read by 12,000-50,000 people (depending on the post’s popularity). In terms of people influenced, blogging is going to be more effective for me due to the massive up-front time investment I’ve made over the past three years (my “sunk costs”).

What makes things complicated is that face to face contact is exponentially more memorable than someone skimming your essay in their RSS reader. In addition, if I dedicated as much time to speaking as I have to blogging I would be speaking to much larger crowds, speaking more often (which would allow re-use of my talks), and generally glean a lot of benefits that a single speaking engagement at a local code camp wouldn’t bring.

The conclusions I’ve arrived at are:

1. Assuming you have any lick of natural ability, investing hundreds of hours into any of these options (blogging, writing, training, speaking) will pay off, and I would venture to say that hundreds of hours is what’s required to obtain a good return on your investment.
2. Pick the one you think you’ll enjoy most, and only get started if you have time to invest.
3. A combination of two or more is a good approach; that’s why it’s so common among big names in the community. Plus it will keep you from getting bored.

Any thoughts?

[tags]programming, self-promotion[/tags]

By the time I was 13 I had been selling candy and comic books to my classmates for almost 3 years. Though I did quite well, I was itching to try something bigger, and that meant extending my reach beyond the walls of Math class.

This was the late 80s, so resources were limited for a 13 year old living in the country. I ordered all of the free information available in the work at home section of the Penny Saver (a free newspaper consisting entirely of ads), and started going to the library twice a week to read up on entrepreneurship. I was searching for a business idea that I could pull off at 13, and after literally hundreds of books, booklets, and information packets I decided to publish my own booklet on comic book collecting.

“Smart”
Since I was seven years old I’ve been an avid reader. I consumed 2 or 3 books a week during my childhood, including a large collection of “crazy facts” books and the Guinness Book of World’s Records (every year). By the time I was 13 I’d been reading 2-3 books a week for 6 years, and the breadth of my knowledge was astonishing for someone my age.

I knew how the stock market worked, why Beta had lost to VHS, why Apple was losing market share to the PC, and how double-entry accounting worked (although I couldn’t do double-entry accounting). But I had no idea how to start a business. With all of my book knowledge about the business world, I had no clue how to execute an idea.

I’d read several books on self-publishing and writing non-fiction, and I could have a really good conversation about them, but I’d synthesized the information for knowledge-sake, rather than to act on it. That made a big difference.

And so it continued for months…I didn’t have the guts to start writing the booklet for fear I wouldn’t know what to do next. Instead, I visited more libraries and sought magazines that did nothing but rehash information I already knew. I filled my head with the same information from piles of resources, but I still couldn’t get things going.

After months I finally took the leap. I spent 60 hours researching and writing the booklet. I printed it at Kinko’s, placed a few classified ads, and sold 9 copies at $15 apiece, breaking even on the cost of printing and advertising. Financially it was a wash, but I learned a valuable lesson.

The Question
13 years later I went through a nearly identical scenario when I started my consulting firm, The Numa Group.

I’d read stacks of book about entrepreneurship, startups, management, leadership, consulting, and running a service business, but I had no idea how to get started. I was waiting for the one book that was going to kick me into action by telling me exactly how to proceed given my skills, strengths, goals, and financial situation. Alas, that book never appeared. I finally realized that I needed to take a leap of faith and go to a place where no one else could lead me.

Through these experiences I realized the following:

Some people are consumers by nature; they consume vast quantities of knowledge purely for learning’s sake. Others are producers; they consume knowledge with the intent of one day acting on the knowledge and producing something, be it a book, a song, a blog, a startup, etc… Neither is better than the other.

The key is to answer one question: which are you?

I want to say again that neither is better than the other. If we were all consumers we wouldn’t have anything to watch; if we were all producers no one would be reading our blogs or listening to our podcasts. What matters is:

There is a huge benefit to finding out if you tend to be a producer or a consumer.

Which Are You?
If you convince yourself that the zillions of books, blogs and podcasts you’ve consumed over the past 2/3/4 years are in preparation for that glorious day when you’ll tell your boss to stick it in his ear because you’re heading out the door to starting your own company, you are wasting your time. Don’t read another blog post about startups, Micro-ISVs, or the business of software. Once you’re done reading this post (or even before), go start building something (a product, a blog, a company…). Because until you do, the knowledge you’re gaining is all but worthless to you.

But if you realize that one of the pleasures in your life is to read about code/startups/entrepreneurs/music, then embrace that you are a consumer. Knowledge for knowledge’s sake is not bad as long as you realize that you are not working towards an end beyond your own edification, which again, is not a bad thing.

Likewise, if you’re someone who has an unquenchable desire to produce something, then stop reading about other people, and start doing it yourself. Seriously, don’t read another blog post, tweet, or issue of Fast Company until you’ve made a visible move towards that goal you so desperately want, but think that reading and dreaming about will somehow make it come true. Once you’ve made that single action towards advancing your idea, you can come back and read a few more posts.

While it’s true it’s not either-or, that you are likely a mixture of both types and will experience fluctuation in your ratio of production vs. consumption from one month to the next, unless your name is Robert Scoble you really do have to choose one or the other.

To recap:

• Consuming for the pure love of learning is absolutely ok.
• Producing purely because you have a fire that won’t die until you do is fine, too.
• But don’t kid yourself about who you are.

If you’ve been reading startup blogs for years and never started anything, it’s time to accept that your tendency is to be a consumer. It’s not to say you can’t break out of that classification by starting something, but if you haven’t done it thus far you’re not likely to do it soon without some external motivation (maybe this post?).

If you have 50 software product ideas and your hard drive is littered with folders containing 30 lines of code from each, you tend towards being a consumer (or at least a producer who has trouble finishing things).

And if you figure out that you are a producer, stop daydreaming about the day you’ll make things happen. Start making it happen in the next 30 days, or forever hold your peace.

Additional information: Baker University

I received the following email a few weeks ago:

I graduated with an MIS degree while serving in the Military. I took some programming classes like JAVA, C++ etc… I am now back in Boston, MA and find it difficult to find employment where I can learn to become a better programmer. I don’t have the experience but I am willing to learn. Can you please provide me with some direction on what to say on my resume, to gain the experience in the civilian workforce so I can become a better programmer?

My response:

To begin, read the following posts on my blog and think seriously about following the steps I outline in each. It will take time, but I’ve been doing this for almost 10 years and can tell you from experience that they work:

Advice on How to Become a Programmer
Nailing Your Technical Interview
Self-Marketing for Software Developers

Second, check out this article on programmer resumes.

Third, there are no magic words that you can put on your resume. The key is to have a good-looking resume that’s clean, free of typos, and that highlights your strong points (your education and military experience) at the top.

The tech economy, especially in the bay area and Boston, is healthy right now, so you should have no trouble finding an entry level position as a developer, especially if you are open to learning PHP or .NET. Also, start learning PHP or .NET in your spare time – build some sample web projects to show off (put them online so you can easily forward a link). This is the most impressive thing I’ve seen from young programmers, is when they’ve built something in their spare time and taken the time to put it online. Bonus points if you build something that people are actually using.

Lastly, read software blogs. Read Joel, Eric, Paul, Jeff and Scott, and now and again you can slum it on my blog. These sites will lead you to other good blogs. The closer you are to the community the more you’ll understand what people are talking about and looking for in their hiring.

Good luck,

Rob

[tags]programming, resumes, hiring[/tags]

SmartMoney.com interviewed me this week for their article Web Sites Find Security Seals a Boon for Business. The article talks about ways online merchants, specifically small businesses, can use security seals to legitimize their websites in the eyes of potential customers.

It occurred to me that displaying seals doesn’t change how a website operates; the seals are all about marketing. They’re all about playing the game of looking legitimate to potential customers.

In this case, standards and seals are a good thing: they allow people to quickly verify if a website uses SSL or is reasonably “hacker safe.” This is helpful when you’re shopping for that antique Platypus Beanie Baby and wind up on a site you’ve never heard of. Seeing the Verisign seal probably gives you a bit of warm fuzziness.

Standards
In high school you may have worked your butt off for grades or a good score on the SAT (a standardized test taken by high school seniors in the U.S.). The fact is, you were smart whether or not you did these things, but you had to do them to prove it. You may not have realized, but you were marketing yourself to colleges. And the best way to do this is to fit their mold of standardized tests and grades; to play the game.

When you go to a job interview you already know you can do the job. The entire process of creating a resume, making it look pretty, putting on a suit, using your best manners, and writing code on a white board is all packaging. It’s not really you; it’s the best possible view of you that you bring to the game.

I have a friend who is a fantastic developer (I mean it; he’s top-notch). But he has trouble finding contract work. All of the online marketplaces are filled with commodity development shops. The temp houses take a huge cut and are always trying to beat down his rate. So a guy who’s worth $100+/hour winds up making $70. He’s worth more, but he hasn’t figured out how to differentiate himself from every other developer in the universe.

Self-Marketing Rule #1: It’s a sad statement, but even from early on in your career, knowing how to market yourself will do more for your earnings and reputation than becoming better at what you do. This is not a license to be a crappy developer, but an imperative to become a better self-marketer.

The Basics
Self-marketing, also known by the more sinister name “self-promotion,” works wonders for both salaried employees and freelancers. In both cases the bigger your name, the more recognition you’ll receive from those around you, the more money you will make, and the more opportunities that will come your way.

I receive a lot of email asking how to get a raise, and how to get around the developer salary cap, and here’s the simple answer: set yourself apart.

Here are a few approaches to doing that; there are certainly more (please post a comment with your ideas):

• Get Certified. A good first step.
• Write technical articles. Print or online; it doesn’t matter. Scott Mitchell and Rocky Lhotka have built careers using this approach in the .NET world.
• Speak. Start by speaking at local developer events.
• Blog. Joel Spolsky is the poster child for making a name for yourself as a blogger.
• Win Awards. Microsoft’s MVP and ASPInsider awards come to mind. I’m not sure if there are equivalents on the Java/PHP side.
• Contribute to Open Source Projects. Nothing is more impressive than saying you implemented feature X in a popular blogging engine.
• Release your own free applications or utilities. Have you heard of LINQPad or Reflector? Suffice to say these developers have earned major clout in their circles.
  

Self-Marketing Rule #2: Start now. It will take a long time to get going (think years, not months), and the sooner you start the sooner you’ll reap the rewards.

A New Game
The approaches I mentioned above are good to know when you’re starting out in the game of self-marketing. But some people don’t play the game at all. They re-write the rules to create a new one.

A girl from my high school didn’t get her diploma because she refused to take P.E. (Physical Education), but she was a science prodigy and was accepted to M.I.T. She knew how to market herself using her substantial accomplishments (inventions, awards, articles, etc…), and M.I.T. saw her as an exceptional candidate even though she didn’t meet the basic requirement every guidance counselor tells you about. She refused to play the grades/SAT/diploma game and decided to make up her own rules.

Fog Creek Software makes millions annually selling bug tracking software. Are they the best bug tracking application available? I don’t really know. But it isn’t about being the best, it’s about marketing. And Joel knows a lot about marketing (he doesn’t admit this, instead saying he stumbled into the popularity of his blog).

These days everyone has a blog to promote their software, but when he started Joel on Software back in March of 2000, Joel was inventing a new form of self-marketing. Intentional or not, writing his own rules has made Fog Creek an incredibly profitable company.

Self-Marketing Rule #3: If you have an exceptional talent, market yourself through exceptional means. Don’t play the game everyone else is playing.

Last time I checked, Fog Creek Software didn’t have a Verisign seal on their website.

Digg This!

[tags]marketing, self-promotion, programming, consulting[/tags]

When I was a coding newbie I thought applications should never crash. I wrote code that caught and ignored errors because I didn’t know how else to handle them. I didn’t want the user to see an error page, and figured a running application was always better than an error page. Oh, how wrong I was. On one application alone (not written by me) I wasted 50+ hours over the course of a few months because of exceptions that were caught and not properly handled. Don’t let this happen to you.

I’ve found this mindset to be so common among new developers that I’ve distilled the basics down to two fundamental rules a new developer should follow to the letter. I’m exhausted with cracking open code and seeing a Try/Catch block with no action after the catch. Whether you’re using a language with actual exceptions is beside the point – what matters is that you read through these few simple paragraphs and never, ever obfuscate your application errors.

Picture this (in C#):

Try
{

‘ Application code here
}
Catch
{

‘ Do nothing
}

What happens when an exception is thrown from the application code? Nothing…and that’s a problem.

Let’s say the application is attempting to insert a value into the database. Instead of a crash and some type of error message (even the default message would be helpful), the program continues to execute. At some point in the future, perhaps seconds, minutes, or weeks, another piece of code comes along looking for that database value and doesn’t find it. The result is a crash. Well, hopefully a crash. An even more likely case is that it will continue to execute and write 1s and 0s over the only remaining copy of your grandmother’s priceless rhubarb pie recipe. Or worse, the only remaining copy of the financial statements for your grandmother’s rhubarb pie factory. Yes sir, dirty data is eeee-vil.

With that in mind, let’s take a look at these two simple rules:

Rule #1: If you can’t add helpful information to an error message, don’t catch the exception.

If you are simply going to catch and re-throw an exception, you are better off removing your Try/Catch block and letting the runtime throw the exception for you. In other words, if you don’t know why you’re adding a try/catch block, don’t add it.

Rule #2: If you catch an exception, log it.

I’ve seen this rule broken in at least 10 applications in the past 6 months. Use log4j, log4net, Microsoft’s Logging Application Block, a text file, morse code, or carrier pigeon…just log the damn thing. Never catch an exception and do nothing unless you are writing a tool used to log exceptions.

Logging exceptions is not just a good idea, it allows you to know about errors before your customer does and is an invaluable tool for maintaining a healthy application.

If you have other exception management suggestions feel free to post them to the comments.

[tags]asp.net, .net, exceptions, error handling[/tags]

This is part of an ongoing series centered on becoming a better software developer. For other posts in the series, see the Becoming a Better Developer heading in the right navigation.
–

Last Valentine’s Day my wife gave me a gift certificate for a massage. Nearly a year later (obviously a busy one) I finally redeemed it, and had the most productive day I’ve had in a while.

I’m a pretty healthy guy with no medical conditions or injuries, and I only occasionally eat my weight in carne asada. But I have aches and pains just like anyone else who sites in front of a computer all day.

My massage therapist (whom I mistakenly called a masseuse…oops!) gave me quite an education while I was there. She began by asking about my breathing; most people with desk jobs tend to have very shallow breathing while seated. She drew my attention to my breathing as she worked on my neck, chest, rib cage and, oh yes, the back! Anyone out there with neck aches? Rounded shoulders? Pain in wrists & forearms? Yeah, I thought so. You can have the best ergonomic workstation in the world, but our bodies need care to compensate for endless hours in a chair. Massage with an eye towards specific work in these problems areas can go a long way towards longevity in this field.

She also told me that massage lowers blood pressure, enhances alertness, increases speed and accuracy on math computations, and lowers anxiety (source). I guess they teach this stuff in massage therapy schools.

So not only are you improving your work output, you’re also improving your health and, in the long run, working towards longevity in your career. Given this information how hard would it be to convince your boss that getting a massage is a fabulous way to celebrate a project milestone?

If you’re interested, the best places to find a massage therapist in your area are www.amtamassage.org and www.ncbtmb.com. A therapist trained in deep tissue or even sports massage might provide you with valuable expertise since we use a lot of repetitive motions. There are also therapists trained in Structural Integration who have an eye towards improving optimal structure and alignment.

One other thing she added is that massage alone won’t keep you in this business for the long haul. Other related lifesytle choices that contribute to longevity, physically speaking, include: balancing sedentary work with active exercise, eating healthy foods, taking breaks during work to look up and give your eyes a rest, and honoring your body when it complains about being in the chair too long. But you probably already knew that.

Bottom line: the massage was amazing and I highly recommend it. If you take the plunge, post a comment and let me know how it goes.

[tags]programming, massage[/tags]

When I was in college I was a professional comic book writer. After numerous submissions I had several stories accepted by three independent comic book companies, all slated for publication.

I even received a $100 advance for one of the stories, with all of them paying royalties on the “back end,” meaning I’d probably wind up making $100 per story if I was lucky. And back then $100 was a lot of…no, let’s face it, even back then $100 was nothing. But I could call myself a professional comic book writer.

On Being a Professional
Which is a joke, of course, because I wasn’t a professional. I was writing in a tiny bedroom, typically from 10 at night until 2 in the morning, cranking out a short script every week or two. Sure, I had honed my skills as a writer enough to match the myriad of others trying to make it, but I was not a professional writer. And I’ve had a hard time puting my finger on what it was that distinguished me from those whom I considered “legitimate” comic book writers. It wasn’t the fact that I worked out of a small apartment. Or that I wrote at night.

It was the fact that I didn’t consistently deliver under the pressure of deadlines.

I’m sure I’ll receive a few comments saying that a professional is someone who gets paid for what they do, or someone who does something as their main source of income, or someone who’s easy to work with, or someone who comments their code. Those are some of the components of being a professional, but one of the most important and often overlooked pieces of being a professional is consistently delivering a usable product in the face of deadlines.

How Many Deadlines Must a Man Walk Down…
I knew at least two guys who were amazing comic book artists. Both drew as well as the books on the shelves, but neither could draw an entire 22-page comic in a month…and that’s what it takes to be a professional in that game.

I’m not saying if you miss a deadline you’re suddenly an amateur – the continuum is much less binary than it is fuzzy. But during your career, your present job, or the past 6 months, how many deadlines have you hit? How many have you missed?

There are going to be extenuating circumstances. There are going to be times when a third party vendor flops and the project falls apart at the last minute. And there are going to be times when the deadline is set externally and you know from the outset you’ll never hit it. But if you find that there’s always a reason you aren’t hitting deadlines you have to start asking yourself: Is it you?

I know that somewhere between 55 and 90 percent of software projects fail. Missing deadlines is easy; I could get my mom, who knows nothing about software development, to come in and miss project deadlines. Does the fact that she showed up and collected a check make her a professional developer? She’s easy to work with and comments her code.

So here is my question: during your career, your present job, or the past 6 months, how many deadlines have you hit and how many have you missed?

This isn’t a show of hands, just a gut check.

A Software by Rob reader writes:

I want to learn to program computers:

• What is your advice on becoming a good programmer?
• How do you acquire the knowledge?
• Is it necessary to know mathematics, specifically algebra, to be a good programmer?

I receive several emails per month along these lines, so I’ve decided to share my advice on the subject. Note that I said “my advice” and not “the one and only way”; there are too many paths for one person to know them all. Here are some thoughts based on my experience:

Q: What is your advice on becoming a good programmer?

Everyone I’ve talked to has taken a different path. Programming is different from other engineering disciplines; if you want to become an electrical engineer you go to school, graduate, work for an engineering firm, and one day take a test and get licensed. Programming is different because people do it as a hobby; no one designs electrical subsystems for fun. This creates more possibilities for learning how to code.

Here are the elements I think are key:

• Learn, learn, learn. You must have an insatiable appetite for knowledge. This usually means reading a programming book every few weeks in the early days, and moving on to more conceptual books like The Pragmatic Programmer, Code Complete, and Facts and Fallacies after 6-12 months of full-time coding. I can’t stress enough the value of reading, nor the value of immersing yourself in code early in the process.
• Transition into Concepts. Learning how to be a good programmer begins with learning logic concepts and language syntax; they are much easier to understand when taken together. But good developers quickly desire knowledge that transcends language syntax. Perl, PHP, Java, ColdFusion, ASP…all languages I used in my first 18 months as a professional programmer. What made me a good programmer was not my knowledge of each language, but my desire to understand and refine concepts like D.R.Y., the broken window theory, and code re-use.
• Hang Out With Programmers Who Are Better Than You. As a guitar player, the most I ever learned about the craft of songwriting was when I was hanging out with people who were much better than I. The same goes for writing software. And due to this new-fangled internet thingy you don’t even have to be physically present to be a part of the community: read programming blogs from the heavy hitters (Scott Guthrie, Rocky Lhotka, Dino Esposito, Scott Mitchell, etc…), check out programming forums, and look at other peoples’ code. Reading source code can be a pain, but the more you see the more you will be able to identity code that’s easy to understand, and code that takes a PhD to figure out how they output “Hello World” to the screen.

Q: How do you acquire the necessary knowledge?

There are a number of possibilities:

• A Software Apprenticeship. If you haven’t ready my article on Software Apprenticeships, I recommend you do. The best (and I would argue the quickest) way to become a good programmer is to write code under the wing of an experienced developer who will teach you not only the basics, but the in-depth knowledge that takes years of experience to learn. I consider this option leaps and bounds above all others.
• Learning while Doing. Want to learn to code? Get a job writing code. I don’t care if you make $5 an hour; you will progress more in 1 month as a full-time developer than you will in a year of hobby programming. There’s no better way to learn to program than to write code.
• Books & Mags. Books and magazines have been key in my quest for programming knowledge. When I’ve apprenticed developers in the past, I use books as their primary source of basic knowledge, having them read 1-2 programming books per month, while teaching them more advanced techniques in person.
• College. Having gone this route myself I am well aware of the limitations of the U.S. College system in preparing students for a career in computer programming. Preparing them for a career in determining little-o and big-O notation, sure, but actually writing code from the get go? Nope. College is great for high-level theory, but work experience trounces it when it comes to learning software development. Programming degrees from online schools are affordable, but nothing beats real-world experience.
• Tech school. I’ve only worked with one programmer who went to a technical school and she had good knowledge of language and coding concepts, but not a ton of theory or design knowledge. As a result, her code was utilitarian and used a lot of brute-force, but was often not well-designed or easily maintainable. There’s obviously a balance between not enough practical knowledge (college) and not enough theoretical knowledge (tech school). I am using a very narrow sample, so don’t take this as a blanket judgment of tech schools. Perhaps an SbR reader with more experience in this area can enlighten us. As an aside, the network administrators I’ve worked with from tech school have been well-trained and great to work with. Perhaps the nuts and bolts of networking are better suited for such a practical teaching approach.

Q: Is it necessary to know mathematics, specifically algebra, to be a good programmer?

Quite simply, no; it’s not necessary to know math in order to be a programmer.

If you’re developing games, then mathematics and physics play a large part, but building an invoicing application does not require much beyond basic addition and subtraction.

However, from personal experience, people who have an easy time learning mathematics and enjoy solving logic problems (be they algebra or how to move Mount Fuji), tend to learn code quicker and enjoy it more in the long run. It takes a twisted mind, my friends.

==

If you are interested in reading more on the subject of becoming a programmer, I’ve written a totally free 33-page ebook titled How to Become a Programmer: Everything (Non-technical) You Need to Know. You can download it here.

JD over at DCS Media published an insightful post titled Top 20 Programming Lessons I’ve Learned in 20 Years. A few highlights:

• Always backup your code
• You are not the best at programming. Live with it.
• Simplify the algorithm
• Reminisce about your code
• No project is ever simple
• Software is never finished

From my new article Nine Things Developers Want More Than Money:

“If you want to collect a paycheck for 25 years and retire with a gold watch and a pension then go for companies that have the hygiene factors nailed. Stroll in at 8, head for the door at 4:59, and count the years until you’re kicking up your feet on a beach bar in Costa Rica.

But if you’re reading this, odds are that you aren’t the kind of person who never thinks about code after 5:01; you’re more likely to have a collection of DVDs that come up in an Amazon search for “Silicon Valley.” You’re probably one of those people who needs motivation factors or you go crazy with restlessness, and when the motivation factors are in place you’ll work ridiculous hours for low pay just because it’s so damn fun.

I talked to a dozen colleagues and pored over my own experiences to arrive at this list of nine software development motivation factors – Rob’s Criteria for Keeping Your Developers Happy.”

Read the complete article here.

This is part of an ongoing series centered on becoming a better software developer. For other posts in the series, see the Becoming a Better Developer heading in the right navigation.
–
In the book Joy at Work, the former CEO of an $8 billion energy company describes an experiment where he allowed a business development group to determine their own salaries over the course of two years.

The first year everyone chose their own salary but the numbers were kept private. The result was that the best people paid themselves too little, and the average and under-performing people paid themselves too much. This is in line with Paul Graham’s quote: “…people who are great at something are not so much convinced of their own greatness as mystified at why everyone else seems so incompetent.”

The next year the company set a total budget for the department’s salaries and repeated the exercise, except this time all of the employees had to submit their proposed pay to their colleagues for comment – not to be approved or rejected, simply for comment. When everything was said and done the department was only slightly over budget, and upon closer inspection the company determined one person was highly overpaid based on the salaries of his colleagues with similar abilities. This person had not listened to the feedback of his co-workers who had told him he was overpaying himself. After being informed of this, he reduced his salary and they met their budget.

What does this tell us?

First, people who think they are underpaid are probably not very good at what they do.

Second, people who think they are overpaid are probably pretty good.

Finally, the people you work with are the best judge of your abilities. Yes, even better than you.

If everyone at work thinks you’re abrasive, it’s time to take a serious look at your interpersonal style.

Have you ever seen yourself give a speech or teach a class? Every time I see footage of myself I’m shocked at how I look when I’m in front of a group. I’m appalled at my posture and nervous ticks I didn’t know I had.

Your colleagues are the video camera that can see your ability to write code, deal with stress, communicate your ideas, write clearly, and a whole slew of other things that are critical to our jobs as software developers. If you’re not using them as a resource you are overlooking a powerful tool that can help improve both your technical and non-technical abilities.

The moral: If you are genuinely interested in improving as a developer, ask your colleagues what they think of your abilities. Not just your development skills, but your writing skills, interpersonal style, ability to deal with stress, etc…

Then ask them again and tell them to be honest.

There comes a point in every person’s career when we have to offer criticism of someone else’s work. For software developers and managers this can be especially difficult since most programmers view the software they write as an extension of themselves, and take criticism of that software very personally.

We all know how to criticize, but the question is how to criticize well.

Be Specific
The #1 rule of good criticism is be specific.

In Freaknomics, Steven D. Levitt examined phrases in real estate listings that had a positive correlation on sale price (meaning a higher sale price), and ones that had a negative correlation (lower sale price). The results were as follows:

Higher Sale Price
granite
state of the art
corian
maple
gourmet
new
move in condition

Lower Sale Price
well maintained
fantastic
spacious
charming
!
great neighborhood
wonderful
immaculate

What you’ll notice is that higher sale prices resulted from being more specific. Tangible, real things like granite, corian, maple, new, outweigh ambiguous, possibly made-up things like fantastic, charming and wonderful.

And so it is with criticism. Telling someone their code is “total crap” is not helpful. Telling them they misspelled two variable names, have several place where they’ve repeated code, and they need error handling in all of their methods is much more helpful. It not only allows them to improve their current code, but perhaps it will help them out in the future, as well. They still may get mad, but that’s up to them.

It certainly takes more time to itemize mistakes, but it’s worth it.

Criticize the Code, Not the Person
If someone writes crappy code, talk about the code, not about the person’s ability to code. If someone doesn’t meet a deadline, talk about how that affected you and what needs to happen in the future, don’t talk about how the person is a complete slacker (at least not the first time you discuss it). Doing so will help keep the conversation less personal.

Be Constructive
Without much effort at all I can give you a list of negative things about Los Angeles: traffic, smog, too many people, and a distinct lack of trees.

I could also give you a list of bad things about the internet: spam, viruses, poorly-designed websites, and pornography. Just because I can point out a ton of negative things doesn’t mean that the internet is not worth your time, and doesn’t mean you shouldn’t live in L.A. For all the negatives there are tons of positives to outweigh them, at least for the 10 million people who live in L.A. County, or the 1 billion people on the internet.

It’s easy to be negative. It’s easy to come into a situation and complain. It’s easy to point out the flaws in everything (have you ever read the comments on Digg or Slashdot?). If you don’t have a suggested solution in mind it’s going to be difficult for people to respect your opinion. Someone who complains often will be ignored rather quickly.

Constructive critisism is helpful; venting just pisses people off. Before you criticize something stop to think if it really matters to you and needs to be improved, and make sure you’re talking to the person who can do something about it.

From my new article How To Burn $6,540 a Week: Indecision and Software Development:

“These kinds of decisions come up constantly during development. Let’s say we have five developers working on a project and between them we encounter 10 in a week . If a monkey flipped a coin he’d choose the right answer half the time. Giving the manager the benefit of the doubt, let’s say he chooses correctly 60% of the time. 6 out of 10 times we break even, the other 4 we lose $420, for a total cost of $1,680 per week.

If we decide not to make any decisions we lose 10 times $822, for a total of $8,220 per week.

Let me say that again: blanket indecision loses $8,220 per week; making decisions (including bad ones) loses $1,680 per week. That’s a difference of $6,540 per week.

Give that a few minutes to sink in.”

You can read the full article here.

From my new article Nailing Your Technical Interview:

“People are strange. I’m not just talking about your Uncle Cedric with the hairy feet and stale piece of toast with the image of Tina Turner that he swears will grab six-figures on eBay, I mean it more in terms of our mental capabilities. Think about how brilliant we are compared to a tape recorder, but how hopelessly inaccurate our ability is to remember a conversation.

Ask any police officer who’s interviewed six eyewitnesses and he’ll give you six different accounts of the same event.”

Read the complete article here.

People are strange. I’m not just talking about your Uncle Cedric with the hairy feet and stale piece of toast with the image of Tina Turner that he swears will grab six-figures on eBay, I mean it more in terms of our mental capabilities. Think about how brilliant we are compared to a tape recorder, but how hopelessly inaccurate our ability is to remember a conversation.

Ask any police officer who’s interviewed six eyewitnesses and he’ll give you six different accounts of the same event.

$200 Dinners
It’s widely accepted in the world of research that humans remember meaning rather than fact. As an example, if I told you “I went to the mall the other day,” it’s likely that in 10 minutes you would remember the sentence as “I drove to the mall the other day.” In other words, the meaning would stick rather than the details.

Let’s take Fred as an example. Fred is on his way to a job interview for a position as a software developer. His experience meets all the requirements, and based on his resume he’s the top candidate out of the 50 or so that applied.

Fred arrives, dress to impress in his $149 suit from TJ Maxx and $20 black leather shoes from Payless. The interview goes extremely well; he builds rapport with the interviewer, answers most of the technical questions correctly, and manages to craft an artful LEFT OUTER JOIN on the whiteboard.

Fred is on top of the world until, to his surprise, he notices a huge ink stain on his shirt. It turns out Fred likes to keep fountain pens in his shirt pocket (because the ladies dig it). On this fateful day, that pen decided to gush it’s payload all over Fred’s brand new cotton dress shirt. Fred’s embarrassment is palpable as the interview wraps up and although he makes it out of there alive, he doesn’t get the job. Why?

You could say it’s because I made this story up and can twist it any way I want to prove a point. That’s valid, but how about this: after interviewing four more candidates over the next two weeks the hiring manager doesn’t have point by point recall of every interview. In fact, although he made a few notes here and there, all he can do is go with his gut feeling about who would be the best fit for the position. And you know what? Even though Fred fit the position perfectly, there’s a voice in the back of the hiring manager’s mind that won’t let him hire Fred. He doesn’t know why, but he has an awkward feeling about the whole experience. All because of a lousy fountain pen.

The moral of the story is to buy high-quality fountain pens. *ahem* I mean, the moral of the story is that human beings remember meaning rather than fact. This means that the impression they take away from an experience is much more important than what actually happens.

This is why restaurants like The Melting Pot can charge 50 bucks a person for fondue when you can make it at home using the change in your sofa. It’s also why, two years after you see a crappy movie, you won’t be able to remember the character names, dialogue, scenes, or much of the plot, but you will remember that it was terrible. It’s all because the experience of these events is forever lodged in our brains, while the fact of a $200 dinner have long since departed.

This is easily translated into advice for interview day: do everything within your power to make sure you leave the interviewer feeling like she’s hugged a warm puppy. Be cordial, don’t show negative emotions, have excellent manners (the ones you never use around the house) and never, ever act indignant about answering technical questions.

Some people think it’s unfair to ask candidates to write code on the fly; you may be one of these people. The interview is not the place to voice that opinion, whether verbally or through your body language (like the “leaking tire” noise you make when asked – I actually had a candidate do this once).

I’ve also had candidates act bored or roll their eyes at basic programming questions. If explaining how GET is different than POST is beneath you, suck it up, answer the question, and hope the interviewer moves on to topics worthy of your genius soon. If not how will he ever discover how you built a Ruby on Rails compiler in assembler on your Commodore Pet?

Finally, it’s been shown over and over that attractive people fare better in job interviews, get more promotions, and earn more money. Unless you’re Brad Pitt you should show up showered, shaved, and wearing a suit. It doesn’t matter if you don’t believe in suits and don’t ever plan to wear one to work – everyone looks better in a suit (even Brad Pitt).

Bring Something Real
People also remember things that are related to other memories; the more connections, the easier something is to remember.

This is why commercials contain catchy jingles that are really just remakes of pop songs with the words slightly modified. It’s because these songs touch on a piece of our brains that will somehow relate the “coolness” of the song to the product.

If the marketers did their jobs, the next time you hear the song you will likely have an urge to run out and buy yourself a new pair of insoles. These insoles may hurt your feet so bad you’ll feel like you’ve been dancing on broken glass, but somehow they’ll still seem cool because Britney Spears sang “Oops, I bought insoles again.”

This is also why every single memory improvement book revolves around relating things to common objects you encounter in everyday life. Be it a list of items or peoples’ names, the more memories you have that link to an object, the stronger the memory of that object becomes.

To capitalize on this, bring something memorable to the interview. You want the interviewer to link you with as many “good feeling” thoughts as possible. Bring glossy, color print-outs of a UI you worked on or prettied-up copies of a data model you designed. You could even bring sample products from your current or former employer. Your company makes soft drinks? Bring a 6-pack of root beer. Your company prints newspapers? Bring a few copies of today’s edition. Bring something real that the interviewer can look at and touch once you’ve left.

This brings me to a concept I’ve been cooking up for quite a while: a HireMe^TM book. With cheap, high quality, on-demand publishers like Lulu and Blurb, creating a few copies of a custom tome is economical and requires minimal time investment. For around $10 a pop you can print your own commercial-quality paperback containing your resume, samples of your work, and, if you’re the creative type, a section of “Reasons to Hire Me.” I plan to devote a future essay to the concept and design of a HireMe^TM book.

The Self-Reference Effect
Psychologists have discovered a phenomenon they call the self-reference effect, which boils down to the following: people tend to remember information that refers to themselves.

This is why you easily remember someone with the same name as your brother, while forgetting the other 19 people you meet in an evening. This is also why the Jack in the Box commercials during Soccer games have Jack racing after a soccer ball; the marketers are trying to relate to something that a large chunk of the audience will find as a self-reference.

In addition to remembering names and marketing quasi-food, the self-reference effect is amazingly effective at making interviewers relate to you, remember you, and maybe even like you.

Before your interview try to find out as much as possible about your interviewers. If necessary, politely request a list of names to help with your preparation, and head to Google. With common names, try to narrow your search by including terms like the name of the company, or the name of the city where the company is located, or even something as generic as “software developer.” If you find a personal homepage or can pull up a resume you’re golden. This type of information allows you to build a picture in your mind of who they are and what they’re about.

With this information in mind, try to honestly relate to them during the interview. If they publish a lot of articles, be sure to bring up recent articles you’ve written. If they like to water ski, bring up the fact that you go every summer. Do they play the guitar? Mention your Taylor that you play every chance you get. Obviously, this isn’t a license to lie about things you’ve never done to make yourself more familiar; trust me, you’ll get caught. But anything you can do to relate to this person is not only a step towards a connection, but it’s a step towards being burned into their mind forever…or at least until your start date.

The self-reference effect, when used appropriately, is extremely powerful.

Finishing Touches
These techniques are like a coat of Carnuba wax on a Corvette; they add shine, but the underlying paint has to look nice, too. These techniques won’t salvage a lack of technical knowledge or a disregard for punctuality, but used in conjunction with basic interviewing skills they will improve your chances of landing a job.

Just be sure to leave the fountain pen at home.

Special thanks to Mike Taber and Sherry W. for reading drafts of this article.

[ Bookmark this post with del.icio.us (What is del.icio.us?) ]
[ Digg this ]

“We will encourage you to develop the three great virtues of a programmer: laziness, impatience, and hubris.”

— Larry Wall, Programming Perl (1st edition)

Read more