On one hand, they’re incredibly useful as shortcuts to lengthy, often hard-to-find network paths.

On the other hand, mapped drives suck for everyone else.  More to the point, when one user tries to leverage a mapped drive for other users, under the assumption that everyone has the exact same mapping.

Example:

A: I saved a file for you to look at.  It’s out on the network.”

B: Really?  Where?

A: On the X Drive.

B: I don’t have an X Drive.  Where’s it really located?

A: Go to ‘My Computer’, then look for ‘X…’

B: No, I mean there’s no ‘X’ on my machine…

Hilarity ensues.

This, of course, is not the fault of the user.  They’re playing by the rules of the operating system, which does them a service by making long, strange absolute network paths shorter and easier to get to. 

The problem is that by hiding addresses under drive letters, it becomes all too easy to start viewing them as local, shared paths.  “It’s got a letter on my machine, but I know it’s on the network, so everyone else should be able to see it…”  It becomes the assumed common knowledge of the infrastructure.

Only it’s not.  Not everyone’s machine gets imaged the same way; or maybe that’s a new path that only recently started getting used.  Either way, shares are never as common as most users assume; someone is going to miss it.  And when users go around talking about an “N-Drive”, “W-Drive”, what-have-you… it’s a safe bet someone will have no idea what they’re talking about.

Is there a better way?  I’m not sure.  But what every operating system should do in my opinion is find a clear way to let users know that mappings only conceal real addresses.  (In this context, “clear” does not mean just right-clicking on the drive and viewing Properties to get the full path).

Something that says to them “Psst… I know this looks like a W:\BigShare… path… but it’s really out on machine ABCDOMAIN2…”

I know, I know… wishful thinking.

Because the iPhone is prettier.

That’s right, I said it.  It may not be the most sound or practical reason, but it’s honest.

I primarily chose the iPhone because I found it pretty.  And “pretty” in this respect is actually important.  The aesthetics of something should be an indicator of its intrinsic quality, not a mask to hide its defects.  Nor should poor design get a free pass merely because it’s a container for good software.

Apple gets this.

And to be fair, I had thought about the Droid.  Seriously.  It had good features, decent price, and heck, it was on Verizon.  But, deep down, I knew I’d always be comparing it to the iPhone.  The look, and therefore the appeal, just wasn’t there for me.

Evidently, I wasn’t the only one who had qualms about the Droid’s appearance.  Verizon even had an ad (which I can no longer find… odd) that tried to explain away the device’s decidedly un-iPhone-ish look with super-geniusness (“It ain’t no beauty queen, but… “).  I felt it was a cheap knock and a weak argument.

Whenever good design is automatically viewed as “unprofessional”, or portrayed as incapable of being functional, it’s an implicit statement that “pretty” things have no value.  When we start to buy into that idea, something more important gets lost: the notion that we should have both brilliant design and superb quality in our lives.

I had a chance to take a look at Rhonda Tipton’s blog, and just by chance noticed that the mobile version was very different from the regular one.  Readability is key for me.  I navigate to many blogs now via Tweetie, so I know what a pain it can be to have to manually resize content for a mobile browser.

This new blog is a work in progress.  I’m thinking about changes in tone and direction (hence the new title).  I’m also thinking about lowering my often self-defeating level of censorship (that absolute main reason why it took me forever to get anything posted).  That doesn’t mean you’ll see foul language here; that’s something I’ve always been opposed to on any public medium.  It just means more opinionated content.

Requisite Caveats: Before I go too far, let me clarify: I’m talking about regions in user-generated code.  My concern is really about developers making decisions about how they organize their own code for purposes of readability.

And yes, I’ve used them in the past – repeatedly – in the manners listed below.

They Distract From Refactoring

I look at regions as pseudo-refactoring tools.  All too often, their usage is the result of logic like “Hmm, this file is pretty big and unwieldy…  I know, I can use regions to get it under control.”  Leading to what I consider the fallacy of thinking that by condensing code inside the editor, we’ve made it more manageable.  When in fact, we haven’t done anything.

Big files are blazing neon red flags that real refactoring opportunities are at hand.  Using regions, however, can trick some developers into thinking that n-thousand lines of code in a single file is really maintainable, because well, see, we’ve got them all organized into nicely labeled areas.  They’re a distraction from the real work that needs to be done.

Regions don’t make the file smaller, but they can mislead you into thinking this much code is maintainable.

Personally, I feel that when a file is growing to about 300 or more lines, something is amiss.  Whether it’s something like an SRP violation, a lack of optimization, or just that’s it becoming the “miscellaneous” file, a big class usually means big trouble.  I’m happy with small.  Small is readable; it’s maintainable; it typically doesn’t need regions to stay organized.

