Liveblogging p&p summit, day 3, designing for performance

Yes, let's all agree that all apps must have a performance plan.

• Highest-priority scenarios - could be response times to user input, or server throughput, or other. I'm thinking data response times too.
• Articulate Bad, Good and Excellent performance - e.g., on startup 10 sec is bad, 3 sec is good, <>
• Do coarse estimation if "good performance" is in jeopardy - if uncertain, prototype and measure more; if bad, redesign.

Design design design design. "If you have a performance catastrophe - 10x, 100x from acceptable - then you either have some serious bugs or the flaw is in design. If it's in the design, then you're screwed. You cannot fix this late in the product cycle. You have to start over and redesign the app from scratch for version 2." You don't say. J.f.C.

Measure. Use real numbers. Measure early. Don't skimp on this. Performance is not free.

You cannot commit to features or designs until you know how much they cost, and to know that, you need real facts and real numbers. Use references (consults?), past experience, and experiments/prototyping to determine what things cost. You can only make rational decisions about how to build things if you know this. (I am sure this must apply to aspects of decision-making beyond just performance.)

Multi-threading. Ugh.

A symptom of blocking - you have a ton of stuff going on/waiting, but the machine's CPU is not fully utilized. This means something's hanging on some thread while the machine has idle threads to spare. Points of communication between threads will then be the bottlenecks. It's fine to share RO data between threads because each thread can keep its own hot copy.

Disk is 10,000x slower than RAM.

"The problem with caches is they only work the second time." D'oh.

("Argaments"?)

Memory is not a primary metric - time is. It only matters inasmuch as it affects time.

Takeaways:

1. Care.

2. Plan.

3. Measure.

4. Design.

5. Measure some more.

Liveblogging p&p summit, day 2, keynote

"Don't allow an unbelievable schedule to live."

Not just don't, but here's why not:

When people don't believe the schedule, it undercuts their belief in anything else you say.

When everybody "knows" you can't make the schedule, if you're not actively managing that, they'll start making their own decisions and judgments. If this is under the table, then they won't do it the way you (the manager) would want. E.g., if they "know" the ship date isn't realistic and no one is talking about that, maybe they'll speculate about how much it's going to slip, and start working to that assumption. If you (the manager) don't know what they're speculating and aren't giving realistic, believable input into that judgment, then you won't have any influence over that decision they're silently making about how to work. Yowch.

The usual solutions are to change the ship date or change the scope, to bring about a believable schedule. Both of which are the right things. I suppose there is another possibility, to convince people that the original scope & schedule should be believable, by providing lots of supporting facts and Gantt charts and suchlike. The problem here is that this is more like browbeating, most of the time. If your developers don't believe the schedule (assuming your developers are minimally competent and are at least somewhat able to explain their concerns rationally; if not, then you have a much bigger problem), chances are you should listen to them instead of trying to talk them out of it. As well, not listening to them makes all of the above outcomes worse.

"Working harder is a short-term solution." Death marches R bad, mmmkay?

Liveblogging p&p summit, day 1, more

Gratified to see that my team isn't the only one with an unhealthy fondness for layer cake metaphors (and Visios)!

"Customer doesn't care whose fault it is; they just want things to work." Good reminder for me, personally.

Got to talk to a very delightful p&p program manager/session presenter in the coffee line while a different session was going on. If I were actually any good at this "networking" thing, I would have figured out a way to snag a business card or thought of a thought-provoking question for further follow-up. Live & learn.

"When [users/developers] get a new version and have to spend all their up-front time fixing compatibility issues, they tend to not want to use your app at all." Not that Microsoft would know, of course. ;)

Much later in the day...

Experimental 15-minute "lightning sessions" debuting this year. The first one was a Program Manager discussing transition to Agile, which was disappointing because it didn't cover Agile in very much depth. In 15 minutes. I know! Really! (Ahem, kidding.)

The current "lightning session" covers a concept called Behavior-Driven Design. I love it. This is either something we are already accidentally doing, or something I wish we were doing. Either way, it seems to me that it would fit well within the methodologies we already use. Awesome.

I exercised restraint and did not "mention" the speaker, @ElegantCoder, in a tweet, even after other attendees did and his TweetDeck notifications started popping up on his presentation laptop. The temptation was tremendous.

