Kudos on unscrewing yourself, MSDN!

Seen and heard (but mostly seen) – MSDN’s shiny skinny new look.

Compare and contrast the two looks. Here’s a random page about one of the classes you can use to hammer on XML, the way it was before.

And here's the new low-bandwidth edition of the same page.

Oh hey look – I don’t have to dig through panes and curse quietly to myself when that fucking clownishly giant left pane class navigator slides in and out because I’m using Firefox’s incremental search-as-you-type or target where I wants to scroll.

The garnish disappears quickly and I’m left chewing on the meat of the information that I wanted to get at.

Executive summary – dear designers, please consider servicing the needs of your users rather than merely servicing yourself.

Love, me.

Software management - The Oregon Trail model

OK, forget reading Peopleware and The Mythical Man-Month. If you want to manage developers, there's only one - no wait! - two things you need to do.

1. Be born in the late 70's/early 80's
2. Play The Oregon Trail on an Apple II

That's it! If you can make it to the end of the trail, you know everything that you need to know about successfully managing software, so go successfully manage the shit out of a project or three!

Wait. You're still here? I should go on? OK.

You have your hunters, guys who strike out in hopes of lucking into a bounty of delicious, delicious meat. Speaking authoritatively as someone who's never hunted or caught anything of note while fishing, I'll say that a good hunter operates off of instinct, innate ("animal") intelligence, skill and luck. Legends tell the tale of the hunter who struck off into the deep of the jungle with nothing but a knife and came back carrying a gorilcopterous (work with me people, I live on the edge of the tundra) or some big tasty animal that lives in the jungle⁰.

Then you've got the gatherers who plant crops and (hopefully) eventually got to harvest the bounty. It takes a deep investment in time and resources to see a field from seed to harvest, and even then there's any number of natural disasters that can beset you along the way. This isn't to say it's easy. On some level, we all understand how plants grow. They eat sunshine, water and carbon dioxide and crap oxygen and chlorophyll, right? On another level, there's a hell of a lot that goes into it - seeds cost money. Machines to till and harvest cost money. Irrigation costs money. You've got to know when to plant. What to plant. When to rotate your crops.

Developers are an impatient bunch, which means that we don't generally have the patience for the small, far-off, rewards and repetitive work that it takes to grow a crop. But we get hungry, so we're going to strike out and hunt, hoping to bag the next seminal idea. OK, it's probably not a seminal idea by any stretch of the imagination, but for a brief moment in time, you really feel like you've crafted something brilliant and have found something more than you could have hoped for, something that's somehow bigger than you could have imagined.

But eventually, the quarry of the once-fertile plains and forests of imagination!!!!!!! will run dry. Your hunters will pick up on the fact that there's no more ideas to be hunted, only tedious fields that demand regular, monotonous maintenance, and they'll migrate elsewhere. This is all well and good, but every now and then wouldn't you like a steak to go with those potatoes?

But again, I get ahead of myself - let's take a step back to see what a dated educational game has to do with any of this.

In The Oregon Trail, you're in charge of seeing a family¹ make the trip on the Oregon Trail from Missouri² to Oregon³.

You notice how they emphasize "try"? It's because of a simple fact that you don't want to admit to yourself - no matter how simple it seems like it should be, that shit is fucking hard to accomplish⁴. To the outsider, it's as simple as getting from point A to point B. That's really all there is to it, right?

Go figure - there's nuances that you hadn't even considered when you started out. Could this mean that you'll eventually discover that there are nuances upon nuances? This makes the decision of something that seems as simple as when to leave a dizzyingly difficult one.

Leave early and you'll be freezing and making slow, painful, progress⁵. Leave too late and you'll face the unenviable, super-difficult, task of over-wintering⁶. Face it - you've tried to make a trip like this before and you've probably still got the bruises and scars from the last one, but you keep telling yourself that this time will be better.

You need supplies to make the trip. Oxen to move your cart⁷, clothing to keep you warm⁸, food⁹, replacement parts¹⁰... and bullets for hunting¹¹. And naturally, you're constrained to a budget that's tighter than you'd like.