They Conceal Surprises And “Ugly” Code

Regions can be, and often are, used to hide ugly and/or mysterious code.  The really scary stuff (general cruft, old commented-out lines, or my personal favorite… the “surprise!” code that tends to throw reviewers for a loop) that you know you don’t ever want to see again.  And maybe that you don’t want anyone else to see, either.

I’m of the belief that ugly code should never be hidden.  You don’t want a “people under the stairs” scenario; that stuff will fester, rot, and mutate… and it will always come back to haunt you.  It has to be exposed; literally dragged out into the center of your editor, kicking, writhing, and screaming, so that it can be healed and cared for.

Regions can cleverly disguise code that’s loaded with surprises.  Or, at least not what you’d expect when you read their captions…

…and then expand them out to find, well, hopefully something good.

Make Your Code Readable

Readability has nothing to do with regions, in my opinion.  It has everything to do with making your code sensible, logical, and straightforward.

The best way to keep your code organized is to think critically about what you’re writing.  Don’t rely on editor shortcuts; they can become very addictive habits that are hard to break free from.  I put regions in this category; they trick you into thinking you’ve made your code more readable, but in reality you’ve done very little.  Far worse, you’ve inadvertently hidden stuff that other developers may need to see one day.

What do you think?  Let me know if you still use regions.  Do you consider them necessary?  And, if so, where have they helped you the most?

I thought about that question, and my own answer, after attending the the January Houston ALT.NET Geek Dinner.  To me, ALT.NET is about fostering the developer community, but I know not everyone sees it that way.  This got me wondering about how developers define the term for themselves.

All I know about the developer community, to be perfectly honest, is what I’ve conjured up in my head.  So the rest of this post… and consider this fair warning… is nothing more than my perception, and probably a distorted one at that.

It’s a necessity

Developers need… in fact, crave community.  The stereotype of the geek who doesn’t talk to anyone, stays in their cube or office all day, only comes out for coffee or a [mandatory] meeting, and generally is unable to communicate very well with other bipedal organisms… I refuse to perpetuate it.  I’m not sure how that image got started, or how the connection between “writing software” and “being socially isolated” got made, but I cannot subscribe to it.  And moreover, I think most serious developers… who care deeply about their profession… feel the same way.

Rather than solitary and isolating, I choose to see software development as a social experience.  And not because there is the potential to have what we write end up in the hands of other people; some of whom are going to give us feedback, wanted or otherwise.  It’s actually because of the developer user groups, events, and conferences.  I find it amazing that all these fundamentally social gatherings, focused in one way or another on development, even exist.  I see them as natural manifestations… as proof, really… of the need for developers to connect and exchange information.

It’s a social fabric

The developer community is a hodge-podge at best.  It’s not just a single group that, say, meets once per quarter and proclaims “Yep, we’re pretty much it”.  It’s an amalgam of individuals, groups, and entities.  It’s a chorus of voices, via blogs, tweets, speaking engagements, magazines, coworkers and colleagues, that all work to shape and expand our craft.  They all do this in different ways, of course, but the net effect is the same.

I enjoy reading lots of blogs (and I would say “books”, but I’ve been unintentionally remiss on book-reading), attending conferences, going to HDNUG meetings, and just about anything else that allows me to meet and hear other developers.  Reading blogs is critical, in my opinion; so much so that I consider it a bare minimum for community involvement.  I have a long list of feeds and I make use of a good RSS aggregator (I’ve been extremely loyal, or maybe just too lazy to change from, Newsgator).  Confession: There are podcasts and vidcasts that I’d like to really digest, but I have a difficult time getting into continuous, heavy AV use.  I’m much, much better at reading than I am at listening to podcasts.  But that is something I want to work on. 

I use Twitter, which is a relatively new tool for me; I’ve found it immensely valuable.  I’ve watched countless fascinating discussions happen in real-time.  And every user I follow has had something useful to say.

Beyond micro-blogging, I rely on social networks (like LinkedIn), IM, wikis (well, at least one for now), this blog, and even email as ways of staying in touch with other developers.  My goal is to use every tool I can find (and that suits me) to help establish and maintain connections.  I think that’s how the developer community works; we’re technologists at heart, but we’re social ones, so we use a variety of tools to that end.

It cultivates learning

Good developers, of all skill and knowledge levels, understand the necessity of continuous improvement.  They willingly foster the learning process, support those who want to learn, and always remain open to new ideas.  For me, that exemplifies the goal of the community: encourage its members to improve.  It’s not about ego, “supreme coders” on parade, or being in an “everyone-else-is-doing-it-wrong” clique.  (And if that’s all you find around you, look elsewhere until you find something more positive.)