So he uses the word "scenario" for the "given/when/then" construct describing a desired/expected behavior. We also use the word "scenario" and I'm trying to figure out whether our usage is reasonably compatible with this standard definition, or if we're abusing it. We use it to describe automatedly-testable behaviors, so it does seem to fit together, but it doesn't really describe our internal architecture, so maybe not so much.

OK, this is cool. Third lightning session on SharePoint development seemed ridiculously irrelevant to our team, but instead, here he is demoing the concept of Inversion of Control, which is perfect for some of the team members we brought along, and the examples are simple, and he's explaining the value IoC adds to the process. Hooray!

That means 2.5 out of 3 lightnings are useful so far.

Last lightning round: Billy Hollis. Always a total, major win even if he doesn't fully appreciate that there may be female coders in his audience (or in the universe) when he writes his jokes. Ahem. *dusts shoulder-chip* I'll still give him full credit for "useful". 3.5 out of four, nice work p&p.

Liveblogging p&p summit, day 1, intro & keynote

ZOMG it's Martin Fowler. Right now! I knew he'd be here, but, first! #fangrrrl

"We need to reduce our emphasis on quality so we can fit more features into the next release"? No, that's definitely never happened to me. Nope.

Attendance is way, way down compared to two years ago. Our own delegation this year is half the size (or smaller?) than ours then, and I'd really guess the overall crowd size is similarly proportioned. Which makes me wonder about last year (immediately mid-meltdown) when we couldn't attend at all. Don't know if it is valid to think of us as a bellwether.

Lord, this clacky Dell keyboard is already not making me any friends here.

Key concepts from the Martin Fowler leadoff keynote, part 1:

External quality, which is negotiable with the users/product owners (e.g., they get to prioritize bugs vs. new features), vs. internal quality (architecture), which really mustn't be.

Accidental complexity vs. essential complexity. Code debt!! Initial accidental complexity is the principal and working with the accidental complexity when implementing new features/changes is the interest. This impacts the effort required to do that new work. It isn't just "debt", it could be on the scale of a technical subprime mortgage. Not that I would know. Nope.

Debt planning (refer also to the debt payoff line graph):

Deliberate/prudent: "We must ship now and deal with the consequences"

Deliberate/reckless: "We don't have time for design"

Inadvertent/prudent: "Now we know how we should have done it"

Inadvertent/reckless: "What's layering?"

Event sourcing:

(This is relevant to my interests.)

We log all events in an insert-only store, and we trust our log, such that at any time we could rebuild the entire current application state (e.g., dB) by parsing the log. This also means we have a solid audit trail, and we could rebuild the entire historical state of the application (presumably someplace else) just by dialing back the date. Or diff two states. In other words, this stuff isn't just for version control systems any more.

Also useful for various other things which hopefully one of my colleagues took notes about. Oops. #shortattentionspan

OK, now there's a dude in front of me taking pictures of Martin Fowler. Unless he's part of Microsoft's PR division, that means I am not the only #fangrrrl in the room! I am sorely tempted to take a picture of him taking a picture.

Coffee time!

Feminist technology theory as it is realized in a Guitar Hero III Pro Face-Off

Big news first. There's a vendor booth here where they're running a contest: beat one of their employees at Guitar Hero III Pro Face-Off, win free software (developer tools). I was too chikin yesterday, but today I showed up determined to play. That's when I found out their real GHIII player had to go home, so other booth staff are subbing in for him. The new rules? "You pick the song, you pick the difficulty, but no Expert. And if it's an upper-tier Hard you're pretty much gonna win." Heck. If I'd've known that yesterday....

Anyway, I picked the hardest song I can beat on Hard: Stevie Ray Vaughan's "Pride and Joy". I knew I was in trouble when I didn't complete one single Star Power phrase in the entire song. Beat him anyway, with 80%, which isn't a score I'm happy with, but not bad for a Pro Face-Off in front of strangers with no warm-up. :)

When we were finished, someone from the little group of spectators called out to the booth staffer: "You got beat by a woman!"

Hmm.

Didn't like that.

I prolly should've challenged the heckler to a duel right then & there. You know, on all the afterschool specials they say even if you fail epically, you'll win their respect. I dunno. Not my style. Whatever.

I filled out all the paperwork for my free software, and got my photo taken for the booth's "Wall of Shame" screen saver, which I gotta go back and check out later. That's awesome.

As I walked away, another conference attendee walked alongside and complimented my performance. "You really pounded him! Nice job. Do you play at home with your kids?"

Wait. What?