Making matters worse (you mean it gets worse?), you're probably making the trip with a bunch of egomaniacal (wo)man-children. I mean, we all strive to be egoless in our tasks, but we all take an undue amount of pride in an elegant solution and invariably take it the wrong way when someone points out the glaring flaws in our implementation. Or maybe I'm the only one, who knows?

But... about those supplies. Some of them are effectively interchangable. If you've got a good hunter (you have a good hunter, right?), you can exchange bullets for food in the wild - that's the biggest bang (pun unintended) for your buck. Then you can trade food for just about anything else you need along the way¹². You can run pretty lean-and-mean¹³ but you need enough food to keep your bellies full.

You're going to want to hunt (because it's fun!), but not every hunt can be a winner.

What can I tell you? Times is tough out there. Even with a gang of elite hunters firing on all cylinders and a pile of food (ideas!) as high as the eye can see, sometimes nature just doesn't smile on you. As in any pursuit, it's entirely seemly that you can do everything right and still fail.

Not only are times tough as hell, but you're fairly constantly reminded of your own failures and the failures of others in a big, somber way.

Is there any wonder why Einstein up there didn't make it? Wasn't cut out for it. You can't teach people how to hunt - they're born with it or they'll never get it, now matter how blue in the face you get trying to explain it to them.

The trip itself? It's possible that your people are entirely happy in Missouri right now. You can crack that whip all they want, but if you don't instill a powerful longing in them to reach the promised land of Oregon, you'll never make it. In fact, you might find yourself unwillingly invited to a Donner Party. And not to ruin the surprise, but everyone at the party will be eating but you.

---

0. you know, your run-of-the-mill whispered about in legends superhacker
1. your development team
2. the start of the project
3. the project's end (you do have a concrete end-point in mind, right?)
4. #9 on Software's Classic Mistakes - Wishful Thinking
5. sometimes you have the toolchain you need to complete your project, other times you're kind of winging it as you go along - bootstrapping too much of your own technology stack only shrinks the chances that you'll ever make it
6. running out of funding
7. computers
8. technology stack - compiler, language, yadda yadda
9. ideas
10. source control and the other niceties of modern development (build server, unit tests)
11. ain't nothing more dire than running out of bullets - there's no metaphor here
12. dumbest way of describing the point of open source ever?
13. agile??!?

This week's dispatch from the seventh circle

"I don't understand why FxCop is complaining about this static property on a static class."

"Probably because static classes are stateless, so exposing properties doesn't make a whole lot of sense."

"Yeah, but I want to expose properties so that a caller can set the values that they want."

"But that's really not such a great idea. Either overload methods with the parameters you're trying to read from properties or let callers instantiate the class and set the properties themselves."

Why did I find this so disturbing? Probably because it took two days for the chap to make the change.

The other reason I found it disturbing? I did the math in my head and decided that there would be approximately zero point in trying to get him to understand why globally mutable state can quickly lead to misery (false negatives/positives) when you're dealing with the MTA that NUnit runs in.

Design patterns as religion

I've come to an understanding of and guarded appreciation for design patterns.

They're not at all useful in and of themselves, but they are useful at a level of abstraction - they give us a common language to explain our implementations with ("...so basically, the model objects are just kind of structs and we cajole them into doing interesting things by Decorating them...") and, more importantly, they let us learn about the boundaries, limitations and realities of the design space that we're working in by revealing the problems that get solved and solved again and again and... you get the picture.

If your objects start to look like a pattern, it's a curiosity. Patterns were discovered "in the wild" to begin with, so don't tire your arm out patting yourself on the back for rediscovering one. No gold star for knocking out a Flyweight, sorry. On the flip side, don't flagellate yourself when you realize that you've implemented a Singleton - if it emerges from solid design, why would you throw it away?

It doesn't matter if you're blindly implementing a pattern or blindly rejecting an implementation because it looks like a pattern that someone on the Internets doesn't like - it's cargo cult programming either way.

Design patterns are there and were there before anyone started looking for them or writing about them. People have classified subroutines as a design pattern - like other "patterns", this isn't a reason to use or not use them, it's further establishing where they come from - introspection on how we make programs work. There's something to be said for taking a stroll through that meta-field, but I don't linger there too long. Most of the time.

