It’s the things you learn after you know it all that count.

Legenday basketball coach John Wooden died two days ago. If you watch basketball, whether it’s NCAA or NBA, you must have heard of the man. I’ve been reading books on business, leadership, and self-help. I’ve encountered Wooden quotes while reading these books.  Tonight, I was watching the NBA Finals, Game 2, LA versus Boston. In the half-time show, NBA Hall-of-Famers Kareem Abdul Jabbar and Bill Walton shared their experience playing for Wooden. Both of these guys admired the guy for the lessons-about-life that Wooden taught them. Bill Walton said Wooden is known for all his great quotes but there is this one “creed” that Wooden personally gave to him when he lost games as a college ball-player at UCLA: “It’s the things you learn after you know it all that count.” Wow, the line really hit me. I love learning. Especially in this field that I belong in – information technology and software development – you never know it all. There’s always something to learn. There’s always room to absorb more.

Sometimes you get to a point in your career where you think you’ve “mastered” something. Then BAM!—the new version of the framework you’re working with gets overhauled! I have a few friends in the industry who have “cried ‘Uncle’” and promoted themselves to management, thinking that they don’t have to catch up with changes in technology (Web apps, servers, services, etc.) anymore. But you know what? They’re still not done learning. Instead of picking up books on .NET, SharePoint, or Web Services, they have to read books on business management, project management, leadership. It’s competitive anywhere you go, especially in today’s economy. You have to keep your brain in shape and train.  It’s a never-ending process, this thing called learning. It can be tough sometimes, all these reading and learning. But I wouldn’t have it any other way. I don’t think I can be in a field where I don’t have to learn anything new in order to be competitive. It would just bore me to death.

In honor of the legendary coach, here’s a few more of John Wooden quotes (Googled tonight):

• “I’d rather have a lot of talent and a little experience than a lot of experience and a little talent.” – when it comes to hiring IT resources, I believe in this. I’ve recommended someone with less “time-in-grade” over someone who had “twenty years of experience” many many times because at the end of the day, if you want a project done right, you need to have good people. Years in the industry do count but I’ll take talent and skills over experience anytime.
• “If you’re not making mistakes, then you’re not doing anything. I’m positive that a doer makes mistakes” – if you are a developer, you better make your mistakes during the development phase of the project. I’ve seen a few guys scared to make mistakes or see bugs in their apps. Mistakes and defects are good, if you can catch them early in the project cycle. If you avoid the defects and issues early on–uggh!!–good luck when you encounter issues and defects after you deliver your software!
• “The worst thing about new books is that they keep us from reading the old ones.” – Ain’t that the truth when it comes to technology books?? I have so many books (technology, leadership, business)  in my collection that I still have to read and yet I already know that I’m about to buy more books. Two books I will need to buy soon–SharePoint 2010 development and ASP.NET 4.0. In my ideal world, I only work 30 hours a week and learn/study 16 hours a week. The reality is I work average 45 hours a week and maybe study for about 4-6 hours a week. Too many things to catch up on. 
• “Never mistake activity for achievement.” – I LOVE this one. In other industries, working longer hours almost equate to achieving more than the next guy. In information technology, I see too many people patting themselves in the back for working long hours. For the life of me, I don’t understand why these people can be proud for taking a long time to solve a problem. Who’s better, the programmer who can write the solution in 2 hours and is idle for the rest of the day or the programmer who has to work 12 hours (assuming the task and problem set is the same)? It should be obvious, right? What about from an operations type person, like a DBA? Would you rather have a “lazy DBA” who sips coffee all day or the DBA who has to work 60 hours every week? I’ll take the lazy DBA anyday. He’s probably lazy and not doing anything because his ship is ran tight.  That’s achievement, getting your stuff squared-away. If you have operations people working overtime month after month–that’s NOT achievement–that’s a hug red flag that they don’t know what the heck they’re doing.

I’ve never read a John Wooden book. But after getting reminded tonight how wise the guy was, I think I’m going to get one of his books.