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.

There is big SharePoint team in one of my customers and it’s a good blend of developers, engineers, analysts, and managers. When this team started in 2007, only a handful (2 people really) was knowledgeable in the ways of SharePoint. But because the user-base for this organization is so big, technical resources of other backgrounds started getting recruited to become part of the SharePoint team. Traditional network engineers became SharePoint farm admins. ASP.NET developers became SharePoint developers (that’s how I got into SharePoint). Other Web developers (Coldfusion) became SharePoint developers too.

There are still some Coldfusion developers in this organization but these Coldfusion apps are being phased out and eventually  will be converted to ASP.NET and/or SharePoint. These Coldfusion developers do not have a background on ASP.NET programming model, which is really different, closer to VB6 model if you look at it that it is closer to “classic ASP” model. “Classic ASP”, Coldfusion, and PHP are in the same category in my book—they are server-side scripting. ASP.NET and  SharePoint on the other hand are more object-oriented.

One of the Coldfusion developers asked me which topics on ASP.NET and SharePoint should they learn and in what order. They are excited to develop SharePoint stuff such as Web parts and workflows but need some guidance on where to start.

Here’s the list of high-level skills/topics I pointed out one should in order to develop SharePoint solutions:

• ASP.NET model
  • ASP.NET User Controls
  • Intrinsic Objects (HttpContext, Application, Request, Response, Server, etc.)
  • ASP.NET Page life-cycle
  • C#
  • ASP.NET Web App configuration files
  • .NET Namespaces
• Object-Oriented/Component Programming
  • Properties and Methods
  • Events
  • Delegates
  • Inheritance
  • Implementation (interfaces and abstracts)
• SharePoint Features Development
  • Visual Studio SharePoint Project Extensions/Templates
  • SharePoint Object Model
  • Deploying Features using STSADM

I was viewing my blog today and noticed the tag cloud on my sidebar. The most prominent tags are “SharePoint”, “Developers”, and “Administrators”. SharePoint. Developers. Administrators.

From time to time, I will meet SharePoint professionals in networking events or when interviewing job applicants at a customer site and I will ask what their SharePoint experience is like. “Oh I am a SharePoint Developer“. Then I find out that the extent of their development experience revolves around master-page and page-layout design, style/CSS customizations, and graphical/logo design. Basically, branding tasks. And then there is the “SharePoint Administrator“. “Oh, I am the site collection administrator and manage user-permissions, site-collection features, and sometimes recycle items for end-users from the Recycling Bin.”

I think people are calling themselves SharePoint Developer more than they should. In my opinion, a SharePoint developer is someone who can develop Web parts, workflows, user-controls, Web controls, ASPX pages, client-side scripting, and complete SharePoint solutions. In addition, they also understand deployment options such as creating solution packages. If your experience around SharePoint is limited to CSS, branding, and design stuff, you’re a designer, buddy; not a developer, but a designer.

Now, let’s talk about the “SharePoint Administrator”. Yes, to a point, the site-collection administrator is an administrator. But to me, and again, this is just my opinion, farm admins are the real SharePoint administrators. To call yourself a SharePoint administrator, especially on job interviews, you better know your SharePoint deployment scenarios, Central Admin, SharePoint disaster/recovery procedures, IIS, SQL Server, Windows Server OS, and the beloved “stsadm” command.

Sometimes I will encounter resumes where the job applicant puts “SharePoint Developer” or “SharePoint Administrator” in their work history but nothing in the roles and responsibilities indicate the degree of technical expertise required to be called a “real SharePoint Developer” or a “real SharePoint Administrator”! 

The point I’m trying to make is please, please, please–do not inflate your work experience, especially when applying for jobs. You might fool the recruiters but you’re not going to fool the technical leads. Please be honest in your resumes because people will catch you if you think the inflated titles will make you a better candidate for a job.

Honesty people!