Do You Know .NET?

I got an email from a friend recently, saying:

"As I search for my next situation, I stop when I see .NET as a requirement. So...  what does it take to learn .NET?" This turns out to be the same friend who inspired this blog post.  I guess he just has a knack for asking blog-worthy questions. Like many people I know from my last job, this guy's what I'd call a technology generalist.  He's spent most of his career supporting, troubleshooting, tweaking, and business-analyzing software.  A lot of shops have people like this around: they know enough about a variety of technologies to move data around from spreadsheet to database, maybe a little scripting skills, enough SQL knowledge to write a query or ten.  They're often the people who respond to the constant stream of ad-hoc queries coming from senior leadership or finance.   As a database specialist and sometimes-programmer, I've dealt with this question myself.  What does it mean to "know" .NET?   I once tried to explain to a sales team what .NET was, and it just about killed us all.  "Dot NET" as a marketing term has come to stand for as broad-- and as vague-- a set of technologies as "green" has: it may very well have a very specific meaning to the person using it, or it might just be that person's shorthand for "cutting edge" or "Microsoft".   However, if ".NET" is listed further down in the job description, I understand it to mean three things: "We work primarily on MS Windows-based software" "We use C# (probably), VB.NET (maybe), or some other .NET programming language" "We're not using "old" technology like VB6, C++, Fortran, etc. How much experience they expect you to have, and how much exposure to .NET languages the job actually has, can vary a lot. Here's how I approach it, and my advice to my friend: if the primary focus of the job is .NET development, look elsewhere.  These jobs are for people who are computer programmers by trade.  It's a little like the difference between a General Practitioner and a brain surgeon.  A GP could operate on your brain in a pinch, and do a much better job than a non-doctor.  But you're still probably better off with a mediocre brain surgeon than an exceptional GP. The two answers I want to be able to give (honestly) in an interview are the following: I've worked with/supported/extended/etc programs that were written using .NET technologies-- I think it was mostly ASP.NET for the Web/UI layer, C# for business logic, and SQL Server on the back-end.   I've done a little C# programming recreationally-- not enough to consider myself a programmer, but I wrote a little web app to store recipes in a database, and I'm familiar enough with what a C# program looks like-- if I looked through someone's else's code, I could probably work out what it's doing. I want to establish right up front that I'm not a programmer, but that I have enough experience and professional curiosity to have dabbled in it a bit.   At this point, the employer should have enough to tick (or not tick) that requirement off the list.  If they really need someone who can take over primary coding responsibilities, I'm not the guy, and I don't want to be.  If they just need someone who can maybe maintain and tweak a couple little C# utilities that the last guy wrote, as 10% of the job duties, I can probably do that.  It might take me ten times longer than a "real" programmer, but let's talk about how my skills fit the other 90% of the job. So, how does someone like my friend get from "I get the idea that .NET is a framework" to being able to cover these two points?  Here's my advice: For the first answer, ask questions about the software you're working on-- even if you're just doing tech support, or gathering requirements, or whatever.  Talk to the programmers and ask them what languages and technologies they're using, and why.  Don't be afraid to ask stupid questions: programmers have a reputation for being brusque, but at some point they have to explain what they do to their spouses and moms.  Ask them, "What exactly is Ruby on Rails anyway?" and the good ones should be able to give you some analogies at least, or tell you why it differs from other development languages.   Also, as long as you're willing to assume the "dumb guy" role, most people get a big ego boost expounding on their area of expertise to a newbie.  It's why guys love explaining the finer points of football to an interested female (and why girls do so well asking, "Tell me again about the guys in the stripey outfits?")  Programmers love being the smartest guy in the room, and you can get a lot of knowledge by starting questions with, "I understand you're the X guru here..." Ask these questions, all the time, about whatever web site or app you're supporting.  If you're no longer at the job, contact some former colleagues and ask them.  The goal isn't to learn all these technologies-- just to be able to talk about them a little.  Good sales guys do this all the time-- they may not know a rack from a pinion, but they want to be able to tell the average Joe why he wants one. For the second answer, you'll have to work a little harder.  You're going to want to teach yourself-- or have someone teach you-- C#.  This seems to be the most common language in use out there, so it's probably the place to start, although VB.NET is a bit friendlier and will work just as well for this objective.  If you have some familiarity with any kind of computer programming-- maybe you took a Fortran class way back when-- and you have some familiarity with variables and parameters, you've got a head start.  If not, you'll be learning new concepts as well as a new language, so it might take longer. Get yourself a copy of Microsoft Visual Studio Express here (it's free!) and pick up a beginner's C# book-- lots of people seem to like the Head First series, like this one on C#.  A lot of these are broken down into one or two hour lessons, and if you dedicate a few nights a week to studying, you can learn the basics in a month or two.  Alternatively, check with your local community college or continuing ed program.  Most offer introductory classes. As you work through each exercise, make up little variants to test yourself:  "What if I want my window to be red instead of blue?"  "What if I want to let the user choose the window color?"   Make sure the book you use shows you how to interact with a database, and how to write a web application as well as a Windows/desktop one.  This will force you to learn a little SQL, and understand how IIS and web sites work. From there, it's  kind of up to you.  Maybe you'll get the bug and want to take some more classes on computer programming, or you'll decide you want to write the next Angry Birds and make your millions $3 at a time. Most likely, you'll learn a little bit about programming-- much of which you'll forget-- and maybe pick up some skills you can use at work.  I've found that the most useful thing to do, once you know a little of a language, is to challenge yourself to some business task: write a little application that looks through all the documents in folder for and reports how many times the word "mortgage" appears.  You'll have to search the web to learn how to loop through files in a directory, how to open up various file types, how to search.  These are the things a technology generalist often needs to be able to do with .NET: just complicated enough that you don't want to do it by hand, but simple enough to accomplish with 100 lines of code or less. Remember, the goal here isn't to fake your way through a test, or to just learn enough "buzz words" to impress the interviewer (actually, that is the goal of the first answer).  The goal here is to understand enough about C# to be able to use it to do some basic tasks for you.  You want to be the GP who can do a sloppy brain surgery if you absolutely have to.  When the job calls on someone to write a little routine that sends an email if the stock goes over $40 a share, you want to have just enough skills to Google "C# get stock price" and "C# send email" and be able to cobble the examples together to make something that gets the job done.  Then you can tell the next interviewer, "I'm not a programmer, but once I had to write a little app to monitor the stock price and send an email, and it worked." I can't stress this last point enough.  People go to school for years to learn professional programming techniques, and then often spend years honing these skills on the job.  And many of these people still might not describe themselves as really "knowing" .NET.  You're not trying to become the next rockstar programmer in a month. But, there's a ton of little tasks on the job that can be solved with a few lines of the right code.  The powerful thing about .NET is that there are thousands of libraries out there to open spreadsheets, send emails, move files around, monitor RSS feeds, get the weather, and any other of a million little tasks, and there are millions of web sites and forum posts explaining how to use them.  A tech generalist has to be a little like a librarian: you might not know everything, but you know how to find out.  A business analyst, or tech support rep, or QA engineer who can cobble together a little .NET code when they have to is often a very valuable person to have on your team. Now, go out and "learn" .NET!