All this is a long-winded way of explaining why my monocole absolutely popped out the other day at work. I was busy doing something or other at the time (transliterating objects to an XML format I don't control using unhealthy amounts of Reflection, I think?) when I saw one of the other developers explaining something or other. I popped out my earphones to catch the explanation midway through.

He had the Head First Design Patterns book open on his desk and was walking through his ideas.

"Why are we bothering with inheritance? The domain model you guys put together is too convoluted and doesn't work in this case."

"If there's something we missed, it's not like it's set in stone. If it's really hairy, we can walk through it and see if there's some reasonable way to get it factored in and if there isn't, we can go further back and see how we can make the model work for us."

"The <I forgot already!> pattern says that you can use hashtables to store the data for your objects, rather than inheriting from a base class."

"Well, yeah. But think about why we use objects and I think you'll see why that's probably a bad idea."

...

"For our model objects, we're use them not only to encapsulate associated data but to make it easily discoverable - when you're working with them internally, it may seem pretty convoluted that your parent base Foo class has property Bar that's exposed by a child Buz object (which has more properties and methods from the IBaz interface that Foo implements), but that's all readily discoverable by anyone who's consuming a Buz object. They could kind of care less how it works, they just need access to have access to its state and be able to send it messages to have it do interesting things."

He was not sold by my explanation and the discussion closed in on arguing (something about our respective tones and the other developers in the office getting quiet and looking uncomfortable) about whether it makes more sense to have the classes representing data internally like a struct or as a hashtable - I scoffed (and still scoff!) at the idea but told him that he was the one implementing it, so if he had a good reason for properties exposing a hashtable behind the scenes, I was fine with it.

I started to look up hashtables and figure out whether he was really on to something or whether my gut feeling that it was adding an unnecessary level of complexity to the design (OK, I was premature optimizing in my head and wondering about the relative weight of sparsely-populated hashtables, too) when, a few minutes and pages in the book later, he announced to another developer in the office (!!!) that the book said that you should only use hashtables when you're dealing with a lot of inheritance and a lot of properties.

I don't think there was any amount of selling I could have done to get him to walk away from the curious implementation - it was design pattern as dogma. Blinders on, reject facts, implement on faith and The Pattern will see you through.

I'm still trying to figure out if I was wrong (probably, yeah) for knee-jerking away the use of hashtables or not. I'll let you know when I turn that page.

So, about that Microsoft-Yahoo Merger

So it was a slow day and I was reading about the Microsoft-Yahoo merger. How developers at Yahoo are fleeing in droves because Microsoft doesn't get the 'net and will ruin Yahoo.

And this isn't so say that they're wrong, but how about fleeing Yahoo for a better reason? Like, say, because of this embarrassment puddle parked out on the street in front of my shonky whip? I mean, come on Yahoo. I've never seen a Googlemobile, but I suspect that they're not quite as... butch as this one is.

(click to engorge this shameful display)

I've got no eye for color or detail, but... fuscia with the cheesy flame job? Really?

Then again, it did bring a smile to my face. For all the wrong reasons, but I was smiling. Way to go, Yahoo. Good luck keeping the corrupting influence of Microsoft far away from your pristine shores.

Management Conundrums - The Cowboy

I read an article refuting the value of crunch time and got to wondering about it.
I've been the cowboy before, working 100+ hour weeks. Dreaming in code, pulling 24 hour days, a real Team Player. I don't want to ever go back there again. I'd like to prevent people I work with from going there too.
I found crunch time to be a vicious cycle. Rather than sit back and think my way through the problem, I dove in head-first and bumped my head on the bottom. Hard. Repeatedly.
I found myself working long hours, making mistakes along the way, and then working longer hours because I told myself "I'll just fix this later." And then working longer days because I couldn't remember the fix that I had in my head earlier but it all seemed so clear to me and in retrospect, fuck embracing death march values.

To push my street cred through the roof, I'll just quote Bun B who puts it better than I do.

Start with your head, homie, then use your hands / If you try it in reverse, you don't even stand a chance.

I don't know if it's confirmation bias on my part - I'm a pretty lazy guy (note to anyone daydreaming of hiring me: I'm totally joking about that). Am I just buying into what these people and their so-called "studies" are saying because I'm (*cough* not) lazy and want to believe anyone that's telling me that working a square 40 hours a week is really OK and even preferable?