Super nice guy. Paying me a compliment. Loved it. But I cannot imagine that the hundred developer dudes here who've beaten the booth staff at GHIII got asked if they learned to shred by playing with their kids. The guy before me who pwned him on Iron Maiden didn't get that question from anybody.

At lunch, K & I got talking about assumptions, and how initial assumptions are generally based on past experience, and hell, even I would have to assume that a random girl I meet, even here at TechEd, probably doesn't shred on Guitar Hero and probably doesn't aspire to be a software architect. Can I blame other people for basing their assumptions on what we all observe together as the most common realities? Certainly not.

In our most recent architecture session, I looked back through the roomful of ~300 attendees and saw that I was one of only two females in the entire room. That percentage of women who are here at TechEd at all (you know, the ones in the Women in Technology Luncheon I blew off yesterday), almost none of them are in the 400-level architecture track. I noticed this, and I was proud to be one of the only girls in the room. I have started to feel like the more profoundly outnumbered I am, the more likely I am to find the content rigorous and interesting... the more likely I am to be exactly where I want to be. And that was before Guitar Hero!

I'm very seriously really hoping I'm the only girl on the Wall of Shame screensaver and will be disappointed if I'm not. I'm sure a girl who plays GHIII is perfectly capable of beating the booth staff, but I don't expect the girls, even here, to be likely to play in the first place. Even I make that assumption.

So perhaps it isn't the assumptions that cause the problem... as long as you're open to being wrong, open to individuals being individuals.

"No, I don't have any kids." Random TechEd dude was perfectly delightful after that, rolled with the punches, kept up the conversation. Well done, random TechEd dude. It's true... I only look like a girl. I don't really talk or act like one. I like it that way.

But it isn't really enough to throw "girls" under the bus and argue that I only need concern myself with people's assumptions about me: "sure, girls are lame, but I'm an exception." Not cool.

"Beat by a woman" implies that the crowd expected me to suck... even after I finished playing. In their eyes, the fact that I won didn't prove anything good about me... only something bad about the guy I beat.

And that's why you TechEd dudes are not fully off the hook for how you think about us girls. Even if 95% of the females you've ever met or heard of don't show any interest in actual software development, even if they all end up on the BA or PM or UI tracks, even if they don't game, it doesn't mean girls are bad at the tough technical stuff. It just means they tend to be no-shows. You don't know why that is. You can't actually assume anything from that, and you shouldn't.

And that's why I have to keep being a girl here at TechEd. And that's why I, who am wearing a skirt today and everything, am gonna go see if I can beat that guy again. ;)

Update: it has been brought to my attention that kids, regardless of gender, are generally way better than adults, regardless of gender, at Guitar Hero. This is the sort of thing I would have been in a better position to have known if I had kids... and it is a worthy and valid point to consider. Perhaps developer dudes don't get asked about their kids because the answer ("my kids pwn me at Guitar Hero") is obvious. :)

Roller coaster

Been looking longingly at SeaWorld Orlando's Kraken coaster, which is clearly, hugely visible from the south windows of the Orange County Convention Center. $70 admission to ride one damn coaster. It mocks me, there on the skyline.

Here inside TechEd, session offerings are listed at three "levels": 200-Intermediate, 300-Advanced, and 400-Expert. When I sat down with K to plan our schedules, one of the first things he did was filter all the courses for "400-Expert" and pick from those. I was horrified, firmly believing that I had no business attending anything labelled "Expert" level.

Yeah. OK.

I accidentally went to a couple of 400-level sessions. They were amazing. Fast-paced, chock full o' useful information, learned tons, and got it.

Then I went to a couple of 300-level sessions. Slow. Kinda repetitive of stuff I already knew. Made me wish for more 400s.

WTF?

Either the "levels" are totally inflated, or, hmm, I'm kinda expert.

So who needs the Kraken when there are such wild roller coasters right there at TechEd?

Sketchy programming day

Conference presentation programming, not code programming. Well, maybe both.

I could tell I wasn't the only one who found this morning's offerings to be somewhat dissatisfying... I bailed out of two different classes, hoping to write code (DIY Hands-on Lab!), only to find the wireless network getting utterly hammered by other attendees having, perhaps, the same idea.

Dilemma of the day

The "Women in Technology" Luncheon conflicts with a lunch-hour session on C# lambda expressions.

So... do I choose to be a girl today, or a coder? Stay tuned.

Update: Even worse. The lambdas session was full, so I skipped both and wrote code. Wonder what that means.

Core competencies