What I want out of the developer community is to learn more than I can on my own.  So I expect that it will demonstrate a sincere commitment to developer education.  In my view, those with the knowledge I seek can tolerate giving more than a few “Getting started…” presentations, a dozen or so rudimentary questions, as long as it helps raise the awareness of everyone in the audience.  Of course, it shouldn’t always be about 101-type experiences; a healthy association pushes its members to grow; not just stay on the remedial track.

It’s not for everyone, but it should be

Despite all that I’ve said, it’s true that there are many talented, highly proficient, even brilliant, developers out there who probably don’t give one whit about any sort of community.  They get by just fine with maybe a few books, whitepapers, and near-perfect recall of their Computer Science courses, thank-you-very-much. 

The only problem I have with that kind of developer is that they end up being “hidden” resources; their knowledge and experience stays locked away inside their brains.  They could benefit a lot more people than just the ones who happen to be lucky enough (or not) to work with them.  They may not need the community, but it could always use them.

Community is important.  If you don’t see yourself as part of it, I recommend getting involved at least a little bit.  That could be anything from attending a user group meeting to reading a developer’s blog and leaving a comment.  Even if you don’t get a benefit from the content, the mere act of participation will still move you in the right direction.   Ultimately, community is whatever you make of it; just remember that it’s there to help you.

When: Tuesday, January 6th, 2009 @ 6:00 PM CST

Where: Microsoft Houston
One Briar Lake Plaza
2000 W. Sam Houston Pkwy. S. #350
Houston, TX 77042

Topic: If I remember correctly, this meeting should be covering Silverlight out of the browser.  However, there’s a strong possibility that I’ve projected my hopes and wishes onto that agenda.  Whatever the real topic, it promises to be good.

More Info: The D2SIG main site 

This is a very, very new group, dedicated to the User Experience (UX), but it’s quickly getting a strong following.  If you’re interested in anything having to do with the latest in UI, this group is for you.  Feel free to drop on in.

When: Wednesday, January 7th, 2009 @ 6:00 PM CST

Where: Freebirds World Burrito
3745 Greenbriar
Houston , Texas 77098

Topics: TBD, but you can see the working list on the forum here.

More Info: Houston ALT.NET Group

I’m new to the whole ALT.NET scene, and to be clear I am NOT the organizer of this dinner… that would be Ben Scheirman.  But I am really looking forward to it; I’m hoping it will be a great way to discuss various developer-related topics with lots of bright people.  And maybe eat something… I’m taking the “dinner” part of that title very seriously.

So I went with a different tactic.  I renamed mine to “goals”, and spent a goodly amount of time on them… in the tens of minutes, at least.  Completely different animal.  And I figure what better way to keep them enforced than to make them public.  So here they are, in order of priority:

1. Blog more.  I honestly want to do more of this.  I enjoy writing; it’s my second-guessing (both on topics and syntax) that slows me down more than anything else.  I think that’s one of those problems that only gets minimized through continual practice.  I figure I should get myself to an average frequency of one post per week this year.
2. Do more public speaking.  It’s something I’ve only done a handful of times, and loved every minute.  I’m going to find ways to do more of this.  My goal is five presentations – in whatever forum I can get, I’m not choosy – for the year.
3. Dive head-first into at least three things I barely know.  Sometimes the only way to learn something… to really learn it… is by doing it.  This could just be by implementing small pilot projects at home, participating in something community-driven, or even something at work.  My target list for now * includes:
1. Domain Driven Design
2. Behavior Driven Development
3. ASP.NET MVC
4. F#/Functional Programming
4. Read at least two technical books.  I’ve seriously neglected the whole book-reading thing (in terms of growing my developer skills); staying mostly with material I can find online and in ebooks.  In 2009, I’m going to get some highly recommended real books and take the time to read them.  (However, I’m staying away from technology-specific books; I’m more interested in concepts and methodologies than in new skillsets).

* I reserve the right to capriciously change my head-first list at any time.

It’s a short list for now, but it’s enough to keep me motivated.  Most likely I’ll be editing this as time goes on.

I’ve been using TweetDeck so much lately that it’s got me wondering a lot why Silverlight doesn’t yet have a desktop container.  I like the idea of having RIAs on my desktop (and yes, I am an unabashed fan of Vista Sidebar, which allows me to actually enjoy my desktop).