The thing is, not everyone believes it - and this is not just managers that I'm talking about, either. As the comments on the article over on programming.reddit show (and as my anecdotes reinforce), some developers have an almost bloodthirsty need to believe in the power of crunch time. There were a couple of chaps in there extolling the virtues of brutal hours of work, stating that without doing months of crunch mode, their projects wouldn't have finished. I prodded, trying to lead them down a path to questioning whether the projects might have finished in the same amount of time without crunching for it, but it was rejected out-of-hand.

The Mythical Man-Month gave us the should-be-more-famous truism that "you can’t get a baby in one month from 9 women" - some tasks really are going to take a set amount time no matter how many resources you throw at them. The mother can start pushing on day one or wait until month nine to start pushing; the baby's not coming out any faster no matter how many months she's been pushing. I think that believing that you can accelerate nature (I'm talking development projects now not babies; work with me, people) is equal parts foolhardy and arrogant, but I also think that a good developer needs a healthy dose of both of these qualities.

When it's a team gelling and putting in the overtime because they want and need to, you let it go. That's a no-brainer. Of course, you can't go on auto-pilot. You need to figure out when they're sprinting to a dead end, when they've started sprinting too soon and have been sprinting so hard that it's counter-productive and maybe you should kick them the fuck out of the office at 5 PM on Friday so they can see their families and come back ready to do good work on Monday. You need to reel them in at some point. Like any design pattern, "crunch time" has its use. Just take care to not treat it like a golden hammer and you'll be fine.

It's the lone cowboy that I'm concerned about, and I'm concerned about what to do with them. When it's a team working to a goal, they're building together. When it's the lone person banging away at all hours, they're using their back more than their brain and will miss simple, obvious solutions to their problems and get aggravated at everyone else who isn't putting in the same brutal hours they are.

Part of me wants to save them, but then again I'm not sure that anything can be done with or for them. Reason, logic and studies seem to bounce off of them (it did off of me) like bullets off of Superman's skin.

At my current job, we had a cowboy developer. Good developer, smart guy, put in long-ass hours. Went on vacation, came back in with a custom XML business rules engine (like Drools) that used .Net Reflection and all that good stuff to drive it. It's pretty good code, just that in retrospect... we didn't really need it. I never had the heart to tell him that outright and thousands of lines of code nobody wants to refactor out of the application remain today.

When he eventually left, another of our developers quietly became the new "hard worker" to pick up the imaginary slack left behind. I don't know that I'd even have noticed this quiet change if I hadn't read The Lucifer Principle by Howard Bloom (this and The 48 Laws of Power are Dave Solomon picks for bizarroland must-read management books).

In The Lucifer Principle, Bloom relates an anecdote about a researcher's study at a summer camp. The researcher had identified four major archetypes for kids in group behavior - the "alpha male", the "bully", the "joker" and the "nerd" and conducted an experiment with them (nothing on the level of Milgram or the Stanford Prison Experiment).

The scientist assembled a cabin composed entirely of "leaders," boys who had been dominant, "alpha males" in their old groups. Very quickly, the new cluster sorted itself out according to the familiar pattern. One of the leaders took charge. Another became the bully. A third became the group joker. And one of the formerly commanding lads even became the new group's nerd.

- The Lucifer Principle, Howard Bloom, pg. 92

I know I'm doing a terrible job explaining this, but what it comes down to is that I've seen the shift in my co-worker and I don't think it's a conscious one. He may think that he "needs" to work longer hours (I've certainly danced around it trying to get him to feather the brake pedal on it, so to speak) to get things to work, but could he explain why?

Of course, self-interest on my part demands that I don't push them too hard to not kill themselves. I'm not the boss and if he's not doing the long hours, I'm sort of afraid that someone else is going to give me the stink eye because I'm not checking in code after midnight just before I leave on vacation to show that I'm a team player, never mind that the code's invariably broken in some hideous ways and people are going to have to quickly find and fix all the mistakes I've made because I was tired and rushing.

Moreover, like I said, I suspect that there's some subconscious understanding about the archetypes (for developers, read: "design pattern") of a team, and that the "overachiever" is one of them. I know just how loaded the word archetype is which is why I think it's probably an aft metaphor - if our work habits are indeed an unconscious manifestation of our identity, then there's no clean way to divorce one from the other - the cowboy's going to keep drawing for that six-shooter no matter what you do and resent you for telling him to keep it on safety before he blows his foot off. They may not be able to do it any more than you could conquer someone's fear of snakes just by bringing to their attention the fact that they are, in fact, terrified of snakes (I suspect this is an easier one to break though). Moreover, you get rid of one and another will rise to the occasion.

Unless you do what you can to make them and everyone else on the team aware of your distaste for their overwork and unless your boss (and bosses all the way up) are on board with holding people to a square forty, I doubt it will happen.

Sadly, getting everyone to throw fallacious common sense overboard and accept the fact that working smarter and working harder are just about always mutually exclusive and working smarter beats working harder just about every time isn't an easy task. If it was easy and if these work archetypes didn't exist, then everyone wouldn't be positive that today's Dilbert (for pretty much any value of Dilbert) just had to have been sent in by one of their co-workers.

But I'm no manager, so I keep on doing what I can to make things better, forty hours a week.

Meaningful Certification is Hard

When I read Raganwald's post on certification a while back, I was impressed by what laid underneath the surface. What he's looking to certify out of the gate is a first-pass cut to weed out the scrubs and find people with a shared set of values that is not up for discussion - no matter what you're doing or how you're doing it, if you can't prove that you're doing it correctly and safely, it hasn't been done. I like the idea because it implicitly weeds out the people who can't program all that well in the first place; if getting it to compile is a chore, tacking on unit tests and being able to talk coherently about why injection attacks are rendered irrelevant is certainly going to be beyond your means. If it's a certification done on a small scale, you're going to be finding an exclusive group of developers and you're going to have a high degree of confidence in any of them and as such, you've pretty much rendered the cover letter+resume then let's small talk thing moot - you're hired.Of course, this ignores a harsh reality. If there's an economic incentive to having that certification, there will invariably be ways to game the certification. I've interviewed (and worked with) enough incompetent but acronym-accredited developers (IBAADs, copyright MEEEEEEEE) to pay certifications little mind at all. They're not bad, but all that's being certified is that the person's achieved some encylopediac familiarity with the terms of the field rather than a true understanding of how and when to apply them... more on that later.

More recently, Joel's posted about just how lame undergraduate programming courses are. Did you know that people come out of school patently unprepared to do development work? This is, frankly, SHOCKING. That last sentence was, frankly, sarcastic.But don't despair people - software is hardly the only profession where this sort of thing is endemic.

I'm friends with some lawyers and I generally hear the same thing - going to law school and passing the bar is tough, but all it does is certify that you've achieved a base level of competence; they come out of the process thinking that they're ready to take on the world and are pretty immediately humbled when they realize just how unfit they are to do any lawyering. It takes 18-24 months for a freshly bar'd lawyer to be able to do much of anything beyond researching case law, being mentored by more experienced lawyers most of the time. Doesn't this sound familiar?

I can't help but see the similarity with getting my degree in information systems - I graduated with good grades (cum laude, what!) and was sure that there wasn't anything I couldn't do. I look back on my first few jobs/years of professional work and shudder at how awful of a developer I was. I look back on code I wrote a year ago and shudder at that too. At this point I don't think that any amount of education could fulfill all values of "rigorous and practical", let alone most of them. This isn't to give JavaSchools a free pass or whatever, because I've interviewed people from them and their abject lack of passion for the craft is a ferocious turn-off for me.

In that regard, I'm with Joel. I don't expect that people are going to step out of school ready to do it all (not gonna happen) but I do hope that they'll have been exposed to more than one way of doing things. In my time, I brushed up (and a few hours a week for a couple of months is about all that I got in most cases) against x86 assembly, C, C++, COBOL and, yes, Java in my four years of college. I'd like to think that I took a little something away from each of these languages about how you can make software work and the lack of LISP or some other functional language is the reason I'm learning Haskell and going through The Structure and Interpretation of Computer Programs these days.

Lawyers go through as much college as I did and then 3 more years on top of that and then a certification on top of THAT and at that point, they're still so green that they require a year or two of more or less intensive mentoring to become productive. Word on the street has it that doctors do all that, except that they're putting in hundred hour weeks while they're mentoring to boot.

I understand Joel and Raganwald - I wish that there was some way to certify that the developers have a shared set of values, a shared passion and a capability to rise to the task that's put in front of them, but looking for this to come from schooling or certification is, or so it would seem to me, praying for a magic bullet.

And even those JavaSchools that churn out mediocre developers serve their purpose - we can't all be superstars. A great certification or four years of a great school won't turn mediocrity into a hacker god, and not every piddly project needs a superstar developer. Certifications and education are both fine signifiers, but it'll take something more rigorous than either to signify what we're all after.

A love letter to the software QA folks of the world

In our twisted little minds, we're fashioning castles out of dirt, breathing life into the imaginary peasants that inhabit the castle and coming up with new and fascinating ways to teach the little people to exercise functionality. Nothing could be wrong with my castle! I built it myself from scratch! Can't you see all the little people in there grinding away just like I taught them to?
But oh! There be a storm brewing! Eventually we have to put down our magic wands and show people just what we've been up to and there's the QA folks. Looking everything over with a discerning, non-paternal, eye and pointing out that I'm just an idiot playing with dirt and by the way that castle you built? The walls aren't up to spec.
Developers and QA operate in an antagonistic relationship. We build things that we're proud of (and if you're not proud of what you're building, you're making their job a hell of a lot easier) and they knock it down. Maybe it's because I'm an entirely reliable source of bugs, but on the whole, it's been mostly mock antagonism. True, I enjoy tagging bugs as "unable to reproduce" or "user error" more than I should, but at the end of the day, I appreciate that there's someone checking what I'm producing and verifying that it's not all wrong.
I'd tell you that I test as much as I can, but if I told you that, then I'd be pretty hard-pressed to explain some of the head-scratchers I've released in the past. Can I blame it on not using test-driven design? Not being agile enough?
Developers get the cool software toys. I've seen a few QA test environments in action and they're pretty execrable, little better than the (super-awesome and totally deserving of the coveted Dave Solomon Seal of Approval) Watir. I can get unnaturally pumped about source control. What else is there to get psyched about in the world of QA software?
We get the cool development methodologies. Test-driven design (jesus christ we're developers pretending to be QA! are we trying to put you folks out of a home?). Agile. Scrum. What do QA folks get? Seriously. I have no idea.
Worst of all, the project timelines. When the specs take too long to get hammered out and development drags on too long because the software's more complex than expected (leaving more nooks and crannies for bugs to fester in), what does your enterprising project manager propose as the solution? Push the release date back? Nah. Just cut the QA cycles short. Sell the sizzle, the quality of the steak be damned.
How many projects will be haunted to their grave by that decision?
So here's to the software QA testers of the world. Despite being forgotten children when it comes to software, viewed as a liability by managers and loathed by developers afraid to eat their own dog food, you somehow manage to persevere and keep the quality up.
Just quit going over my code with a fine-tooth'd comb, willya?

WTF exactly is wrong with The Daily WTF's site rename?

Ladies and gentlemen, a new pithy tenet of the software development world has been born into life.

Before, we had to slum it with lame old one-or-two-liners like...

The first 90% of development will take 90% of the time. The last 10% of development will take the other 90%.

Perl is write-only.

Java is the new COBOL.

But that's so pre-web! We need to get with the times and have something that goes down easy in our RSS readers! So we have a new one!

The Daily WTF sucks now that the WTF stands for "Worse Than Failure."

Has the quality of the postings gone down? I don't think so. With new editors there and the 3 posts/day that they're churning out, there's bound to be some that don't quite fire on all cylinders, but I get a chuckle or a sad shake of my head out of something most every day there (still). That said, I can't lie and tell you that I'm some sort of sophisticated gentleman. I play video games and laugh at fart jokes so I obviously don't know from quality, plus I might have licked my old Voltron toys to get them to stick together better when I was a kid so I might be a little (OK, a lot) retarded.

Is there really that much in a name or is there more to it? Obviously, I think there's more to it, and here goes.

When it was The Daily WTF and the WTF stood (spoiler alert!) for What The Fuck, it was nothing more than a freak show. Only in the place of the bearded lady and the world's largest horse, we had the programmer who overloaded booleans so he could enumerate FILE_NOT_FOUND! Ha ha ha! They're so much dumber than I am! Can someone around here give me a big high five because I solved FizzBuzz in Erlang the other day? Paula Bean LOL!
Now that it's Worse Than Failure, could it be that it cuts to the quick of that nagging fear that I've got in the back of my head. Maybe it's in yours too... it says things like "I thought this object model was the bee's knees, but have I gone too far? Can anyone but me support it? Could I have done it a better, simpler way?" Things like "What exactly is the point of all this? There's a metric shit-ton of code and tables, but at the end of the day, does anyone appreciate what I've done?" Things like "Is this what I have to show for the last few years of my life on this?"

Or, to paraphrase Morse, "What hath we wrought?"
It hurts to think critically and realize that the system that you've worked so hard on probably should never have been built in the first place. That those pet classes of yours might look like the Sistine Chapel to you, but to the rest of us they're little more than a house-shaped booby trap constructed out of snot, zip ties and duct tape, waiting to trap and maim us in new and unexpected ways each time we brush up against the walls.

That you've taken a rusty, but perfectly servicable, old DOS application and re-implemented it as a spanking new web app with all the fixins (AJAX! MVC and so many other patterns! Multi-threaded!). You see a success, your users see that you've architected a monumental clusterfuck that's so ornery and unusable that they're keeping around their 386s because you've all you've succeeded in is failing their needs miserably.

That a lot of the time, development feels an awful lot like the Red Queen's Race.

Or maybe I'm missing the point altogether and have no clue what the fuck I'm on about. Has the quality really dropped, are Alex Papadimoulis and his associates sellouts (however that would apply) or should Shakespeare have wondered "what's in an acronym?"

Really, is the world a better, happier place because of what you've done? Are people getting more out of your system than they're putting into it? If your system disappeared tonight, would anyone care tomorrow or the day after that? Is it possible that your successes are such untenable messes that they really are worse than failure?

Code Smells - Developer Literacy

Continuing on the subject of interviews, if I could give one piece of advice to people job-hunting, it's this - proofread your resume. It isn't hard, honest. If I could give another piece of advice to developers actively writing code, it's this - proofread it.

When hiring time comes around, I have no trouble whittling down the candidate pool. A middle-of-the-road candidate is getting tossed if their resume has misspellings or glaring grammar errors. My grammar's awful enough that I wouldn't know a dangling participle if it hit me in the face (I know that they're bad, do I win a cookie?) but I do know to avoid tense shifts and other obvious biffs.

But developers write in code, not in English! Surely this is a case of the narcissism of minor differences!

I think it goes beyond that. Misspellings are a code smell for me - if a developer can't be bothered to learn and properly apply the language that they've been speaking for 30 or 40 years, how much faith do I have in their ability to learn and properly apply a language that they've only been "speaking" for 5 or 10 years? So, if I may retort...

If you don't proofread your resume/e-mail, how much faith should I have that you proofread your code?

If you don't proofread your code, how confident do you expect me to be in the fact that you've debugged it?

If you can't be bothered to crack open a dictionary, chances are you won't bother cracking open Google when you encounter a problem. I imagine that you'll instead choose to boldly and blindly rush head-first go into the same tar pit that so many arrogant developers before you have.

I won't go so far as to say that you should go out and get an editor (but the man is on to something), but I will say that you're not showing a whole lot of regard for the person on the other end if you can't spell right. If the person on the other end is me then you're not instilling a whole lot of confidence in the quality and professionalism of your work either.

If the person on the other end of your typo'd code is you (and it probably will be) then why don't you love yourself enough? You need a hug.

If I wrote the typo or awkward grammar, Word was broken and my internet's tubes were completely full of kittens that day so you have to forgive me (and not point it out). After all, I'm just a developer. You must understand - we write in code, not English.