Unfortunately for the health of this blog, the best lectures won't get the best blog posts because I'll be busy listening to them.

The Magic Seven core competencies for architects was, for me, greatly encouraging. (I'm trying to reassure K that the stuff I found exciting wasn't precisely the same stuff he objects to on principle.)

A lot of the Magic Seven, I already have.

I have at least a little bit of all of the different types of them.

Some of the things that separate architects from developers are the same sorts of things that cause me not to feel like a true developer sometimes. You mean there's a name for that?

Many of the competencies that I don't have, or need work in, I can think right now of very specific problems I'm having on my project that are caused or worsened by those very things (or the absence of them).

Finally, even supremely competent architects fail. In the middle of an ongoing epic fail, it's pretty much impossible to know whether the architect could have prevented the failure by successful deployment of core competencies, or whether the whole thing was doomed from the start, but one hopes to be able to learn something someday looking back. (Hopefully not looking back from the business end of an espresso machine, though.)

Friends don't let friends drink Kool-Aid

The thing is, software + services is almost certainly the right model for us (the place where I work) whether we "like" it or not. :)

And yes, a major draw of "cloud computing" was its Microsoft-killer potential.

But it's still funny-sad to see how hard Microsoft propagandizes for desktop client software plus services, pretending as though their very life didn't depend on it (and as if they weren't also scrambling to get cloudy just in case). "Software plus services! What a great idea! Oh, no reason."

Pre-conference seminar for Aspiring Architects

Turning software development into a true profession has been a wishlist item for years. If only we had a governing body, unity, standards, education and career paths to follow, networking, community, leverage. Some of my hotheaded friends even threw the word "union" around for a while. Now it's gotten even more specific: turning architecture into a true profession. In all the same ways. Which seems kinda odd considering the original software development profession thing hasn't been solved either. (At least, I don't think it has... hope I didn't miss a memo.)

Having said that, the presentation by the founder of the (non-profit) International Software Architects Association (IASA) was really interesting and useful. He's a good speaker, and he addressed so many of the things I struggle with... sure seems like I'm not the only one trying to get my brain around this.

"Architects are technology strategists." (I heard a lot of keyboarding in the room after he said that one, but I'm still contemplating what it means.) "The best developers don't always make the best architects," and vice versa. I do not think that actually means a bad developer can be a good architect, but it does seem to contradict the notion that an architect is someone who's been a developer for > n years for some employer-specific value n. Following that idea, "can architects be made?" From scratch? Is the architecture skill set a refinement of the developer set, or is it something else entirely? IASA guy says the latter. Interesting.

I'm glad for the focus on professionalism, rather than yet another list of articles and/or tools and/or frameworks... not necessarily because I think the pink-unicorn-dream of turning software into classical engineering or medicine or what have you is likely to happen, but because even short of a full-blown professional organization, talking about the professional issues seems to be the right path toward applying architectural ideas to real problems.

Who are you and what right do you have to call yourself an "architect"?
What do you need to know to be any good?
Once you learn that, what's next?
How do you get the support you need from your employer?
How do you get them to listen to you?
How do you prove your value to your employer?

P.S.: I had some doubts about whether Microsoft really was going to be totally on top of every single little detail at this conference. (TechEd veterans may point & laugh at the n00b now.) I needn't've worried. They've got it all covered. E.g., I guess OCCC doesn't necessarily have wireless coverage throughout the center, which seemed like a major oversight, but, duh, Microsoft brought in their own.

Resistance is futile: Microsoft TechEd NA 2008

"But this is Microsoft! Why wouldn't they have their pre-eminent developer conference of the year in Seattle?"

The fact that I've now seen two business-suited Orange County Convention Center staffers zip by on Segways suggests an answer to this question. OCCC is mind-bogglingly huge. The quantity and density of hotels in the immediate vicinity similarly challenges the imagination. And, finally, here in Orlando there's stuff to do. Hell, that's all Orlando is, is stuff to do. The whole thing definitely puts the Washington State Convention & Trade Center into perspective: a very tiny perspective.

I've only been here an hour, and I've already seen exponentially more females than I expected. I have a feeling this is not so much a measure of any different ratio than I expected, but rather of the huge size this conference is going to be.

I shall be trying to stay attentive to what they're teaching here, shying away from Kool-Aid but remaining open to actual knowledge. :) I shall also be trying not to fall apart from feeling way in over my head. Stay tuned.

We finally get an opportunity to learn VSTS....

... and it turns out I haven't bought my team the proper licenses. No hands-on for us!

I guess this is where all those VSTS planning meetings I skipped might have come in handy.

This is so going on my perf eval....

Update: Proper licenses (and my job) secured. Now get to work. :)

Introducing TDD to an existing codebase

When you find a bug, prove it's a bug by writing failing unit tests for it, then fix the bug. Now you've got unit tests around pre-existing code. Magic!

Windows Technology Frameworks (p&p, day 5)

The wrap-up.

When our speaker asks, "how many of you think this stuff is so complicated that you'll never be able to learn it all?" and all the hands go up, well, that's encouraging.

He likens the .NET Framework to shopping at Home Depot. We wander around from aisle to aisle, with some kind of broken home widget in our hands, desperately searching for something that resembles the widget, so we can zero in on a replacement for the widget, and if/when we get to the right item, we turn it over and the installation instructions make no sense.

"How many of you have looked up the documentation for the DoSomething() method and found that its sole contents are: 'Does something'?"

"ASP.NET: the most impressive kludge in the history of software development." A pretty reasonable attempt to layer a real programming language over browser-based development.

"If the root problem is complexity, EntLib is not the solution."

Agile, TDD, software factories, etc., touted as panaceas... really an attempt to spackle over the real problem, complexity. And now, we kick around a Peter-P-who-shall-not-be-named, for his pairing and TDD presentations at p&p last year (which, wow, I remember!)...

Pair programming had better produce twice the value of one programmer programming alone. We've talked about how hard it is to find good developers. If you put two bad programmers together, do they become > 2 good ones?

If TDD means you write 2 lines of test for every line of production code, then that prod code had better be three times better. (If not, you're just feeding a substance abuse problem.)

If everybody pairs, and everybody writes 2 lines of test per line of code, and every team has 2 testers per dev, the only possible conclusion is that we suck. (Our ratio of testers to developers causes #DIV/0!, so don't assume the converse.)

Fueled by iPods, "people are waking up to the idea that simplicity has value and complexity has cost."

Simplicity Manifesto v1.0

• Stop adding features
• Make help helpful
• Fix the bugs
• CRUD for free
• Hide the plumbing
• Get better names

"HTML: the COBOL of the internet"... we've pushed it way, way beyond what it was envisioned to do.

"Treat simplicity as a feature" and demand simplicity in tools, too.

Boldly go, y'all.

< 10 of these things are not like the others (p&p, day 5)

The speaker this morning told a funny story about women.

He didn't say anything offensive about women, particularly.

I'm not going to belabor this. But it made me feel several inches tall, and I didn't hear a damn other word he talked about during his hour.

Update: on the bright side...

5 of the aforementioned < 10 are from UW. That's both a good thing, for me, and an even more disproportionate thing for the rest of the world.

It occurs to me that UW is a spectacularly good place for women in IT to work, as evidenced by the fact that we just don't do that. That's why hearing it here was like being ambushed by a grotesque. This fact could be a powerful recruiting tool if I could figure out how to wield it.

Change the world and/or go home (p&p, day 5)

First half hour of keynote: more Scott H hilarity, lots of LOLcats, a nice wrap-up, like an Episcopal benediction and dismissal, but for geeks. "Be well, write good code, and stay in touch." Thanks be to [insert your Microsoft joke here]!

Second half hour of keynote: more MVC Framework demos by popular demand.

Yesterday was exceptionally difficult and depressing for me (capped off with a miserable 90-minute commute home), so this is just the right mood enhancer at just the right time. Not just the comedy and the great stock photo usage, but also that Scott H explains complicated things pretty accessibly.

More musings on learning styles... I tend to tune out when I can't "contextualize", i.e., figure out how the demoed tech relates to anything I'm doing now (or have done before). The problem is, if I haven't paid attention, how'm I going to recognize an opportunity to apply new tech in the future? We already know the answer to that.

Push learning is going to work better than pull. If I load up on stuff I don't understand now, I'll have a better chance of wiring it together someday when a context presents itself. This is a lot better than flailing around for a solution when I get stuck later, especially because most of the time I won't be "stuck", I'll be writing code that works, but is crap, because I don't know any better.

The benefits of showing up and paying attention: John Lam has just shipped LOLCODE on the DLR and is coming down to the podium to demo it. Now that's something that might really come in handy someday.

WCSF (p&p, day 4)

Web development paradigms

• Content sites (e.g., news)
  
• Transactional sites (e.g., stores, banks)
  
• Collaboration sites (e.g., wikis, workflows)
  

Demo, helpfully, to focus on transactional sites

WCSF facilitates...

Separation of UI development & UI design!

Richness, experience, navigation

Security, manageability, testing

Separation of responsibilities very easily, very clearly... deploy without affecting other subteams (ahem).

I guess the thing I find most challenging about "Factories" day is that demos like these, for me, are just teasers. They either get me thinking, "hey, that'd be fun to play around with" and/or "hey, that sample problem resembles a problem I recognize", or they don't. I think to do this, they have to show a variety of things in modest depth, but the depth itself ends up being lost on me, and that makes for long hours of struggling to pay meaningful attention.

I suspect some "homework" on my part would help with this... if I were to keep current on p&p, or at least brush up on the latest initiatives before heading off to the summit, I'd probably have enough of a basis in the technologies to have formed specific interests and questions. To that end, I've subscribed to about 15 different blogs today. Will the momentum carry through to 2008? Tune in!

MVC (p&p, day 4)

Scott H reaffirms that stand-up comedy skillz are at least as valuable as a liberal arts education, in any industry [see also: Mark Driscoll].

MVC Goodness!!1!

• Separation of concerns
• Red/green testability
• Extensible/pluggable
• Clean URLs, clean HTML
• Great integration within ASP.NET

Don't Panic (or perhaps the Kool-Aid)

• Not Web Forms 4.0; about more choices
• As simple or as complex as you wish
• Fundamental in System.Web
• Plays well with others

"Where does the file live?" It doesn't really exist. The URL/I doesn't point to a physical location.

Everybody wants a friendly, hackable URL/I. It's a user-interface point now.

And now, code.

"IM IN UR NORTHWIND"

Just like yesterday, I think watching and listening to a code presentation that I barely understand, or don't understand at all, is improving my skills by osmosis. Better than a book. Every once in a while, I see a problem I recognize from having solved it (poorly) once before...

He keeps coming back to the clean/intuitive URL/I thing, but that's a problem I can totally relate to!

"The problem with XML is not that it's human-readable, but that it's manager-readable."

Holy cow, it's an MVC gradient graphic generator. My head might explode.

This was awesome! What a great start to a probably otherwise challenging day!

Can I choose 'none of the above'? (p&p, day 3)

Face-off on the future of patterns, featuring, for reasons which never really became clear, suction-cup-dart guns.

Should patterns be disseminated as a new online share/wiki/repository and in books? I.e., descriptively?

OR

Should patterns be built into tools and libraries and provided? I.e., some other adverb?

In some ways it took on the characteristics of a negative political campaign, with both sides explaining each other's shortcomings, and had the same effect on me as it does on voters, which was to depress turnout. :P

For me to be able to use patterns, I need to learn them as a vocabulary and understand them intuitively. Patterns aren't imposed, anyway, they emerge from good coding practices and become named as a means of communicating about them. (I learned that several trainings ago, along with lots of other things I can't actually implement.)

Back on day 1, one of the speakers captured the answer here already. Patterns aren't magic, they're just a language that allows architects to talk to each other and to coders about what should be built and how.

I don't learn well by reading. I wouldn't use books. I don't have anything to contribute to a wiki. They are right that nobody would want to sit down and document the pattern anyway, we have work to do.

But, tools without understanding are like... FrontPage­. Pretty much exactly like FrontPage­.

I learn by doing, and I learn by surrounding myself with people smarter than me (about the topic in question, eh!). Any pattern I've ever heard of, I learned by someone near me talking about it whilst I smiled, nodded, and covertly Googled­. It works!

Aha! And the reason it works is that I learn the pattern in context. I'm not just figuring out what the pattern is, I'm trying to figure out WTF my friend and/or colleague is talking about, which is probably an application of a pattern, and when I figure it out, I have learnt both. I will remember it, and I'll be better equipped to apply it somewhere else later (in theory).

OK, Google­ usually points me to Wikipedia, and somebody had to have written that, and I do then assimilate it by reading it. But I'd be very unlikely to go there, or anywhere else, and browse patterns for the sake of patterns, so discussing the future without a context just isn't that helpful to me (see also: years of unapplied trainings).

The mechanism doesn't matter. It's about the understanding. The right community doesn't even have to try, they just have to be smart about patterns in proximity to each other.

Get me my suction-cup-dart gun.