So I started searching the tubes for anything I could find on whether or not there actually was a Silverlight container.  Maybe it was out there but I just hadn’t seen it yet; but if there wasn’t anything, and no plans for it in v3, then I wanted to find out why. 

All I was able to find, however, was a scripting solution that allowed you to run Silverlight apps on a Windows-only platform, hosting them inside HTML applications.  If you want to know more about that, you can find a detailed solution here: Silverlight: Running standalone full trust applications.  (Caveat: the post uses SL 2 Beta 1, as near as I can tell; I had to do some minor tweaking to get it to run against SL 2 RTM).

I concluded that there was no real Silverlight fit client out there, nor was there one on the horizon, and I began laying out a list of wild, uninformed speculations about its absence for this post.  And I almost posted it last night; I’m glad I didn’t, partly because it was turning into a minor rant, and also because I finally found what I was looking for once I started searching for new features in Silverlight 3.

It now appears that Silverlight might actually have a fit client platform in version 3.  This means that you will be able to build desktop applications directly in Silverlight, and they will [theoretically] run on any OS.  If it’s true, then it’s a very, very good thing.  You can find this info among the list of other upcoming Silverlight 3 features at Bart Czernicki’s Silverlight Hack.  His source for the fit client material came from an InsideRIA post by Richard Monson-Haefel, which goes into more detail on the RIA wars happening under our very noses.  And that post is using a NYT article as its source (hmm, starts to feel just a little like “a guy who knows a guy who knows a guy who said something about Silverlight…”)  Richard states about the NYT item:

Sound familiar?  What the NYT is saying is that Microsoft has plans to create a Silverlight runtime outside the browser similar to Adobe AIR, JWT, Gears, or Curl. That means developers will be able to create Silverlight applications that run right off the desktop – any desktop. This is what we call a "Fit Client" solution – a RIA platform that works both in the browser and out of it.

I’m a little concerned, however, that I had to scour for as long as I did before I found this information.  My take on it is that most of this is prediction; but I’m also expecting this to get cleared up at Mix09, when there should be some formal announcement about Silverlight 3’s feature set.  Until then, I plan on following this topic for as long as I can.

Phil’s presentation was filled with useful advice, but the one topic that stuck out for me the most was mentoring.  I believe that all developers could benefit from having mentors, but you just don’t see much of it in the wild.  (Well, your experiences may vary, but I personally haven’t seen much of it.)

I’ve been thinking a lot about mentoring, and synthesizing some of Phil’s comments with my own requirements and goals.  I see mentoring as a two-way street: if you are serious about having someone to learn from, then you should reciprocate whenever you get a chance.  So, get a mentor, but also be willing to be a mentor.  So here’s my rough list of what I think that should entail:

• Get a mentor. 
  • Pick someone that you respect and open up a dialog.  This doesn’t have to be some sort of awkward, platonic variant on a promise ring exchange or anything like that.  Just ask questions, gain knowledge, that’s about it.
  • Look for someone who challenges you and shows you respect.  There are a lot of people out there who are brilliant but just don’t make good mentors because they lack “people skills”, or have larger than life egos.  Do not expect those people to make very good mentors.  A mentor should test your limits and challenge what you think you know, but not in a overly negative or discouraging way.  Put another way, they are not drill sergeants.
  • It should not be someone on your team or anyone you work directly with.  This came from Phil’s presentation, and actually caught me by surprise.  But the more I think about it, the more sense it makes.  You need to have uncompromised communication with your mentor, and that’s just not always possible with someone on your team, or your manager, etc.
• Be a mentor.
  • Be open to the idea of helping those around you.  If you’re an alpha geek, this shouldn’t be hard since you should be used to answering a lot of questions already.  (And, btw, what are you doing reading this blog? )  If you’re not, or don’t consider yourself one, just teach what you know.  If you’ve been doing any serious development for the past few years, you do have knowledge that can help someone else.
  • Advocate the learning process, not just the skill.  Given enough time, anyone can learn anything (notice I didn’t say “…master anything”).  Maybe you’re a code ninja now, but at some point you weren’t; developers looking for a mentor want guidance and want to learn from your experience, not to hear how you did some wicked refactoring over the weekend.
  • Be patient with anyone who is actively trying to learn.  I hate to harp on this one point, but I feel it’s worth repeating: I’ve seen scary-smart developers who were also just the worst people in the world to learn from.  And that’s okay, not everyone needs to be a teacher.  But if you really want to educate those around you and you’re finding that you’re impatient, please find a way to work on that.  Your knowledge is important, and you can make a difference to another developer.

That’s all that I can put down now; I’m hoping to refine this list a bit better over time.  Maybe when I get a chance to actually mentor someone myself.